Conversion APIs for Meta, TikTok and Google, Deduplicated

Meta deduplicates the browser event and the server event on the pair of event_name and event_id inside a 48-hour window. If the two layers generate their ids independently, nothing is deduplicated, every purchase is counted twice, and the ROAS your team is planning next quarter's budget against is exactly double the truth. This is the most common finding when we open a conversion API setup that someone installed in an afternoon, and it is why the first thing we do is count, not connect. Where the ids come from: One id per business event, generated once, at the point the order is created, and carried to both the browser and the server. Not generated in the tag, not derived from a timestamp twice, not taken from the order number in one layer and a UUID in the other. Alongside it: action_source set correctly per surface, fbc assembled from fbclid in the documented fb.1.timestamp.fbclid form rather than pasted raw, fbp persisted so a returning visitor is still recognisable, ttclid and ttp handled the same way for the TikTok Events API, and a test_event_code path kept for QA that never reaches production. Match quality, honestly: Meta's event match quality runs 0 to 10 and it moves on identifiers that are actually true: email, phone, the click id. It does not meaningfully move on city and postcode inferred from an IP address, and stuffing those fields to raise a score is how a setup ends up sending invented personal data about real customers. We report the score, we tell you which fields are missing and where in your checkout they could legitimately be captured, and we stop there. On the Google side we implement enhanced conversions with SHA-256 over normalised user-provided data, which requires the customer data terms accepted in the Ads account and the conversion action configured for it. For lead conversions this is a separate switch and it is skipped often enough that we check it first. Consent, before anything is hashed: Identifiers are transmitted only when the consent record grants ad_user_data, evaluated server-side rather than trusted from the client. Declined users are either excluded or sent without identifiers, agreed in writing with your data protection officer before the first event fires, and the declined path is tested in the same session as the accepted one. Value integrity, which is where these setups quietly go wrong: Furniture with an eight-week delivery raises a question with no default answer: does the platform see the conversion at order or at dispatch? Pick one, apply it everywhere, and restate cancellations rather than leaving a phantom order optimising your campaigns for four more weeks. Beauty subscriptions raise the mirror question about the first order versus each recurring charge, and whether the algorithm should be bidding towards both. We make you decide, then we make the events match the decision. What we will not do: We will not bulk-upload a CRM list because a platform representative suggested it. Legal basis first, in writing, or not at all. We will not fix double counting by turning the browser pixel off. That trades one broken number for a worse one, since the server layer cannot see everything the browser can. We will not claim this recovers attribution lost to consent refusal or to iOS. It recovers signal quality and event completeness. Those are different claims and only one of them is true. We do not do incrementality testing or media mix modelling. When your real question is whether a channel is additive, conversion APIs will not answer it, and we will say so instead of selling you this. Who this is not for: Advertisers spending under roughly EUR 50,000 a month per platform, where the default integration is adequate. Teams without a stable order id in their backend. Anyone who wants the numbers to go up rather than to be right.