Tracking in affiliate marketing

If you’re reading this on the FunnelFlux blog, chances are you’re already aware of the existence of tracking systems… and full disclosure, I own one and am obviously biassed towards recommending it (well, it’s the best after all).

So I have mentioned tracking and tracking systems several times already but I haven’t really detailed what these involve.

The tracking system is a platform either hosted by you or some third party that's purpose is to track clicks – people clicking a URL and going somewhere.

This involves receiving a click (a user clicking a banner for example), sending it to some destination, and tracking/logging as much information as possible about this user.

The information that we track may be things that we can obtain using various tools e.g. their IP and thus geographic location, their operating system, device model and so on. 

Other information will be passed directly from the traffic source generally by us putting certain terms in the URL that we use. 

Passing data in URLs is a key part of tracking.

Indeed, the most reliable form of tracking is based on “click IDs”, where each system generates a unique identifier and passes it on to the next.

Later those systems can pass it back to signal a conversion happened – think of it as a relay race where a different baton is being passed between each runner. When a conversion happens, the race goes backwards and people hand their batons back.

Runner A recorded that baton A came in, they went out with baton B. The next runner B receives baton B, moves forward with his own baton C, and passes the at o runner C.

Simplistically, we had data passing of A > B > C.

When some event happens downstream, the last system, runner C, passes back baton C to runner B. That runner recorded that baton B matched with baton C, so they then took baton B back to runner A.

In this situation, we now have passing of C > B > A

This might seem like a silly analogy, but many people struggle to understand how tracking works. It’s just a chain of software systems receiving information, logging that under a specific ID, then passing that ID on to the next system. That system does the same and you end up with a chain of IDs in systems, which look up other received information and pass it back.

So why even use a tracker?

Many people might ask… why? Why use a tracker when I can just direct link from Facebook to my lander, then an affiliate link, and use FB pixel tracking?

Well, there are many reasons. 

You could likewise ask why a bookkeeper uses Xero when they could just do everything in Excel and not waste money on a subscription.

They’d look at you and laugh at your naivety, knowing you clearly have little experience actually doing the work they do.

In a nutshell, this is why you use a tracking system:

• To centralise your analytics data in a place you control
• To create specific flows of pages (e.g. lander > lander > offer), where some system controls the steps between these, allowing you to modify them on the fly without making changes to your page code
• To make it easy to split-test variations of landers/offers
• To coordinate click-based tracking between multiple systems, e.g. affiliate network > your system > traffic source
• To simplify the setup of capturing and passing data between systems
• To have live, real-time control over the path users take
• To do conditional routing when you need to send different users to different places
• To have consolidated, accurate cost and revenue data. Platforms like Google and FB are no longer that reliable with revenue/conversion metrics due to privacy issues

Let’s dive into a few of these important aspects, and I’ll give you specific examples from FunnelFlux Pro.

Controlling the click flow

The tracking system also does something which I like to call “controlling the click flow”.

This means that for every click you control exactly where it goes.

This is critical to split testing, but also lets you redirect users based on various parameters.

For split-testing, it makes it easy to do something like this:

Here I can send users to the “traffic” node at the beginning and split them to 3 different landers. Then when the user clicks through I can split them to two different offers.

At any time I can change this, add or remove pages, and it will immediately affect live traffic – no need to change links used in the campaign.

Additionally, I might have restrictions on the offers where they only accept traffic from the US – or, and this is quite common, the affiliate network bounces people outside the US to some irrelevant sweepstakes page.

Besides being annoying, that fact can lead to campaign disapprovals (or worse, account bans), on traffic sources that are compliance heavy, should a manual reviewer test your ad link and click through the lander (they will do this at a some point).

So besides improving traffic quality in the network’s eyes, you can also protect your campaigns/accounts from frivolous disapprovals.

In FunnelFlux Pro, that’s as easy as adding a condition node in the flow, just before the rotation to the offers:

Now if the users aren’t US-based, I can send traffic to a fallback offer – which could be the offer URL directly (skipping the affiliate network), or some other relevant page that aligns with the ads/funnel. You wouldn’t use something like google.com as that’s going to look very suspicious to the reviewer and incongruent with your ads and funnel.

Centralising data for analysis

Media buyers are driven by data and a lot of time is spent on analysis.

Breaking down reports rapidly by creatives, zones, device types etc. is much easier in a tracking platform than a traffic source.

The traffic source’s goal is to make as much money as possible from selling you their ads, and maximising ad delivery and performance.

It’s not to make your life as easy as possible with data analysis.

Tracking systems on the other hand are built towards rapid breakdowns of campaign data.

In FunnelFlux Pro for example, you can drill down into any funnel, traffic source or campaign and quickly cycle through some standard reports:

