Writing the Same Conversion to Four Different APIs: Data Manager's Destination Map

There is a single order record in the backend, and today that record has to reach three or four places at once: it will feed a conversion action in Google Ads, complete the purchase the tag missed on the GA4 side, be written to Floodlight in an account running Campaign Manager 360, and refresh a Customer Match list if identity data exists. Each one is a separate integration: separate authentication, separate field names, separate error behaviour, separate maintenance load.

Data Manager offers a single data model and a single endpoint for that sprawl. Its own documentation is explicit: a unified ingestion API for data partners, agencies and advertisers to send first-party data to multiple Google advertising products.¹ The critical detail sits here: one API does not mean every destination is entered on the same terms. Each destination comes with its own account type, its own permission rule and in some cases its own access approval. Throughout this post I call these gates: preconditions that reject the request when they have not been opened in advance, even if the code side is ready.

In the measurement series I have been writing through August I first covered bringing two dashboards onto a common footing, then joining at row level and choosing a join key that connects a Shopify order to an ad click. This post is the next step in that series: once the matched record is ready, through which gate and with which identity it gets written back.

A Destination Is an Account Type, Not a Product Name

The first assumption to correct when planning an integration is that the destination is a product name like “Google Ads” or “GA4”. The documentation defines a destination by account type, and every request carries two separate pieces of account information: the operating account the data will be written to, and the login account making the request.²

Account type	Operating account	Prerequisite
GOOGLE_ADS	Customer ID	Login account can be a manager in the hierarchy
DISPLAY_VIDEO_ADVERTISER	Advertiser ID	Login account can be advertiser or partner
DISPLAY_VIDEO_PARTNER	Partner ID	Login account is the partner
GOOGLE_ANALYTICS_PROPERTY	Property ID	Login account has to equal the operating account
FLOODLIGHT_CONFIG	Advertiser ID	Login account has to equal the operating account
GOOGLE_AD_MANAGER_AUDIENCE_LINK	Audience Link ID	Access through a partner link
DATA_PARTNER	Login only	Approved data partner account plus a partner link

A product ID sits alongside the account ID: an audience ID, a conversion action ID, a measurement ID on the GA4 side or a Floodlight activity ID. In other words “I connected the account” is not enough in this API; the destination is stated explicitly on every request.

On GA4 and Floodlight the Login Account Is Not Free

On the Google Ads side, a manager account making requests on behalf of a sub-account is routine. That habit does not work for GA4 and Floodlight destinations: if the login account does not match the operating account, the request fails with OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH.² That error reason entered the API’s error list with the 2025-11-05 release.³

What this means in practice: an agency setup planning to write to every client’s GA4 property with a single service account has to build the permission model property by property. The way I read it, the constraint is documented but expensive to correct once discovered after integration, because service account access is granted one by one on the client side.

The Ad Manager side sits somewhere else. The destination there is not a network ID directly but an audience link ID, and access is established through a data partner link.² A data partner account in turn requires an application and an approval process; it is not an account type that opens by itself.⁴

Two Requests, Two Different Flows

The API offers two separate ingestion paths, and each works with different data types. The audience side manages user lists; the event side sends conversion and event records.

What is sent	Which request	Destination	Gate
Customer Match (contact info, user ID)	Audience	Google Ads	Standard
Customer Match (contact info)	Audience	Display & Video 360	Standard
Mobile device ID list	Audience	Google Ads, Display & Video 360	Standard
PAIR data	Audience	Ad Manager side included	Partner link
Offline conversions, enhanced conversions for leads	Event	Google Ads	Terms acceptance on the account
Multi-source conversions	Event	Google Ads	General since 2026-02-10
Store sales conversions	Event	Google Ads	Allowlist and eligibility
Recommended and custom events	Event	Google Analytics	Reserved event names banned
Multi-source events carrying a transaction ID	Event	Google Analytics	Allowlist per property
Floodlight offline conversions	Event	Campaign Manager 360, Search Ads 360, DV360	Standard

