Google extended its Data Manager API on May 28, 2026, to accept IP addresses in Google Ads Customer Match uploads and to push offline conversion events into Google Marketing Platform, two changes that tighten how advertiser-supplied signals reach the company's advertising stack and that carry a hard exclusion for one of Google's own products.

The announcement landed on the Google Ads Developer Blog, published by the Data Manager API Team. It pairs a feature aimed at advertisers who upload first-party audience lists with a separate measurement change for agencies and media buyers working inside Google Marketing Platform. Both additions route data through a single interface that Google has spent more than a year positioning as the successor to a patchwork of older, product-specific pipelines.

What Google changed in the Data Manager API

Two distinct capabilities arrived together. According to Google, the Data Manager API now supports sending offline conversion events to Google Marketing Platform products, a category that covers Campaign Manager 360, Search Ads 360, and Display & Video 360. Separately, advertisers can now include IP addresses in Google Ads Customer Match uploads using a new field called CompositeData.

The IP feature is the one most likely to change day-to-day audience operations. Providing IP addresses alongside their observation timestamps, according to Google, will help drive higher match rates for Customer Match beginning in the third quarter of 2026. That is a forward-dated promise rather than an immediate effect, and Google framed it as an expectation tied to a future quarter rather than a measured result available now.

The release follows the v1.6 update that added store sales ingestion and expanded Analytics events, which the same Data Manager API Team published earlier in May. It also extends the consolidation logic established when Google launched the Data Manager API in December 2025 as a centralized ingestion point for first-party data across Google Ads, Google Analytics, and Display & Video 360.

How IP ingestion works in Customer Match uploads

The mechanics sit inside a restructured way of describing audience members. Historically, an audience upload carried user identifiers in a userData object. The new approach introduces a wrapper.

Composite data

Google now offers two ways to provide user identifiers for an audience member. The recommended path sets a compositeData field, which contains a nested userData object where identifiers such as hashed email addresses live. The older path sets userData directly on the audience member. According to Google's developer documentation, the function of the nested userData inside compositeData is identical to the standalone userData field, so the migration is structural rather than behavioural.

What compositeData unlocks is the ability to carry IP data. The field bundles two components: UserData, which holds the familiar hashed identifiers, and IpData, which holds raw IP information. An advertiser can send IP data on its own, or alongside identifiers like email address, phone number, and address information. That flexibility is the practical reason Google recommends moving to compositeData even for integrations that have no immediate plan to send IP addresses.

The IpData object

The IP payload is small but specific. IpData contains a required ipAddress field and two optional timestamp fields, observeStartTime and observeEndTime, which record the window during which the IP address was observed for a given user. Google recommends including both timestamps to help improve match rates. Both IPv4 and IPv6 are supported. Unlike email addresses, the IP and timestamp fields must not be hashed or encoded - a notable contrast with the SHA-256 hashing pipeline that governs email handling.

Hard requirements and rejections

The feature ships with guardrails that will reject malformed requests outright. According to Google, CompositeData must contain either userData with at least one user identifier, or ipData with a non-empty ipAddress field. Empty composite objects do not pass. There is also a configuration prerequisite on the receiving audience: the destination must have CONTACT_ID in its uploadKeyTypes. Requests that send compositeData to audiences missing that key type are rejected. Developers who attempt the new flow against an incorrectly configured list will not get a partial result; they will get a refusal.

Where IP matching does not apply

This is the exclusion buried in the documentation, and it matters for two reasons. First, geography. According to Google's developer guide, "Google Ads does not support IP address matching for end users" in the European Economic Area, the United Kingdom, or Switzerland. Google instructs integrators to add logic that conditionally excludes IP addresses for users from those regions, to give clear information about data collected on their properties, and to obtain consent where required by law.

Second, product scope. IP ingestion through CompositeData is a Google Ads Customer Match capability, and it is not supported for Display & Video 360 Customer Match uploads. The same announcement that brings Display & Video 360 into the fold for offline event ingestion withholds the IP feature from it for audience matching. One product gains a measurement pathway in the same breath that it is denied a targeting signal. For programmatic teams who run audience strategies across both Google Ads and Display & Video 360, that split means the IP enrichment cannot be applied uniformly.

