We are pleased to announce the release of our mobile trackers: Snowplow iOS Tracker and Android Tracker version 4.0. The headlining features of this release are the support for hybrid mobile apps and anonymous tracking. These features were requested by the Snowplow community and we are excited to bring them to the mobile trackers!
The release brings various other improvements both in the tracker as well as the documentation. Read on to learn about:
Hybrid mobile apps
The new Snowplow WebView tracker is a library that can be installed in Web apps used in embedded Web views. It can communicate with the iOS and Android trackers and pass any tracked events to them. In turn, the iOS and Android trackers can track the events as if they originated in the native code with the same session and platform context entities as other events. The following diagram illustrates the interaction of the WebView and iOS/Android trackers in a hybrid app.
In order to set up the communication between the WebView and native trackers, one has to subscribe the native trackers to messages from the Web view:
Snowplow.subscribeToWebViewEvents(webView). Subsequently, it will be possible to track events from the Web view app using the WebView tracker API. To learn more about setting up tracking in a hybrid app, follow the accelerator guide here.
The affected user and session identifiers are stored in two context entities: Session and Platform context. Concretely, the following user and session identifiers can be anonymised:
- Client-side user identifiers: the
userIdin Session context entity and the IDFA identifiers (
appleIdfv) in the Platform context entity.
- Client-side session identifiers:
sessionIdin Session context.
- Server-side user identifiers:
There are several levels to the anonymisation depending on which of the three categories are affected:
1. Full client-side anonymisation
In this case, we want to anonymise both the client-side user identifiers as well as the client-side session identifiers. This means disabling the Session context altogether and enabling user anonymisation:
let config =TrackerConfiguration() .sessionContext(false) // Session context entity won't be added to events .userAnonymisation(true) // User identifiers in Platform context (IDFA and IDFV) will be anonymised
2. Client-side anonymisation with session tracking
This setting disables client-side user identifiers are but tracks session information. In practice, this means that events track the Session context entity but the
userId property is a null UUID. In case Platform context is enabled, the IDFA identifiers will not be present.
let config =TrackerConfiguration() .sessionContext(true) // Session context is tracked with the session ID .userAnonymisation(true) // User identifiers in Session and Platform context are anonymised
3. Server-side anonymisation
Server-side anonymisation affects user identifiers set server-side. In particular, these are the
network_userid property set in server-side cookie and the user IP address. You can anonymise the properties using the
serverAnonymisation flag in
let config =EmitterConfiguration() .serverAnonymisation(true)
Setting the flag will add a
SP-Anonymous HTTP header to requests sent to the Snowplow collector. The Snowplow pipeline will take care of anonymising the identifiers.
You can find more information about anonymous tracking in the mobile tracker documentation.
Other tracker improvements
There are several other noteworthy changes in this release. Concretely, the remote configuration now supports switching between multiple endpoints. This lets you have multiple sources of remote configuration and switch between them in your app. Additionally, it gives feedback of where the configuration was retrieved from. You can set a callback function that is now passed this information using the
ConfigurationState enum that can indicate whether the configuration was read from cache, using default values or fetched from the remote endpoint over network. Learn more about remote configuration here.
Another welcome feature is that the the
tracker.track(event) function now returns the tracked event ID. Having the event identifier can help referencing the tracked events in other data.
Finally, thanks to an external contribution from @onato, the iOS tracker can now be utilized in share extensions of iOS apps.
We are very excited to announce major improvements to the documentation that now gives more guidance on how to make use of all the tracker features! We hope that this will improve the developer experience of instrumenting tracking in mobile apps.
For help integrating the tracker please have a look at the setup guide. If you have any questions or run into any problems, please visit our Discourse forum. Please raise any bugs in the iOS Tracker’s issues or Android Tracker’s issues on GitHub.