Uplift in Data for Google Ads: Comparing Client-Side vs. Server-Side Measurement

When analyzing the effectiveness of your server-side migration of Google Ads, it's common to encounter scenarios where data is captured through different methods during migration phase.

This article aims not only to clarify the core concepts but also to offer guidance on establishing a reliable method for meaningful comparisons of different frameworks (client- and server-side). We will delve into the complexities of comparing Google Ads data when utilizing client-side Google Tag implementation as opposed to server-side measurement with the JENTIS Tag Management and Data Capturing Platform. Grasping the fundamental distinctions between these methods is essential for precise result interpretation.

Comparing Apples to Pears

The first and foremost point to emphasize is that comparing client-side Google Tag implementations with server-side measurement via JENTIS is akin to comparing apples to pears. These two methods are fundamentally different in their operation and data collection techniques.

• Client-Side Measurement: In this approach, tracking codes are executed in the user's browser, collecting data directly from user interactions. While this method can provide immediate insights, it is affected by ad blockers, browser privacy settings, and user behavior that prevents data capture. At the same time the client-side measurement has a positive effect of still partial third-party-cookie support in some browsers. So multiple effects work against and for higher counts in one method alone.

• Server-Side Measurement: JENTIS operates by capturing data server-side, which provides greater reliability and consistency in data collection. This method can circumvent issues related to client-side tracking as you now fully control data streams, which adds according configuration questions and naturally will impact the data a tool receives.

Due to these inherent differences, it is crucial to approach any comparative analysis with caution, recognizing that the data collected through these methods cannot be directly equated.

The Black Box of Google Ads Reporting

Another significant challenge arises from the nature of Google Ads reporting. The data processed and aggregated by Google Ads operates as a black box, meaning that the inner workings of how data is processed, attributed, and reported are not fully transparent. This obscurity makes it difficult to establish direct correlations between the data collected through client-side and server-side methods.

Key considerations include:

• Data Aggregation:
  Google Ads aggregates data in ways that may not align with how data is captured through JENTIS. Variations in how clicks and conversions are recorded can lead to discrepancies in reported figures.

• Attribution Models:
  Google Ads uses various attribution models that influence how conversions are attributed to specific clicks. Without a clear understanding of these models, making accurate comparisons can be problematic.
  For each conversion you can select a data driven method or a last-click attribution option with Google Ads. However, it is in both instances not a straight forward conclusion that a conversion signal you send will in the end actually be counted as a conversion. Google will match data to their own users database and campaign click information before a conversion is acknowledged as such.

• Modeled Conversions and Google Consent Mode:
  Since years Google Ads has trained models to uncover conversion signals that can not be linked. While it is not creating virtual conversion counts, it is establishing a link between observed conversions and conversion signals where a link (a GCLID, or any other attribute to establish the connection to a campaign interaction) might be missing for privacy or tracking prevention reasons.
  In your “conversion” metric in all Google Ads reports the modeled numbers will blend in. And it is not possible to unlink those models, which hampers the comparison in tracking-techniques.

  • ”Conversions can be tracked across different surfaces (such as mobile or desktop) and may include modeled conversions.”

  • “Modeled conversions are reported with the same granularity as observed conversions. This includes dimensions such as conversion totals, attribution path, and conversion values.”

In a nutshell: sending 1.000 conversion signals (well formatted, confirmed to be received by Google Ads servers) does not mean that this exact number of conversions will be displayed with your reports. It can be even lower or higher, as multiple effects are at work (attribution, modeling, as seen above). As observed conversions and modeled conversions are reported both as “conversion” (metric) but it doesn’t disclose which is which in Google Ads reports.

Unfortunately Google does not transparently display if modeling is active and if it is an account- or campaign wide modeling or if it hits conversions individually.

As a starter here are some dynamic parameters that indicate if data will contain modeled (virtual) numbers and thus affect your comparison:

• Modeling Thresholds:
  Only when enough traffic is observed in your campaigns the modeling can be activated, as only with a certain amount of clicks and sessions it can be effective. While no specific numbers are publicly defined with Google on this topic, from our experience the traffic you should have is around 700 to 1.000 clicks on at least 7 consecutive days.

• Google Consent Mode:
  There are such things as Google Consent Mode basic and advanced which track based on your configuration client-side signals even before a user interacts with a consent banner. This is a major contributor to the modeling as it provides insight in how big of a gap is to be closed with virtual numbers.
  This further must be distinguished by landing-page based signals (hitting with each click on an advertising) or with conversion signals. And not just the Google Consent Mode parameters (such as gcs Google Consent Status) is important but also the signals itself, that can be “cookieless pings”.

So to answer and possibly understand the fundamentals of modeling you’d need a map that outlines questions specific to your individual configuration like:

• do you load a Google Tag client-side, is it with “cookieless pings”, or basic/advanced consent mode?

• is Google Tag configured for a certain Google Analytics property, which is linked to Google Ads? Or is Google Tag loaded and configured with a Google Ads account? How does this relate to any tools and tags installed server-side with JENTIS? Are those tools also connected with the same Google Ads account?

