Skip to main content
C
CookieBeam
Back to Guides
Integration6 min read

Server-Side Conversions API With Consent (Meta & Google)

How to run Meta and Google Ads conversion tracking through a server-side GTM container, with event deduplication done right and consent enforced before any conversion leaves your server.

Why Conversions Moved to the Server

The single most valuable thing most teams do with a server-side GTM container is send conversions through it. Browser-based conversion tracking, the classic Meta Pixel and Google Ads tag, loses data to ad blockers, to Safari's cookie restrictions, and to iOS privacy features. The Conversions API (CAPI) model answers that by sending the conversion from your server directly to the advertising platform, server to server, instead of relying entirely on a browser request that may never complete.

Done well, this recovers conversions you were losing and makes your reported numbers more complete. Done carelessly, it double-counts sales or forwards data for people who declined tracking. This guide covers both halves: the setup, and the consent discipline that has to sit in front of it. For the container itself, start with How to Set Up a Server-Side GTM Container.

How Server-Side Conversions Flow

The path is straightforward once you see it:

  • The browser sends an event (a purchase, a lead) to your server container on your first-party subdomain, usually via a GA4 event that the server's client parses.
  • The server container holds one or more conversion tags: Meta's Conversions API tag, the Google Ads conversion tag, and typically a GA4 tag forwarding to Analytics.
  • Each tag forwards the conversion server-to-server to its destination, attaching the identifiers that platform needs to match it to a click or a user.

Meta has officially published a Conversions API tag template for server-side Google Tag Manager, so you configure it inside the container rather than writing custom code. Google Ads and GA4 tags run in the same container. The server becomes the one place where every conversion is assembled and dispatched.

Deduplication: The Step Everyone Gets Wrong

If you send a conversion both from the browser pixel and from the server, the platform will count it twice unless you tell it they're the same event. This is deduplication, and it's the most common source of inflated server-side numbers.

For Meta, the rule is specific: the browser event and the server event must carry the same event_id, and it helps to send the same _fbp and _fbc cookie values from both. Meta matches on the event ID and discards the duplicate. If the IDs don't match, Meta may double-count or drop the events entirely.

// Generate one shared event_id in the browser, send it BOTH ways.
const eventId = crypto.randomUUID();

// 1) Browser pixel event
fbq('track', 'Purchase', { value: 49.90, currency: 'EUR' },
    { eventID: eventId });

// 2) Same id into the dataLayer so the server tag reuses it
window.dataLayer.push({
  event: 'purchase',
  event_id: eventId,        // server CAPI tag reads this
  value: 49.90,
  currency: 'EUR'
});
Copy code to clipboard

The principle is one event, one identifier, two transports. Generate the event_id once, use it for the browser pixel and the server event, and the platform reconciles them into a single conversion. The same discipline applies to Google's Enhanced Conversions, where hashed first-party data supplements the click identifier. Our Server-Side Tracking Validation guide shows how to confirm deduplication is working before you trust the numbers.

A Conversion Is Personal Data, Enforce Consent First

Sending a purchase to Meta or Google, with email hashes, cookie IDs, or IP addresses attached, is processing personal data for advertising. Moving it to the server doesn't change that. If a visitor declined marketing consent, the conversion must not be forwarded, no matter how much you'd like the attribution. Enforce the decision inside the server container: check the consent state on every event and drop or strip advertising conversions when consent is absent. A server that fires CAPI regardless of consent is a compliance liability that's harder to detect than a client-side pixel.

Wiring Consent Into the Conversion

There are two layers of consent to respect, and you need both.

1. Google Consent Mode v2 for Google destinations

Since March 2024, advertisers targeting the European Economic Area must implement Consent Mode v2 to keep using Google's ad personalization, remarketing, and measurement features. Version 2 added two signals your tags must receive: ad_user_data, which controls whether user data may be sent to Google for advertising, and ad_personalization, which controls whether it may be used for personalized advertising and remarketing. Your server-side Google Ads and GA4 tags must respect these signals. For the mechanics, see Consent Mode: Advanced vs Basic and GA4 and Google Ads Consent Mode.

2. A hard consent gate for every conversion

Consent Mode governs Google's own behavior, but it doesn't gate Meta's Conversions API or any non-Google destination. For those, the server container itself must check the visitor's consent state, carried in with the event, and refuse to forward advertising conversions when consent was not given. Build the check once, at the point where conversions leave the server, so nothing slips past it.

Modeling Isn't a Substitute for Consent

Google's Advanced Consent Mode can send cookieless pings for non-consenting users and model the conversions you can't observe directly, which recovers some measurement without storing identifiers. That's a legitimate feature, but it isn't a licence to forward identifiable conversions without consent. Keep the two separate: model the gap for denied consent, forward real identifiers only for granted consent. Conflating them is how well-intentioned setups drift into non-compliance.

Making It Consent-Native With CookieBeam

The hard part of all this is getting the visitor's real consent decision into the server container at the moment a conversion is about to fire. CookieBeam's server-side GTM add-on stores the consent choice in a first-party cookie and exposes it inside the server container, so your Meta CAPI and Google Ads tags can read the actual decision and gate on it, rather than guessing from a client-side flag that may be stale. Consent enforcement and conversion forwarding end up in the same place. See Server-Side Consent Enforcement for the enforcement model and the CookieBeam GTM integration for how the signal originates.

Related Guides and Sources

Continue with Server-Side Tracking Validation, How to Debug Consent Mode v2, and Server-Side vs Client-Side GTM. Primary sources: Meta's Conversions API for Server-Side Google Tag Manager, Google's Consent Mode updates for the EEA, and the server-side tagging documentation.

Back to all guides
Server-Side Conversions API With Consent (Meta & Google) | CookieBeam | CookieBeam