Data Manager status diagnostics can expose outcomes by destination. Treating the top-level request as simply successful or failed can hide a destination that rejected events, accepted a subset, or requires a different retry and consent decision.
Use this for WordPress and WooCommerce connectors that send one source event set to several Google destinations, accounts, conversion actions, or downstream workflows.
Quick answer
Store a separate state row for each request and destination. Preserve terminal status, reason counts, timestamps, identifiers, code version, and redacted source map without inventing row detail. Retry only the destination and event set proven safe, using stable event IDs and destination-specific policy. Reconcile reporting, audiences, bidding, and CRM outcomes separately.
What to check first
- Record request ID, source batch, event IDs, destination type, destination ID, conversion action, account, send time, terminal status, reason counts, and last status time.
- Map each destination to consent, identifier, timestamp, schema, deduplication, attribution, reporting, audience, and bidding requirements.
- Test all success, one partial success, one failure, mixed reason counts, unknown reason, delayed destination, retryable transport error, and permanent validation error.
- Keep aggregate destination counts aggregate unless the response or an isolated batch proves exact row ownership.
- Reconcile each destination dashboard and downstream business effect before closing the source batch as complete.
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 |
|---|
| Persist one state per destination | Record request ID, source batch, event IDs, destination type, destination ID, conversion action, account, send time, terminal status, reason counts, and last status time. | Every configured destination has its own status and reason record. |
| Map destination-specific rules | Map each destination to consent, identifier, timestamp, schema, deduplication, attribution, reporting, audience, and bidding requirements. | A successful destination receives no duplicate replay when another destination fails. |
| Separate aggregate and row evidence | Test all success, one partial success, one failure, mixed reason counts, unknown reason, delayed destination, retryable transport error, and permanent validation error. | Aggregate counts remain honest and unknown reasons stay preserved. |
| Retry only proven scope | Keep aggregate destination counts aggregate unless the response or an isolated batch proves exact row ownership. | Ads reporting, audiences, CRM, and internal ledgers match the recorded destination outcomes. |
Why this usually happens
- Destinations validate different fields and identifiers.
- One destination can process later than another.
- Top-level summaries can hide per-destination reason counts.
- A replay safe for one destination may duplicate another destination's accepted events.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request_id: req-A91
source_events: 40
destinations:
- id: ads-1
status: SUCCESS
- id: ads-2
status: PARTIAL_SUCCESS
reasons: {FORMAT_INVALID: 3}
retry_scope: ads-2-only
stable_event_ids: true
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.
- Persist one state per destination
- Map destination-specific rules
- Separate aggregate and row evidence
- Retry only proven scope
- Reconcile every business outcome
Decision rule
Close the source batch only when each destination has a terminal owned result, accepted events are not replayed accidentally, unresolved reasons are visible, and reporting effects are reconciled.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- Every configured destination has its own status and reason record.
- A successful destination receives no duplicate replay when another destination fails.
- Aggregate counts remain honest and unknown reasons stay preserved.
- Ads reporting, audiences, CRM, and internal ledgers match the recorded destination outcomes.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Can a top-level success close every destination?
Use the most specific destination evidence available. A single top-level label should not erase a documented divergent destination result.
Should failed destination events receive new event IDs?
Usually preserve stable event identity when the destination uses it for deduplication, but follow the exact destination contract and business policy.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, reconcile Data Manager destinations.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references