How the SDK works

The way our SDK works is by auto-starting with the application launch and attaching to the current process in order to intercept the events and gestures we are interested in.

See Session Replay Initialization to learn how Session Replay is initialized.

Once started, our SDK fetches its configuration from our servers.
Then, depending on the segmentation size (defined by our team when you sign a contract) and the user consent status, it will start collecting analytics data from system and user events it detects from the runtime.

The SDK monitors the application lifecycle events, the view hierarchy, and generates data from the behavior of the app, the content of the screen and the user interactions.
These events are then locally stored, and eventually sent to our servers in batches. We then aggregate that data to create usable visual information into our Web Application, which you use to gather insights.

See Session Replay Initialization to learn how Session Replay data collection works.

Analytics data are sent in batches of maximum 50 events. Requests are triggered when network conditions allow for the server to be reached and:

• The current batch of events has reached 50
• Or the app is put in background

Our requests use lowPriority ↗.

See Session Replay Requests to learn more about how Session Replay data is sent.

See Send Crash data to learn more about how crash data is sent.

A session represents a single period of user interaction in the app. In Contentsquare, the SDK marks the start of a session when an app start or app show event is first detected.

A session ends when the time spent outside the app reaches 30 minutes. This is the default value which be changed upon request.

If the app is put in the background or killed (intentionally by the user or by the OS) and the user comes back within the next 30 minutes, subsequent events are considered part of the same session.