Data Manager request status can report `PARTIAL_SUCCESS` with reason counts but not a row-level mapping. Blindly retrying the original batch risks duplicates, while logging or splitting production personal data carelessly creates a privacy problem.
Use this for server-side WordPress and WooCommerce uploads where a controlled replay is allowed, event IDs are stable, destination rules are known, and a partial-success batch needs safe isolation.
Quick answer
Preserve the original request and redacted row map, then first remove causes detectable locally with schema and consent validation. For a reproducible aggregate failure, partition only the unresolved synthetic or approved replay set into stable halves, send each with immutable event IDs and separate request IDs, and compare terminal reason counts. Stop when the smallest actionable group or a non-reproducible condition is found.
What to check first
- Record original request ID, terminal status, destination, total events, accepted count if available, reason counts, send time, code version, and a redacted source-row map.
- Run local format, consent, timestamp, identifier, destination, and deduplication checks before sending any diagnostic replay.
- Define whether the destination can deduplicate immutable event IDs and whether replay could change bidding, reporting, audience, or customer state.
- Partition deterministically by non-personal row ID, send one subset at a time with separate request IDs, and poll using the documented delay, backoff, jitter, and terminal-state rules.
- Compare reason vectors rather than only success status, stop at the smallest useful group, and delete temporary diagnostic maps according to retention policy.
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 |
|---|
| Preserve the original evidence | Record original request ID, terminal status, destination, total events, accepted count if available, reason counts, send time, code version, and a redacted source-row map. | Every diagnostic send has a unique request ID and stable event IDs. |
| Validate locally before replay | Run local format, consent, timestamp, identifier, destination, and deduplication checks before sending any diagnostic replay. | Reason counts reconcile across partitions or the run records why they do not. |
| Prove destination deduplication | Define whether the destination can deduplicate immutable event IDs and whether replay could change bidding, reporting, audience, or customer state. | No duplicate conversion, audience, billing, or customer action appears. |
| Bisect deterministically with new request IDs | Partition deterministically by non-personal row ID, send one subset at a time with separate request IDs, and poll using the documented delay, backoff, jitter, and terminal-state rules. | Temporary row maps are access-controlled, redacted, and deleted on schedule. |
Why this usually happens
- Asynchronous diagnostics can aggregate errors by reason and destination.
- Several bad rows can share one reason count.
- A destination can accept part of a batch before status is retrieved.
- Uncontrolled replay can create duplicate conversions or expose personal data in logs.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
original_request: req-A
events: 64
status: PARTIAL_SUCCESS
reason_counts: {FORMAT_INVALID: 3}
partition_key: stable_redacted_id
left_request: req-A-L
right_request: req-A-R
event_ids_reused: true
destination_dedup_verified: true
smallest_failing_group: 4
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.
- Preserve the original evidence
- Validate locally before replay
- Prove destination deduplication
- Bisect deterministically with new request IDs
- Classify and remove temporary evidence
Decision rule
Use bisection only when replay is authorized and idempotent. Pass when the smallest actionable group is isolated without duplicate business effects, personal-data leakage, or false row attribution.
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 diagnostic send has a unique request ID and stable event IDs.
- Reason counts reconcile across partitions or the run records why they do not.
- No duplicate conversion, audience, billing, or customer action appears.
- Temporary row maps are access-controlled, redacted, and deleted on schedule.
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
Does bisection prove which exact event failed?
It narrows a reproducible problem. Exact attribution still requires a singleton result or direct API evidence, and changing service conditions can make failures non-deterministic.
Can production conversions be replayed safely?
Only after confirming destination deduplication, stable event IDs, consent, timestamp rules, and business impact. Prefer synthetic fixtures when possible.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, 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, debug Data Manager partial success.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references