One detail gets missed on the audience side: when Customer Match data is sent through this API, matching runs through confidential matching, and that behaviour is the default.⁵ The same holds for Customer Match flows using a direct connection on the dashboard side; there is no extra cost and nothing further for the advertiser to do.⁶ Encryption is a separate layer and is not mandatory.

Another detail is the targeting threshold. Lists uploaded through the API were subject to a 1,000 member minimum in the first release; with v1.3 on 2025-10-06 that threshold dropped to 100 members.³ For accounts working with small segments, that means lists which previously never qualified for targeting become usable.

The Gates: Allowlist, Approval and Declaration

Reading through the prerequisites the documentation lists, the conclusion is this: in this API part of the delay originates in access, not in code. Three gates operate separately.

The first is the allowlist. Store sales conversions only work on Google Ads accounts that meet the eligibility requirements. On the GA4 side, multi-source events carrying a transaction ID are also behind an allowlist at property level, and Google publishes a separate application form for it.⁷

The second is data partner status. Parties wanting to write into other advertisers’ accounts through a partner link go through an approval process; the account type does not open without submitting an interest form.⁴ For a structure working in an agency model, that is a line item to plan before the technical integration.

The third is declaration. From 2026-04-01, under the EU political advertising regulation, creating, updating and deleting user lists as well as audience ingestion calls can be restricted with an EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED error on accounts without a declaration.³ For accounts managed from Türkiye but running ads in the EU, this is the kind of gate that gets noticed after the integration is already built.

On the enhanced conversions for leads side there are also account-level terms acceptance and data policy checks; when they are not met the request does not reach the destination, and the error message names the missing requirement directly.³

Inherited Paths and the Concrete Difference of Migrating

It is more accurate to read Data Manager as a layer that collects scattered uploads rather than as a separate product. Google publishes separate migration guides for existing integrations: Google Ads store sales, Customer Match on the Google Ads and Display & Video 360 side, Campaign Manager 360 offline conversions, and Measurement Protocol on the GA4 side.³

The concrete differences of the Measurement Protocol migration are listed in its guide: a data model shared across products, encryption support for sensitive data, multiple destinations in a single request, no more need for api_secret, and a fail-fast error model.⁸ The last two are what gets felt most in practice. On the Measurement Protocol side a malformed request returned no error unless the validation server was used, and the result only showed up as missing data in reports; Google counting fail-fast among the differences confirms this.

If work is happening on a side that follows the IAB Tech Lab Event and Conversion API standard, there is also a mapping document, meaning how ECAPI fields correspond to Data Manager requests is defined.⁹ For setups writing to more than one platform with the same event contract, that removes the burden of writing your own mapping table.

Dashboard Connector or API?

There are two ways to do the same job, and the choice is usually about rhythm rather than data volume.

Criterion	Dashboard connector	API
Import frequency	Daily at most	Frequency set by the caller
Row limit	100 million rows per import	No such stated limit
Field mapping and hash	Through transformations defined in the UI	The caller’s responsibility
Data freshness	Source has to be refreshed before the run	The data at request time
Source variety	A list including BigQuery, S3, Snowflake, HubSpot	Source independent

On the dashboard side the daily cap on import frequency and the requirement that the data source be refreshed before the run are stated explicitly.¹⁰ The rule that a single import should not exceed 100 million rows appears in the data preparation guide; larger sources get split or filtered.¹¹ In exchange the dashboard takes on field mapping and hashing: SHA256 hashing and normalisation for PII fields are applied automatically.

The decision reads like this: if the data already sits in a warehouse and a daily rhythm is acceptable, the dashboard connector needs less maintenance. If loading is needed at order time or hourly, or if the data does not sit in any supported source, the API side becomes necessary.

Four Questions to Answer Before Starting the Build

