Google Ads Customer Match: Prepare Your List and Verify the Upload Route

Check the current upload route first

As checked on 25 October 2026, Google’s Customer Match API guidance says new integrations should use Data Manager API. Its older upload services are restricted for projects without qualifying Customer Match activity in the specified historical period.

SourcetoMCP’s current upload operation uses the older OfflineUserDataJob route. This article has not verified that its project is eligible for that restricted route. The operation also does not expose job-level consent fields. It is therefore not a general-purpose route for every new list or consent requirement.

Start with a route check, with no identifiers attached. Where the old route is unavailable or cannot express the required consent, use Google Ads Data Manager or an appropriate supported integration. A connector operation existing in the code is insufficient evidence that Google will accept your upload.

Keep API-route access separate from advertiser eligibility and list eligibility. Passing one check does not establish the others. Confirm the account’s current status and Customer Match requirements before planning a campaign around the list.

Prepare the intended first-party list

Define the segment in your own customer system, such as current paid customers or a specific consented customer group. Record the selection date, source and inclusion rule. Remove records that fail your organisation’s permission, consent or data-quality requirements before preparing the advertising file.

Do the preparation in your approved data environment. Keep raw addresses and phone numbers out of an ordinary chat. Hashing produces an identifier for matching, so it does not turn the upload into anonymous marketing statistics.

Follow the destination’s current normalisation and hashing requirements for the exact identifier type and route. Normalise before applying SHA-256. A formatting error before hashing produces a different value, even though the resulting digest has the expected length.

The current SourcetoMCP operation accepts pre-hashed email or phone values as 64-character hexadecimal strings. It does not normalise raw contacts, hash them for you, accept postal addresses or upload mobile advertising IDs. Passing the format check verifies the shape of the hash, with no proof about its source or matching accuracy.

Count records, identifiers and matched users separately

Suppose a hypothetical customer export contains 1,200 rows. Removing 100 duplicate rows and 150 rows excluded by your documented selection rules leaves 950 customer records. This is an illustrative preparation calculation, with no proposed universal rule for which customers to include.

If 800 records have an eligible email and 300 have an eligible phone number, the file has 1,100 identifiers. Some customers have both. The 1,100 identifier count is neither 1,100 unique people nor 1,100 matched Google accounts.

SourcetoMCP submits the email and phone arrays as separate identifier operations. Its returned members-submitted number is the combined count of identifiers. It cannot deduplicate those arrays into a verified person count or report the match rate from that number.

Understand the list and asynchronous job workflow

The list-management operation creates a CONTACT_INFO Customer Match list and supports its name, description and membership duration. A newly created list is an empty resource until the appropriate population step succeeds. The implementation defaults membership to 540 days, so choose and approve the intended duration explicitly.

Where the upload route has been independently confirmed as suitable, the existing operation creates a job, adds identifier operations and starts processing. It returns a job ID and an initial status. Keep that identifier and check the separate job-status operation later.

A pending or running status means processing is incomplete. A success status describes the job’s processing state. The operation does not return a complete item-by-item acceptance report or a matched-user count. Check the upload details and list status in Google Ads rather than treating job success as universal acceptance.

The operation can add, remove or clear identifiers. Clearing a list affects all its members, so it requires a distinct reviewed decision. Do not include a clear action in routine preparation or use it to make a failed upload look clean.

Check consent, list eligibility and delivery separately

Consent must be handled through an upload route that can represent the required settings. The current connector has no fields for the relevant job-level consent values, so a prompt cannot add them to this operation. Use the suitable platform route rather than inventing a consent parameter.

Google’s list troubleshooting guide distinguishes uploaded list size from active users and delivery thresholds. A large source file can still produce a small eligible audience because matching, activity, policy and additional targeting affect delivery.

A list also needs a membership and refresh plan. Google’s data-use explanation documents the 540-day maximum membership and current refresh requirements. Recheck the account’s present rules before deciding a schedule.

Inspect how a campaign uses the list. A list ID is different from a GA4 audience ID, and attaching it does not prove a campaign serves exclusively to that list. Review targeting mode and any expansion behaviour with the audience-targeting guide.

Use an AI preflight without contact data

Prepare a Customer Match review for Google Ads account [ID]. Do not create a list, upload identifiers, remove members or change targeting. Use this aggregate preparation summary: [counts and selection rules, no contacts or hashes]. Separate customer records, identifiers, upload acceptance, matched users and active audience. Identify the current upload route and the connector’s consent-field limitations. List the evidence needed from Google Ads or Data Manager before upload. If I provide an existing job ID, report its processing status without claiming a match rate.

Use the assistant to check the preparation arithmetic and produce a handover with the segment definition, chosen membership duration, approved route and unresolved items. Keep any customer-level validation within the approved environment.

For audiences based on website events, use the retargeting workflow. That is a different population route and should have its own collection, sharing and eligibility checks.