dedup-verificationlisted

# Dedup verification Once you send the same conversion from the browser and from your server, you are either deduplicating or double counting. Reporting looks plausible either way. Nothing in the interface announces which one you have. ## How the match is made The platform collapses two events into one when they carry the **same event name and the same event ID**, within a matching window. Treat the window length as a platform detail to look up rather than memorise, because it has changed before. Browser identifiers can act as a weaker fallback pairing, but a fallback is not a design. If your dedup depends on it, you do not have dedup. ## The one rule that decides everything **The event ID must come from a shared business key, generated once.** An ID minted independently on each side — a fresh random value in the browser and another on the server — can never match. This is the single most common cause of silent double counting, and it passes every "is the tag firing" check. Use the transaction, order, lead or payment identifier. Generate it once, pass it into the browser payload and into the server payload. If no such key exists at the moment the event fires, that is the finding: the ID problem is an application problem, not a tracking problem. ## Reading the symptom Compare platform-reported conversions for an event against the business record for the same window. | Ratio | Most likely reading | |---|---| | Near 2.0, stable across days | Dedup is failing outright