What We Learned Implementing Server-Side Analytics Last Year
One prediction from 2024 that didn’t quite come true was Google Chrome’s total blocking of third-party cookies. When this does happen – Google predicts it will be in 2025 – marketing tags such as Google Analytics, Meta Pixel, and Linkedin Insight Tag will be far less effective at measuring user behavior, and it will be much more difficult to attribute the results of media spend.
That is, unless you implement an analytics strategy that does not rely on third-party cookies.
Last year, we wrote several articles on how to prepare for third-party cookie blocking by implementing server-side measurement with server-side Google Tag Manager. Moving measurement to the server-side sets marketing cookies as 1st party or sends website event data directly to the advertising platforms (Google, Meta, etc.) so that marketing measurement stays intact.
Given that Chrome blocking hasn’t happened yet, was implementing server-side analytics worth it?
In our recent experience, yes. With all the other privacy implementations such as Apple’s ITP blocking legitimate tracking, there is already a compelling case to implement server-side now to improve measurement accuracy. And, of course, there’s the readiness and experience gaine if/when Google finally blocks third-party cookies in Chrome.
Our server-side journey started about 18 months ago by testing out on our own site and then implementing onto clients’ sites with different platforms such as Shopify, Kentico and WooCommerce for high volume ecommerce and lead generation.
Given the differences of how each client’s existing measurement is set up, there’s usually more than one way to set up the server-side container. In addition, implementation is somewhat more complicated, requiring more planning and documentation than with standard analytics deployments.
What have we learned from these implementations?
Traffic in GA4 marked as ‘Direct’, dropped by ~40%.
The ‘Direct’ channel in GA4 includes traffic that is genuinely without a trackable source but also traffic that has had its source obscured. Over the last few years we’ve seen the proportion of traffic that is in the Direct channel increase from around 25% to 45%. Ad and analytics blockers are in part responsible for this.
Not knowing the true source of traffic means it’s harder to attribute value to the correct channels and make the best media investment decision.
After implementing server-side analytics, we noticed the proportion of traffic allocated to the Direct channel decreased. This allowed us to see the full conversion paths, meaning all the channels that played a part in a multi-visit sale or lead, in 20% more cases. For one client, a significant proportion of paid advertising visits were previously marked as Direct, which undervalued the channel and gave a lower Return on Ad Spend (ROAS) score. Once server-side was implemented and Direct traffic dropped, we were able to advise the client to invest more in the appropriate paid channels.Meta and Linkedin conversion APIs are now essential tools to measure the performance of those ad networks when third-party cookies are blocked. Without these server-side tools, a growing proportion of conversions attributable to the ad networks would not be reported, hence undervaluing those paid media.
Rather than using separate servers for each of the converrsion APIs and GTM, we consolidated into one server-side GTM instance together with Google Ads Enhanced Conversions. This saved us time and server fees by using the same infrastructure.
Set up and maintenance were easier since testing and debugging involved shared elements for the different tags.The switch to server-side analytics should be seen as a necessary upgrade to your ecommerce or lead gen infrastructure rather than a panacea to improve ROAS. Yes, server-side analytics will give you a clearer attribution picture, but it's up to you to implement a media strategy that actually improves ROAS.
Plan to run separate client and server-side analytics accounts in parallel while you work out the bugs in the server-side implementation.
Unless there were specific scale or IT policy requirements, we would always choose a server-side GTM hosting provider such as TAGGRS or Stape instead of deploying directly through Google Cloud Platform (GCP). The service providers are less expensive and offer useful features and add-ons that aren’t available through GCP.
In conclusion, although the big Chrome-blocking event hasn’t happened yet, there are plenty of reasons to start implementing server-side analytics now. If you need advice, drop us a note and we’d be happy to help.