When someone says “I don’t trust my data” they are, in essence, questioning its quality. Even minor inconsistencies can raise concerns for data analysts—and rightfully so. As a business, you can either account for these discrepancies in your reporting or take proactive steps to resolve them.
Google Analytics allows users to track data using custom parameters, which are expected to appear alongside associated events. However, when these parameters fail to populate correctly, reports may display “(not set)” values, leading to reporting inconsistencies. This becomes especially problematic when these parameters are essential for segmentation or filtering.
This article explores the impact of questionable data quality within Google Analytics and provides a practical solution to address a common issue at the implementation level.
Impact of Data Quality on Google Analytics Reports
I worked with a client who relied on a critical custom dimension event-scoped parameter in Google Analytics called “market_event”. This parameter wasn’t just useful for analysis—it was a fundamental filter for their Google Analytics sub-property, ensuring data was properly separated. The screenshot below shows how the market_event parameter is used alongside page URL to filter data into a subproperty.
When this parameter failed to populate, it introduced significant gaps in their reporting for some events, making accurate analysis nearly impossible in some cases. The screenshot below illustrates the impact of “(not set)” in your reporting.
Sidenote: In case you’re curious—market_event can have a “(not set)” value in the sub-property because the filter includes an additional condition that considers the URL of the website as shown in the previous screenshot above.
The implementation on this website was designed to ensure that a market_event value is always present with every event. As shown above, thanks to a generally solid setup, the (not set) value for the market_event parameter accounted for less than one percent of total events during that timeframe. However, your case might be more severe. Addressing this issue is crucial to maintaining accurate and reliable reporting regardless of the scale.
Further investigation revealed that the primary cause of the (not set) values being observed was certain automatically generated events, particularly the user_engagement event, which might trigger before the market_event parameter becomes available.
The next sections describe how we used a recommended dataLayer approach to solve this issue, and a few recommendations to follow if you want to avoid technical issues before pushing these changes to production.
How Data Looks without Pre-Populating the DataLayer
We already saw the effects of not pre-populating the dataLayer for Google Analytics reports in the previous section. Here, we would see, within Google Tag Manager (GTM), where that issue is originating from.
When the dataLayer is not pre-populated, the parameters, like market_event and page_type, might not be immediately available for use by GTM when the page first loads. This is because the dataLayer values are dynamically populated as the page or the events trigger and GTM processes them.
The screenshot below shows a situation where GTM is not pre-populated:
- Initial GTM Load: At first, no parameters like market_event or page_type are available in the dataLayer.
- Later triggered Page View manually with parameters: As the page continues loading or after certain actions/events, those parameters (market_event, page_type) will be added to the dataLayer. In our example, we are sending these parameters with a manual “page_view” event.
As we enable the GTM debugger on our test website, we can observe from the screenshot below that without pre-population, GTM cannot immediately reference the critical parameters necessary to pass the values. This results in the tags that depend on this information being unable to reference values it should pass, leading to missing data in our Google Analytics reports.
Notice from the screenshot above that the parameters are unavailable when the ‘initialization’ trigger fires, which can affect parameters required for automatically collected events like session_start and user_engagement. However, these parameters are available by the time the ‘page_view‘ trigger fires, as shown in the next screenshot.
How Data Looks after Pre-Populating the DataLayer
To improve data collection quality, as per Google’s recommendation, it’s recommended to pre-populate the dataLayer with the most critical parameters before GTM loads.
Ideally, you would include parameters that you know would be available early enough to avoid missing information. Information like:
- page_location
- page_title
- page_type (custom)
- Other custom parameters that are available early enough
Parameters like user_id may not always be available early, depending on your implementation. Therefore, it’s best to focus on other static, page-level parameters that are likely to be available. The dataLayer implementation would look something like the screenshot below:
Notice from the screenshot above:
- We haven’t scoped this pre-populated dataLayer to an Event Name (like page_view). This would ensure it’s available very early in GTM (more on this at the end of this section).
- We triggered the page_view event later, with other parameters we might want to pass on page_view.
The screenshot below illustrates where the parameters are available. Notably, the parameters are accessible in the ‘Message’ trigger of the dataLayer, meaning they are available globally, even before the ‘Consent Initialization’ and ‘Initialization’ triggers.
The screenshot below shows that the parameters are now available early, allowing tags triggered at the ‘Initialization’ stage—executed right at the start—to access them. In contrast, the screenshots from the previous section highlighted that the parameters were unavailable at the same stage, as they hadn’t been pre-populated before GTM loaded.
The moment you’ve been waiting for—let’s dive into the Google Analytics data and compare the results before and after the fix.
- This solution was applied to a production property based on our use case.
- The solution was applied after Jan. 19, 2025.
- The results show a 55 percent reduction in market_event = (not set) and a 20 percent improvement in market_event = FR value after the fix was deployed.
Additionally, observe the downward trend across all events over a longer period following the fix deployed on the 19th, particularly with the user_engagement event, where the missing market_event parameter results in a (not set) value.
Note: The approach in this article—not including an event_name like page_view event with the pre-populated parameters—depends on your goals. Google’s method pre-populates with page_view, but this may delay parameter availability until after the “Initialization” trigger.
Recommendations
Here are my top five recommendations for identifying data gaps and seamlessly addressing them:
- Monitor Data Quality: Regularly check for (not set) values to maintain reliable reporting.
- Pre-populate the DataLayer: Ensure critical parameters are available before GTM loads to prevent missing data. Develop a strategy for what parameters should exist before GTM loading vs. what can be defined after.
- Optimize GTM Triggers: Ensure custom parameters are loaded early in GTM for accurate data collection.
- Ensure Adequate Pre-deployment Validation: GTM preview mode, paired with the Google Analytics debugger, is an excellent validation tool. Use them to ensure data is populating correctly.
- Track Post-Fix Impact: Continuously measure improvements after fixes to refine data strategies.
Conclusion
In conclusion, maintaining high-quality, reliable data in Google Analytics is essential for accurate analysis and informed decision-making. Issues like missing or incorrectly populated custom dimensions, such as page_type or market_event, can severely affect reporting, creating data gaps and inconsistencies. By pre-populating the dataLayer with key parameters early in the page load process, businesses can ensure GTM has the necessary data when needed, minimizing these issues.
The solution presented in this article illustrates the power of this approach, demonstrated by the significant reduction in (not set) values and improved data quality in a live Google Analytics environment. For any business aiming to ensure clean and trustworthy analytics, adopting best practices for dataLayer implementation is crucial. With the right setup, data discrepancies can be minimized, unlocking the full potential of Google Analytics and leading to more accurate insights and smarter, data-driven decisions.
