In our increasingly inter connected world,users can come to your website through different means. Examples:
It's not only important to bring users to your website, it's also important to know the traffic sources:
(1) Where they come from
and
(2) What brings them here
Is it a particular campaign? eg. sale, launch, offer, reminder
Without knowing the traffic sources, you will not be able to determine the effectiveness of your marketing spend.
In this article, we will explain:
When you click a link on a webpage that leads you to next, the destination webpage typically has info about the previous page. This info can be accessed using the JavaScript property: document.referrer
Let's look at an example:
If you are the owner of www.mywebsite.com, it's important for your website to know that a user has come to your website FROM https://www.google.com.
Note: When going from one domain name (eg. www.google.com) to another (eg. www.mywebsite.com), the browser will typically retain only the domain name portion in document.referrer for security purposes. That means you won't be able to see the path (eg. /search) or the URL parameters (eg. ?q=...) of the previous page.
As such, this method can be used only to determine where users come from, but not what brings them here.
Some websites may be programmed to strip away the document.referrer info.
Some landing webpages may be programmed to redirect to another webpage. Example:
www.mywebsite.com/landing → www.mywebsite.com/intermediate1 → www.mywebsite.com/intermediate2 → www.mywebsite.com/final
Typically, there is no issue if 3XX redirection methods are used. 3XX redirection means the web server is doing redirection in the background whereby the users do not see any of the intermediate pages until the final page.
To illustrate:
Problem arises when JavaScript redirect (code 200) is used. This means that the webpage is loaded and shown to the user (albeit perhaps only a blank page and for a few short seconds) before the redirection is done by the browser (not the web server). The fact that the webpage is loaded means it becomes the new referrer for the next page.
To illustrate:
If Google Analytics is only loaded (or only has time to be loaded) on the /final page, the true traffic source info (https://www.google.com/) will be lost.
The Document Referrer method described above is only able to determine the source domain name. To add more info to the traffic source, we can add custom URL parameters to the target link.
Commonly used methods:
Some websites may be programmed to strip away the unrecognized URL parameters. This can also happen during page redirection, like described above.
To illustrate:
Some websites or tag management systems may be programmed to modify the URL parameters. Common examples include changing all the characters to lowercase:
The URL query parameters (starting from the ? character) should always come before the the URL achor/fragment (starting from the # character). However, some websites uses /#/ as part of the website path structure, which may cause some analytics/advertising platforms to not be able to read the URL query parameters.
Example:
https://www.mywebsite.com/#/page1?utm_source=...
Though it is understandable that this can be difficult to avoid as you can't easily change how a webserver fundamentally works.
A simple check that you can do is go to an external website that has a link to your own website. Examples:
Click on the link, when you land on your website, do the following:
Open the browser console window and execute this JavaScript command: document.referrer
It should return the originating website domain name (eg. https://www.google.com/). If instead, you are seeing:
It could be an indication of the issues mentioned above and that the original traffic source is lost.
This is a simple check to ensure that the URL parameters (eg. gclid, utm) from the originating websites are still intact on the address bar when you land on your website.
If you don't see the URL parameters, it could be an indication that your website has stripped away the custom URL parameters.
If your website has been having these issues for a long time, it can be more difficult to detect them. A telltale sign that you can look at is:
If changes are made on your websites that cause these issues, it's easier to detect them. We recommend creating a simple line chart with the Transactions metric, breakdown by the Session default channel group dimension. Check this report periodically (eg. every few days) to see if there's any unexpected change in the breakdown trends. For example:
This method can be very effective in detecting anomalies in the data, and informing you of possible website issues.
Although it is possible to detect these issues on your own, it would take you a lot of time to do so. One way to speed this up is to use our automated GA4 Auditor tool, which runs over 50 checks on your selected Google Analytics property, returning a comprehensive audit report that flags potential issues and provides actionable feedback in just a few MINUTES! The GA4 Auditor tool identifies common causes of misattribution, such as malformed UTM parameters, helping you catch problems before they spiral into bigger issues.
Reach out today to learn more or request a demo!
Understanding the importance of retaining the true traffic source info and the common website issues that could affect this ability. We highly recommend the following:
If this is not possible, then you may have to work out a custom solution whereby:
There are countless number of advertising and social media platforms, it's not feasible to whitelist recognized URL parameters. We recommend not touching the URL parameters at all. And if you use page redirection, ensure to forward all URL parameters throughout all intermediate pages and to the final landing page.
