While those two are fairly similar, there are some differences that you need to keep in mind.
Online and Offline
The biggest difference is probably that an app can work even if the mobile device has no network connection. Most apps are built so they can work “alone”. In fact, this very ability is what makes apps so attractive.
You can still track what users are doing in the app even when the network is unavailable.
The Mobile SDKs for the current mobile ecosystems all have buffering built-in.
When an app cannot find network connectivity, the library will simply buffer the tracking calls and send them off once network is back.
s_vi. This cookie contains a random visitor ID.
The system uses the visitor ID from the cookie to tie together activities by a single visitor across time. It allows the system to determine activities within a visit and attribute things people do to other things people do later. This is what allows your friendly marketer to track email campaigns for example.
Unfortunately, some browsers do not accept 3rd-party cookies. In those cases, the code (H.25.4 and later) will set a cookie called
s_fid and put a different, random visitor ID into it. If there is no
s_vi but an
s_fid cookie, the system will use the latter.
Other browsers are set not to accept cookies at all. In those cases, the system will use the
HTTP User-Agent field along with the IP address to calculate a visitor ID.
You can imagine that the whole visitor ID thing is not as accurate as most marketers would like it to be. But that’s just the reality of current technology.
The good news: for mobile apps, there is only one mechanism and it is pretty accurate.
When a tracked mobile app is installed on a device for the first time, the library generates a random visitor ID and saves it with the app data. If the app is updated, the visitor ID persists. Only when the app is deleted will the visitor ID be deleted as well.
So on mobile apps, visitor IDs are very stable and your friendly marketer can therefor really analyse user behaviour over time.
When a browser loads a page or when a user clicks something, we can easily add tracking. But what about a user leaving a page or closing down their browser?
Apps are different.
As we said in App Tracking – Part II, you can track the
onPause() callback on Android (or the equivalent on iOS and other systems). Because apps are programs, you can be sure these callbacks will be called! Unless the device crashes, the system will always call
onPause() when an Activity closes.
Why does that matter?
Measuring time will be more accurate. Instead of relying on a time out for seeing when a visit ends, the app “knows” when it is done.
The same applies when you compare someone walking away from their browser versus someone putting away their phone: the browser on a desktop computer has no idea whether the user is currently looking at it. But on a phone, when you put it away or it goes to sleep, the Activity or View will be put into the background.
The result is that your marketer can get pretty good “engagement” metrics from an app.
With the exception of Android (see App Tracking – Part II), most mobile eco systems lack end-to-end tracking capabilites.
Your friendly marketer spends budget on a couple of things, one being acquisition of visitors, basically getting people to your site or app.
They want to use analytics to see whether they spend the right amount in the right places or whether they should change their strategy or channel distribution. For a marketer, this is very important!
So they tag up all URLs that they send out, be it to web sites, specific landing pages or even app downloads.
Apps, however, are different. Currently only Google Play passes URL parameters all the way through to the app so they can be grabbed, tracked and reported against. For all other systems, this end-to-end capability simply doesn’t exist.
Here’s hoping that the other vendors will follow Google.
Remember: this method is called every time a tracking call is generated.
The Mobile SDKs do not have that sort of mechanism, but you can build it yourself fairly easily.
If you are following best practice, you’ll be using the
TrackingHelper class a lot. You’ll be adding custom static tracking methods for most of the Activities or Views in your app and you’ll rarely call low-level tracking functions anywhere else in your code.
That means you can build your own doPlugins function and plugins fairly easily within the
I recommend you do that.
When something goes wrong with the tracking on a web site, or when you simply want to change the tags, you can push a change live either via the
s_code.js file or to the actual pages (or templates) that make up your site.
As soon as you do that (and the various caches you might use have expired and are passing through the new version) everybody is tracked according to the new configuration.
In general, every change that you roll out on a site applies to everybody immediately.
Not so with apps!
You can put a new version onto the App Store or Google Play, but noone forces users to get that update. At least not yet.
The result is that every change you make to tracking has to take into account backwards compatibility.
No changing of events for the fun of it. No reassigning of eVars. Once you use a “variable” for something, you’re tied in.
Unless you are using Context Data Variables and Processing Rules, of course. If you tag a mobile app, you should use Context Data Variables if only for this reason! No excuses!
Can you think of any other differences?