A mover can record one inquiry several times without realizing it: a form event fires twice, a thank-you page reloads, a connector retries or two conversion actions describe the same outcome. Preventing duplicates requires a definition of the business event and an inventory of every delivery path. Reducing the reported count is not enough; the remaining count must still represent real opportunities.
View full-size graphic ↗List every path that reports the outcome
Scroll the table horizontally to compare all columns.
| Path | Possible duplication | Evidence to inspect |
|---|---|---|
| Form and confirmation page | Both report the same submission | Tag triggers and request identity |
| Browser and server delivery | Same event arrives twice | Destination-specific shared identifiers |
| CRM connector retry | A retry creates another event | Delivery log and stable event key |
| Native ad event and analytics import | Separate actions describe one outcome | Conversion-action inventory |
| Repeat calls | Follow-up counted as new demand | Call-to-opportunity relationship |
Map each path to a precise event: inquiry received, qualified opportunity or booked job. Distinct stages are not duplicates merely because they concern the same customer. The problem is multiple reports of the same intended event, or goals that unintentionally reward it more than intended.
Save the current configuration before changing it. A cleanup should be reviewable and should not erase the evidence needed to explain historical reporting.
Assign stable identity to the business event
Use an opaque identifier tied to the actual inquiry or milestone. The same event must retain its identity across retries; a genuinely new opportunity needs a new identity. Do not generate a fresh random ID every time the delivery code runs.
Google Ads documents transaction-ID deduplication for the same conversion action and warns against reusing a static ID across different transactions. It also prohibits customer-identifying information in the identifier. Its Count setting is a separate control, not a substitute for event identity. [1]
Check the current destination's matching rule
The current Google Data Manager guide describes same-action multi-source deduplication using matching transactionId values. That does not establish deduplication across different conversion actions or across separate advertising platforms. [2]
For other destinations, verify the current official requirements and supported integration behavior. Do not assume Google's field name, scope or retry semantics apply to Meta or another platform. The principle is shared identity; the implementation is destination-specific.
Audit goal selection as well as delivery
An event can be delivered correctly yet counted through multiple actions that serve the same business purpose. Review native tags, analytics imports, call integrations and CRM outcome imports together. Decide which action represents the intended optimization signal.
Google distinguishes primary and secondary actions under standard goals, with an important custom-goal exception. Review the actual campaign goal configuration rather than assuming a secondary label always excludes an action from bidding. [3]
Use the booked-job import guide for the downstream outcome workflow. This guide focuses on repeated delivery and overlapping definitions.
Run a controlled event-identity test matrix
Scroll the table horizontally to compare all columns.
| Scenario | Expected business result | Identity behavior |
|---|---|---|
| One valid inquiry | One inquiry event | New stable event ID |
| Same delivery retried | Still one inquiry event | Reuse the original ID |
| Confirmation page reloaded | No new business inquiry | Do not create a new ID |
| Same person requests a separate move | A distinct opportunity if genuinely new | New opportunity/event identity |
| Inquiry becomes booked | A distinct defined milestone | Preserve relationship, use the milestone's identity |
| Two delivery sources report one event | One intended outcome under supported rules | Use the required matching key |
Use safe test environments or approved platform diagnostics. Do not feed fabricated qualified or booked jobs into live optimization as a routine test. Record the request, delivery result and destination interpretation without exposing customer secrets.
Verify both positive and negative cases. A shared static ID may remove duplicates by suppressing almost everything, which is a serious undercounting error. The separate-new-opportunity test helps catch that failure.
Distinguish receipt, attribution and reporting
A successful delivery response does not prove that an event is attributed, eligible for optimization or visible in every report. Compare system logs with destination diagnostics and allow for documented processing behavior.
Reconcile unique CRM opportunities and milestones with each platform's defined view. Do not sum platform-attributed conversions as though they were necessarily unique company jobs. Cross-platform attribution overlap is a different issue from duplicate event delivery.
When discrepancies remain, inspect a small approved sample. Record the event identity, action, timestamp, delivery path and observed result. This creates a useful debugging case without guessing from aggregate totals.
Keep duplicate checks in the change process
Re-run the matrix after form changes, tag-manager releases, new plugins, CRM migrations or connector updates. Maintain an owner for the conversion-action inventory and remove obsolete paths deliberately after reviewing dependencies.
Document changes to measurement so trend reports remain interpretable. A lower conversion count after a correction may reflect better accuracy rather than worse acquisition. Explain the break in comparability instead of hiding it.
A tracking and attribution audit should inspect identity, delivery and goal configuration together. The CRM source-field guide helps preserve the provenance behind those events.
Common questions
Does setting Google Ads to count one conversion solve all duplicates?
No. The Count setting and transaction identity address different behavior. Duplicate delivery, overlapping actions and cross-platform attribution still need explicit review.
Should the same customer always use the same conversion ID?
No. Identity should match the defined business event. A retry of one event retains its ID, while a genuinely separate moving opportunity or milestone needs the appropriate distinct identity.
Your next step
Define the event, inventory its delivery paths and test stable identity. Accurate deduplication preserves real new opportunities while preventing repeated reports of the same outcome.
Sources & editorial notes
Platform claims cite the documents below. Operating frameworks and labeled examples are MoverFuel editorial analysis, not client results or industry benchmarks.
- Google Ads: transaction IDs and duplicate conversionsGoogle Ads documents same-action transaction-ID deduplication, unique non-PII identifiers and the separate Count setting. Reviewed .
- Google Data Manager API: send Google Ads offline eventsCurrent Data Manager guidance describes matching transactionId values for same-action multi-source deduplication. Reviewed .
- Google: primary and secondary conversion actionsPrimary/secondary action behavior depends on standard versus custom goals and campaign configuration. Reviewed .