The regional carve-out arrives against a live industry argument about whether IP signals are accurate enough to justify the privacy cost. Earlier in 2026, FreeWheel warned that IP-based targeting can miss the bulk of households when addresses are sourced from probabilistic graphs, citing a study that found IP addresses match postal records only a small fraction of the time. Google's framing is different: it presents IP data as a supplementary signal layered onto deterministic identifiers, with the timestamp fields meant to anchor when an address was actually observed. Whether that distinction produces materially better outcomes is precisely what the Q3 2026 timeline leaves open.

Offline events extended to Google Marketing Platform

The second half of the announcement targets conversion measurement rather than audience building. The Data Manager API can now send offline conversion events - conversions that occur away from a website, such as a sale closed by phone or a lead marked won in a CRM - to Campaign Manager 360, Search Ads 360, and Display & Video 360.

To support this, Google expanded the AdIdentifiers object. According to the company, it now includes dclid, impressionId, matchId, and encryptedUserIds. These fields let advertisers attach the right click, impression, or match references to an offline event so that Google Marketing Platform can attribute it correctly. Google directed developers to its Get started guide to see which fields are required for uploading conversions that occur away from a website.

For teams already pushing conversions through the older Campaign Manager 360 API, Google recommended reviewing an upgrade guide. The stated advantages were three: a unified schema across all Google advertising products, encryption of user identifiers such as email and phone number, and the ability to route events to multiple destinations in a single request. The multi-destination routing is the same fan-out principle that defined the API at launch, when a developer could send data once and have it reach several Google products at once. PPC Land detailed that unified schema and the confidential matching that ships with the API earlier in 2026, noting that a single field could previously mean subtly different things depending on which product pipeline received it.

This event-ingestion expansion also fits a sequence of Google moves to push measurement into the newer interface. Google has framed the Data Manager API as the primary route for importing offline conversions, with the older Google Ads API path closing to new offline conversion adopters. The Marketing Platform addition rounds out the picture: conversions that previously required the Campaign Manager 360 API now have a documented home in Data Manager.

CompositeData versus userData

Google was explicit about direction without forcing an immediate cutover. The company stated it will continue to support the user_data field for user identifier uploads. In the same breath, it recommended sending user identifiers through composite_data to keep an integration ready for future improvements and features. This is a soft migration: nothing breaks today, but the newer structure is where Google is investing.

The pattern echoes how Google has handled earlier transitions. When the company shut down new session attribute and IP address imports in the Google Ads API, it directed developers toward the Data Manager API as the destination for that data. The recommendation to adopt composite_data now reads as the next link in that chain - a structural choice that positions IP ingestion as a feature of the consolidated API rather than the older one.

The mechanics of an audience upload

The IP feature does not change the broader contract for sending audience members, and the surrounding requirements help explain why the data must be prepared so carefully.

Email addresses follow a strict formatting and hashing routine. According to Google's guide, an integrator must remove all leading, trailing, and intermediate whitespace, convert the address to lowercase, hash it with the SHA-256 algorithm, and encode the result using hexadecimal or Base64. Get any step wrong and the request fails with a descriptive error: a plain-text email returns an INVALID_HEX_ENCODING reason, while an email that is hex encoded but never hashed returns INVALID_SHA256_FORMAT. The stability of email as an identifier is itself a moving target, a point that surfaced when Gmail began letting users change their primary address, adding a layer of complexity to how advertisers maintain hashed records over time.

Audience size carries a floor. "An audience must have at least 100 members," according to Google's documentation, before it is eligible for targeting. Requests also have to satisfy regional advertising rules. Audience member ingestion must comply with the EU Political Ads Regulation policy, and an operation on an account that lacks the required declaration can return an EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED error. That requirement connects to the broader compliance regime Google built when it tightened account-level enforcement of EU political advertising declarations earlier in 2026.

The request itself combines destinations and audience members, sets an encoding value, and can include fields such as validateOnly and consent. Consent is expressed through adUserData and adPersonalization settings. For Customer Match, a termsOfService field records whether the user accepted the Customer Match terms of service. Setting validateOnly to true checks a request without applying changes, a dry-run mode that lets developers confirm formatting before committing data. A successful request returns a requestId, which an integrator records to retrieve diagnostics as each destination is processed; diagnostics are available only for requests that succeed and are not run in validation mode. A failed request returns an error status such as 400 Bad Request together with field-level detail.

