Login

In this guide I will run you through how URL-based tracking works.

Tokens, URL parameters, postbacks, etc.

I know it is technically overwhelming for many, but once you understand the basics it's like riding a bike.

If you're quite new to trackers and/or affiliate marketing, this guide should help you with technical confidence and understanding many of the terms used.


The basics - how URLs work

When you load a link in your browser, or indeed from any system, it's composed of several parts, like this:

Often you won't have a port or fragments in it – the protocol and domain are required, but everything else is optional.

Here's what these parts do or mean:

  • The protocol says what kind of connection to use – which tells your browser how to connect
  • The domain determines what you're connecting to. DNS resolution will happen to figure this out, so domain.com will go through your DNS system (e.g. Cloudflare) and ultimately get to some IP of a server
  • The port says which destination port to try to connect on (like a doorway on the server)
  • The path is then important for the end software that processes the request. It will use it to understand what you're trying to request
  • The query (or query string) is then an optional list of key:value pairs after the question mark. It's of the format ..?key=value&key2=value2 and so on. The end software reads these to capture useful information. This is the part of URLs that is the most dynamic.
  • The fragment is then optional, and is most often used on webpages to scroll to specific headers on the page.

So, why understand this?

Because if you understand URL structure, all your tracking links, offer URLs and so on will make more sense.


FunnelFlux redirect URL structure

Now, let's generate a sample redirect link from FunnelFlux. It might looks like this:

The URL specifically is:

https://track.onlyforyou.pro/fts/2nIemJxCKbFX-2n5JuOKWLTzd?campaign=[campaign]&external=[clickid]&country=[country]&lang=[lang]&zone=[zone]&time=[time]

Let's break this down into the parts:

  • The protocol — https
  • The domain — track.onlyforyou.pro
  • The path — /fts/2nIemJxCKbFX-2n5JuOKWLTzd
  • The query string — campaign=[campaign]&external=[clickid]&country=[country]&lang=[lang]&zone=[zone]&time=[time]

Each part of this is important for your FunnelFlux link.

The protocol instructs how to connect to our system. It will always be https and this is the default you'd always use on the web.

The domain is your custom tracking domain, which will point to our system. It's through this domain that we know the incoming request is from your account, because we look it up and match it to a customer ID.

The path - here, fts means "funnel traffic source" and is just something in our backend software that tells us it's an incoming new entrance from an ad click.

The 2nIemJxCKbFX-2n5JuOKWLTzd part is actually funnel ID - traffic source ID, and tells us the funnel and traffic source this link is going to.

If you generate links to nodes other than the traffic node, and further to internal pages of a group, there could be additional parameters in this path.

Lastly, we have the query string. You can think of this like a table of data:

campaign=[campaign]
external=[clickid]
country=[country]
lang=[lang]
zone=[zone]
time=[time]

This URL would be used in a traffic source and these [tokens] would be replaced with real data, so in reality the URL would pass something like:

campaign=some_campaign_id
external=some_click_id
country=US
lang=en
zone=some_zone_id
time=1723448742

Our server knows what funnel and traffic source this incoming click is for. It's able to cross-reference the defined tracking fields, and so knows to capture campaign and external, and that country is tracking field 1, lang is tracking field 2, etc.

This is how the URL data gets logged to our database, which you are then able to analyse in reporting.

If you added other random key=value pairs to the URL, they would not get into the database and reporting, because they are not defined in the traffic source –> there's no logic to store them in the database.


FunnelFlux direct URL structure

Let's now compare to direct links, which you can get from a page group node:

Here the URL is:

https://test-resources.funnelflux.pro/landers/test-page-1.html?f=2n1d9uWZBrPa&n=0T0tWCKXzVrc&p=2n1d96FUcOKy&ts=2n5JuOKWLTzd&campaign=[campaign]&external=[clickid]&country=[country]&lang=[lang]&zone=[zone]&time=[time]

And if we break this down further, we see the initial part is just our landing page (because we are direct linking), and then there's a long query string of this data:

f = 2n1d9uWZBrPa
n = 0T0tWCKXzVrc
p = 2n1d96FUcOKy
ts = 2n5JuOKWLTzd
campaign = [campaign]
external = [clickid]
country = [country]
lang = [lang]
zone = [zone]
time = [time]

Unlike before, we can't put information into the "path" of the URL – it's not a FunnelFlux redirect link pointing to our software, it's just your landing page directly, which we have no control over.

So, we need to instead pass all the needed information like funnel ID, traffic source ID etc. in the query string instead.

On loading the page, our Javascript should be there. This JS code is then going to read the query string, look for these parameters, and then pass all the data to our software to interpret.

It's ultimately the same data, but it's being communicated in different parts of the URL because of the different situations.


The basics of tokens

Tokens are another important part of URLs used in tracking.

They can be called tokens, macros, variables, personalisation tags, etc. In the end they are a small piece of text that software has been programmed to recognise and replace.