And additionally, you can use reporting to do flexible breakdowns of just about anything.

As an affiliate marketer you’ll need to get comfortable drilling into the data and unearthing key information that helps you optimise campaigns.

That could be which device types are working well, finding that certain ISPs are performing really badly on mobile content offers, finding that certain landers are working really badly for some countries but great for others, and so on.

This isn’t something you’ll be able to do at a traffic source.

For example, in FF Pro reporting I can break down by Funnel > Traffic Source > Campaign ID > Device OS > Browser and look for key cut/kill decisions I can make for that specific campaign:

In this example I see that Android + Chrome Mobile is accounting for the vast majority of traffic.

So I can consider making a new campaign that only targets Android + Chrome Mobile to make my life easier (by reducing variables).

I can break down instead by zone IDs above and filter my entire report to Android + Chrome Mobile as well, to better understand the expected performance in that new campaign, as below:

From this I can start a new campaign and could take a lot of these very low ROI placements and blacklist them from the beginning, and/or create a whitelist campaign with the ones in the green.

There’s no way I could accomplish this in the traffic source or affiliate network alone. Breaking down a specific campaign by OS and browser combined, then filtering to only Android + Chrome Mobile and breaking down further by Zone ID? No chance.

Likewise the affiliate network probably doesn’t have reporting at this level, nor would they have any awareness of cost, so ROI calculations would be impossible.

This kind of reporting is what you will need to get very familiar with as a new affiliate.

Coordination of conversion data

This is one of the other major things a tracking platform does.

To give an example of PropellerAds > your landing page > affiliate network link

PropellerAds uses server-to-server tracking using a “postback URL”.

This works based on them generating a unique click ID per visitor, which you can capture and send back later, along with a revenue value.

Now, you need to capture this value on your landing page and send it to the affiliate network URL.

Then on the affiliate network side, you need to set up a postback directly to PropellerAds that will be fired on each conversion.

That’s not too complicated overall.

However, now you need to add custom code to every one of your landers to do this, and that code could change with different lander formats.

And what happens when you want to start a campaign on a different traffic source?

You would need to capture different data on the lander and append that to the affiliate link in the same way.

But oh no! The offer at the affiliate network already has a postback set for PropellerAds… and you can only set one!

Now imagine you want to run a different offer but use the same landers. The affiliate link is completely different, so now you need to make more custom code to capture data and append it differently depending on the offer, else duplicate the landing page to have separate code.

Sounds annoying? It is. A tracking system removes all of this by becoming the central system that defines incoming traffic sources, outgoing offer/page URLs, and all conversions get sent back to the tracker only.

In this way you can use a single postback in the affiliate network regardless of the traffic source/campaign/funnel – the tracker is responsible for passing onward a unique ID to the network and when it receives that back, coordinating which traffic source the visitor was from and the postback to send.

This on its own is probably worth paying money for… just to reduce the time you waste on manually passing data between systems.

Lastly, let’s mention tokens and postbacks, as these are often a source of confusion.

URLs, tokens and postbacks

Firstly, I recommend you check my FF Pro knowledge base article HERE.

This is available in multiple languages as well (can change language in the top right).

URL data passing in general

When we pass data in URLs, most often we do so in the “query string”

By query string, I mean everything after the ?

For example:

https://domain.com/offers/?affiliate=abc&offer_id=123&lander=456

Here I might be loading some affiliate link. The software running on domain.com/offers/ is programmed to expect a URL parameter of affiliate to identify the user, an offer_id parameter to determine the offer, and a lander parameter to determine which lander (of that offer’s set) that it will redirect to.

The URL parameters (and the valid values) are determined by this system.

They might have additional optional parameters like subid1, subid2, etc. for me to pass custom text data for them to store – which I might use for reporting or tracking later, e.g.

https://domain.com/offers/?affiliate=abc&offer_id=123&lander=456&subid1=click_id&subid2=campaign_id

In all cases, the URL parameters (the first parts) are determined by the software system that the URL points to.

The values on the other hand could be anything I want to pass – but their system will process those values, so I better pass what I am told to, outside of the parameters that are designed for me to pass my own data.

For example, if I change the affiliate parameter, it may no longer attribute the clicks to me – causing errors or flushing money down the toilet.

If I change the offer ID it won’t go to the offer I expect, or it might not be a valid offer ID and it just breaks.

But the subid1/subid2 fields are designed for custom text data from me, so I can pass whatever I want.

Almost all affiliate tracking is based on using these URL parameters to pass data from one system to another.

Tokens

Tokens have many names depending on where you encounter them:

• Variables
• Tokens
• Macros
• Personalisation tags (often in email)

In general, they are just a predefined format of text that a software system recognises and tries to replace. The same thing happens in all programming/coding as well.

For example, in JavaScript, I might have some code like…

