Google defines DESTINATION_ACCOUNT_TYPE_MISMATCH as a destination account type that does not match the specified account ID. Teams often copy an identifier from a manager account, advertiser, Analytics property, destination resource, or another environment and place it in the wrong field. The fix requires naming each identifier by type and proving permissions, not adding separators until the request passes.
Use this for agencies and internal teams with several Google Ads advertisers, manager accounts, Analytics properties, service accounts, and staging or production credentials. Treat account IDs and resource names as controlled configuration, and never place OAuth tokens or private keys in the audit artifact.
Quick answer
Inventory every ID in the request and deployment configuration, label its product, resource type, owner, environment, and field, then compare it with the official field contract. Confirm the authenticated principal can access the intended advertiser or destination. Correct one configuration value, run a synthetic event, and replay only rows that failed under the proven configuration with stable identifiers.
What to check first
- Capture the destination account type, supplied account ID, destination resource name, operating account, login account, authenticated principal, environment, deployment version, and exact error field.
- Resolve each identifier in its native Google product or API and record whether it is a manager, advertiser, Analytics property, data source, destination, customer, or service project.
- Verify hyphen handling, resource-name prefixes, environment variables, secret versions, tenant selection, and whether a manager ID was substituted for an advertiser ID.
- Test permissions separately from type by listing or reading the intended resource with the same authenticated principal and approved least-privilege scope.
- Group quarantined rows by bad configuration version, correct the mapping, send one synthetic event, and set a replay boundary using deployment and first-failure timestamps.
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 |
|---|
| Label every identifier by product and resource type | Capture the destination account type, supplied account ID, destination resource name, operating account, login account, authenticated principal, environment, deployment version, and exact error field. | Every request identifier has one documented product, resource type, owner, and environment. |
| Resolve IDs in the native account hierarchy | Resolve each identifier in its native Google product or API and record whether it is a manager, advertiser, Analytics property, data source, destination, customer, or service project. | The authenticated principal can access the intended destination with approved scope. |
| Verify the principal's access separately | Verify hyphen handling, resource-name prefixes, environment variables, secret versions, tenant selection, and whether a manager ID was substituted for an advertiser ID. | The synthetic event reaches the correct advertiser or destination without the mismatch. |
| Correct and test one deployment configuration | Test permissions separately from type by listing or reading the intended resource with the same authenticated principal and approved least-privilege scope. | Replay rows are bounded to the bad configuration version and retain stable event IDs. |
Why this usually happens
- Several Google identifiers are numeric and visually indistinguishable without type labels.
- Manager and advertiser accounts can both appear in one authentication flow.
- Configuration templates may reuse a generic customer_id key for different resource types.
- Staging secrets and production destinations can be combined during deployment.
- Permission errors and type errors can be incorrectly collapsed into one setup checklist.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
config_key,value_type,environment,field_result
login_account_id,manager,production,valid
operating_account_id,advertiser,production,valid
destination_account_id,manager,production,mismatch
expected_destination_account_type,advertiser,production,required
correction_source,approved_account_registry,production,pending
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.
- Label every identifier by product and resource type
- Resolve IDs in the native account hierarchy
- Verify the principal's access separately
- Correct and test one deployment configuration
- Replay only the affected configuration window
Decision rule
Change an account ID only when its native resource type, owner, environment, and field contract are proven. A different ID that merely removes the error is not a valid fix if the conversion lands in the wrong advertiser or destination.
What to tell the client or owner
Give the tracking owner a redacted account matrix with configuration key, resource type, owner, environment, expected field, access result, corrected secret version, test event, and replay window.
Production verification checklist
- Every request identifier has one documented product, resource type, owner, and environment.
- The authenticated principal can access the intended destination with approved scope.
- The synthetic event reaches the correct advertiser or destination without the mismatch.
- Replay rows are bounded to the bad configuration version and retain stable event IDs.
Mistakes to avoid
- Do not guess account type from the number of digits.
- Do not use a manager account ID where the destination requires an advertiser.
- Do not fix the error by sending conversions to a convenient but wrong account.
- Do not paste OAuth tokens, client secrets, or service account keys into the matrix.
Questions teams ask during testing
Is DESTINATION_ACCOUNT_TYPE_MISMATCH the same as PERMISSION_DENIED?
No. Type and permission should be diagnosed separately, even though both can originate in the same account setup.
Should account IDs be stored with hyphens?
Follow the specific field contract. First prove the resource type and owner; formatting alone cannot turn a manager account into an advertiser account.
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, audit Data Manager account mapping.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references