Why Your Javascript Tracking Leaks Data

Why Your Javascript Tracking Leaks Data

By Ryan Koonce

Most of the modern analytics packages are based on event calls. When someone signs up, you fire an event. When they buy something, you fire an event. These events make up the bulk of the data that we use to track growth, a/b test our designs, and understand our products. The problem is that Javascript tracking is unreliable.

Here’s a time line of what Javascript tracking should look like:

javascript-event-tracking

This is what should happen.

When someone performs an action, the Javascript on that page will fire an event to a third-party tracking platform. When the platform (such as Google Analytics, Mixpanel, or cough Attribution) receives the event, the tracker will fire a callback telling the page “You can load the next page now, we received the event.” Then you direct the browser to the link they clicked on. The problem is, you don’t want to wait very long for that callback. You have to decide for yourself how long is too long, but for the sake of our demo we’ll assume a 300ms timeout. Unless you noticeably slow your conversion flow, you will miss some events:

javascript-tracking-timeout

In this case you missed the callback. Chances are the event wasn’t stored, although in some cases the event will be stored but you just missed the callback. When the event isn’t stored you miss out on important data. So how do you fix this?

The solution is fairly simple: use server side tracking wherever possible.

Call `track` events from the server, call `identify` and `page` from the client.

Events like identify and page are called when the page loads, so assuming normal human browsing, these calls should have enough time to reach a server. Most interesting ‘events’ involve a pageload – form submissions, button clicks, etc.

The best practice is to use server side tracking wherever possible. Calling identify on the page with Javascript is still necessary, there is no calling identify on the server. Calling pagefrom the server is possible but probably not necessary. Gathering critical event data in the browser is not recommend, and will probably leave you scratching your head at why the numbers don’t add up.

As a bonus, calling events from the server means that you can also correlate things that happen off-site to specific users. This is really valuable when sales happen offline or in a separate app.

Server side tracking can take more effort to set up but the benefits are enormous.