Google Tag Manager (GTM) is a powerful tool that simplifies website tag management.
It eliminates the need for manual coding, allowing marketers to easily deploy and manage a variety of tags like analytics trackers, marketing pixels, and ad conversion scripts. This empowers teams to gain valuable insights into user behavior, optimize marketing campaigns, and personalize the user experience.
However, despite its widespread adoption, implementing GTM effectively can be challenging.
To maximize the power of Google Tag Manager, it’s essential to navigate the potential challenges that can hinder Google Tag Manager implementation.
Here is a blog post that will help you understand the potential pitfalls that can ensure a smooth and effective GTM setup to maximize your website’s performance and analytics accuracy.
#1 Unaligned GTM Script
Although Google Tag Manager implementation on a website can be straightforward, however, for a Salesforce-integrated website, this process can become significantly more complex.
For instance, Salesforce often utilizes dynamic content loading and custom components that standard GTM setups might not handle correctly. This means that tags may not fire as expected, leading to inaccurate data collection and analytics. Misalignment can cause significant challenges such as tags firing prematurely or incorrect event tracking, and ultimately, flawed data that can lead to poor decision-making.
Therefore, the JavaScript used within GTM should be meticulously aligned with the specific requirements and behaviors of your Salesforce setup.
Solution: To avoid such issues with your GTM script, ensure that you conduct a comprehensive analysis of your Salesforce setup to identify custom elements and interactions that could affect GTM. Customize your GTM configuration to handle dynamic content loading and ensure that triggers are set up to fire correctly in response to Salesforce-specific events.
#2 Discrepancy Between Google Analytics and CRM
Discrepant data between your CRM system and Google Analytics 4 can cause critical issues during GTM implementation. Here’s why:
a. Conversion tracking is different in both Google Analytics 4 and in a CRM.
b. GA4 configuration has filters such as an Internal IP filter whereas a CRM tends to show unfiltered data.
c. CRMs are typically designed to capture detailed interactions and attributes of individual users whereas GA4 focuses on website/app-based user interactions.
d. A single user interaction is recorded multiple times in a CRM due to various touchpoints whereas GA4 records it as a single event within a session.
e. GA4 has a pre-defined limit of 500 hits per session and if it is exceeded before the user converts, the transaction might not get recorded. However, a CRM records every transaction.
These differing measurement methodologies can cause inconsistencies in data, impacting the decision-making process.
Solution: To mitigate these discrepancies, you can create a segment in GA4 that includes the condition “Include sessions where hits = 500”. Within this segment, view the “User Explorer” report. If you see a correlation between high-hit sessions and “Quota Limit Exceeded” errors, this could indicate an underlying issue. You can also implement JavaScript error tracking to analyze which Google Analytics object is not initialized and has led to improper data tracking.
#3 Increase in Direct Traffic Acquisition
Direct traffic is attributed to users directly typing in the website’s URL or discovering the website through organic and paid channels, referrals, social media, and email. Without proper context, it’s incorrect to assume that an increase in direct traffic is concerning. Here’s why you might see an inflated GA4 direct traffic:
a. UTM parameters are essential for informing Google Analytics (GA) about a campaign’s source, medium, and other details. Incorrectly tagged URLs that do not match Google’s defined parameters or parameters like the wrong source and medium not in Google’s list of channel groupings can lead to traffic being attributed as direct traffic.
b. Incorrectly configured redirects can cause a loss of referrer information, leading to spikes in direct traffic. Both 301 (permanent) and 302 (temporary) redirects eliminate query parameters from URLs, sometimes misclassifying traffic as organic.
c. When traffic comes from an HTTPS domain to an HTTP site, the referrer information is lost due to HTTPS website security protocols, resulting in this traffic being classified as direct. However, this issue can be resolved if the website traffic moves between HTTP to HTTPS, HTTP to HTTP, and HTTPS to HTTPS.
Solution: You can fix the UTM parameters issue by managing and tagging the URLs with UTM parameters according to Google’s definitions. Configuring your server to retain UTM parameters during redirects and minimizing the use of vanity URLs can help you fix redirects leading to a spike in direct traffic. Also, transition your website to HTTPS, as it is the current standard. You can even create an intermediate page (similar to Facebook or Twitter) to capture referrer data before directing it to the actual page.
#4 Duplicate Events & Post Data Layer Implementation
While implementing event tracking, duplicate events can be created in the following scenarios:
a. When the same event is triggered multiple times on a single page. Failing to scope events correctly to individual elements results in multiple instances of the same event being fired.
b. In case you are using Google Tag Manager (GTM) to set up GA4 event tracking, configuration errors can also lead to duplicate events. For instance, having multiple tags that trigger the same event or a single tag configured with multiple triggers can cause the same event to be recorded multiple times.
c. The uncalculated inclusion of extraneous GA4 IDs within the advanced settings of Salesforce or any other CRM can lead to each ID triggering the same event, hence the creation of duplicate events.
Solution: Ensure the GA4 tracking code isn’t hardcoded alongside GTM to avoid tracking the same events twice. This will prevent the occurrence of duplicate events when identical events are sent from both GTM and GA4. Verify that events aren’t pushed multiple times to the Data Layer on the same page by reviewing the website’s code for redundancies. Additionally, you can inspect the website’s code for multiple instances of the GTM container and remove any duplicates.
#5 Inconsistency in New & Returning User Data
Implementing Google Tag Manager (GTM) and Google Analytics 4 (GA4) can present several challenges, one of which is accurately understanding user metrics.
When analyzing user data in GA4, you might notice discrepancies in the numbers for returning and new users compared to the total user count. A common misconception is to assume that the total number of users is simply the sum of returning and new users. However, this is not always the case in GA4.
‘New Users’ in GA4 are quantified by counting first_visit or first_open events. However, if these specific events are not sent, particularly in scenarios involving the Measurement Protocol, new users will not be accurately tracked. This leads to an underreporting of new users because the absence of first_visit/first_open events means they are not included in the new user count.
‘‘Returning users’ are those who have previously visited a website or application. These users are identified by having session counts greater than one, indicating they are not on their first visit.
The equation “Total Users = New Users + Returning Users” might seem straightforward, but GA4’s methodology for counting user types can lead to scenarios where the sum of new and returning users is either greater than or less than the total user count.
Solution: It is essential to understand how GA4 attributes sessions and user activities because it differs from traditional counting methods. Let’s consider two instances to understand this:
Case 1: New Users + Returning Users < Total Users
In Google Analytics 4 (GA4), you have three types of users:
a. New Users (NU): People visiting your website for the first time.
b. Returning Users (RU): People who have visited your website before.
c. (Not Set): Users whose status (new or returning) couldn’t be determined.
When you add new and returning users, it might not be equal to the total users because some users fall into the (not set) category. So, if new users (NU) = 5, returning users (RU) = 6, (not set) = 3, then total users (TU) = NU + RU + (not set) = 5 + 6 + 3 = 14. On the other hand, new users (5) + returning users (6) = 11, which is less than the total users (14) because of the 3 (not set) users.
Case 2: New Users + Returning Users > Total Users
In Google Analytics 4 (GA4), if a user visits your website for the first time and then visits again later the same day (with at least 30 minutes between visits), it can result in the following:
a. New User: Counted as 1 (since it’s their first visit).
b. Returning User: Counted as 1 (since they came back later).
c. Total Users: Counted as 1 (since it’s the same person).
This happens because GA4 counts new and returning users separately, but the total user count remains unique for the same person. Therefore, in this case, you might see: new users = 1, returning users = 1, and total users = 1. This implies new users (1) + returning users (1) = 2, which is greater than the total users (1).
#6 Errors in Data Sampling
Data sampling in GA4 can be a barrier to viewing an accurate web analysis, especially when handling large datasets. GA4 has both Standard Reports (pre-configured reports for efficient analysis with less data sampling) and Advanced Reports (ideal for large datasets to provide in-depth insights into user behavior).
GA4 employs data sampling to handle large data volumes efficiently, reducing server load and expediting report generation.
While this speeds up data processing, it’s essential to recognize its potential impact on data accuracy, particularly in highly detailed or segmented reports where sampling can lead to estimations instead of precise data.
Understanding the nuances of sampling is crucial for correctly interpreting GA4 reports and deriving meaningful insights from web traffic data.
Solution: Transfer raw data to BigQuery, analyze extensive datasets, and enable strategic decision-making. Utilize standard reports in GA4 to offer unsampled data for accurate and efficient analysis. Carefully select date ranges to eliminate sampling bias and ensure a clearer view of website interactions. Employ parallel tracking in GA4 for efficient data collection, particularly for high-traffic websites to reduce server load and minimize the need for data sampling.
#7 Limitations in GA4 Custom Dimensions and Metrics
Using custom dimensions and metrics in GA4 comes with some limitations. For instance, if you create a new custom dimension or metric, it will only start collecting data from the time it was created and cannot retrieve historical data. Also, the custom dimensions and metrics are not always available in certain reports like Exploration reports, which limits the visibility of those custom dimensions data.
Moreover, GA4 has predefined limits on the number of custom dimensions and metrics that can be configured. It allows up to 50 custom dimensions and 25 custom metrics per property. This can be a constraint for businesses with complex data tracking needs or those requiring more granular segmentation.
Solution: To optimize custom dimension and metric usage in GA4, it’s recommended to prioritize key metrics and attributes that are most relevant to your business goals. Identify the essential data points that will provide valuable insights into user behaviors or attributes.
Also, ensure that you regularly review and update custom dimensions and metrics to learn which essential data are you capturing effectively without exceeding the predefined limits. This may involve reevaluating the necessity of existing custom dimensions and metrics and making adjustments to stay within the limits while maximizing data relevance.
#8 Inadequate Debugging Practice in GTM
Insufficient debugging practices during GTM implementation impact the accuracy of data tracking and the overall functionality of Google Analytics 4 (GA4) tags. This can result in data discrepancies, incorrect tracking, and overall unreliable data insights. Improper debugging also increases the risk of sending data to the wrong property, affecting data integrity.
Solution: Here’s how GTM’s built-in debugging tools and best practices can help resolve this challenge:
a. Preview Mode: GTM’s Preview mode allows you to test changes before publishing them live. It enables you to see how tags, triggers, and variables interact on your site, helping to catch potential issues early in the implementation process.
b. Preview Console: The Preview console in GTM provides detailed information about which tags were fired, which triggers were activated, and how variables were evaluated during a preview session. This insight is crucial for debugging and ensuring that your tags function as intended.
c. GA4 DebugView: GA4’s DebugView is a powerful tool for verifying that events are sent correctly to the intended GA4 property. It allows you to see real-time data hits, including event parameters and user properties, aiding in validation and troubleshooting.
d. Utilizing Real-Time Debugging Features: Apart from GTM, leveraging real-time debugging features offered by other tools like Facebook Pixel (if applicable) adds an extra layer of validation and ensures that data is accurately transmitted across multiple platforms.
#9 Complex Form Tracking Submission
Form submission events may appear even with “Check Validation” enabled, leading to inaccurate tracking of successful form submissions. “Check Validation” is an option that appears when you configure a Form Submission trigger.
There is a section, “Enable this trigger when…”, which is responsible for activating the listener (a function that is activated in the background and is looking for Form Submission events on a page). If this section is misconfigured, it can prevent the Form Submission trigger from activating, affecting event tracking.
Merely enabling Form Variables is insufficient; a Form Submission trigger must also be active to track form submissions accurately. Moreover, issues with the Data Layer configuration can cause the Form Submission trigger to malfunction, impacting all event tracking in GTM.
Solution: Here’s how you can correctly configure form variables in Google Tag Manager:
a. Access the Variables section from the main menu. By default, these variables are disabled. To enable them, click on “Configure” under built-in variables, and in the right sidebar, activate all Form variables.
b. Navigate to the Triggers section and create a new trigger with specific settings. If you check the “Check validation” checkbox, GTM won’t activate the trigger if the default form action is prevented. However, leaving it unchecked means the triggered fires whenever a submit event is registered, regardless of form validation.
c. When the “Check validation” checkbox is enabled, a new field titled “Enable this trigger when…” appears. If you want a trigger active on all pages, enter “Page Path contains /” as the condition since Page Path always includes at least one slash.
d. To test if the default form auto-event listener works, use GTM’s Preview and Debug mode. Click on “Preview” at the top-right of your GTM account, enter the URL of the page with the form, and click “Start.” A new tab opens with your website, and at the bottom, you’ll see a connected badge indicating a successful connection.
Key Takeaway
In navigating the challenges of GTM and GA4 implementation, meticulous attention to detail is crucial. Integrating GTM and GA4 with various CRMs adds complexity, which requires increased vigilance and customized strategies for optimal results. By avoiding these common mistakes, web analytics professionals can navigate the GTM and GA4 implementation process with confidence. This meticulous approach lays the foundation for smooth tracking, accurate data analysis, and ultimately, well-informed business decisions.