Recently, I came across a user question in the Google Analytics discussion group. The user mentioned that they cannot view detailed information about requested URL paths within a single-page web application.
During basic setup, Google reports URL parameters through standard structures, and as a result, it does not reflect the details present in the URL path. For example, a URL such as domain.com/app/#/Partner/home will be displayed as /app/ only, excluding the main machine name. However, the user’s request is to see the relevant request URL in the Page field as /app/#/Partner/home. In this article, I will discuss how we can solve this issue. Before that, let’s examine how we can reflect the Domain Name (main machine name) information in reports without using it as a secondary dimension.
As of July 9, 2023, Universal Analytics (UA) is being replaced by Google Analytics 4 (GA4). After this date, UA properties will no longer be able to process new data. They are expected to become inaccessible by the end of the year. For details on differences between property types and other operations, please refer to my article titled Universal Analytics (UA) to Google Analytics 4 (GA4). You may also request technical support at (https://calendly.com/dnomia/15min).
Viewing the Full Page URL
- Page:
http://www.domain.com/dizinadi/sayfa.html - Request:
/dizinadi/sayfa.html - Domain (Main Machine Name):
www.domain.com
Viewing the Domain Name
By examining the relevant tables (Behavior > Site Content), we can view both the domain name (hostname) and the request URI. Especially, when you want to track activities across different applications and web pages under a central property, and analyze interactions between properties, this becomes useful. For example, imagine a food brand that launches separate web pages for each product.
- Brand website:
anamarka.com - Product 1:
urun1.com - Product 2:
urun2.com - Campaign:
kampanya.com
Let’s assign separate UA IDs for each of the above websites. You can create another property to track user interactions between these IDs, segment them, and use them in retargeting campaigns. You can then assign these UA IDs to all the websites listed above.
For more detailed information about this process, please refer to my articles on Google Analytics Global Site Tag, Global Site Tag Event Handling, and Cross-Web Property Tracking.
After implementing the setup above, the Explorer content will no longer display the Page values under the “App Name” (i.e., different websites and applications) field. However, we can display the “App Name” as a secondary dimension, shown as a column. We can leverage filters to configure this and also view the field name information within the “Page” field during the central setup1.
After applying this filter, you will be able to see, in real-time, within the “Active Page” field, the “App Name” value for each page URL2. Please note that this feature may conflict with existing filters and goals, and you must ensure to update the relevant fields to include the “App Name” value.
Tracking URL Hash Changes
Yes, we’ve now addressed the actual problem I mentioned at the beginning of the article. How can we track hash changes within the URL without page jumps (i.e., when a link is clicked, the page content remains unchanged)? For this process, I’ll provide explanations both through the Google Analytics Global Site Tag and through Google Tag Manager. My recommendation is to perform these operations via GTM. In the example scenario, I’ll examine the reference management on the ecodiurnal.com webpage, and attempt to display the click/view rates for the references listed within the article. As an example page, I’ll use the page associated with the article titled “Scientific Method” 3. As previously mentioned, I’ll explain how this process can be implemented both through Google Analytics and Google Tag Manager 4. Let’s start with the first example: Google Analytics 5;
Google Analytics AllowAnchor Operation
When setting up Google Analytics, the following modifications must be made within the code snippet:
gtag('config', 'UA-ID', {
allowAnchor: true,
page_path: location.pathname + location.search + location.hash
});
You can add the following code to the footer section to handle clicks on links:
jQuery(document).ready(function () {
jQuery('a').click(function(){
var match = jQuery(this).attr('href').match(/#\S+/);
gtag('config', 'UA-ID', {
allowAnchor: true,
page_path: location.pathname + match[0]
});
});
});
As a result of these operations, the page URLs will be displayed on the screen as follows.
We need to carry out a series of steps on the GTM container. Our first priority is to create a new Custom JavaScript Variable under a newly created User-Defined Variable containing the following JavaScript code:
function() {
return window.location.hostname + window.location.pathname + window.location.search + window.location.hash;
}
// or
(() => window.location.hostname + window.location.pathname + window.location.search + window.location.hash)();
Then, we need to configure the trigger to fire upon History Change events, specifically when the field created under History Source has the value equals = popstate. Finally, in the newly created Tag field, we need to specify what behavior we’d like to occur during a History Change. In my case, since I’m handling PageView events, I selected the Universal Analytics snippet and linked the page field, which I created under Tag Configuration > Variable Configuration, to the JavaScript variable. Additionally, I set the field value allowAnchor to true.
After saving and implementing these changes, I verified that GTM is correctly sending both PageView and click events to Google Analytics for hash URL changes. Yes, that’s all. If you have any questions, please feel free to share them in the comment section below. To stay updated on additional articles and training sessions related to Google Analytics and Google Tag Manager, please enter your email address in the field below to sign up.
*[hostname]: the main machine name
*[Request URI]: Request URI