Conversion APIs With Deduplication You Can Audit

The first number we report on a conversion API engagement is the duplicate rate, and the target is under 1 percent of matched events. A pixel and a Conversions API sending the same purchase without a shared event identifier inflate reported conversions towards double, which then trains bidding on a fiction. Deduplication is not a detail of this work. It is the work. Deduplication first: Every event gets an identifier generated once, server-side, where the order is created, and carried to both transports. We verify in Events Manager, in TikTok Events Manager and in Google tag diagnostics that the platform is genuinely collapsing the pair, then hold a parallel window and compare platform-reported conversions against your order table day by day. If the two do not converge, the implementation is unfinished, whatever the green ticks say. We report the real match quality score. Meta's EMQ rises when you send more identifiers and there is an obvious way to make it rise that we will not use: sending fields you inferred, padded, or collected from people who never agreed to advertising personalisation. A score built that way is a compliance exposure in an attractive colour. Delayed and offline conversions: This is where Brazil departs from the templates. Pix confirms asynchronously and boleto can confirm three days later, so the browser is the wrong place to fire a purchase. We move the event to the payment webhook, with the click identifier stored against the order at checkout, so a boleto paid on Thursday still attributes to Monday's click inside the platform's lookback window. The same mechanism carries CRM outcomes back for long sales cycles. A solar installer whose leads close in sixty to ninety days should be optimising towards signed contracts rather than form fills, which means an offline upload keyed on the click identifier, on a schedule, with the value net of equipment financing. We build the export from your CRM and the ingestion job. We do not leave you pasting spreadsheets into an ads interface every Monday. Where we stop: We do not manage the media. We will brief your buyer on what the events now mean and what changed about the counts. The bidding decisions after that are theirs. We do not build the tagging server. If there is not one, that engagement comes first. We do not send health data. For pharma and medtech clients this is the line the whole engagement is designed around. Under LGPD Article 11 health information is sensitive personal data, Meta's own terms prohibit sending it, and a conversion event whose name identifies a treatment is a disclosure even when the payload is hashed. We build schemas that carry commercial value without carrying condition, and where a client insists on the second, we resign rather than argue it through. We turn down: Work whose stated goal is to make reported conversions rise. Deduplication done properly lowers the number in the platform, sometimes sharply, and the correct response is to rebaseline targets rather than reverse the fix. Work where consent is unresolved. If nobody can tell us which users agreed to advertising personalisation and how that signal reaches the server, we are being asked to guess on your behalf and accept your risk. We would rather wait for the consent work to finish.