Most of the articles written about cross-domain tracking only mention simple cases, and it’s rare to see articles written about cross-domain tracking in complicated cases. Regarding such cross-domain tracking, in this article I will explain how to do cross-domain using hashing, which you will not see on other blogs, and how to use it.
About cross-domain tracking
Cross-domain tracking basics
Google Analytics uses a string called a client ID to uniquely identify a user. This client ID is stored in a cookie associated with the domain. Since it is stored in the browser using cookies, it is usually not possible to share the client ID across domains.
Therefore, in cross-domain tracking, when transitioning between different domains, the client ID is added to the link destination URL in the form of a query string. By doing so, the process of synchronizing the cookie of the linking domain and the cookie of the linking domain is called cross-domain tracking in Google Analytics.
What is hashed cross-domain tracking?
By default, this is achieved by adding a query string like ” http://example.com/index.html?_ga=1.0000000.000000 ” to the link destination URL when clicking on a cross-domain link. increase. If you change the part of the code related to this cross-domain tracking , it will append the information with hash string like ” http://example.com/index.html#_ga=1.000000.000000 ” instead of query string. I can.
Setting up hashed cross-domain tracking
When to use Google Tag Manager
If you set ” Use hash as delimiter ” to “True” from “Other settings > Cross-domain tracking” in the Google Analytics tag settings , the cross-domain tracking parameters will be in hash format.
Case of installing directly on the site
If you want to install directly on the site, change the autoLink command of the linker plugin as follows.
// 変更前
ga('linker:autoLink', ['destination.com']);
// 変更後
ga('linker:autoLink', ['destination.com'], true);When to use the hash format
Difference between query format and hash format
The difference in appearance is easy to understand, but here we will explain the difference from a technical point of view, not a difference in appearance. I think the biggest difference here is that “the query string is sent to the web server, but the hash string is not sent to the web server” (the web server here is the Google Analytics server instead of the website server).
When You Must Use the Hash Form
The fact that the hash string is not sent to the website server means that the website server will not rewrite (delete) the hash string.
For sites with dynamic systems, there are cases where the server side redirects several times before the page is displayed. In this redirect, there are cases where the cross-domain tracking parameter that was given with much effort is deleted.
In such a case, even if a redirect occurs on the server side, the power of hash-type cross-domain tracking that remains on the browser is demonstrated.
Illustration
I think it is difficult to explain in words, so I will give an example. I couldn’t find a site that was easy to explain, so I’ll try to explain on the order history page of the amazon.co.jp site. Of course, this page is a page that cannot be viewed unless you are logged in to Amazon.
Normal access first
If you open https://www.amazon.co.jp/gp/your-account/order-history (order history) without logging in to amazon , https://www.amazon.co.jp/ I think it redirects to ap/signin/************** (login screen). This is the normal access result.
Access with query format parameters
This time, access with a query parameter like https://www.amazon.co.jp/gp/your-account/order-history?_ga=abc (order history, query format). Then you will be redirected to a URL like https://www.amazon.co.jp/ap/signin/************** (login screen) again. The above is masking, but if you actually try it, you can see that the “_ga=abc” parameter is redirected to the URL without it.
Therefore, cross-domain tracking will fail in this situation.
Access with parameters in hash format
Next, access with a hash format parameter like https://www.amazon.co.jp/gp/your-account/order-history#_ga=abc (order history, hash format). Then you will be redirected to https://www.amazon.co.jp/ap/signin/**************#_ga=abc . Unlike before, the “#_ga=abc” part is maintained and redirected.
If so, cross-domain tracking should succeed.
summary
Regular cross-domain tracking has become easier to set up with the advent of Google Tag Manager. However, depending on the structure of the site, including patterns that include redirects like this one, it can be very troublesome.
In fact, I don’t think anyone understands what is written here and sets up cross-domain tracking (I just recently realized that myself). In fact, what is written here can support not only cross-domain tracking but also custom parameters like utm source/utm medium.
Why don’t you try implementing access analysis that is one step ahead by using query format and hash format parameters properly?
