GA4 Consent Mode v2 and Meta Conversions API: how to set up server-side conversion tracking for e-commerce

Why browser-based tracking is no longer enough

Conversion data gets lost for four different reasons, and each one is fixed by a different tool.

Cause of loss	What happens	Solution layer
Safari ITP, Firefox ETP	Third-party cookies are blocked; script-set first-party cookies are capped at 7 days, in some cases 24 hours. A customer returning after 7 days counts as “new”.	Server-side tagging, first-party cookies
Ad blockers	Pixel and gtag.js never load. Noticeable on a meaningful share of desktop traffic.	CAPI / server-side delivery
iOS ATT and in-app browsers	On pages opened inside Instagram/Facebook the Pixel signal weakens; attribution breaks.	CAPI + fbc/fbp parameters
Consent rejection (GDPR, ePrivacy)	No cookies can be set for a user who rejects the banner; nothing is measured.	Consent Mode v2 modelling

Meta reports an average 13% improvement in cost per result for advertisers using the Pixel together with CAPI. Google documents that Consent Mode modelling recovers a significant share of conversions lost to consent rejection, depending on the consent rate. Under GDPR and the ePrivacy rules, non-essential cookies require explicit consent, so consent management is a technical requirement in every EU market, Germany included.

Consent Mode v2: four signals and two modes

Signal	Controls	If denied
analytics_storage	GA4 cookies (_ga)	GA4 sends cookieless pings; sessions and users are modelled
ad_storage	Advertising cookies (_gcl_*)	Click IDs are not stored; conversions are modelled
ad_user_data	Sending user data to Google for advertising	Enhanced conversions and audience data are not sent
ad_personalization	Personalised ads / remarketing	User is not added to remarketing lists

Basic mode: no Google tag loads until consent is given; no data arrives from users who reject, and modelling relies on general rates. Advanced mode: tags always load but send cookieless pings without consent; modelling is based on those pings and is more accurate. We recommend advanced mode for e-commerce; if your legal team considers the cookieless ping to be data processing, stay in basic mode.

Implementation: default to denied, update on choice

The critical rule: the consent default command must run before gtag or GTM loads, at the very top of the page. Otherwise the first hit counts as consented.

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){ dataLayer.push(arguments); }
gtag('consent', 'default', {
  analytics_storage: 'denied',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500          // wait up to 500 ms for the CMP
});
</script>
<!-- GTM / gtag.js loads after this -->

// When the user makes a choice in the banner:
gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

If you use GTM, use your consent platform’s (CMP) template bound to the “Consent Initialization” trigger; tools on Google’s certified CMP list do this out of the box. Every tag must declare which signal it requires under its “Consent settings”.

Thresholds for modelling to work in GA4

Behavioural modelling does not switch on automatically. Google’s conditions: Consent Mode must be set up correctly, the property must receive at least 1,000 events per day with analytics_storage: denied for at least 7 days, and have at least 1,000 consented daily users on at least 7 of the previous 28 days. Small stores will not reach this; then only consented data is reported, which is normal.

Meta Conversions API: send events from the server

Deduplication: not counting the same event twice

The Pixel and CAPI report the same purchase through two separate routes. To merge them into one event Meta looks for the same event_name and the same event_id; the second arrival within 48 hours is discarded. The event_id must be deterministic, such as the order number, never randomly generated.

// Browser (Pixel)
fbq('track', 'Purchase',
    { value: 129.90, currency: 'EUR', content_ids: ['HON-PINE-450'], content_type: 'product' },
    { eventID: 'order_104233' });

// Server (CAPI) – POST https://graph.facebook.com/v22.0/{PIXEL_ID}/events
{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1760700000,
    "event_id": "order_104233",
    "event_source_url": "https://www.example-store.com/checkout/thank-you",
    "action_source": "website",
    "user_data": {
      "em": ["<sha256(lowercase email)>"],
      "ph": ["<sha256(E.164 phone, no + or spaces)>"],
      "client_ip_address": "203.0.113.4",
      "client_user_agent": "Mozilla/5.0 ...",
      "fbp": "fb.1.1760699000000.123456789",
      "fbc": "fb.1.1760699000000.IwAR0..."
    },
    "custom_data": { "value": 129.90, "currency": "EUR", "content_ids": ["HON-PINE-450"], "content_type": "product", "order_id": "104233" }
  }]
}

Event Match Quality (EMQ): how well your events match

