How to Fix Your AWIN Attribution

Connor Jennings • 2 April 2025

If you promote your business with affiliates at all, there’s a good chance you use AWIN. It’s a platform that can tie purchases on your website to promotions from specific affiliates, allowing you to learn who is the most effective, and reimburse them for their work. However, after doing a few AWIN implementations, I’ve spotted some issues with the way AWIN attributes traffic. Given you’ve found yourself on a blog with this title, I’d wager you’ve seen the same thing!

The Last Click Identifier

Before we start, we need to explain what the Last Click Identifier is. This tag is part of all AWIN implementations and is responsible for attributing the traffic. When a user lands on site, it checks the url for utm tags and sets a cookie named AwinChannelCookie. It will set it to either aw, direct, or other. This is what each of those mean.

aw - The last click came from an Awin link.

direct - The last click had no source in its url.

other - The last click came from some other non-awin source.

This is important, because if I go on to convert with this cookie set to “aw”, then AWIN will take credit for the conversion. If this cookie isn’t set correctly, you could be underpaying or overpaying your affiliates.

When you set up the Last Click Identifier (LCI), you’ll notice there’s a section called Used Source Parameters. This field is supposed to contain the names of any source parameters you use across any advertising campaigns. It’s essentially a list of parameters you’re asking the LCI to check.

Underneath is a field called Awin Source Values. This is where you tell the LCI what value to check for. So, if we set up the tag like this:

The LCI will check the url for a query parameter labelled source and utm_source. If either of them contain the value ‘aw’, then the cookie will be set to aw. If one of the query parameters are present, but they aren’t set to ‘aw’, then the cookie will be set to other. If neither source or utm_source are present, the cookie will be set to direct.

So far, so sensible. However, if you go into the tag template itself you’ll find a few issues.

Issue 1 - Overwriting the Cookie

Here’s an example of an awin affiliate link.

https://www.hookflash.co.uk/?source=aw&sv_campaign_id=78889&sv_tax1=affiliate&sv_tax2=&sv_tax3=AffiliateSite&sv_tax4=vogue.it&sv_affiliate_id=78889&awc=18739_1739803849_c9e3060fe199ee03c02184d74e6959e8&utm_source=AffiliateSite&utm_medium=affiliates&utm_campaign=78889

There are two source values in this link, source, and utm_source. One of them contains ‘aw’, but one of them doesn’t. How does the LCI deal with this?

Well, as of writing, the most up to date version of the Last Click Identifier sets the AwinChannelCookie based on the last source value in the link. So, despite the fact that source contains ‘aw’, the LCI will set the cookie to other, because it’s basing its decision on utm_source, which appears second. This is why you get situations like this.

You might be wondering “If source is the value that sets the cookie to ‘aw’, why are we checking for utm_source anyway? Why not only check for source?”. Well, if you did that, you would solve the above problem, however you would also over attribute traffic to AWIN.

Remember, we need to input all source parameters used across all campaigns. This is because we want to attribute based on the last click. If my previous session was an AWIN one, but now I come through a google paid ad, I need the cookie to be changed to other. To do that, we need the LCI to check for all sorts (gclid, utm_source, etc). If we only check for source, then AWIN will still take credit, because Google Ads doesn’t use source in their utm tags.

So, the real solution is to change the code in the template itself. Instead of searching all parameters, and setting the cookie based on the last value, we need it to search until it finds an aw. Once it’s done that, it can stop searching, because we know it’s AWIN traffic. This will prevent it from getting confused like the above example. (Info on the actual fix at the end of this article).

Issue 2 - Using ‘Contains’ instead of ‘Exactly Matches’

So we solved the overwriting problem, and now AWIN traffic gets set as AWIN even if it has some extra source parameters trying to confuse things. We’re almost there, but there is another issue that might affect you, especially if you run google ads.

Here’s the part of the code that checks the source parameters for ‘aw’ (or whatever value you asked it to check for)

Formatted JavaScript Code

 // Try to find the given Awin Source Values in the matched source parameter.
if (Contains(matchedSourceParameter.toLowerCase(), awinSource[i].toLowerCase())) {
    awLastClick = "aw";
    SetChannelCookie();
    break;
}

Notice it uses “Contains” as its method of matching. This would be fine in almost all cases. I say ‘almost’ because some advertising platforms, such as Google Ads, generate long random ids for their utm tags. If we check if the source parameter contains ‘aw’, and one of these generated ids happen to contain ‘aw’, then the traffic will count as AWIN. I’ve seen this exact thing happen in the wild. Here’s a non-wild example.

Pretty simple fix for this, we just need to check the source values exactly match what you specify, instead of checking if they contain what you specify.

Formatted JavaScript Code

 if (matchedSourceParameter === "aw") {
        awLastClick = "aw"; 
        SetChannelCookie();
    } else if (matchedSourceParameter === "other") {
        awLastClick = "other"; SetChannelCookie();
    }

Fixing the Template

Now if only there was someone that did all this work for you, so you could just download a new template for the Last Click Identifier with all these fixes added. Someone with boyish charm, and the classic handsomeness of old hollywood? Well unfortunately, Sean didn’t work on this project, but I did! You can download our version of the tag template free of charge here. I am a benevolent God.

Note: Installation instructions are in the ReadMe file.

< Older Post

Newer Post >