Adam Brzostek
Reading time: 6:00

From a leaky bucket to an armored data pipeline: the IMPEST case study

How IMPEST improved the Google Analytics vs CRM data match by almost 30% and recovered over 20% of conversions in Meta Ads with server-side tracking.

GA4 Ads panel conectors inforgrafik x px – Jak IMPEST poprawił zgodności Google Analytics vs CRM o blisko 30% i odzy

Impest sp. z o.o. is the undisputed e-commerce leader in personalized gifts in Poland. The company owns the murrano.pl, maverton.de and maverton.fr brands. It serves tens of thousands of customers in Poland and is quickly growing its sales in the German and French markets.

The challenge

At the end of 2024, as operations grew and the company expanded into Western markets, it noticed a widening discrepancy between the actual sales reported in the store's backend and what the analytics (GA4) and advertising systems (Google Ads, Meta) were reporting. A significant data gap had opened up.

The business consequences were serious. Ad algorithms were getting incomplete data, which artificially drove up costs (inflating CAC) and made it harder to scale sales in new markets. There was a real risk of wasting ad budget.

Bettersteps was given a clear goal: fix the analytics, plug the leaks in the data flow and prepare the infrastructure for the challenges of 2025/2026, including the ongoing restrictions on third-party cookies (the User Choice model).

First steps in server-side

When we started working together, the company had an established position in Poland with a well-developed advertising setup, but it was only just building up sales in Germany and preparing to expand into France. Despite a well-run platform, the data left a lot to be desired. As recently as November, the match with the CRM was only 66%.

Together with the client, we decided to go with server-side tracking and chose maverton.de as the testing ground. Once proven, the solution would be rolled out to the other sites.

In the second half of November, we started by implementing server-side Google Tag Manager (sGTM) on Google Cloud Platform (GCP) infrastructure, running on Cloud Run with a custom domain.

Case Study Server side – Pierwsze kroki w server-side

Result: The CRM data match improved by about 5%, to 72%

Takeaway: The solution helped, but we knew there was still room for more.

Seeing the positive results, we looked for further improvements. A Consent Mode audit showed that the custom in-house CMP wasn't passing consent correctly, which caused a recurring race condition between the event firing and the consent state being sent.

Read our Consent Mode guide

To free up the company's developer resources, we decided to drop the in-house solution. In February 2025 we replaced it with CookieScript. At the same time, we enabled advanced Consent Mode in GTM. In this mode, GA tags send anonymous "pings" even without consent, which let Google use behavioral modeling to fill in missing data that previously didn't show up in reports.

Result: Another 10% increase in collected signals, and after 3 months, modeled data was unlocked.

Takeaway: At this stage, a match of around 80% was already satisfactory, but variable Google Cloud costs (dependent on traffic), complex infrastructure management and the lack of built-in tools against ITP (Intelligent Tracking Prevention, e.g. in Safari) prompted us to look for alternatives.

Migrating to Stape and cutting costs

In mid-year we decided to migrate the sGTM infrastructure from Google Cloud to Stape for two main reasons:

  • Cost: Switching from a "pay-per-request" model to a fixed, predictable subscription at this traffic volume cut infrastructure costs by 50%, which mattered a lot given that the solution would be rolled out to the other brands.
  • Technology: Access to ready-made "Power-ups", extensions that plain GCP doesn't have. At this stage, Cookie Keeper turned out to be the most important one

Apple devices (iOS/macOS) are very popular in the German market. Safari has ITP, which shortens cookie lifetime to 7 days, and in some cases even to 24 hours. That makes it harder to analyze purchase paths and attribute conversions. Implementing Cookie Keeper let us restore user identifiers, which in practice extended the attribution window and made it possible to correctly attribute conversions to campaigns that happened weeks earlier.

How does it work?

Stape's "Cookie Keeper" power-up works cleverly: it uses a "Master Cookie" and the browser's local storage or user identifiers to restore marketing cookies (_fbp, _ga) on the next visit and give them a new expiration date.

Case Study Server side – Cookie Keeper: Walka z ITP

Sealing the system: Same Origin & Custom Loader

Even after the migration, some data was still lost to ad blockers that blocked gtm.js scripts loaded in the browser.

To fix this, instead of using a subdomain (e.g. sgtm.maverton.de), we configured sGTM to run on the main domain, in First-Party Mode. We used Cloudflare Workers to create a data tunnel, so from the client's point of view, analytics requests can't be told apart from the store's own requests.

As an extra safeguard, we used another Stape extension: Custom Loader. It's a custom loader for the GTM script that serves it from the store's (main) domain instead of googletagmanager.com and masks the path, making it invisible to ad-blocking algorithms.

Case Study Server side – Uszczelnienie systemu – Same Origin & Custom Loader

Result: We recovered another 5% of transactions that had previously been invisible to analytics systems. This brought the CRM match to 89%, which these days is an outstanding result.

Meta Conversions API

With the sGTM infrastructure configured this way, we could get the full potential out of the Meta Conversions API.

Thanks to sGTM and Same Origin (First-Party Mode), the fbp and fbc cookies became resistant to browser restrictions, because they are treated as first-party.

With server-side tracking, more data that would otherwise have been blocked in the browser reached the Meta Ads account.

We also implemented enhanced conversions, again through sGTM, which improved match quality even further.

Case Study Server side – Meta Conversion API

Result: Conversions attributed in Meta Ads increased by over 20%. Meta's algorithms got better input (Data Truth), which made campaign optimization more effective.

More about Meta CAPI

Summary

Server-side tracking transformed the analytics from "leaky" (about 65% coverage) to "Data Truth" (89% coverage).

Ilustracja: Case Study Server side 960 x 270 px – Podsumowanie

Key metrics:

  • +20-25% more data overall (the combined effect of sGTM, Same Origin and Consent Mode).
  • +20% better attribution in Meta Ads.
  • Stable costs after migrating to Stape.

Let's be realistic: e-commerce is changing, and ever-tighter legal and privacy restrictions lead to one conclusion: today server-side isn't optional, it's a necessity.

This kind of tracking improves your current data and also opens up many new possibilities, such as

  • consent exception tracking: statistical tracking without consent
  • data enrichment: securely enriching data on the server before sending it to the destination system

Server-side also opens the door to many other new technologies. If you see potential in this for your company, get in touch. We'll find a solution that works for you.

Related articles

Get in touch

Characters left:
2000