Data Manager API Partial Failure Retry Queue for WordPress
When a Data Manager API upload accepts some WordPress lead rows and rejects others, the retry logic must separate temporary failures from permanent data problems. Re-uploading everything can duplicate conversions or hide consent issues.
Use this for WordPress form, WooCommerce, CRM, or call-tracking pipelines that send offline conversions or enhanced conversions for leads through Google's Data Manager API.
Quick answer
Data Manager API Partial Failure Retry Queue for WordPress should be handled with a narrow evidence-first workflow: assign event ids, classify responses, retry temporary rows, then verify the result before making broader changes.
What to check first
- Store an internal event ID before upload so accepted and rejected rows can be reconciled.
- Classify each response as accepted, temporary failure, permanent failure, duplicate, or consent blocked.
- Retry only temporary failures and keep the original event ID stable.
- Send permanent failures to a review queue with the field, value, reason, and source lead ID.
- Reconcile uploaded conversions against CRM stage changes and Google Ads reporting windows.
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 |
|---|---|---|
| Assign event IDs | Store an internal event ID before upload so accepted and rejected rows can be reconciled. | Accepted rows are not resent during retry jobs. |
| Classify responses | Classify each response as accepted, temporary failure, permanent failure, duplicate, or consent blocked. | Temporary failures keep the same event and dedupe IDs. |
| Retry temporary rows | Retry only temporary failures and keep the original event ID stable. | Permanent failures include a clear field-level reason. |
| Review permanent errors | Send permanent failures to a review queue with the field, value, reason, and source lead ID. | CRM and Google Ads totals reconcile within the expected attribution window. |
Why this usually happens
- Offline conversion pipelines often start as CSV exports before they have durable row status.
- A single bad email hash, missing click ID, or invalid timestamp should not block clean rows.
- Changing event IDs during retries can create deduplication problems.
- The Google Ads API offline conversion import changes have increased urgency around Data Manager API migration.
Field notes
- Treat accepted rows as immutable. Fix and retry rejected rows separately.
- Store the API request ID or response trace with the upload batch so support can audit it later.
- Never retry rows missing required consent until the consent source is corrected.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
retry_queue_row:
internal_event_id: lead_89342_stage_sql
source: gravity_forms
upload_batch: 2026-07-01-01
status: temporary_failure
attempts: 2
last_error: DEADLINE_EXCEEDED
retry_after: 2026-07-01T15:00:00Z
dedupe_key: lead_89342_sql
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.
- Assign event IDs
- Classify responses
- Retry temporary rows
- Review permanent errors
- Reconcile uploads
What to tell the client or owner
Tell the marketing owner how many rows were accepted, how many were retried, how many need source-data fixes, and which rows were blocked by consent policy.
Production verification checklist
- Accepted rows are not resent during retry jobs.
- Temporary failures keep the same event and dedupe IDs.
- Permanent failures include a clear field-level reason.
- CRM and Google Ads totals reconcile within the expected attribution window.
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, repair WordPress offline conversion uploads.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.