Server-Side Events API Build for Meta and TikTok

What the first measurement usually says: On the Czech and DACH storefronts I have instrumented, browser-only pixel tracking reports thirty to forty-five percent fewer purchases than the shop's own order table. Safari's tracking prevention, ad blockers and consent refusals account for most of it, and the loss is not spread evenly. It falls hardest on mobile, high-intent traffic, which is exactly the traffic you want the optimiser learning from. A server-side implementation does not invent conversions. It reports the ones that already happened, with enough matching data attached that Meta and TikTok can attribute them. What gets built: A server-side container you own. Google Tag Manager server-side on Cloud Run, or on your own VPS if you would rather not carry that dependency, receiving from the storefront and fanning out to Meta Conversions API and TikTok Events API. Every event carries an event_id shared with the browser pixel so deduplication actually works; without it you get double counting that looks like a win for about a month. Click identifiers are the part usually done badly: fbclid and ttclid captured on landing, written to first-party cookies with the correct lifetime, and replayed on the server event, so a purchase two weeks after the click still attributes to it. Match quality is the number I hold myself to. I target Event Match Quality of 7.0 or better on purchase and tell you which fields get you there. Hashed email and phone do most of the work; city, postcode and external_id close the remaining gap on guest checkout. Consent, and where I stop: Czech law implements the ePrivacy opt-in requirement, which means consent before non-essential storage. Consent Mode v2 signals, ad_user_data and ad_personalization, are carried through to both platforms, and events from a refusing visitor are dropped at the container rather than sent with a flag attached and hoped over. I will not build a server-side path whose purpose is to transmit data a visitor declined. If that is what is wanted, this is the wrong engagement and I will say so on the first call rather than after the invoice. For pharma and medtech there is a harder line. Nothing leaves a symptom checker, dosage tool, patient portal or prescription flow, hashed or not. Hashing an email that exists only because someone looked up a condition still transmits the condition. Those flows get a coarse page-level event or nothing at all, and your regulatory lead signs the event taxonomy before anything goes live. Not included: No GA4 rebuild, no CDP migration, no warehouse modelling. No consent platform selection or purchase; I work with the one you have or the one your counsel approves. No creative, no media buying, no ongoing campaign management under this engagement. How it gets verified: Fourteen days of parallel running, browser and server events side by side, reconciled against your order table with each discrepancy explained line by line rather than averaged into a tolerance. You receive the event taxonomy as a written document, the container configuration inside your own accounts, and a handover session with whoever maintains your storefront. If you are on Shopify, expect the Web Pixels sandbox to constrain what can be read at checkout, and expect to hear that before the work starts. Who this is not for: Teams with no engineering availability at all. This needs a few hours of someone who can deploy to your storefront, and without them the build stalls at the first DNS record.