Tracking Apps vs Web Pages

Today we’ll focus on the differences between tagging a web page (see Basic Tracking) and tagging an app (see Tracking Mobile Apps).

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.

If you’re using Javascript-based tracking on a normal web page, you simply can’t do that. (Well… you could in theory use HTML5 local storage, but let’s not go there.)

Visitor IDs

When a person first visits one of your web sites, the Javascript-based tracking code tries to set a cookie on their browser called 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.

Pretty important.

Unfortunately, some browsers do not accept 3^rd-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.

Leaving Pages

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?

Currently there is no reliable way to track that with Javascript.

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.

End-to-End Tracking

With the exception of Android (see App Tracking – Part II), most mobile eco systems lack end-to-end tracking capabilites.

What?

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.

On web sites, you can very easily track this, see Email Tracking. The automation in the s.doPlugins() method makes it an integral part of the site.

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.

s.doPlugins()

Talking about automation… with Javascript-based tracking on the web, you can automate a lot of things using Javascript plugins or code you write yourself in the s.doPlugins() method.

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 TrackingHelper class!

I recommend you do that.

Updates

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?