After our Advanced Ads Tracking 2.0 release resulting in a much faster and more reliable ad impression and click tracking, I had a chance to get to an issue that sat in my backlog for some time.
I wanted to check the accuracy of referral traffic in Google Analytics. Once in a while, a client asks our support team about it. While the documentation of Google Analytics is somehow clear, I wanted to get some first-hand experience to see what could cause referrals that are not visible as such.
While I am testing with Advanced Ads Tracking users in mind, the same applies when you place external links manually on your site.
Table of Contents
The setup is the following: some of our clients are publishers who get paid by clicks on an ad or at least report the numbers from the Advanced Ads dashboard to advertisers who bought ad space on their site. Some of these advertisers might double-check on the reported numbers in their Google Analytics account.
Where is referral traffic going?
One would assume that when you measure 20 clicks on an ad that goes directly to the client’s website, they could see it under Acquisition > All Traffic > Referral traffic, with the Source being the website on which the ad is visible.
Occasionally, the numbers differ entirely, even after using our improved and bot-safe Tracking 2.0.
When we first discovered this, we did double-check all the tracking debug options and logs to verify that these 20 clicks were coming from real users. So there was no reason to just filter them out on Analytics’ end.
Now, I set up the following test to see if there is an issue on our end or how our clients could resolve it.
Testing referral traffic
When this came up originally, I did a lot of research and found that this is a common problem. In most cases, when human mistakes are not the cause, the issue relates to redirects. There are several cases of redirects, and I won’t go further into that right now.
The solution we recommended was to add UTM parameters. A link would then look like this: https://example.com/utm_source=Facebook
.
The additional parameter allows the advertiser to find the traffic coming from their partner site under Acquisitions > Campaigns.
We now saw a report that also UTM parameters might not work. With the constraints we have when debugging on live sites, I decided to think about a test setup we fully control to check which types of links Google Analytics records.
I just took one shortcut: I used two live target sites (the “advertiser”) that I own so I wouldn’t need to get through setting up Analytics again. One website is using Matomo Analytics, a privacy-sensitive website tracking tool. Comparing Google Analytics with Matomo might help me see if the issue is with one of the tools and not the links.
The point of documenting my steps was to show that it can be done even by non-developers. I did not have to write any PHP or JavaScript code in the whole process, nor did I install fancy tools or learn new technology. I simply made up a protocol with different scenarios.
The referrals setup
I wanted to test and compare referral traffic from the following scenarios:
- Google Analytics vs. another tracking tool (Matomo Analytics) on the target page
- Exact links, vs. some that redirect:
- linking to HTTP, but the site redirecting to HTTPS
- linking to a URL not ending with /, but the site redirecting to it (which is WordPress standard)
- Testing Chrome, Safari, and Firefox – all of them already installed on my system and Safari on my iPhone
- Using a VPN to simulate traffic from two different places
Setting up the publisher page
The “publisher page” is the page that hosts the ads that link to the advertiser’s page. I set up a blank WordPress page with Advanced Ads, and Advanced Ads Tracking installed, using the default options. For Tracking, this means the Frontend tracking method is enabled.
5 minutes into the setup, I changed two things to speed up testing:
- I enabled Advanced Ads > General > Open links in a new window
- Install Advanced Ads Pro to save a lot of time by duplicating existing ads
The page is publically available, so I don‘t need to log in.
In the end, I created six ads with:
- a non-redirecting link to the website using Google Analytics
- an HTTP-redirecting link to the website using Google Analytics
- a slash-redirecting link to the website using Google Analytics
- a non-redirecting link to the website using Matomo Analytics
- an HTTP-redirecting link to the website using Matomo Analytics
- a slash-redirecting link to the website using Matomo Analytics
Each ad links to a different post on the given websites. I choose articles on both websites that have little to no traffic so that it is clear from where the clicks came.
The ad’s content did not contain more than this example and the appropriate target URL in the ad options.
<div style="width: 100%; height: 100px; background: #428bca; color: #fff; line-height: 100px; text-align: center; ">
GS: HTTP redirect
</div>
Code language: HTML, XML (xml)
Embedding the ads
I embedded all these ads into a single post on the publisher site by grouping the ads, showing all of them simultaneously, and delivering this setup using the Advanced Ads block.
First round: the test matrix
Before actual testing, I created the matrix from the scenarios I wanted to cover. It combines the different links (horizontally), and the browsers + locations used (vertically).
Each time I clicked on a link, I marked the appropriate field with an “x.” I also made a note in the area if I derived from the setup or noticed an error.
Now, I am opening the links one after the other in the different browser setups.
A few notes about my testing
- I logged out of the target websites. Otherwise, they might not track me
- While not needed for this test, if you want to record clicks in Advanced Ads, you need to wait 10 seconds between clicks in the same browser. That is a timeout Advanced Ads Tracking uses to prevent recording accidental multiple clicks.
- After I landed on the target page, I waited until it was fully loaded to give the analytics tool time to record the visit.
- If it works, you should be able to see yourself in Analytics under Realtime > Overview.
GA direct | GA HTTP | GA Slash | Matomo direct | Matomo HTTP | Matomo Slash | |
Chrome(1) | x | x | x(3) | x | x | x |
Chrome with VPN set to the USA | x(2) | x | x | x | x | x |
Chrome with VPN set to India | x | x | x | x | x | x |
Safari Desktop | x(2) | x | x | x | x | x |
Firefox | x(2) | x | x | x | x | x |
Safari on iOS | x(2) | x | x | x | x | x |
I made notes while testing which you see in brackets (e.g., (2)
). They might not matter later, but I wanted to make sure I remember them. Here are their explanations:
- I tested through the links while still being logged in on the target sites. It later turned out that I didn’t have an option enabled not to track logged-in users, so it didn’t matter.
- The target site uses a vendor to collect consent according to TCF 2.0. If Analytics tracking honors that choice, it might not track visitors who don’t consent or leave the site immediately. This is just a side note, though, since I did consent on my sites.
- It showed later that I clicked this link twice.
Check referral traffic in Google Analytics
While Analytics allows you to see the current day’s activity, I wasn’t sure how significant the delay might be, so I waited until the next day to look at the click reports.
My goal was to find all the clicks from the tracking matrix above.
I first navigated to Acquisition > All Traffic > Referral. It showed five users, 4 of them new, on the day I tested. All of them came from my test domain.
Five users are almost accurate since I used six different browsers. Maybe, I can find out which one Analytics ignored.
Adding a Secondary Dimension
I am now adding a Secondary Dimension to see more details. I started with Browser.
As we can see, users with Firefox and Safari (desktop and mobile) was fully tracked. One user is missing for Chrome.
Since I used different VPNs to simulate traffic from three countries, I am changing the Secondary Dimension to Country.
It looks like Analytics didn’t count the traffic from “India.” What also strikes out is the high number of Pages / Session. Maybe, referral links from India and the USA are in the same basket. The explanation might be simple: I used the same private window to test both. I should probably have closed it in between.
Content Drilldown
I checked if at least all page impressions were counted under Behavior > Site Content > Content Drilldown.
“page-1” is the target page with a slash redirect. A look into the clicks recorded by Advanced Ads Tracking shows that I did indeed click the link twice. Hence it recorded a pageview more. Unique Pageviews filters out multiple views per user, so we are back at the five individual users we saw earlier.
I also expected the high Exit rate for “page-1” since that was always the last page I visited with a given browser.
I also checked Behavior > Site Content > Landing Page and found that only the first page, the one without a redirect, was listed. That was expected since I visited the other pages in the same session.
Check referral traffic in Matomo Analytics
I added a test with Matomo Analytics to see if that is more stable than Google Analytics. With Analytics tracking almost delivering the expected results, I am not spending too much time comparing them.
The bottom line, Matomo tracked all six visitors individually, so that is a 100% match with my expectations.
Testing link cloaking
Before Tracking 2.0, our click tracking was using cloaked links by default to overcome a technical limitation.
For example, when the original target site was https://example.com
, the link that showed when you hovered over it on your website was something like https://my-publisher-domain.tld/linkout/123
. 123 was the ID of the ad.
With a rewrite in Tracking 2.0, we were able to show and track the original target URL. Since then, link cloaking is only an option.
I went back to the ad edit screens and enabled the “Cloak the link” option.
Then I went through the matrix again, clicking the links on different devices.
Just in case, I switched the order of the test for the USA and India and closed the private window between the tests.
GA direct | GA HTTP | GA Slash | Matomo direct | Matomo HTTP | Matomo Slash | |
Chrome | x | x | x | x | x | x |
Chrome with VPN set to the USA | x | maybe skipped | x | x | x | x |
Chrome with VPN set to India | x | x | x | x | x | x |
Safari Desktop | x | x | x | x | x – didn’t wait 10 sec | x |
Firefox | x | x | x | x | x | x |
Safari on iOS | x | x | x | clicked twice | not clicked | x |
As you can see in my comments, I made a few mistakes while testing. Thanks to documenting them right away, they shouldn’t matter when I come back to check the referral traffic in Google Analytics.
Find cloaked links in Google Analytics
Day 3, and I am back checking if Google Analytics tracked the cloaked links as referral traffic.
Navigating to Acquisition > All Traffic > Referral, I now see six users coming from the publisher’s domain. This exactly matches my expectations.
Adding Country as a Secondary Dimension shows that also my VPN settings worked out this time. Closing the private window in between tests seems to have resolved that one.
The additional session in Chrome might come from clicking twice when using Safari on mobile, though that should not have started a new session. I am assuming that I missed something while testing when it doesn’t happen again.
The number of New Users is expected to be only two since I neither cleared the browser history nor opened a private window for most sessions. I did so only when using a VPN. In that case, the browser clears all cookies, and Analytics did no longer know me.
Checking the traffic by browser and the page impressions on the test sites confirms that all clicks were tracked correctly.
Find cloaked links in Matomo Analytics
In Matomo Analytics, all six visitors have been tracked, together with 18 actions in total, which are indicating the three page impressions I made with each browser.
When I look at the impressions per page, I noticed that I clicked twice on the same link when using iOS and missed one other link. The Advanced Ads click tracking stats confirmed this. That has no impact on the correct attribution of the referral traffic, though.
Testing UTM campaign links
I mentioned that using UTM campaign parameters can solve referral traffic not showing up in Google Analytics. Even though I wasn’t able to find a general issue with wrongly attributed referral traffic, I was curious enough to test them as well.
According to the Analytics manual, you need to use at least three parameters:
utm_source
utm_medium
utm_campaign
.
If you are unsure how to build the UTM parameters, you can use the Campaign URL Builder.
Back to the ad edit pages, I disabled link cloaking and added ?utm_source=test-site&utm_medium=link&utm_campaign=referral-test
to the end of each URL.
After that, back to the matrix…
GA direct | GA HTTP | GA Slash | Matomo direct | Matomo HTTP | Matomo Slash | |
Chrome | x | x | x | x | x | x |
Chrome with VPN set to the USA | x | x | x | x | x | x |
Chrome with VPN set to Argentina | x | x | x | x | x | x |
Safari Desktop | x | x | x | x | x | x |
Firefox | x | x | x | x | x | x |
Safari on iOS | x | x | x | x | x | x |
Since the VPN service I am using had connectivity issues with India and some other countries as a location, I chose Argentina.
This time, I did not make any mistakes when clicking through the links. Believe me, it looks easier than it is.
PS: UTM parameters cover more than campaigns. Check out this article by Google to learn more.
Evaluating UTM links in Google Analytics
As with the last tests, I first navigate to Acquisition > All Traffic > Referral to see if Google Analytics tracked my intended click bombing as referral traffic.
There was no traffic recorded though. How can this be?
Google Analytics does only count one source. If you add campaign parameters to a URL, the source is campaign traffic. It has a higher priority than referral traffic. More on that later.
When using UTM parameters, one usually finds traffic from campaigns through Acquisition > Campaigns.
There they are.
The stats indicate that I opened one more session for my German and Argentinian users. My test protocol does not suggest that I did, and I am sure I didn’t close the private window. I am not regarding this as a significant issue though.
I made one additional click on iOS, which is recorded correctly under Behavior > Site Content > Content Drilldown.
These numbers are in sync with my test protocol and the clicks recorded by Advanced Ads Tracking.
Referral traffic vs. other traffic sources in Google Analytics
I mentioned above that campaign traffic has a higher priority than referral traffic. This is important to understand when looking at traffic sources in Google Analytics and derive any (marketing) activity from it.
The following part from the flow chart under Campaigns and traffic sources in the Analytics help center practically states that this is the allocated traffic source whenever Analytics finds valid campaign parameters.
Since there can only be one traffic source, the link will not show up as referral traffic.
While not relevant for our current scenario, I wanted to highlight that direct traffic is allocated to campaign traffic if the user visited previously through a campaign link. For publishers, this means a user could create multiple sessions, all allocated to the campaign link from a first visit, even if the next visits happen directly to the advertiser’s page.
Further tests and explanations
So far, I wasn’t able to reproduce an issue with ad clicks not being visible in the advertiser’s Analytics account. At least simple redirects don’t seem to matter. All clicks were accounted for, or deviations could be explained.
One could use this post as a template to test different redirect scenarios. Publishers who link their ads to a URL that is also the final one that visitors are seeing should be safe.
Publishers and advertisers need to be aware that they can either identify traffic as referral or campaigns, but not both.
Even though my test showed almost 100% matches between actual and recorded clicks, in a real-world scenario, that barely happens because visitors leave any time. They could close either the publisher’s website before tracking happens or not wait until Google Analytics tracked the visit on the advertiser’s page.
Another source of differences is privacy blockers. Either a cookie consent on the publisher’s website that the visitor has to confirm before Google Analytics could count traffic or an aggressive adblocker or privacy setup in the user’s browser will account for deviations without any party being able to do anything about it.
In addition to timing and privacy solutions, a broken or impartial integration with Google Analytics on the publisher’s site could also account for issues. One thinkable scenario is the missed implementation of Analytics on an AMP page.
Summary
In this tutorial, we have seen how complex the analysis of referral traffic in Google Analytics can be under certain circumstances and which special features you must consider when evaluating it.
I hope that it has become clear how essential a well-documented test environment is to test different scenarios validly. Therefore, I am happy if this template helps you with your independent analyses of your Referral traffic in Google Analytics.