Bulletproof Tracking Guide

How to ensure tracking is consistent and coherent in all situations

Zeno avatar
Written by Zeno
Updated over a week ago

Now is an era of growing privacy concerns, increased scrutiny on tracking users (even anonymously) and both browsers, operating systems and large traffic sources like Facebook are taking steps to address these concerns -- all of which make it harder to consistently track user activity across pages.

As a result, numerous scenarios can arise where tracking is disrupted and:

  • Visitors do not get routed to the right destinations when clicking action links

  • Tracking data gets disconnected from visitor identities, making it hard to analyse profitability and traffic source data

  • Action links on landers simply don't work, leading to lost potential revenue

This quick guide will explain how you can set up robust tracking approaches in FunnelFlux to minimise the above scenarios.

Skip to Part 3 if you want to get straight to the practical details.


Part 1: Understanding how FunnelFlux tracks visitors

To understand how this works its important to have a basic understanding of what goes on behind the scenes.

Let's take the following example:

  • You create a funnel with the traffic node linking to a lander, which then links to another lander, followed by an offer. Think of it as a pre-sell lander, the main lander, then the sales page/offer.

  • You launch a campaign on Facebook that links to the traffic node using a FunnelFlux redirect link

When the visitor clicks an ad > loads the tracking link a few things happen:

  1. The visitor generates an entrance to your funnel

  2. This visitor gets given a unique Visitor ID

  3. FunnelFlux starts a "session" for this visitor, describing their activity. This session file has a Session ID and the data is stored locally so it can be quickly accessed -- it is not stored in your analytics database, its a temporary file

  4. The visitor loads the first lander, and this "hit" to the lander has a unique Hit ID

  5. All this info is stored in the session file as well as a cookie the tracker drops on the user's computer. 

As you can see, there are a few unique ID's that get generated and are associated with that visitor and their activity, with that data being stored in a temporary session file as well as a cookie.

This cookie is the only thing that exists on the visitor's side that can tell the tracker "who they are".


Part 2: What happens when a visitor clicks an action link?

Ok, so now a visitor is on your landing page. 

They have a visitor ID, a hit ID for that specific landing page visit (hit IDs exist for every node a user touches in a funnel), and an active session with a Session ID.

They also hopefully have had a cookie dropped with all this info as well.

Now, they click your action link. That action link could have two forms:

In either case the first thing FunnelFlux will do is check the cookie for domain.com to determine this user's visitor ID and what node they are coming from.

Knowing this allows the tracker to decide where to send the user next.

On clicking the action the visitor would go from node A > node B, and then another action click would logically take them to node C (if it exists), since they have moved away from the original lander (node A).

But what if you have multiple action links on a page or they open in a new tab so the user can click them multiple times? Here you would have multiple events coming from node A, you would not want the second action click to originate from node B.

In this case the tracker looks at the referrer to determine if they are coming from the original lander -- this is how the tracker is able to handle multiple clicks stemming from node A even if the following nodes have their own actions.

Considering the above, there are two important things the tracker needs access to:

  • The cookie dropped by the tracker during the initial redirect (or if using the javascript, the one created when the page loads)

  • The referrer for any action clicks.

There are situations where both of these get compromised, as below.


Part 3: Where issues can come from

First, lets start with referrer as this is easy.

Referrer

If you are using any landers/offers with multiple action links on them, or where you want these to open in new tabs, it is very important that you ensure referrer is passed to the tracker's action links.

There are two main situations where this runs into trouble:

  1. If you add rel=noreferrer to your action link <a> elements. Don't do this. There is zero reason to hide information from your own tracker.

  2. HTTPS > HTTP changes. If you have a landing page that is loading via HTTPS then your action links are HTTP, most browsers will not pass the referrer to the insecure HTTP link. Same result as above. 

So, don't use rel=noreferrer. On the other hand rel=noopener is fine.

It's also best practice to use HTTPS for everything you do  -- this is only going to get more important, e.g. recent Chrome updates show "not secure" now for HTTP pages, giving a greater sense of insecurity to users.

Note: in some browsers/modes, for example Firefox Private Mode, the browser blanks referrer all the time. For every link. Our bulletproof tracking workarounds do help with this.

Cookies

The main thing to be aware of with cookies is that they are domain-specific.

If you pass a user through a redirect link with domain.com, the action links on your page should also use domain.com

If they do not, the tracker cannot access the cookie and the visitor will get a fresh visitor ID, disconnecting them from all previous activity.

If you don't use organic params in your links as well, they would go to a 404.

So, keep domains consistent. You can use the {flux-domain}  token in landing page URLs if you want to dynamically update link domains within a page.

