Google defines EVENT_SOURCE_AND_DESTINATION_MISMATCH as an event source type that does not match the destination type. Retrying the same payload cannot correct that relationship. WordPress and CRM pipelines need to preserve the rejected row, identify the intended business event, verify the source schema and destination reference, and rebuild the route before replay.
Use this for WordPress lead, WooCommerce purchase, refund, CRM stage, Google Analytics, and offline conversion pipelines using the Data Manager API. Keep user data out of general logs and use request IDs, event IDs, and redacted field names to trace failures.
Quick answer
Join the failed event to its request and status result, then record source type, destination type, destination reference, operating account, login account, event name, and conversion objective. Compare that pair with the official destination guide. Quarantine permanent mismatch rows, correct the mapping or route, send one synthetic event, and replay original rows with their stable event and transaction identifiers.
What to check first
- Capture request ID, event ID, event source type, destination type, destination reference, operating account, login account, error reason, field path, and UTC event time.
- Map the WordPress or CRM source object to the intended business event before selecting a destination, including lead, qualified lead, purchase, refund, subscription, or analytics event.
- Verify the destination exists, belongs to the expected product and account, accepts the event source type, and uses the required event and user-data schema.
- Separate configuration-wide mismatches from row-level data errors by grouping failures by source type, destination reference, deployment version, and first-seen time.
- After correction, send a synthetic event with a unique test ID, inspect request status, destination diagnostics, and downstream reporting before controlled replay.
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 failed request and row identity | Capture request ID, event ID, event source type, destination type, destination reference, operating account, login account, error reason, field path, and UTC event time. | The corrected source and destination pair matches the intended conversion objective. |
| Confirm the intended business event | Map the WordPress or CRM source object to the intended business event before selecting a destination, including lead, qualified lead, purchase, refund, subscription, or analytics event. | A synthetic event completes without the mismatch and appears in the expected destination diagnostics. |
| Validate source and destination compatibility | Verify the destination exists, belongs to the expected product and account, accepts the event source type, and uses the required event and user-data schema. | Original event and transaction IDs remain stable through replay. |
| Test the corrected route with synthetic data | Separate configuration-wide mismatches from row-level data errors by grouping failures by source type, destination reference, deployment version, and first-seen time. | The queue stops retrying permanent mismatch rows and monitors the corrected configuration. |
Why this usually happens
- A destination ID can look syntactically valid while belonging to a different product type.
- Shared configuration may route several WordPress event families to one incompatible destination.
- Environment variables can mix staging, manager, advertiser, analytics, and production references.
- A migration can change source schema without changing the destination configuration.
- Generic retry queues often treat permanent mapping errors like temporary network failures.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request_id: dm-20260723-0018
event_id: wp-lead-7841-qualified
event_source_type: CRM
destination_type: GOOGLE_ANALYTICS
destination_reference: properties/REDACTED
error_reason: EVENT_SOURCE_AND_DESTINATION_MISMATCH
retry_class: permanent_configuration
action: quarantine_and_remap
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 failed request and row identity
- Confirm the intended business event
- Validate source and destination compatibility
- Test the corrected route with synthetic data
- Replay quarantined rows with stable identifiers
Decision rule
Do not retry a mismatch until the source and destination types are intentionally compatible. If the intended destination is unclear, quarantine the row and ask the tracking owner rather than guessing from the identifier format.
What to tell the client or owner
Give the tracking owner a grouped report with source type, destination type, account, affected event families, row count, first and last failure, proposed route, synthetic test result, and replay plan. Redact identifiers that expose user data or credentials.
Production verification checklist
- The corrected source and destination pair matches the intended conversion objective.
- A synthetic event completes without the mismatch and appears in the expected destination diagnostics.
- Original event and transaction IDs remain stable through replay.
- The queue stops retrying permanent mismatch rows and monitors the corrected configuration.
Mistakes to avoid
- Do not rename the event while leaving the incompatible route unchanged.
- Do not retry permanent mismatch rows on a timer.
- Do not mix manager, advertiser, analytics, staging, and production references.
- Do not log unhashed user data or complete request bodies for routine diagnosis.
Questions teams ask during testing
Is this a bad event name error?
Not necessarily. Google lists separate error reasons for invalid event names. This reason identifies incompatibility between event source type and destination type.
Can I replay after changing the destination?
Yes, after a synthetic event proves the corrected route and replay preserves stable event and transaction identifiers for deduplication.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, fix a Data Manager API route.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references