Google Data Manager API can send Google Analytics purchase events as an additional data source, but a purchase can be rejected when it references zero or multiple Analytics destinations or omits a required identifier, transaction ID, event name, cart data, value, or currency.
Use this for WooCommerce server-side purchase events, GA4 reconciliation, Google Ads plus Analytics multi-destination requests, agencies, and data partners building a shared event pipeline.
Quick answer
Data Manager API GA4 Purchase Destination Reference Mapping should be handled with a narrow evidence-first workflow: name destinations, select one ga4 reference, map required fields, then verify the result before making broader changes.
What to check first
- Create unique request-level references for Google Ads and each Google Analytics destination.
- Set exactly one Analytics destination reference on each GA4 event and keep Ads destinations explicit where used.
- Map eventName purchase, clientId or another accepted identifier, transactionId, cartData, conversionValue, and currency.
- Reconcile item IDs, quantities, tax, shipping, discounts, and total against the final WooCommerce order rather than browser draft state.
- Use validate-only or a test destination where available, then retrieve request status and compare the accepted purchase with GA4.
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 |
|---|
| Name destinations | Create unique request-level references for Google Ads and each Google Analytics destination. | The API accepts the synthetic purchase without MULTIPLE_DESTINATIONS_FOR_GOOGLE_ANALYTICS_EVENT. |
| Select one GA4 reference | Set exactly one Analytics destination reference on each GA4 event and keep Ads destinations explicit where used. | The accepted event uses the final order transaction ID, value, currency, and item totals. |
| Map required fields | Map eventName purchase, clientId or another accepted identifier, transactionId, cartData, conversionValue, and currency. | A retry preserves the same transaction ID and does not create a second GA4 purchase. |
| Reconcile final order | Reconcile item IDs, quantities, tax, shipping, discounts, and total against the final WooCommerce order rather than browser draft state. | Request status, internal event ID, WooCommerce order, and GA4 record can be reconciled. |
Why this usually happens
- A request can declare several destinations while an event omits destinationReferences.
- Google Analytics purchase events require fields that a basic Google Ads conversion may not use.
- Browser cart state can differ from the final paid order after tax, shipping, or coupon changes.
- Transaction ID deduplication fails when retries generate a new identifier.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event:
eventName: purchase
transactionId: '1842'
clientId: 'REDACTED'
conversionValue: 129.00
currency: USD
destinationReferences: [ga4_property_a]
cartData:
items: '[redacted test items]'
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.
- Name destinations
- Select one GA4 reference
- Map required fields
- Reconcile final order
- Validate and compare
What to tell the client or owner
Share redacted request ID, internal event ID, destination references, identifier type, transaction ID, order totals, item count, API status, and GA4 reconciliation result.
Production verification checklist
- The API accepts the synthetic purchase without MULTIPLE_DESTINATIONS_FOR_GOOGLE_ANALYTICS_EVENT.
- The accepted event uses the final order transaction ID, value, currency, and item totals.
- A retry preserves the same transaction ID and does not create a second GA4 purchase.
- Request status, internal event ID, WooCommerce order, and GA4 record can be reconciled.
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, map WooCommerce purchases to GA4 correctly.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references