var textToUse = `Hi there, it looks like you’re visiting us from ${city}, welcome!`

Here the JavaScript engine replaces ${city} with whatever is current in the city variable.

The same kind of thing happens when using tokens in systems that support them, generally in the URL.

It’s important to note that: The tokens to use are always dependent on the system that is processing the URL or code

So when you use tokens in a URL, you have to consider “what system is actually serving this URL to a user, or calling it” – as that is the system that will process the tokens.

Generally there are three:

• Your traffic source
• Your tracker
• Your affiliate network

Starting from the traffic source, it will have tokens for passing dynamic data – like its click ID for tracking, placement IDs, campaign IDs, etc.

In FunnelFlux Pro when you create traffic sources, you define the URL parameter=value pairs that will be used in your campaign links for a specific source.

Let’s take PropellerAds as an example again:

Here we are setting URL parameters that will be in our tracking/campaign URL.

This is defining, within FunnelFlux, which URL parameters to a) put in the link and b) capture data on.

These are up to you in this case (other than our reserved fields). Other systems you work with will have specific, set URL parameter names – it’s only in trackers that you’ll define aliases like this per traffic source.

In the source token box we have the token that will go in the link as well.

This URL generated in FunnelFlux is going to be used in PropellerAds, so we need to use the tokens that their system understands and replaces.

So when I finally generate a URL for a PropellerAds campaign, it will be like this:

https://DOMAIN/fts/2nIemJxCKbFX-2qUUlvRsENG9?campaign={campaignid}&external=${SUBID}&c={cost}&zone={zoneid}&subzone={subzone_id}&browser={browser}&os={os}&country={countryname}&connection={connection.type}

When that’s used in a live campaign and served to users, the tokens will be replaced by real values, e.g.

https://DOMAIN/fts/2nIemJxCKbFX-2qUUlvRsENG9?campaign=353245934&external=abcdef-123456-abcdef&c=0.012&zone=1234&subzone=1234&browser=Chrome&os=Windows&country=Thailand&connection=Wired

In the image above you can also see a third column, “FunnelFlux Token”.

This is the token you could use internally in FunnelFlux, e.g. within lander/offer URLs, to pass data that has come from the traffic source.

When the user arrives, internally we’d log all this URL data – the value of campaign, zone, browser, etc. Then to refer to it later, we use our own tokens, which we set the format of.

Lastly when you get to the affiliate network, you might have a URL like this in FunnelFlux:

https://network.com/?oid=1234&aid=1234&c=1234

Generally in this type of link, you’ll have something declaring an affiliate ID and offer ID, and maybe a creative/lander ID.

For passing URL data for reporting/tracking to the network, we’ll use whatever URL params they provide for these – often these are called subids and may be subid1-subid5, s1-s5, aff_sub-aff_sub5, or similar.

Often there might also be a dedicated parameter for unique click IDs.

Expanding our link we may get this:

https://network.com/?oid=1234&aid=1234&c=1234&s1={funnel-id}&s2={trafficsource-id}&s3={hit}

Here I am choosing to pass funnel ID, traffic source ID and hit ID (a unique ID for tracking). These tokens in the URL are FunnelFlux tokens and would be processed/replaced by FunnelFlux, as this is the system processing the URL as it redirects users to it.

That the token format is {token} like with PropellerAds earlier is complete coincidence – it’s just a very typical format. You can’t guess token formats for systems, you must always follow their guidance/documentation.

Postbacks

A postback URL is a way of tracking events between systems.

Simply put, it’s just a URL that gets loaded (called/fired) and passes some data in the query string.

https://domain.com/postback/?click_id=value&revenue=value

Here we are passing two parameters in the query string, click_id and revenue, which the end system is expecting and will use for processing.

I can’t pass whatever I want in this URL – the software running on domain.com/postback/ is programmed to expect specific URL parameters and values.

When received, it might take that click_id value and use it to process a conversion.

In the case of FunnelFlux Pro, the format is:

https://customdomain.com/pb/?hit=HIT_ID_VALUE&rev=REVENUE_VALUE

Taking our earlier network example, we passed a hit ID to them under the “s3” parameter.

So to pass it back, we need to reference the stored value under “s3” using whatever token the network uses for that. Likewise for revenue.

In the end, we may use a postback URL of:

https://customdomain.com/pb/?hit=#s3#&rev=#amount#

Now when the affiliate network processes this, it will replace the tokens, and the real URL called would be like:

https://customdomain.com/pb/?hit=xxxxxxxxxxxxxx&rev=1.23

That hits FunnelFlux and it processes a conversion for that ID, with that revenue, and then goes onwards to pass data to the traffic source in a similar manner.

So, that’s a wrap – hopefully this has clarified some of the confusing parts of tracking!