It's much like if you read a form you had to fill out, and parts had [YOUR_NAME_HERE] and [SIGN_HERE].

You would instinctively know that you need to replace these with your name and signature. Software isn't human so it has to be programmed to do this, which will mean explict names and formats, like %token%, {{token}} and so on.

The tokens available to you completely depend on the software creator, and it's important to remember that whatever software is calling the URL is the one who will process it's tokens. You cannot guess tokens or use tokens from one system in another. You'd be speaking different languages.

Taking our earlier example of a redirect link, we had these URL parameters in the tracking link that would be used in the traffic source:

campaign = [campaign]
external = [clickid]
country = [country]
lang = [lang]
zone = [zone]
time = [time]

Here, their token format is [token] and the ad platform's software would replace these dynamically before the ad is served to the user. This would then pass the useful info to FunnelFlux in the link they click.

If we move on to FunnelFlux and look at our offer configuration, we might see something like this:

Here the final URL that FunnelFlux will redirect to is:

https://1268add1fc11.coolcontentlinks.xyz/?p=12867&media_type=mainstream&click_id={hit}&pi={funnel-id}-{trafficsource-id}&sub_id={campaign}

In this, you can see we are using tokens of {hit}, {funnel-id}, {trafficsource-id} and {campaign}. We are passing data to this affiliate link with query string info of:

p = 12867
media_type = mainstream
click_id = {hit}
pi = {funnel-id}-{trafficsource-id}
sub_id = {campaign}

The p parameter probably means some link ID, and media_type is something they provided in the link to us. The rest are URL parameters their system provides for tracking custom data.

Then, the values we pass are using tokens that FunnelFlux uses and recognises. These will be processed at the time of redirect and replaced with the known information – the hit ID, funnel ID, etc.

Now if we move over to an affiliate network and consider a conversion, we would want to pass data back to FunnelFlux. But there, we would need to use their tokens in the URL we tell them to use, to send back the revenue, and the stored hit ID.

In the example above, we would need to pass back the value we sent to them under the click_id parameter. The token for that could be {click_id}, #click_id# or [[click.id]] – we can't know without checking their system and documents for instructions (granted if you use our templates, we have already figured that out for you).


How clickthroughs work

Once someone goes through a redirect (or direct) link and gets to your page, we start a tracking session.

This is the vid parameter which you will often see in URLs – we add it automatically to redirect destinations and our Javascript will also update your browser URL to add this.

Now, if you want the user to click through to the next step of the funnel, you'd use an action link, which looks like this:

https://your-custom-domain.com/action/1

Here the path is now "action", so points to a different part of our software. The 1 then denotes the action number to use.

When a user clicks this link it sends them back to the tracker, which then has to decide where to send them.

But to successfully do this, it needs to know who the user is, what funnel they are in, and what node they are on. If it loses this information it's unable to make a decision. 

It would be like going through security in an airport where they check your passport and boarding pass... then you walk to immigration and have suddenly lost both documents. The officers would have no idea who you are or what to do with you – tracking would have failed.

To keep track of users, we want to ensure we don't lose this session ID (vid). Further, we also ideally would know what node their click is coming from, just in case they are coming from an earlier step in a funnel multiple times (e.g. opening lots of links in a new tab).

We don't rely on cookies for this. Rather, we do a few things:

  1. We try to find action links on the page and inject ...?vid=session_id_here&rn=node_id_here into the links. This passes the known information to the tracker on click, making it very clear who this person is and where the click is coming from
  2. We update the browser URL so that when you click, this information is also in the "referrer" data that browsers pass when you click links on pages
  3. We also do some updates to page code to make sure FULL referrer information passes, because for years now, Chrome has automatically redacted some of this information for privacy

So as you can see, the URLs are key to information passing and are the cornerstone of reliable, robust tracking.


How conversion tracking works

Lastly, let's mention conversion tracking.

As users navigate your funnel, every single "node" in the funnel creates a unique visit ID that we call a hit ID.

If we know the hit ID, we know everything – it's unique to that specific visit.

So when you want to track conversions from a third party, you need to pass them this ID so that later they can pass it back – telling us a very specific event that has now created a sale or conversion.

This is generally accomplished with a "postback URL" – a URL that posts back information.

This URL will look like this:

https://your-custom-domain.com/pb/?hit=hit_id_here&rev=revenue_here&tx=optional_transaction_id

By now you should be able to see what's happening here. The path is "pb" which tells our software it's an incoming postback, then the query string hit=hit_id_here&rev=revenue_here&tx=optional_transaction_id is passing important information.

We take that hit ID and the other optional information and use it to process the event. We know the customer it's from becuase of the domain used.

When you use this URL in a third-party like an affiliate network, it will use tokens so that information is replaced dynamically, e.g.

https://your-custom-domain.com/pb/?hit={subid4}&rev={payout}&tx={order_id}

These will be the tokens relevant to that platform, which will process and be replaced by the data you expect – and in this case, it's expected that we passed hit ID under their subid4 URL parameter.