However, if a browser blocks third-party cookies or cookies in general, there is nothing you can do to stop this -- its something that can only be overcome with backup tracking methods.


Part 4: Setting up "bulletproof" tracking

Our robust tracking approaches rely on the no-redirect JS.

You can put this on pages regardless of whether you link to the pages directly or via a tracking redirect link, the two work together fine (and we'd recommend using the no-redirect JS in general to capture time on page data).

As I detailed above, there are two things that cause tracking issues -- the referrer being absent and cookies being blocked or unavailable.

Unfortunately, there are many situations occurring where this happens:

  • Firefox Private mode blocks referrers on all link navigation

  • The Facebook Mobile Browser blocks third-party cookies by default

  • Browsers are tightening up cookie controls and allowing blocking of third-party cookies as a user's default setting

  • Internet users are becoming more privacy aware and may use plugins to block cookies in general, mainly third-party ones (your tracker cookies will virtually always be third-party)


But fear not! There is hope!


Remember, visitors to your funnels are identified by sessions, cookies, visitor IDs, hit IDs and so on, so all we need to do is ensure we communicate this info to action links.

By doing so we can forcefully tell the tracker who the user is and where they are coming from, even with referrers and cookies being absent. Awesome!

There are two ways we can do this:

  1. By appending session ID to action links

  2. By appending hit ID to action links.

Session ID can tell us who the user is, what funnel they are in and what the last page they landed on is, and so on. It's like a visitor ID.

Hit ID tells us the exact event / node visit that an action click is originating from.

There are subtle differences between the two but the way you use these is very similar.


This is not a primary point of this article, but I wanted to mention that using these is good practice.

These are fallbacks. If FunnelFlux knows where a user is then it will ignore these params. It only uses these if it has no idea who the user is -- something that would happen if cookies were blocked.

Think of it as a way to capture users who would 404 and make them do something productive.

However, these do not prevent the visitor's history being lost.


We have an existing article that covers using session ID here.

The gist of it: we configure the javascript to add flux_sess={session-id}  to action links on your page. We do this by giving the anchor elements a specific class.

So, we modify action links on the page from this:

<a href="https://domain.com/?flux_action=1">Some Link</a>

to this:

<a href="https://domain.com/?flux_action=1" class="flux_cta">Some Link</a>

Now that it has the class name flux_cta , we modify part of our FunnelFlux javascript and tell it to insert session ID into these links:

fflux.track({ 
    timeOnPage: false,
    timeOnPageResolution: 3000,
    noCookies: false,
    tokenInjection: {
      intoUrl: false,
      intoForms: { selector: null },
      intoLinks: { selector: 'a.flux_cta' },
      tokens: { flux_sess: '{session-id}' }
    }
});

By doing this we can ensure that, no matter the blocking of referrer or lack of cookies, the tracker is aware of exactly what session an action click is coming from and who the user is.

There are some pros/cons to this method.

Advantages:

  • Session data is stored in local files that are very quickly accessed, so redirection is as fast as possible

  • Session data is always available, so this will work no matter how quickly the user might click through on a page (assuming the JS has had time to process)

Disadvantages:

  • If you have many action links on a page and/or repeated clicks to those links, and referrer is also absent, the session ID can't correctly tell the tracker that those repeat clicks are coming from the original lander

Thus, if you have simple landers that don't use multiple actions, and where you might expect fast clickthroughs by a user, session ID is the way to go.


We can do this in the exact same way as above, just change this line:

tokens: { flux_sess: '{session-id}' }

to this:

tokens: { flux_hid: '{hit-id}' }


Advantages:

  • Hit ID is specific to the exact visit to a lander, so users could click as many action links as they want (presuming they open in new tabs) and it would always follow the correct action from your funnel

Disadvantages:

  • Hit ID is stored in the tracker database, not in local session files. So, this approach will not work if the hit ID has not yet been logged to your database. 

  • This transfer to the DB can take a few seconds and could be delayed by technical issues, server load etc., so a user clicking through your lander extremely quickly might end up passing in a hit ID that does not yet existing in the database, which would disrupt tracking.

So, if you have complex pages (e.g. offer walls) or many action links from a page going to different landers/offers, appending hit ID is the better way to go.


At this stage it's not wise to pass both session ID and hit ID, but we are working on logic changes so that both can be passed and the session ID used as a fallback if hit ID is absent from your database (so you would get a combo of accuracy, slower speed but a fallback as well).

Note in both cases above, if you do not want to use our javascript, you could use the tokens {session-id}  or {hit-id}  in your lander URLs and then use your own code to grab these and inject them into links.


That's it!

Did this answer your question?