All those questions are highly important for this comparison of numbers - but at the same time, you see the sheer overload of complexity of those. As it is clear that those configurations impact the numbers, but it is not documented how exactly. Modeling can hit and overcount where data quality is amiss (client-side) and possibly be ineffective where better data quality is in place (server-side) leading to incorrect or flawed metrics for comparisons.

The more the better?
It's essential to recognize that an increase in data signals doesn't necessarily translate to better performance metrics. With server-side tracking, fewer signals are blocked compared to client-side methods, which can lead to a more comprehensive dataset being reported. However, this influx of data doesn't automatically equate to improved outcomes. The reported numbers might appear higher, but they could also be lower, as the modeling techniques applied can influence results in any direction. It's crucial to focus on the quality and relevance of the data rather than just the quantity, ensuring that the insights drawn are both accurate and actionable.

Importance of GCLID for Conversion Attribution - Check Before Comparison

For any meaningful comparison, it's vital to recognize the role of the Google Click Identifier (GCLID) and other enhanced conversion signals (such as a hashed email-address value of a converted user). Those identifiers are essential for identifying and attributing conversions within Google Ads. To conduct a reliable comparison between the two methods (client- and server-side measurement), the following guidelines should be observed:

1. Tracking Timeframe: Allow for a timeframe of 30 to 90 days to accumulate sufficient GCLIDs with ANY method compared (if JENTIS was installed on 1st August then the comparison timeframe should not be before 1st of September). This duration is crucial as it enables the system to gather a robust dataset of Click IDs before attempting any comparative analysis.

2. Conversion Signals: Ensure that both systems are capable of reporting conversion signals associated with the GCLID, allowing for accurate attribution of conversions to specific campaigns and keywords.
   In JENTIS you must make sure to install the tag “Google Ads Campaign Linker” which will store GCLID informations server-side.

Recommendations for Conducting Comparisons

If you endeavor to compare Google Ads data captured via client-side and server-side methods, please adhere to the following recommendations. If you’d rather want unbiased and truthful datasets then we’d recommend skipping comparing numbers in individual ad networks own reports such as Google Ads (read on below).

Google Ads specific best practices:

1. Metric Selection: Use the "All Conv. by conv time" metric for your analysis. This metric is preferable because regular conversions are typically based on click time, which can lead to inconsistencies when comparing the two approaches. You can find more information about this metric here: https://support.google.com/google-ads/answer/9549009?hl=en

2. Reporting Timeframe: Establish a reporting timeframe that provides JENTIS with at least 30 days of implementation. This period is necessary to ensure that Click IDs have been tracked sufficiently before beginning the comparative analysis.

3. Conversion Setup: Make 100% sure that the conversions you compare are identical in the attribution and general settings in Google Ads.

4. Account for modeling: Be aware if modeled numbers will hit your report or not (based on the described parameters of modeling above) and make sure to account for modeling that can overcount where signals miss (client-side) and reduce counts where more signals are received (server-side with many consent-granted flags).

Best practice for comparing and evaluating the true observations of your web and app traffic is to use independent tools. Such as web analytics or raw data storages provide. Where you can essentially track at minimum session counts with consented and non-consented users, with the option to group traffic by channel and campaigns. So you can effectively report the actual and real-world observed numbers from a channel and see how it compares to modeling in tools such as Google Ads.

From our experience this is the most certain way to understand the impact and reason for unclear numbers reported within individual and biased tools.

Google Ads Comparison Outcome Evaluation - Is the Uplift too Low?

When comparing the performance of server-side captured data to client-side data collection, one may notice that the expected uplift in conversion metrics from server-side implementations is not as pronounced as anticipated. Several factors contribute to this phenomenon, primarily linked to the functioning of Google Tags and the use of third-party cookies.

Third-Party Cookies and Background Computation

1. Third-Party Cookie Utilization: Client-side Google Tags often leverage third-party cookies to track user behavior across different websites. This capability allows for a more comprehensive data collection process, as third-party cookies can persistently store user information and behavior even when users visit various sites. This extensive tracking can recover data from users who might otherwise have been untrackable due to ad blockers or privacy settings.

2. Background Data Models: The use of advanced background computation and data modeling techniques within client-side Google Tag implementations allows for the recovery of data from users who employ ad blockers or other tracking prevention mechanisms. These models can analyze user behavior patterns and attribute conversions effectively, resulting in a more robust dataset for analysis.

So once again there is a black box situation where potentially Google has methods that are not documented or public which push for data quality even with client-side tracking. These methods might be a legal risk and the return diminish with each year passed. But it is clear that for reasons Google emphasizes client-side tracking solutions still.

Conclusion

In summary, comparing Google Ads data captured through client-side Google Tag implementation and server-side measurement via JENTIS presents unique challenges. By recognizing the fundamental differences between these methods, understanding the intricacies of Google Ads reporting, and adhering to best practices for GCLID tracking, businesses can approach comparative analysis more effectively. With careful consideration and strategic planning, it is possible to derive valuable insights from both data collection methods.