Multiple destinations can travel in one request. Each destination takes a user-defined reference, and the only rule is that each reference must be unique. An audience member can then set destination_references to target one or more specific destinations; if that list is omitted, the member is sent to every destination in the request. The behaviour is the operational expression of the same fan-out design that Google has marketed since the API first appeared, and it is governed by published limits on the maximum number of destinations per request.

Why this matters for marketers

The change reaches marketers on two fronts. For advertisers running Customer Match, the IP feature offers a new lever to raise match rates, the percentage of an uploaded list that Google can connect to real users for targeting. Higher match rates mean larger addressable audiences from the same customer file, which is why the Q3 2026 timing is worth marking on a calendar even though the benefit is not yet live. For agencies measuring across Google Marketing Platform, the event-ingestion expansion gives Campaign Manager 360, Search Ads 360, and Display & Video 360 a documented path for offline conversions through the same interface that already handles audiences.

The strategic backdrop is consolidation. Google merged its advertising developer tools into a single hub in April 2026, and the Data Manager API has been the connective tissue, sending audience and conversion data to multiple products with one call while offering confidential matching and encryption that the older Google Ads API path does not. Confidential matching - Google's use of trusted execution environments so that no party, including Google, can read raw data during processing - was introduced as a standalone technology in 2024 and now sits inside the same API that this update extends.

The IP addition also has to be read against the wider regulatory and competitive context that PPC Land has tracked through Google's pre-GML measurement push. Google is gathering more signal types into one place at the same moment that privacy law restricts how some of those signals can be used. The EEA, UK, and Switzerland carve-out for IP matching is a direct expression of that tension. So is the requirement that integrators handle consent and regional exclusion in their own code. The feature gives advertisers more raw material to work with, and it puts the burden of using that material lawfully squarely on the advertiser.

There is also a question the documentation does not answer. IP addresses are among the most contested signals in advertising, valued for geographic and household linkage yet criticized for inaccuracy when inferred rather than verified. The Customer Match change did not arrive in isolation, either. Days later, on June 1, 2026, Google opened an AdSense control that lets publishers share the full IP address in programmatic bid requests, restoring the fourth octet that firmographic business-to-business targeting, fraud detection, and frequency capping depend on. A standard IPv4 address carries four numeric groups, and the default AdSense configuration had withheld the last one, truncating an address to its /24 range and blurring a specific corporate network into a broader pool. That control is off by default, and it sits on the publisher side of the market rather than the advertiser side, but it points the same direction as the Customer Match move: after years of truncating and restricting IP signals, Google is selectively widening access to them across both first-party audience matching and open-web programmatic. Google has placed its bet on IP data as a complement to deterministic identifiers, bounded by observation timestamps and walled off from Europe. The market will judge the result after the third quarter of 2026, when the promised match-rate improvements are meant to take effect.

Timeline

Summary

Who: Google, through its Data Manager API Team, addressing advertisers who upload Customer Match audiences and agencies that measure conversions across Google Marketing Platform, which spans Campaign Manager 360, Search Ads 360, and Display & Video 360.

What: Two additions to the Data Manager API. The interface now accepts IP addresses in Google Ads Customer Match uploads through a new CompositeData field that bundles UserData and IpData, with required ipAddress and optional observeStartTime and observeEndTime timestamps. It also now sends offline conversion events to Google Marketing Platform products, supported by an expanded AdIdentifiers object that adds dclid, impressionId, matchId, and encryptedUserIds. IP matching is excluded in the EEA, the UK, and Switzerland, and IP ingestion is not supported for Display & Video 360 Customer Match uploads.

When: The Google Ads Developer Blog published the announcement on May 28, 2026. Match-rate improvements from IP signals are expected to begin in the third quarter of 2026.

Where: The changes apply through the Data Manager API and reach Google Ads Customer Match audiences and Google Marketing Platform measurement products, with regional restrictions for end users in the European Economic Area, the United Kingdom, and Switzerland.

Why: Google is consolidating first-party data ingestion into one purpose-built interface that offers a unified schema, encryption of user identifiers, confidential matching, and multi-destination routing. Adding IP addresses to Customer Match is intended to lift match rates, while routing offline events to Google Marketing Platform closes a measurement gap previously served by the older Campaign Manager 360 API.