We utilize the iOS and Android Snowplow SDKs in our native applications. Presently, we initialize the Snowplow tracker asynchronously to prevent the app start from being blocked by analytics. However, this can lead to the loss of screen view events if the tracker takes too long to start and initialize. Do the iOS and Android Snowplow SDKs offer a solution to buffer these events until the tracker is ready? What is the recommended approach to avoid losing events without blocking the entire app initialization?
Both the iOS and Android trackers buffer events before sending and process events asynchronously. On iOS, we have much improved the performance and moved event processing to a background thread in the recently released version 6.
When an event is tracked, it is processed on a background thread. After it is processed, it is then stored in a SQLite event store. From the event store, the events are sent in batches (by default the batch size is 1, so events are sent right after being tracked, but this is configurable). You can also pause emitting events while the app is initialized and resume it when you want to allow the tracker to make requests.
You can read about the buffering options here. To pause sending events, use the pause() function on the EmitterController (iOS API docs here) – you would call something like Snowplow.defaultTracker().emitter.pause().
We do not have an option to delay processing events – some attributes of the events such as the timestamps, screen information, screen engagement metrics are assigned during their processing so delaying that would skew this information. However, event processing should not block the app initialization as it happens on background threads (on iOS starting with version 6 of the tracker).