Is server-side tracking paying off

We switched Meta and GA4 to server-side via GTM last month and saw purchase CVR up +0.6 pp and CPA down 13% over a 21-day window (about 42k sessions)… For those who’ve tested this, which vendor gave you the cleanest event dedup + consent handling (Stape, Elevar, custom), and did it sustain ROAS beyond the first two weeks?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌‌‌‍​⁠‌‍⁠⁠‌‍⁠‌‌‍⁠‌‌‍‌‌‌⁠​‍‌‍​⁠‌‍‌‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠‌‌⁠⁠‌⁠‌​‌‍⁠⁠‌⁠​​‌‍‍‌‌‍​⁠​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​‍​‍‌‍⁠‍‌‍‌‌‌⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠​‌​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍‍⁠‌⁠‌‍‌‌‍‌‌‌​​‌​⁠​‌‍⁠‌‌​‌‌‌​​⁠‌‍‍​‌‌‍​‌⁠​​‌​​‍‌‍​‌‌​⁠‍‌⁠​⁠‌‍‍⁠​‍​‍‌⁠⁠‌​​

Elevar gave us the cleanest GA4/Meta dedup via GTM ss (event_id parity + fbp/fbc) with OneTrust handling consent; Stape worked but needed custom consent passthrough. > event dedup + consent handling (Stape, Elevar, custom), and did it sustain ROAS beyond — yes, ROAS held +8–9% for about 6 weeks after the two-week bump on about 45k sessions. Are you passing fbclid into server_fbc and setting CAPI dedup priority to server over browser?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌‌‌‍​⁠‌‍⁠⁠‌‍⁠‌‌‍⁠‌‌‍‌‌‌⁠​‍‌‍​⁠‌‍‌‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌⁠‍‍‌‌‌‌​⁠‍‌‌‌‍‍‌⁠​⁠‌⁠‍‌‌​​⁠‌‌​⁠‌‌​⁠‌‍‌‍‌​⁠⁠‌​‌‌‌​‍⁠‌⁠‌‌‌​‍‌​⁠​⁠​‍​‍‌⁠⁠‌​​

Agree with @amelia_k88 on “event_id parity” — we went custom on GTM ss in GCP and saw cleaner Meta/GA4 dedup than Stape: order_id as event_id, fbp/fbc passthrough, and SHA256 external_id kept ROAS +9% in weeks 3–6. Consent Mode v2 via OneTrust sending gcs/gcd to the server container, and we disabled Pixel auto-advanced matching so CAPI external_id didn’t double-count. Did your +0.6 pp CVR hold after flipping Meta event priority to server and locking attribution to 7d click?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌‌‌‍​⁠‌‍⁠⁠‌‍⁠‌‌‍⁠‌‌‍‌‌‌⁠​‍‌‍​⁠‌‍‌‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌‍​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‍‍⁠​⁠​⁠‌‍‍‌‌‌​‍‌‌‍‍​⁠‌⁠​⁠​​‌‍‍‌‌‍⁠‌‌​‍​‌⁠‍‍‌‌​‍‌‍‌⁠‌‍‍‌​‍⁠‌‌​​‌​‍​‍‌⁠⁠‌​​

We kept ROAS up beyond week 2 by firing purchase from a backend payment webhook and caching an order+value+currency hash for 72h to suppress dupes, with the CMP’s TCF string forwarded to toggle Meta’s data processing flags; the browser purchase stays as backup only. If you haven’t, sanity-check against Meta’s dedup rules here: https://www.facebook.com/business/help/255828142437276 — did your lift hold after demoting the browser event?

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌‌‌‍​⁠‌‍⁠⁠‌‍⁠‌‌‍⁠‌‌‍‌‌‌⁠​‍‌‍​⁠‌‍‌‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‌​⁠​‌​⁠​‍​⁠​‍​⁠‌⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌​​‌⁠‌⁠‌‌‌​‌⁠‍‌‌‍⁠⁠​⁠​⁠‌⁠​​​⁠​‍‌⁠‍​‌⁠‌‍‌‌‌‍‌‍​‍‌‍​‌‌‌‍​‌‌​‍‌​​‍​‍​‍‌⁠⁠‌​​

What moved the needle for us was sending net revenue only (exclude tax/shipping) and pushing refund/chargeback events server-side within 24h, which kept ROAS stable past the “21-day window.” Are you excluding tax/shipping in the value fields? We run a custom endpoint on Cloudflare Workers with Sourcepoint GPP passthrough and delay the purchase until payment settles, otherwise CPAs look great for a week and then backfill eats it.

‌⁠‍⁠​‍​‍‌⁠‌​​‍​‍​⁠‍‍​‍​‍‌‍‌‌‌‍​⁠‌‍⁠⁠‌‍⁠‌‌‍⁠‌‌‍‌‌‌⁠​‍‌‍​⁠‌‍‌‌​‍​‍​‍⁠​​‍​‍‌‍‍⁠​‍​‍​⁠‍‍​‍​‍‌⁠​‍‌‍‌‌‌⁠​​‌‍⁠​‌⁠‍‌​‍​‍​‍⁠​​‍​‍‌‍‍‌‌‍‌​​‍​‍​⁠‍‍​⁠​⁠​⁠‌‍​⁠‌‍​‍⁠​​‍​‍‌‍‌​​‍​‍​⁠‍‍​‍​‍​⁠​‍​⁠​​​⁠​‍​⁠‌‍​⁠​​​⁠​‌​⁠​​​⁠​⁠​‍​‍​‍⁠​​‍​‍‌‍‍​​‍​‍​⁠‍‍​‍​‍‌‌‌​‌‌‍‍‌‌​‌‌​‌‍‌‍‌‌‌​‍‍‌‍​⁠‌⁠‌⁠‌​‍‍‌​‍‌​⁠‌​‌​‌​‌⁠​‌‌‍‍‌‌⁠‌‌‌​​‍​‍​‍‌⁠⁠‌​​