Snowplow Obj-C Tracker 1.1.0 released


We are pleased to announce a new release of the Snowplow Obj-C Tracker.

Version 1.1.0 introduces new tracking features including new screen view events and screen entities (with the option to enable automatic tracking), and automatically tracked install and crash events.

With these new features, Snowplow users can set up comprehensive tracking much faster enabling users to get started with mobile tracking in Snowplow quickly and easily.

Read on below the fold for:

  1. Screen tracking
  2. Crash tracking
  3. Install tracking
  4. Updates
  5. Documentation
  6. Getting help

1. Screen tracking

With this release we updated our approach to screen view tracking with the introduction of screen contexts and automatic screen view tracking.

1.1 Updated screen view event with new data points

Previously the trackScreenView method took up to two arguments with each screen view: a name and an id:

SPScreenView *event = [SPScreenView build:^(id<SPScreenViewBuilder> builder) { [builder setName:@"HUD > Save Game"<span class="p">]; [builder setId:@"screen23"<span class="p">]; <span class="p">}]; [tracker_ trackScreenViewEvent:event<span class="p">];

The new version of the method takes takes an additional, optional “type” argument, “transitionType” and optional arguments for the previous screenview:

SPScreenView *event = [SPScreenView build:^(id<SPScreenViewBuilder> builder) { [builder setName:@"Home screen"<span class="p">]; [builder setType:@"Navigation bar"<span class="p">]; [builder setScreenId:@"some Id"] [builder setPreviousScreenName:@"Info screen"<span class="p">]; [builder setPreviousScreenType:@"Navigation bar"<span class="p">]; [builder setPreviousScreenId:@"another Id"] [builder setTransitionType:@"swipe"] <span class="p">}]; [tracker trackScreenViewEvent:event<span class="p">];

In addition, the “ID” field is automatically set by the tracking SDK and used in the screen context. The previous screen view ID, type and name are automatically recorded by the SDK with the event, making it easier to understand how individual users navigate through the app.

The fields recorded with each screen view event can be viewed here.

1.2 Introducing the screen context

The screen context is an additional context that describes the screen on which an event is sent, that can automatically be sent with every event recorded from the tracker. To enable this feature, set the context in the tracker build block:

SPTracker *tracker = [SPTracker build:^(id<SPTrackerBuilder> builder) { [builder setEmitter:emitter<span class="p">]; [builder setScreenContext:YES<span class="p">]; <span class="p">}];

The screen context is then attached to every event recorded from the app, based on the screen view events that have been fired.

This makes it significantly easier when modelling the data generated by the SDK to aggregate all the events that occurred on a particular screen based on the screen view ID sent with both the screen view event and each screen context. Previously, in order to identify what screen an event occurred on, a window function would have been required to identify the most recent previous screen view event for that particular user ID.

1.3 Automatic screen view tracking

The new version of the tracker supports automatic screen view tracking. This makes it significantly faster for companies getting started implementing the tracker.

Enabling automatic screen view tracking is very simple:

SPTracker *tracker = [SPTracker build:^(id<SPTrackerBuilder> builder) { ... [builder
 setScreenViewEvents:YES<span class="p">]; [builder setScreenContext:YES<span class="p">]; <span class="p">}];

Screen view events and screen contexts are then automatically tracked and populated.

2. Crash tracking

Automatic crash tracking has been added to the new tracker version. This means an application_error event is recorded whenever the app crashes: providing valuable data about when an app has crashed, and enabling analysis to identify if particular parts of the app, app versions, hardware versions or user actions are more likely to cause the app to crash so issues can be proactively spotted, diagnosed and addressed.

Automatic crash tracking is enabled as follows:

SPTracker *tracker = [SPTracker build:^(id<SPTrackerBuilder> builder) { ... [builder setExceptionEvents:YES<span class="p">]; <span class="p">}];

3. Automatic application installation tracking

The automatic install tracking feature makes measuring app installations over time more straight-forward so your team can conveniently build reports related to app downloads.

Set the following option to automatically track app installation events:

SPTracker *tracker = [SPTracker build:^(id<SPTrackerBuilder> builder) { ... [builder setInstallEvents:YES<span class="p">]; <span class="p">}];

4. Updates

Other updates and fixes include:

  • Allow configurable postPath parameter (#409)
  • Fix various build warnings (#414)
  • Fix warning about self references being retained in SPSession (#412)
  • Add tests for application context (#410)

5. Documentation

As always, information about how to use the tracker can be found in the Obj-C Tracker documentation.

You can find the full release notes on GitHub as Snowplow Obj-C Tracker v1.1.0 release.

6. Getting help

For help on 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 Obj-C Tracker’s issues on GitHub.

For more details on this release, please check out the release notes on GitHub.