Attribution after cookies: server-side and GDPR

Once cookies stop doing the job, marketing attribution doesn't disappear. It moves from the browser to your own server: your shop or app backend sends conversions to the ad platforms directly (server-side tagging, conversion APIs), built on first-party data. That makes measurement more accurate and easier to control, but it doesn't get you around consent: if a visitor said no, you can't send their data from your server either.

There's an irony here. Chrome never actually dropped third-party cookies: in its October 2025 update, Google confirmed it would keep its user-choice approach and retire several Privacy Sandbox technologies, including the Attribution Reporting API. Yet measurement keeps getting leakier. A "cookieless world" isn't a date to wait for. It's a condition most online shops are already living in.

If Chrome keeps cookies, why is measurement still getting worse?

Because third-party cookies were only ever part of the problem. In practice, three things erode your data.

Safari and ITP

According to WebKit's official documentation, Intelligent Tracking Prevention (ITP) deletes cookies created in JavaScript, along with all other script-writeable storage, after seven days of Safari use without user interaction on the site. That's exactly the kind of cookie most pixels and analytics scripts rely on. If someone clicks an ad and comes back to buy much later, the browser has probably forgotten where they came from.

Consent

In the EU, marketing cookies and tracking require consent, and some visitors decline. That's how it should be. This gap isn't something to patch with tricks; it's something to manage deliberately: know how big it is and plan around it.

Blockers and browser settings

Ad blockers and stricter privacy settings often stop tracking scripts from loading at all. In that case it's not the cookie that's missing; the pixel never runs.

Don't estimate the size of your gap from industry averages. Compare one month of orders from your shop database with what Analytics and your ad accounts report for the same period. That difference is your starting point.

What does server-side tracking do differently?

Client-side, the visitor's browser loads the Meta pixel, the Google tag and the rest, and each one sends data to its own servers. Server-side, the browser sends data to a tagging server reachable on your domain (for example a Google Tag Manager server container), and from there you decide which data goes to which platform, and in what form.

Aspect	Client-side pixel	Server-side tracking
Who sends data to the platform?	The visitor's browser	Your server
What does the platform receive?	Whatever the script can reach on the page	Only what you let through
Business events (payment, cancellation)	Only if there's a thank-you page and it loads	Straight from the backend
Setup	Quick, paste a snippet	Server, configuration, testing
Running it	Minimal	Needs ongoing monitoring

There's one trap worth knowing about. A common setup puts the tagging server on a subdomain (say track.yourdomain.com) that actually points to another provider's network. WebKit's documentation says ITP detects this kind of CNAME and IP address cloaking and caps cookies set in those responses at seven days, even when the server set them. So we try to run tracking on the same infrastructure as the site itself, ideally on the same domain under a path.

How do conversion APIs work in practice?

The Meta Conversions API and Google's server-side conversion options differ in the details, but the idea is the same: the conversion is reported by your server directly, not (only) by the browser. In our view, the best signal isn't the thank-you page but the moment your backend records a successful payment. That way an abandoned checkout never counts as a conversion, and you can handle cancelled orders separately in your own reporting.

Here's how we wire it up:

1. An event in the backend: a successful payment, sign-up or quote request, not a page load.
2. Attach consent: we store the visitor's banner choice with the event (with Google Consent Mode, for example, the ad_user_data and ad_personalization states). Without consent for advertising data, the event doesn't go out with personal data.
3. A unique event ID: if you track from both the browser and the server, we send the same ID down both paths so the platform can filter out duplicates.
4. Data minimisation: we send only the fields the platform actually needs, prepared the way its spec requires.
5. Monitoring: we regularly compare the number of events sent with the number of orders. If they drift apart, something broke, and you'd rather find out on Monday than at month-end reporting.

Before it's mapped to any platform's format, an internal event looks roughly like this:

{
  "event": "purchase",
  "event_id": "order-10482",
  "value": 18990,
  "currency": "HUF",
  "consent": {
    "ad_user_data": "denied",
    "ad_personalization": "denied"
  }
}

Here the purchase happened and lands in your own stats, but no personal data goes to the ad platforms. If you run several surfaces (say an app, a shop and a website, like the ones we built for G8 Alakváltók), this approach pays off even more: events come from one shared backend, not three separate pixels.

How do you keep server-side tracking GDPR-friendly?

This is the most important part, because server-side tracking is often sold as a way around consent. We think that's a dangerous misunderstanding. GDPR governs the processing of personal data, not which machine the code runs on. If you forward an email address or an identifier to Meta from your server, it's just as much a data transfer as if the pixel had done it.

• Consent first, tracking second. Google's Consent Mode overview describes two implementations: in basic mode, Google tags don't load until consent is given; in advanced mode they load, send cookieless pings when consent is denied, and Google may fill the gaps with modelling. Get legal advice before you switch on advanced mode.
• Minimise data on the server. Before anything leaves, you can strip IP addresses, unnecessary URL parameters and device details you don't need. That's the genuine privacy upside of going server-side.
• Be transparent. Your privacy notice should say what data goes to which platform, and why.
• Know where your tagging server runs. Which provider, which region, who has access, and whether a data processing agreement is in place.

We're not lawyers: the legal basis and the wording of your privacy notice should be finalised with a data protection specialist. Our job is to build the technical side so the legal decision can actually be enforced.

What should attribution rest on if the picture will never be complete?

First, let go of the perfect picture. Every platform counts from its own point of view, and in our experience the conversions reported by your ad accounts often don't add up to your real order count. So our order of trust is:

• Your own source of truth: backend order data, tied to UTM parameters and, for logged-in customers, your own identifier.
• Platform numbers as signals: you need them to optimise campaigns, but they're not enough for business decisions.
• Incrementality tests: pause a campaign for a period or in one region and watch what happens to orders. That tells you more than any attribution model.
• Label modelled data: when Google shows modelled conversions, treat them as estimates, not measurements.

Clean conversion data from your backend isn't only for ads, by the way. Every later automation builds on it, including your own AI marketing assistant, which is only as smart as the data it gets.

Frequently asked questions

Does a small online shop need server-side tracking?

Not always. If your ad spend is low and most traffic is organic, sort out consent management and basic analytics first. But if you advertise regularly on Meta or Google and the platform optimises on your data, conversions sent from your backend quickly become your most important signal.

Does server-side tracking replace the cookie banner?

No. Consent management stays. Server-side tracking just lets you enforce the visitor's choice precisely and share less data than a pixel would.

What's the difference between Consent Mode and a conversion API?

Consent Mode tells Google's tags what the visitor agreed to. A conversion API is the channel your server uses to send the event directly. They work together: events sent through the API must respect the consent status too.

Can we track only from the server and drop the browser entirely?

For some events, yes, but in most cases we recommend combining the two: the browser sees on-page behaviour, the server sees the reliable business event. A unique event ID prevents double counting.

If you don't know how big the gap is between your orders and your ad accounts, let's look at it together. On a new online shop we design server-side tracking and consent handling into the backend from day one; on existing systems, our marketing team and developers set it up together.