Soku AI
Google's May 2026 Data Manager API update matters most for two teams: the team responsible for Customer Match reach and the team responsible for Google Marketing Platform offline conversion attribution. Those teams often live in different parts of the organization, but the update pushes them toward the same first-party data contract.
For the full overview, start with Google Data Manager API for AI Ad Teams. This spoke focuses on the new Customer Match composite data and Google Marketing Platform destination routing surface.
What changed
Google announced two related updates on May 28, 2026. Data Manager API can now send offline conversion events to Google Marketing Platform products, including Campaign Manager 360, Search Ads 360, and Display & Video 360. The AdIdentifiers object includes dclid, impressionId, matchId, and encrypted user IDs for conversions that occur away from the website.
Google also introduced IP address support for Google Ads Customer Match uploads through CompositeData. Composite data can include IP data alone or alongside identifiers such as email address, phone number, and address information. Google says including IP addresses with observation timestamps in IpData will help drive higher Customer Match rates beginning in Q3 2026 (Google Ads Developer Blog).
The shared theme is richer first-party matching. GMP destinations need ad identifiers and encrypted IDs to connect offline outcomes to media exposure. Customer Match needs enough identity signal to find the right signed-in users. Data Manager API is becoming the common ingestion layer for both.
Why Customer Match teams should care
Customer Match performance is mostly an identity-quality problem. Better creative does not help if the platform cannot match your customer list. Better bidding does not help if your high-value audience uploads undercount a meaningful share of buyers.
Composite data matters because it lets teams package identifiers more flexibly. Instead of treating email, phone, address, and IP as separate upload habits, you can document one identity object and decide which fields are present, allowed, and useful for each audience workflow.
The most important field is not always the field people notice. IP address is useful only with the corresponding observation timestamp and only where consent and policy allow it. Email and phone still matter. Address information can add match help where available. The win is not "send IP"; the win is "send a governed identity record with the strongest permitted evidence."
Why GMP teams should care
For Campaign Manager 360, Search Ads 360, and Display & Video 360, the new Data Manager API support is about offline conversion routing. Many teams still have historical upload workflows built around Campaign Manager 360 APIs or product-specific paths. Google is now pointing those teams toward a unified schema across Google advertising products, encrypted user identifiers, and the ability to route events to multiple destinations in a single request.
That helps when the same offline outcome needs to be used in more than one place:
| Offline outcome | Possible destinations | Why routing matters |
|---|---|---|
| Store purchase | Google Ads, CM360, SA360 | Bidding and attribution need the same revenue truth |
| Qualified lead | Google Ads, SA360, GA4 | Search bidding and analytics need aligned stages |
| High-value order | DV360, CM360, Customer Match | Programmatic attribution and audience activation share the same buyer |
| Subscription renewal | GA4, Google Ads, Customer Match | LTV reporting and audience suppression need consistency |
If those paths use separate jobs, they drift. Data Manager API gives teams a chance to collapse the drift into one routing layer.
The identity object to design
Before implementing composite data or GMP conversion routing, define the identity object your organization is allowed to use.
| Field | Use | Risk to manage |
|---|---|---|
| Strong user match signal | Normalize and encrypt consistently | |
| Phone | Strong secondary match signal | Format internationally before encryption |
| Address | Supplementary match signal | Completeness and consent vary by region |
| IP address | Customer Match composite data, with timestamp | Consent, observation time, and policy fit |
| Click ID | Click-based offline attribution | Capture loss and expiration windows |
| Impression ID | View-through or GMP exposure attribution | Availability and destination requirements |
| Match ID | GMP matching workflows | Must be generated and persisted correctly |
| Encrypted user IDs | Cross-product identity routing | Encryption process must be deterministic |
The Soku recommendation is to review this table with legal, analytics, and paid media together. The worst outcome is a technically successful upload that the business cannot explain later.
Destination routing rules
Use explicit routing rules, not destination sprawl.
Send a record to Customer Match when the purpose is audience activation, suppression, or high-value segment refresh. Send a record to Google Ads when it should train bidding or report conversion value. Send a record to CM360, SA360, or DV360 when it supports offline attribution for that product's media exposure. Send to GA4 when it belongs in behavioral or revenue analytics.
The same source event can produce multiple destination payloads, but the reason should be written down.
| Rule | Good example |
|---|---|
| Every destination must have a purpose | "Qualified lead -> Google Ads for value-based bidding; GA4 for funnel reporting" |
| Every identifier must have a permission basis | "Phone sent only when consent_state = ads_measurement_allowed" |
| Every event must have a dedupe key | "CRM opportunity ID plus stage timestamp" |
| Every route must be observable | "Daily accepted/rejected counts per destination" |
What AI agents can do here
This is a good place for an AI ad agent, but not as an uncontrolled uploader.
Useful agent tasks:
- Detect which Customer Match records lack enough identifiers.
- Compare accepted event counts across Google Ads, GA4, CM360, SA360, and DV360.
- Flag sudden drops in matchable email or phone coverage.
- Explain whether a ROAS change is likely a media problem or a measurement import problem.
- Draft migration plans from Campaign Manager 360 API uploads to Data Manager API.
Risky agent tasks:
- Inventing new identity routing rules without policy review.
- Sending IP data without checking consent state and timestamp quality.
- Routing every event to every destination because "more data is better."
- Changing Customer Match segment definitions without human approval.
The correct loop is agent-inspected, human-approved, deterministic execution.
Rollout plan
Start with the safest high-value segment.
- Pick one audience or offline conversion type.
- Audit identifier coverage for the last 30 days.
- Define allowed fields and consent rules.
- Send a small batch to one destination.
- Monitor accepted, rejected, and matched records.
- Add a second destination only after the first route is stable.
This is slower than a one-day bulk migration, but it prevents the two failures that hurt most: poisoning an audience with the wrong records and teaching automated bidding on mismatched conversion data.
FAQ
What is CompositeData in Data Manager API?
Composite data is the newer structure Google points to for richer Customer Match uploads. It can include IP data and user identifiers such as email, phone, and address information, depending on what you are allowed to send.
Does IP ingestion guarantee higher Customer Match rates?
No. Google says IP addresses with corresponding observation timestamps will help drive higher match rates beginning in Q3 2026. The effect depends on data quality, consent, identifier coverage, and Google's matching logic.
Which GMP products can receive offline conversion events?
Google's May 28 announcement names Campaign Manager 360, Search Ads 360, and Display & Video 360 as supported Google Marketing Platform destinations.
Should I migrate from Campaign Manager 360 API uploads?
If you rely on CM360 offline conversion uploads, review Google's upgrade path. The stated advantages are unified schema, encrypted identifiers, and routing events to multiple destinations in one request.
Can Customer Match and GMP routing use the same source event?
Yes, when the source event has the right identifiers, consent status, and destination purpose. The output payloads may differ, but the source event contract should be shared.
