Server-Side Events for Meta, TikTok and LinkedIn Ads

The number that tells you whether this was worth doing: Event Match Quality on your purchase or lead event. A browser-only pixel on a consented site typically lands between 4 and 6 out of 10. A server implementation sending hashed email, phone in E.164 with the country code, an external_id you control, the fbc value rebuilt from the original click, and the IP and user agent of the request that created the order, reaches 8 or above. Below 6, the platform is matching a minority of your buyers and inferring the rest. Where the events come from: Directly from your backend on the order or stage-change webhook, or through a server-side container on a subdomain you own, hosted on your own infrastructure. What we will not do is rename a client-side container and call it server-side. That is the single most common thing we find when we open an implementation someone else has already billed for. Deduplication, done so it can be checked: Pixel and server send the same event_id and event_name; action_source and event_source_url describe what actually happened rather than whatever makes the dashboard busiest. You get a Test Events recording showing the pair arriving and being deduplicated, and a diagnostics review a week after launch. If deduplication is not working, you have double-counted revenue, and the account will spend against it happily. The platforms are not one integration in four coats: LinkedIn matches on work email and company and takes offline stage events; TikTok's click identifier has a shorter cookie life and needs ttclid and ttp captured at the click; Meta wants fbc reconstructed with the click timestamp when the cookie is gone; Snap is built only where it earns a place. We build each to its own surface rather than shipping a lowest-common-denominator payload to all of them. CRM events for long sales cycles: For freight and industrial accounts the useful event is not the form. It is the stage where a salesperson confirmed a live requirement, and it happens 9 to 40 days later. We store the click identifiers against the record at submit, in HubSpot, Salesforce or Zoho, and fire the event on the stage change with the value that stage is worth to you. The platform then learns from your pipeline instead of your form. Consent is not solved by moving the call to a server: UAE and Saudi data protection law, and Consent Mode v2 if you sell into the EEA or UK. A server that fires regardless of consent state is legal exposure with better match rates. Consent is passed through to the server call and logged, and we will show you where. Out of scope: No consent platform selection or purchase. No warehouse or pipeline build. No attribution modelling or media mix work — that is a separate engagement and it belongs after this one is stable, not alongside it. We also decline to hash placeholder identifiers to lift a match score, which we have been asked to do more than once. Not for you if: Your engineering team cannot ship inside the window. This is not work an agency does alone. Someone with deploy access has to be available for the webhook and the identifier storage, and if that person does not exist yet, that hire comes before this project. We would rather delay a start date than deliver a specification into a queue and invoice for it.