The Ins & Outs of Mobile App Call Types

http://blogs.adobe.com/digitalmarketing/wp-content/uploads/2013/08/hero-image3.png
As a Consultant I often review mobile app analytic implementations of Adobe’s customers. Often I find that what was implemented and the subsequent data being collected is different than what was expected. In particular, this is evident for what should (or should not) be considered an app screen view (aka page view). For example, one app that I reviewed had an astronomical number of screen views within SiteCatalyst for an average number of unique visitors. It turned out that every interaction point that was instrumented within the app (e.g. button-clicks, scrolls to end-of-page, pinch-to-zoom) were all being counted as screen views. As a point of emphasis, micro-level app activity should never be considered a screen view. The purpose of this blog post is to clarify the difference between the call type that counts as a screen view and the call type which does not. We will also look at the app methods which support these different call types and how to validate between the two.

Know Thy Call Type
Within SiteCatalyst there are two fundamental calls types which contain all submitted data. A track call is counted as a screen view, and should be used when a new screen has been presented or when the majority of the screen has significantly changed. A trackLink call should be used for all other situations in which you are wanting to measure a user’s interactions.

As a side note, within SiteCatlyst you won’t’ find a “screen view” metric ‐ you will only find “page view” metrics. The reason we are calling page views as screen views is app developers are more familiar with the concept of screen views. Either way, the underlying data and what it should represent is the same.

Call Types of App Methods
Now that you know the difference between these two call types, how do you use them within the app measurement libraries? The easiest way to show which app methods align to which call type is to look at the chart below.

Call Type Comparison Table http://blogs.adobe.com/digitalmarketing/wp-content/uploads/2013/08/comparison_chart_new.png

The difference between the “Simple” and “Advanced” methods is the scope of what data you can send in within each call. For example, trackCustomAppState allows you to send in a pageName and contextData as a Track call. Whereas trackWithContextData (iOS) allows both ContextData and explicitly set Custom Variables to be sent at the same time as a Track call. For more details on these and other methods, see the iOS and Android documentation. Below are “Advanced” code examples for iOS and Android.

iOS Code Example

Validation
As with any implementation, validation is vital to know if reality is in alignment with your expectations. Sometimes validation can become onerous and time consuming; however, it’s fortunately quite easy to do when differentiating between track and trackLink calls. Simply, if the pev2 variable is found within the call, it’s a trackLink call. If it’s not there, then it’s a track call. To make it easier to remember, here’s a saying: pev2 means no screen view for you. As an important point of clarity, don’t assume because the pageName variable is present that it has to be a track call. Often you will find the pageName variable present within trackLink calls even though it won’t appear within SiteCatalyst reporting. Below are validation examples of track and trackLink calls along with an updated Call Type Comparison Chart which now includes validation.

Validation Examples

http://blogs.adobe.com/digitalmarketing/wp-content/uploads/2013/08/comparison_chart_2_new.png

Now that you know the fundamentals of track and trackLink calls and how to implement them within the Adobe’s mobile app measurement libraries, never again will you need to second guess the accuracy of the screen view metrics within SiteCatalyst reporting.

Update (Nov 19, 2013): This post has been updated to include method calls from the 4.x SDK which was released after this post was first published.