1. Which account type does the destination fall under? If it is GA4 or Floodlight, the permission model will be built per property or per advertiser, and a centralised setup with a single service account will not work.
2. What is the identity surface? Multi-source conversions require a transaction ID and a conversion time, plus at least one attribution identifier: hashed user data or a click ID such as GCLID, GBRAID or WBRAID.¹²
3. Where does consent come from? If a row-level consent field is not sent, the account-level default applies, and what that default is happens to be a separate setting in the interface.¹³
4. Which of the gates is not open? Access approval on the store sales, GA4 multi-source and data partner side has to start before the integration.

Once those four are answered, the remaining work is preparing the data correctly and reading the result of the upload. Each is a separate topic on its own.

The first is the set of behaviours encountered when an additional data source is connected to the tag. The uploaded conversion value permanently overwriting the value the tag wrote, transaction ID match rates staying low, a hundredfold difference arising from sending values in cents versus units, and the double counting risk that appears when a new conversion action is created. I covered these, along with the fourteen day non-biddable trial window, in the additional data source post.

The second is the implementation side: authentication setup, hashing and normalisation rules, optional encryption and reading diagnostics after upload. I covered that in the API implementation post.

Footnotes

1. Data Manager API (Google for Developers). The definition verbatim: “A unified ingestion API for data partners, agencies and advertisers to send first-party data to multiple Google advertising products.” The same page lists the two main usage families, audiences and conversion events. ↩
2. Destinations (Data Manager API). Account types, the operating and login account relationship and destination product IDs are defined on this page. The condition for data partner access is also here: a linked account is only stated if the login account’s account_type is DATA_PARTNER and the operating account’s parent is linked to the data partner account. ↩ ↩² ↩³
3. Release notes (Data Manager API). The OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH error reason was added with v1.4 on 2025-11-05. The targeting threshold dropping from 1,000 to 100 members is in the v1.3 entry on 2025-10-06; the EU PAR declaration and EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED are in the 2026-03-26 entry, naming 2026-04-01. Terms and policy errors on the enhanced conversions for leads side are in the v1.2 entry on 2025-08-06. Multi-source conversions opening to all Google Ads accounts is in the 2026-02-10 entry. Upgrade guides are linked product by product in the relevant release notes. ↩ ↩² ↩³ ↩⁴ ↩⁵
4. Set up API access (Data Manager API). The page states that data partner accounts are only granted after an approval process and points to an interest form. The prerequisites section lists a Google Cloud project, the serviceusage.services.enable permission and a gcloud installation; that any authentication method other than an API key is used, and that the Data Manager scope counts as a sensitive scope, are also on the same page. ↩ ↩²
5. Audiences overview (Data Manager API). On the Google Ads side, Customer Match by contact info or user ID and mobile device ID audiences are supported; on the Display & Video 360 side, Customer Match by contact info and mobile device ID audiences. The page also states that Customer Match data is processed with confidential matching, and notes encryption support. ↩
6. Confidential matching (Google Ads Data Manager Help). The feature is on by default and carries no extra cost: data using Customer Match through a direct connection is processed with confidential matching automatically. Encryption is optional, and the processing code is published in a public repository. ↩
7. Events overview (Data Manager API). Store sales conversions are only available on allowlisted Google Ads accounts; multi-source events carrying a transaction ID are only available on allowlisted Google Analytics properties, and the page provides the application form. Floodlight offline conversions are listed for Campaign Manager 360, Search Ads 360 and Display & Video 360. ↩
8. Upgrade from Measurement Protocol (Data Manager API). The guide lists the differences as a data model shared across products, encryption support, multiple destinations per request, no api_secret requirement and a fail-fast error model. ↩
9. ECAPI specification mapping (Data Manager API). Field mapping for integrations following the IAB Tech Lab Event and Conversion API standard. ↩
10. Manage your connections (Google Ads Data Manager Help). The scheduling section states that import frequency is daily at most and that data has to be refreshed before the run. The same page also covers account-level consent defaults and which features they apply to. ↩
11. Prepare your data for import (Google Ads Data Manager Help). The row limit verbatim: “Data imports shouldn’t exceed 100 million rows.” The same page also defines SHA256 hashing and normalisation rules for PII fields, along with file format and date format requirements. ↩
12. Boost your tag with additional data sources (Google Ads Data Manager Help). The required fields are transaction ID and conversion date and time; alongside those at least one attribution identifier is needed, hashed user data or a click ID such as GCLID, GBRAID or WBRAID. ↩
13. Manage your connections (Google Ads Data Manager Help). The default consent status for imported and uploaded data is a separate account-level setting; consent values stated at connection, import or upload level override that default. ↩