For every event, Meta scores from 1 to 10 how well the user parameters you send (email, phone, name, city, postcode, fbp, fbc, IP, user agent) match real accounts. The practical target is 6 or above; 8+ is achievable on Purchase because you hold email and phone at checkout. All personal fields must be sent SHA-256 hashed, lower-cased and trimmed; fbp, fbc, IP and user agent are not hashed.

Architecture options: which one is right for you?

Option	How it works	Pros	Cons	Best for
The platform’s built-in integration (Shopify Facebook & Instagram, Google & YouTube apps)	The platform manages Pixel + CAPI and conversion upload itself, checkout events included	Minutes to set up, deduplication built in, complete checkout data	Custom events and parameters are limited	Most stores on Shopify, WooCommerce and similar platforms
Server-side GTM (sGTM)	Browser GTM → sGTM container on your own subdomain → GA4, Meta CAPI, Google Ads	First-party cookies, full control, consent managed in one place, data enrichment	Hosting cost (Cloud Run or a managed service), maintenance	Multi-channel stores with a meaningful monthly ad budget
Direct backend integration	The application server POSTs to the Graph API when an order is created	Offline/CRM events (returns, repeat orders) can be sent	Needs a developer, does not cover browser events	Custom software, B2B portals, CRM connections

Step-by-step setup (GTM + sGTM scenario)

1. Choose a CMP and set up the banner. Localised copy, a “Reject” button as visible as “Accept”; the choice can be stored for up to 180 days. A Google-certified CMP generates Consent Mode v2 signals automatically.
2. Put the consent default at the top of the page (code above). The GTM container must load after it.
3. Enable consent settings in GTM: Admin → Container settings → Enable consent overview. Require analytics_storage on the GA4 tag and ad_storage + ad_user_data on Google Ads and Meta tags.
4. Set up the sGTM container on Google Cloud Run or a managed provider, on a first-party subdomain such as gtm.yourstore.com. Put that address in the server_container_url field of the browser GA4 tag.
5. Create the GA4 client and tag in sGTM. sGTM receives the GA4 requests from the browser and forwards them to GA4; cookies are now first-party.
6. Add the Meta CAPI tag in sGTM (Meta’s official “Conversions API Tag” template). Use the same variable for event_id as the browser Pixel; fill user_data from the data layer (hashed). Fire the CAPI tag only on hits with ad_storage and ad_user_data granted.
7. Standardise the data layer. Send view_item, add_to_cart, begin_checkout and purchase in the GA4 e-commerce schema; map them to Meta event names in sGTM (ViewContent, AddToCart, InitiateCheckout, Purchase).
8. Test. GA4 DebugView, Tag Assistant (both web and server preview), Meta Events Manager → Test events. In the test event, the “Browser” and “Server” rows must show the same event_id as “Deduplicated”.
9. Monitor. EMQ and deduplication rate in Meta Events Manager; Consent Mode status under GA4 Admin → Data collection; the conversion “Diagnostics” tab in Google Ads.

Quality checklist

Check	Target	Where to look
Consent default runs before GTM	First hit carries “denied” signals	Tag Assistant → Consent tab
All four signals update	All “granted” on accept	Tag Assistant / dataLayer
Pixel and CAPI deduplication	95–100% matched events	Events Manager → event → Deduplication
Event Match Quality (Purchase)	≥ 6, ideally 8+	Events Manager → event → EMQ
Purchase value and currency	Order total, correct currency	GA4 DebugView, Test events
Gap between GA4 and platform order counts	< 10%	GA4 Monetization report ↔ store admin
First-party cookie	_ga set by the server	DevTools → Application → Cookies

Common mistakes

• Running consent default after GTM. The first page view goes out as consented; it is the first thing an audit checks.
• Random event_id. Browser and server generate different IDs, Meta counts both; purchases look doubled and ROAS is inflated.
• Unhashed email/phone. Meta rejects raw data and EMQ drops. Phone must be in E.164 format (4915112345678) and hashed.
• Firing CAPI even when consent is denied. Being server-side does not remove the need for consent; it is a GDPR risk. Bind the CAPI tag to the consent signal as well.
• Relying on old checkout scripts. On Shopify, checkout.liquid is gone; old Pixel code placed on the thank-you page no longer runs.
• Looking at a single source. GA4, Meta and the store admin never match exactly; differences within 10% are normal, anything above is investigated.

Measurement infrastructure should be planned together with site speed and structured data: the Shopify Core Web Vitals guide and the Schema.org JSON-LD guide for e-commerce complement this article.