Data Manager request diagnostics can identify duplicate GCLID and duplicate transaction ID outcomes. WordPress and CRM pipelines should preserve click time, conversion action, order ID, and internal lead ID so support can tell intentional deduplication from accidental reuse.
Use this for Google Ads offline conversions, enhanced conversions for leads, WooCommerce purchases, and CRM stage uploads.
Quick answer
Retrieve the asynchronous result for the original request and identify the destination and reported duplicate reason before retrying. Compare the business event, action, time and transaction identifier with the earlier upload. Keep a retry of the same event stable; do not invent a new identifier just to bypass a duplicate result.
What to check first
- Capture request ID, lead or order ID, conversion action, event time, GCLID, and transaction ID.
- Check whether the same GCLID and conversion time were uploaded more than once.
- Check whether the same transaction ID and conversion action represent one purchase or a reused ID.
- Trace retries, queue replays, test data, and CRM merges that could duplicate the row.
- Suppress true duplicates and assign new stable IDs only to genuinely different business events.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture keys | Capture request ID, lead or order ID, conversion action, event time, GCLID, and transaction ID. | Every source event has one documented deduplication key. |
| Check click-time pair | Check whether the same GCLID and conversion time were uploaded more than once. | True duplicates are suppressed without changing IDs. |
| Check order-action pair | Check whether the same transaction ID and conversion action represent one purchase or a reused ID. | Distinct business events use distinct stable identifiers. |
| Trace replay source | Trace retries, queue replays, test data, and CRM merges that could duplicate the row. | Accepted, duplicate, corrected, and retried counts reconcile. |
Why this usually happens
- A retry queue may resend accepted rows after losing request status.
- Test and production systems can share order-number ranges.
- A CRM merge can replay the same lead stage.
- An identifier alone is not a complete diagnosis. Include the destination and conversion action when comparing events; do not assume that the same identifier across different actions is automatically invalid.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
dedupe_review:
request_id: req-d88
source_id: WC-10640
conversion_action: purchase
gclid: redacted
event_time: 2026-07-12T12:44:00Z
transaction_id: WC-10640
prior_request_id: req-d61
decision: suppress_duplicate
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture keys
- Check click-time pair
- Check order-action pair
- Trace replay source
- Suppress or correct
What to tell the client or owner
Report request IDs, redacted identifiers, conversion action, duplicate reason, replay source, and final row decision.
Production verification checklist
- Every source event has one documented deduplication key.
- True duplicates are suppressed without changing IDs.
- Distinct business events use distinct stable identifiers.
- Accepted, duplicate, corrected, and retried counts reconcile.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix duplicate offline conversion uploads.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references
Separate validation from processing
Google's current offline-conversion workflow distinguishes validateOnly checks for fast-fail errors from asynchronous processing diagnostics. Retain the ingestion request ID and inspect requestStatusPerDestination before classifying a retry. A successful validation is not evidence that a production event was processed, matched or counted.
A minimal replay worksheet
- Original attempt: source event ID, destination, conversion action, event time and request ID.
- Processing result: destination-specific state, reported reason and observation time.
- Retry decision: same event retry, corrected input, genuinely different event or manual investigation.
- Reconciliation: one business event should not become two internal successes simply because two HTTP calls returned successfully.
Use synthetic records for replay tests and redact click identifiers from shared reports. Preserve the original event record when correcting a queue mapping. This worksheet is a suggested operational check, not evidence that a particular upload was accepted.
Related: verify consent updates before navigation so consent-state errors are not misdiagnosed as duplicate-event errors.
Processing guidance checked October 17, 2026 against Google's offline conversion and request-status documentation.