Key Takeaways

• 01 A destination is an account type, not a product name. The documentation splits destinations into GOOGLE_ADS, DISPLAY_VIDEO_ADVERTISER, DISPLAY_VIDEO_PARTNER, GOOGLE_ANALYTICS_PROPERTY, FLOODLIGHT_CONFIG, GOOGLE_AD_MANAGER_AUDIENCE_LINK and DATA_PARTNER; every request also carries an operating account and a login account.
• 02 On GA4 and Floodlight destinations the login account has to match the operating account. If it does not, the request fails with OPERATING_ACCOUNT_LOGIN_ACCOUNT_MISMATCH, so the permission model is not the same as the manager account habit on the Ads side.
• 03 The audience side and the event side are two separate requests. Customer Match, mobile device IDs and PAIR data go to the audience request; offline conversions, enhanced conversions for leads, store sales, multi-source conversions and GA4 events go to the event request.
• 04 Some of the gates are administrative rather than technical. Store sales and GA4 multi-source events require an allowlist, a data partner account goes through an approval process, and in the EU audience calls fail on advertiser accounts without a political advertising declaration.
• 05 A dashboard connector and the API are not the same thing. On the dashboard side import frequency is daily at most and a single import is capped at 100 million rows; the API has neither limit, but in exchange field mapping, hashing and scheduling become entirely the caller's responsibility.

Frequently Asked Questions (FAQ)

+ Which Google products does the Data Manager API send data to?

On the audience side Google Ads, Display & Video 360 and Google Ad Manager; on the event side Google Ads, Google Analytics and the Floodlight products of the Google Marketing Platform, meaning Campaign Manager 360, Search Ads 360 and Display & Video 360. The documentation lists these by account type rather than product name, and every request carries both an account ID and a product ID inside that account: an audience ID, a conversion action ID, a measurement ID on the GA4 side or a Floodlight activity ID.

+ Should this API replace the Ads API for Google Ads offline conversion uploads?

For new integrations yes, because new capabilities land on this side. Multi-source conversions opened to all Google Ads accounts on 2026-02-10, and store sales plus Floodlight offline conversion support were added release by release. Google publishes separate upgrade guides for the older paths: Google Ads store sales, Customer Match, Campaign Manager 360 offline conversions and Measurement Protocol each have their own. Moving an existing, working integration purely because something newer exists is not necessary; the migration decision makes sense when a new destination or a new field is actually needed.

+ What changes in practice when moving from Measurement Protocol on the GA4 side?

The authentication model. Measurement Protocol worked with an api_secret; on the Data Manager side no api_secret is needed and OAuth-based authentication is used instead. Beyond that the data model is shared across products, one request can target multiple destinations, and the error model is fail-fast, meaning a malformed request is not silently accepted. Measurement Protocol's silent acceptance was the part that made verification difficult.

+ Why use the API when a dashboard connector is available?

Because of two hard limits, one on frequency and one on volume. On the dashboard side a connection imports at most daily and the data source has to be refreshed before the run; a single import also cannot exceed 100 million rows. If a daily rhythm and a table-based flow stay under both limits, the dashboard connector needs less maintenance, because field mapping, hashing and scheduling are defined in the interface. A live event stream, hourly loading or a volume above 100 million rows means moving to the API.

+ Is a Google Cloud project required to use this API?

Yes. A Google Cloud project where the API will be enabled, an account with the serviceusage.services.enable permission on that project, and the gcloud command line tool are all listed as prerequisites. Any authentication method other than an API key can be used; in practice Application Default Credentials are set up either through a user account or through service account impersonation. Because the Data Manager scope counts as a sensitive scope, there is also a scope approval step on the project side.