Collected data points
- The events are in JSON format, which lists the properties and their description in comment.
- Events are sent to the server in batches.
- A batch is a subset of events originating from one session. A session can send events in more than one batch.
- The batch size is defined in a run configuration file specific to each app (50 events by default).
Requests meta data
Section titled Requests meta dataEach batch has a common header, a set of device specific, and repeatable information and an array of events, which is immutable. The header is composed at the moment of sending, so it has to be constant info ONLY. The array in the payload is data stored at the moment of collection.
The structure of the batches of events will have the following format:
Events
Section titled EventsEvents meta data
Section titled Events meta dataAll events have a common first part (don’t confuse it with the header explained above). This common section is data which is common for all events by type but is gathered at the moment the event occurred. This common section is a part of the actual event payload.
All event specific properties are appended to this JSON object.
App Start
Section titled App StartThis event describes the absolute start of the app.
The trigger for this event is the absolute start of the app.
This is the first event sent when the SDK is invoked.
App Show
Section titled App ShowThis event is sent when the user brings the app in the foreground (switching from another app, exiting lock screen, etc.). This event means the app is focused.
App Hide
Section titled App HideThis event is sent when the user exit (minimizes) the app, or switches to something else. This event means the app is not focused and the session might end, but we have not completely ended the session yet, as the user might return.
Screenview
Section titled ScreenviewEverything starts with a View event. This is an event which describes the equivalent of a “page view” in the web. This event is sent when the Track Screen API is called.
cv
node is about Custom Variables being additional information on the screen, the user or the session, sent within a screenview.
They generally include datalayer information, such as: Screen type, Product category, if the user is signed in or not, the number of items in the cart…
This information enables user segmentation or screen grouping.
Custom variable is composed of three parts:
- An index: A unique integer to identify the custom variable across the app.
- A name: A description of what you want to track. Use the same name to identify occurrences of a same var.
- A value: A string describing the payload of the custom variable.
Custom variables number is limited to 20 by screen and cv
node won’t be present if nothing has been declared by the client.
Single Finger gesture event, when the user is interacting with a loaded screen. This is an event which describes the equivalent of a “click” in the web. This event is defined by the following sequence of touch events:
- Touch Down -> N x Touch Move -> Touch Up
Long press
Section titled Long pressSingle Finger gesture event, when the user is interacting with a loaded screen.
This event is defined by the following sequence of touch events:
- Touch Down → N x Touch Move → Touch Up
- Duration: > 500ms
- Distance: < 24 dp
Drag (Slow Swipe)
Section titled Drag (Slow Swipe)Single Finger gesture event, when the user is interacting with a loaded screen.
This event is defined by the following sequence of touch events:
- Touch Down → N x Touch Move → Touch Up
- Distance: > 48 dp
- Finger Velocity < 100 dp/s
Flick (Fast Swipe)
Section titled Flick (Fast Swipe)Single Finger gesture event, when the user is interacting with a loaded screen.
This event is defined by the following sequence of touch events:
- Touch Down → N x Touch Move → Touch Up
- Distance: > 48 dp
- Finger Velocity > 100 dp/s
Transaction
Section titled TransactionTo track transactions we provide a public API which can send a transaction object (see section Track Transactions). This object must contain the following parameters:
Dynamic variables
Section titled Dynamic variablesTo track dynamic variables we provide a public API (see section Dynamic variables).
Reliable targets
Section titled Reliable targetsIn the Zoning Analysis module, reliable targets are assigned to zones to ensure that a UIView
remains accessible in the view hierarchy, even if it has been moved within the same page.
Having a reliable target for a view or a container of views enables the analysis of data across various Snapshots from different dates and versions, including layouts or different A/B testing variations.
One of the following properties must assigned for a view to have a reliable target.
Our SDK will check the properties in this order:
accessibility Identifier
Section titled accessibility Identifierif the view has accessibilityIdentifier
it uses it as first priority and provides a short reliable target.
Example:
restoration Identifier
Section titled restoration Identifierif the view has restorationIdentifier
and no accessibilityIdentifier
then it provides a long reliable target.
If the view has no accessibilityIdentifier
and no restorationIdentifier
then our SDK will use the tag
that has been set, and will provide a long reliable target as well.
tag yields the same identifiers as accessibility with a different tag
ex: [root]>UIView[tg:444]>UIView[tg:223]>UIView:eq(1)