Our Javascript tracking code's helper functionalities (V1)

Please note -- we have now released a version 2 Javascript tracking code and API. This documentation is kept since users may still have the old JS in use. Do not use this documentation if you are implementing JS tracking for the first time.

Our JS plays an important role in keeping track of users and it does not rely on cookies to do so. You can even see in the options part of the JS that you can disable cookies completely (feel free!).

We recommend you put it on all pages even when using redirect links for campaigns.

So, what exactly does our JS do that's so useful?

It automatically fixes common referrer issues

Browsers nowadays tend to mask referrer passing between pages. This causes issues for trackers like FunnelFlux when it comes to detecting where a click came from -- especially with detecting repeat clicks from the same page, such as the case of an offer wall with everything opening in new tabs.

Our JS automatically:

  • Checks if a <meta> referrer policy tag exists in <head>
  • If present, updates it to "no-referrer-when-downgrade" -- the ideal default
  • If not present, adds it with the above
  • Finds any action links on the page and adds a "referrerpolicy" attribute to them directly, to override the page's behaviour just in case

This all leads to much more reliable referrer handling. Chances are, since our new JS was released, you've avoided common referrer issues without even realising it.

It keeps track of visitor ID

The "vid" parameter is important in FunnelFlux Pro. It is the session identifier for a user and we need to pass it from page to page to guarantee the tracker does not lose track of the user, and so that on each page load the JS is aware of who the user is and where they came from.

Our JS will check multiple places for vid:

  1. The current URL, in case you are passing it to the page. We automatically add vid to any redirect links
  2. The referrer, i.e. a page the user previously came from
  3. Cookies, if present and enabled
  4. The JS code itself, since you might dynamically inject vid, which some other system may have stored

If it finds a valid vid in these places, it will use it, ensuring the visitor's journey remains unbroken. If it does break, your visitor may still be tracked, but would lose the context of the traffic source they came from and previous pages visited.

It injects visitor ID into action links automatically

As above, vid is very important, and ideally we would pass it page to page so that we never have to rely on referrer or cookies.

If our JS loads on a page and tracks a page view, it will automatically find any <a> elements on the page with a tracker action link as the href, and will append vid=xxx to them.

Check for yourself at funnelflux.com -- hover over the FunnelFlux Pro button and you will see a vid is automatically appended.

But if you check our source code, you will see this is not an action link. What's going on? Well, that brings me to helpful thing #3

It injects visitor ID into marked links, and lets us track page CTR without using action links...!

In some cases you want to direct link from page to page but still track as if a clickthrough/action has happened, right?

You can take any link element and add the data-lum="action" attribute, and our JS will append vid automatically to the href part.

If you look at our source code, you will see this:

<a class="button" href="http://funnelflux.com/pro/" data-lum="action">

Our JS sees this data-lum attribute and appends vid to the link.

The result? Guaranteed tracking of the visitor coherently on the next page, and then something special happens on our backend.

If you track a view to page A, then a view on page B, and those two pages are connected within the current funnel by an action, our system will logically assume a clickthrough must have happened -- even if an action link was not loaded.

We will then retroactively add the click, so you can still track CTR without action links.

This is made more robust by using the data-lum attribute, since it guarantees the JS on the next page registers the views correctly for the visitor.

So, I rest my case -- use our JS, its more often than not going to improve your tracking and give you more flexibility.

Was this article helpful?