Server-side Conversions API build for Meta and TikTok

A browser pixel in a Nordic market with a working consent banner sees roughly half of what happened. The number that tells you how bad it is sits in Events Manager: Event Match Quality, scored 0 to 10 per event. Below 6 the bidding model is guessing. We build the server-side stream that carries email, phone, external_id, fbp, fbc, IP and user agent on every purchase, deduplicated against the browser event on event_id, and we do not call the build finished until purchase EMQ reads 8 or higher and server coverage visibly exceeds browser coverage in the graph. Where the events come from: A server-side Google Tag Manager container, on Cloud Run in europe-north1 or on your own EU infrastructure, behind a first-party subdomain with a real certificate rather than a shared vendor host. We name Stape where the volume does not justify running the container yourself, and we say so plainly: below roughly two million events a month it is usually the cheaper correct answer. We do not use Meta's CAPI Gateway. It relays the browser rather than the server, and it inherits the problem you hired us to fix. Destinations: Meta Conversions API, TikTok Events API, Pinterest Conversions API, and LinkedIn's Conversions API where the pipeline is B2B. One container, one event schema, per-destination field mapping, rather than four separate builds that drift apart within a quarter. The parts that break: Deduplication. Meta reconciles a browser and server pair only inside a 48-hour window and only when event_id and event_name both match. Using the order ID as event_id is correct until a customer refreshes the confirmation page or your checkout retries. We specify the idempotency rule and then test it by replaying events against staging. Normalisation. Phone numbers hashed without E.164 formatting match nothing. A Swedish number stored as 070-123 45 67 has to become +46701234567 before SHA-256. Emails lowercased and trimmed. We ship normalisation as code inside the container, not as an instruction in a document your developers will read once. Consent. Consent Mode v2 wired to whichever CMP you run, Cookiebot, Usercentrics or Cookie Information, with the server honouring the signal rather than receiving it and ignoring it. We will not fire server events for a visitor who declined, and we will not sell you the version of this build that quietly does. If that is what you are shopping for, stop here. Conversions that happen away from the site: In logistics and energy the event worth bidding on is signed 20 to 60 days after the click and lives in a CRM. We close that loop: lead identifier from the platform's lead form or a hidden field on your own form, carried through HubSpot, Pipedrive or Dynamics, returned as a CRM conversion with the real contract value and the real date. Bidding on qualified lead and closed won rather than form fill is usually worth more than everything else on this page put together. Not included: No legal advice and no consent decisions taken on your behalf. We implement what your data protection officer signs off. No general tag manager housekeeping, no analytics migration, no attribution modelling or marketing mix work. No ongoing container hosting unless you ask for it as a separate arrangement with its own terms. Who this is not for: Anyone who cannot give an engineer four hours spread across the build. And anyone whose checkout sits inside a platform that will not permit a first-party subdomain or a server-side hook, which is a real constraint on some hosted commerce tiers. We check that on the first call and tell you before an invoice exists. What you receive: A running container under version control with a staging environment, the event schema documented field by field, a replay test suite that fails loudly when a deploy breaks deduplication, match quality and coverage benchmarks from before and after, and a recorded handover with your engineers.