Collected data points

A newer version of this documentation is available. Switch to the latest version docs.
  • 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).

Each 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:

{
pid:8, // int - ProjectId - represented in the mobile config format
uid:"ac1529a7-59f6-49d9-b254-6f0a22f57284", // String - uuid Unique user ID
dt:4, // int - device type (loosely enforced enum - [sdk-phone : 4, sdk-tablet :5])
dma:"Samsung", // String - device manufacturer. This property is optional and if by any chance the device model cannot be determined it will be dropped from the Json object.
dmo:"SG", // String - device model. This property is optional and if by any chance the device model cannot be determined it will be dropped from the Json object.
os:"10.0", // String - os version (Android version name 8.0, 9.0, 10.0)
l:"en_US", // String - Language in iso-639 format https://www.ibabbleon.com/iOS-Language-Codes-ISO-639.html
tz:"Europe/Paris", // String - timezone https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
now:1522159618000, // long - timestamp when the batch was sent
to:{ // object - type origin of the event
an:"appname" // String - application name
st:"sdk-android", // String - type of sdk
sf:"release", // string - sdk flavor/variant [release/debug/god]
},
r:{ // Device - resolution.
w:1080, // int - width
h:1920 // int - height
d: 1.5 // The device density as float. Its values can vary between (0.75 and 10)
},
pl:[] // JSON array payload - list of event objects, see below
}

All 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.

{
upt:1522, // long - system update in milliseconds
euid:"euid", // String - event UUID
url:"app-and://identifier/mainPath/secondaryPath?title=screeName", // String - screenName is passed in the title query Parameter
scn:4, // int - the number of screens already shown in the session
c:3, // int - connectivity type [-1 - offline, 0 - error, 1 - wifi, 2 - 2g, 3 - 3g, 4 - 4g]
ci:"verizon", // String - carrier_id when user is on mobile network
o:1, // int - orientation [0 = portrait, 1 = landscape]
vo:{ // object - version origin of the event
sv:"2.1", // string version of the sdk
sb:4, // int - sdk build number
av:"appVersion", // String - application version
af:"appFlavor" // String - application string - [release/debug/god]
ab:1 // int - application build number
},
sn:1, // int - session id (positive int)
t:12894726459435 // long - timestamp of the event (in milliseconds)
}

All event specific properties are appended to this JSON object.

This 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.

ea:0 // int - event action - defined above

This 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.

ea:1 // int - event action - defined above

This 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.

ea:2 // int - event action - defined above

Everything 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.

ea:4 // int - event action - defined above
st:"title", // String - screen title
sl:34543 // int - (load time) screen load time (diff between last action and this event)

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
ea:6 // int - event action - defined above
tvp:"[root]>view#id>view2>", // String - target view path
tvid:"btn_ok", // String - target view id
ur: true, // boolean - was this a "responsive" touch event (the target view had a handler)

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
  • Duration: > 500ms
  • Distance: < 24 dp
ea:8 // int - event action - defined above
tvp:"[root]>view#id>view2>", // String - target view path
tvid:"btn_ok", // String - target view id

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
ea:9 // int - event action - defined above
tvp:"[root]>view#id>view2>", // String - target view path
tvid:"btn_ok", // String - target view id
fd: 3, // int - finger direction - [1,2,3,4,5] -> [up, down, left, right, complex_pattern]
tvd:100, // int - target view distance dragged
tvv:100 // int - target view velocity while dragging dp/s

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
ea:10 // int - event action - defined above
tvp:"[root]>view#id>view2>", // String - target view graph path
tvid:"btn_ok", // String - target view id
fd: 3, // int - finger direction - [1,2,3,4,5] -> [up, down, left, right, complex_pattern]
tvd:100, // int - target view distance scrolled
tvv:100 // int - target view velocity while scrolling dp/s

To track transactions we provide a public API which can send a transaction object (see section Track Transactions). This object must contain the following parameters:

ea:16, // int - event action - defined above
tr:{ // a json object with different properties defining the transaction made
vl: 20.0, // mandatory - float - the value of the transaction
cu: 978, // mandatory - int - the ISO 4217 code of the currency of the transaction
id: "32akjkljklJ575775" // optional - string - an id for the transaction
}

To track dynamic variables we provide a public API (see Dynamic variables).

Event with a string value
ea:18, // int - event action - defined above
k:"key", // String - Custom key assigned by client.
v:"value" // String - Custom value assigned by client.
Event with a number value
ea:19, // int - event action - defined above
k:"key", // String - Custom key assigned by client.
v: 2344 // Integer - Custom value assigned by client.

In 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:

  1. accessibilityIdentifier
  2. restorationIdentifier
  3. tag

if the view has accessibilityIdentifier it uses it as first priority and provides a short reliable target.

Example:

/*
[SalesViewController]
ViewOne
|
viewTwo
/ | \
viewThree viewFour viewFive
*/
let viewOne = UIView()
viewOne.accessibilityIdentifier = "rootView"
let viewTwo = UIView()
viewTwo.restorationIdentifier = "dichotomy"
let viewThree = UIButton()
viewThree.accessibilityIdentifier = "on_sale"
let viewFour = UIButton()
viewFour.accessibilityIdentifier = "new_arrivals"
let viewFive = UIButton()
viewFive.accessibilityIdentifier = "for_kids"
viewTwo.addSubview(viewThree)
viewTwo.addSubview(viewFour)
viewTwo.addSubview(viewFive)
viewOne.addSubview(viewTwo)
// viewThree target would be: UIButton[ai:SalesViewController.on_sale]
// viewFour target would be: UIButton[ai:SalesViewController.new_arrivals]
// We change the view hierachy
viewThree.removeFromSuperview()
viewFour.addSubview(viewThree)
// viewThree target would be: UIButton[ai:SalesViewController.on_sale]
// viewFour target would be: UIButton[ai:SalesViewController.new_arrivals]

If the view has restorationIdentifier and no accessibilityIdentifier then it provides a long reliable target.

/*
[SalesViewController]
ViewOne
/
viewTwo
/ \
viewThree viewFour
*/
let viewOne = UIView()
viewOne.restorationIdentifier = "trichotomy"
let viewTwo = UIView()
viewTwo.restorationIdentifier = "dichotomy"
let viewThree = UIView()
let viewFour = UIView()
viewTwo.addSubview(viewThree)
viewTwo.addSubview(viewFour)
viewOne.addSubview(viewTwo)
// viewThree target would be: [root]>UIView[ri:SalesViewController.trichotomy]>UIView[ri:SalesViewController.dichotomy]>UIView:eq(0)
// viewFour target would be: [root]>UIView[ri:SalesViewController.trichotomy]>UIView[ri:SalesViewController.dichotomy]>UIView:eq(1)

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)