Google has published new Help Center documentation for a beta feature inside Google Ads that allows advertisers to connect their website conversion tags with additional data sources - such as a CRM or order management database - to recover conversions that standard tag-based measurement may have missed.

The feature, currently in beta and not yet available to all accounts, is described in two Help Center pages published by Google: one covering the setup process and data requirements for "boosting" a tag with additional data sources, and a companion FAQ page addressing common implementation questions. No announcement date is listed in the documentation itself, though the pages reflect infrastructure built on the Google Ads Data Manager and its API, which Google formally launched on December 9, 2025.

What the feature does

At its core, the feature creates a dual-input measurement system for a single website conversion action. Advertisers continue using their existing Google tag or Google Tag Manager implementation as the primary data collection layer. On top of that, they connect a second data source - typically a backend record of the same transactions, pulled from a CRM, e-commerce platform, or order database - via the Data Manager interface or the Data Manager API.

The combination serves two practical functions. First, if a conversion event was recorded in the backend system but not captured by the tag - because of browser restrictions, an ad blocker, or a page load failure - the backend record can be used to reconstruct that conversion in Google Ads. Second, if the tag captured a conversion but the backend system holds a more accurate or updated value for that transaction - say, a returned order or a revised sale price - the uploaded value from the additional data source will overwrite the tag's original value.

According to Google's Help Center documentation, "your additional data source becomes the source of truth for conversion value." When a transaction_id from the uploaded data matches an event already recorded by the tag, "the Conversion Value from your upload will permanently overwrite the value originally recorded by the tag."

That is a significant design decision. It means advertisers who connect a backend data source are handing value-setting authority to that source, not to the tag. Any numerical value sent in the upload - including zero, which is valid for a full refund - will directly affect reporting and any active Value-Based Bidding strategies.

The deduplication mechanism

Central to the system is the transaction_id field. This is the same Order ID or unique transaction identifier that the Google tag is configured to pass at the moment of conversion on the website. When the backend data upload contains a transaction_id that matches one already recorded by the tag, Google Ads treats both records as a single event rather than two separate conversions.

This deduplication only operates within a single conversion action. According to Google's documentation, Google Ads "only removes duplicate data within a single conversion action (between the tag and the additional data source), not across two different conversion actions." If an advertiser creates a new conversion action specifically for this feature and leaves the original conversion action active in the same campaign goals, a transaction could be counted twice. Google's stated best practice is to add the additional data source to the existing conversion action, rather than creating a parallel one.

The FAQ documentation is explicit about what happens when transaction IDs do not match: "Google will then try to attribute this new conversion to an ad click using the identifiers you provided (like GCLID or hashed PII)." That attribution attempt uses whichever identifiers the upload includes - a GCLID (Google Click ID), GBRAID, WBRAID, or hashed user-provided data such as an email address, phone number, or IP address.

The upload schema has required fields and recommended fields. Only two fields are strictly required for every upload: the transaction_id and the conversion date and time. However, at least one attribution identifier must also be provided, or the system cannot link the conversion to an ad click. Google identifies three click identifiers - GCLID, GBRAID, and WBRAID - and several hashed personal identifiers as options.

According to Google's documentation, it is "highly recommended to provide both Hashed User-Provided Data (PII) and a GCLID" to ensure high-quality measurement signals. Customer-provided data such as email addresses, phone numbers, and postal addresses that has not already been hashed will be hashed automatically by the system before processing.

The timing of uploads also matters. Google states it is "highly recommended to upload data as soon as possible, ideally within 24 hours of the conversion event, for optimal performance with Enhanced Conversions matching and bidding systems." Data older than 55 days cannot receive value updates for transactions already recorded by the tag, though historical data can still be uploaded for reporting purposes.

The FAQ documentation adds a specific warning about historical backlogs: uploading a full year of historical purchase data will not improve current campaign performance. According to Google, "late uploads are deprioritized by Smart Bidding models and may be ineligible for features like enhanced conversions matching."

The 14-day trial period

When a new data source is first connected to a conversion action, it enters a 14-day trial period. During those 14 days, the data from the additional source appears in reporting and is used for diagnostics, but it does not influence bidding. Newly created conversion events - those where the transaction_id from the upload does not match any tag event - will appear in reporting but will not be used for bidding until the trial ends.

Value updates are also suspended during this window. According to Google's Help Center table, when a transaction_id matches an existing tag event during the trial period, "the tag's value will not be overridden in Google Ads reporting until the trial period ends."

The design mirrors how Google has handled other measurement feature introductions - a buffer period to allow advertisers to identify setup errors before live bidding is affected. The diagnostic alerts system is active throughout the trial, flagging issues such as low match rates between transaction IDs in the tag and the upload, or a tag that is failing to send transaction IDs altogether.

Currency and value formatting

One of the most consequential technical details in the documentation concerns value formatting. The additional data source must use the exact same currency unit as the Google tag. If the tag reports purchase values in dollars with decimal notation (for example, 10.00), the upload must also use the same format. Sending 1000 to represent 1000 cents would be interpreted as $1,000, not $10.00.

According to Google's documentation, "uploading values in a different unit, such as integer cents, will cause severe conversion value inflation, as the system doesn't automatically convert units." This is not a minor implementation risk. An advertiser whose backend database stores transaction amounts in integer cents - a common practice - would inflate their reported conversion values by a factor of 100 if the mismatch is not caught before activation. That inflation would feed directly into any target ROAS bidding strategies connected to the conversion action.

For transactions where no update to the value is needed, the documentation instructs advertisers to send NULL rather than any numerical value, since "any numerical input will directly impact your reporting and Value-Based Bidding strategies."

Supported data sources and setup paths

The feature is available only for website conversion actions set up manually via code - either through the Google tag or Google Tag Manager. Imported Google Analytics conversions and URL-based (codeless) conversion actions are not supported. The FAQ documentation explains the underlying reason: URL-based setups cannot dynamically capture the required transaction ID from the website, while Google Analytics conversions require the data merging and deduplication process to happen within Analytics before importing.

There are two primary setup paths. The first is through the Data Manager page inside Google Ads, under the Tools menu, where advertisers can connect a new data source - either via a direct connection or a third-party integration - and map fields step by step. The second path is through the Data Manager API, for developers or teams that need programmatic control over the connection.

Within the field mapping process, advertisers configure six sections: event information (the required transaction_id and conversion date), attribution details (at least one click ID or hashed PII), conversion value, consent fields, and user agent and session attributes. The consent section specifically requires mapping per-row consent values, distinguishing between ad_user_data consent and ad_personalisation consent. Only consented events are used to supplement conversion data.

The Data Manager UI permits only one additional offline data source per conversion action. If an organisation needs to consolidate data from multiple systems - for example, Salesforce and a separate internal database - Google's documentation states those systems must be merged into a single unified dataset before connecting to Data Manager. According to the FAQ, "connecting multiple offline systems directly to the same conversion action" introduces "a high risk of conflicting data from the different uploads and complicates the deduplication process."

Why this matters for measurement

The feature sits within a larger pattern of measurement infrastructure changes that Google has been making across its advertising stack. The Data Manager API, which provides the technical foundation for this beta, was launched in December 2025 and has been the destination for an expanding range of data types that were previously managed through older, more fragmented systems. By April 1, 2026, Customer Match uploads via the Google Ads API were blocked, requiring migration to the Data Manager API pathway. Starting June 15, 2026, the Google Ads API stopped accepting new adopters of offline conversion imports, continuing the same directional push.

The "boost your tag" feature is a distinct capability from those migration-driven changes, but it uses the same Data Manager infrastructure. It addresses a measurement problem that has become more acute as browser privacy protections have tightened. Safari strips Google Click IDs in an estimated 20% of sessions, and ad blockers intercept tag-based signals for a share of desktop traffic. Consent Mode enforcement in July 2025 caused a documented case of a Google Ads account losing 90% of measured conversions overnight, with only 40% recoverable after remediation.

Against that backdrop, a backend data source connected directly to a conversion action provides a measurement layer that is not subject to browser-level restrictions. The backend system - an e-commerce order database or CRM - records the transaction regardless of what happens in the browser. If the tag fires, the transaction_id matches and the backend value can update the tag's record. If the tag does not fire, the backend record creates the conversion event from scratch, using whatever attribution identifiers are available. This structural redundancy is what Google describes as "resilient and accurate measurement."

The Data Manager API reached version 1.7 in late May 2026, adding offline conversion event support for Campaign Manager 360, Search Ads 360, and Display and Video 360. Version 1.6, released May 7, 2026, expanded the "additional data source" mechanism beyond purchase events to any event carrying a transaction_id, including app data streams via Google Analytics for Firebase.

The tag-boosting beta is the consumer-facing interface for a subset of those capabilities: specifically, supplementing web conversion tags with backend data through the Data Manager UI or API, with deduplication built in and a 14-day trial period before the data affects bidding.

Bidding implications

For advertisers running Value-Based Bidding strategies - target ROAS or maximize conversion value - the accuracy of reported conversion values determines how the bidding algorithm calibrates its bids. If the tag consistently captures a lower-than-actual value because some transactions are missed, the algorithm underestimates the value of conversions and may underbid for the traffic that would produce them.

Conversely, the value-override mechanism introduces a risk if the backend data contains errors. Because the uploaded value permanently overwrites the tag's value for matched transactions, and because Smart Bidding uses conversion value data to adjust future bids, errors in the backend data feed directly into bidding decisions. Google's documentation notes that a value of zero is valid - correctly representing a full refund - but that all other entries should be numeric, greater than zero, and correctly formatted.

The Google Tag Manager and Google tag are also undergoing a broader architectural convergence announced in May 2026, which will affect how tags transmit data to Google destinations. That change, like the Data Manager infrastructure on which the beta feature depends, reflects ongoing investment in the measurement layer that feeds the bidding systems advertisers rely on for performance.

Timeline

  • March 2022 - Google launches enhanced conversions for leads, the first feature allowing offline data to supplement tag-based conversion measurement via CRM data. PPC Land coverage.
  • October 11, 2024 - Google adds two new diagnostics to the Tag Diagnostics tool, including alerts for tags that have stopped transmitting data and tags placed too far down the page. PPC Land coverage.
  • December 9, 2025 - Google formally launches the Data Manager API, providing a unified ingestion layer across Google Ads, Google Analytics, and Display and Video 360, and establishing the infrastructure that the tag-boosting beta depends on. PPC Land coverage.
  • January 7, 2026 - Google announces restrictions on session attributes and IP address imports through the Google Ads API, effective February 2, 2026, directing developers toward the Data Manager API.
  • February 2, 2026 - Google Ads API stops accepting new implementations of session attributes and IP address data in conversion imports.
  • March 4, 2026 - PPC Land reports on the upcoming April 1 deadline for Customer Match uploads to migrate from the Google Ads API to the Data Manager API. PPC Land coverage.
  • April 1, 2026 - Google blocks Customer Match uploads via the Google Ads API. All audience uploads must now use the Data Manager API pathway.
  • April 2, 2026 - Google publishes the second Ads DevCast episode dedicated to the Data Manager API. PPC Land coverage.
  • April 10, 2026 - Google announces unification of enhanced conversions for web and leads into a single toggle starting June 2026. PPC Land coverage.
  • April 25, 2026 - PPC Land reports on Safari stripping GCLIDs in an estimated 20% of sessions, illustrating the signal loss problem the tag-boosting feature addresses. PPC Land coverage.
  • May 7, 2026 - Google releases Data Manager API version 1.6, expanding the additional data source mechanism to any event with a transaction_id, including app data streams. PPC Land coverage.
  • May 15, 2026 - Google announces that the Google Ads API will stop accepting new offline conversion import adopters from June 15, 2026. PPC Land coverage.
  • May 20, 2026 - Google announces the forthcoming merger of Google Tag Manager and the Google tag into a shared infrastructure. PPC Land coverage.
  • May 28, 2026 - Google releases Data Manager API version 1.7, extending offline conversion event ingestion to Campaign Manager 360, Search Ads 360, and Display and Video 360. PPC Land coverage.
  • June 15, 2026 - Google Ads API stops accepting new adopters of offline conversion imports. Google Signals loses authority over Google Ads data collection; ad_storage becomes the single consent control for linked accounts.
  • June 2026 (beta, ongoing) - Google publishes Help Center documentation for the "Boost your tag with additional data sources" beta, making the feature available to eligible accounts.

Summary

Who: Google Ads advertisers who use manually coded website conversion actions - via the Google tag or Google Tag Manager - and who have access to backend transaction records from a CRM, e-commerce platform, or order database.

What: A beta feature that connects a Google Ads website conversion action to an additional offline data source, using a shared transaction_id to deduplicate events and recover conversions missed by the browser-side tag. The uploaded data becomes the authoritative source of truth for conversion value, overriding tag-recorded values for matched transactions. A 14-day trial period prevents the new data from affecting bidding while advertisers verify their setup. Only one additional data source per conversion action is permitted through the Data Manager UI.

When: The feature is in beta as of the publication of Google's Help Center documentation. No specific launch date appears in the documentation. The Data Manager infrastructure it depends on has been in active development since December 2025, with the most recent API update (version 1.7) published May 28, 2026.

Where: Inside Google Ads, accessible through the Conversions summary page (by editing a website conversion action) or through the Data Manager page under the Tools menu. Programmatic access is available through the Data Manager API. The feature is not available for all accounts during the beta period.

Why: Browser privacy protections, ad blockers, and consent enforcement have progressively reduced the completeness of tag-based conversion measurement. A backend data source - recording the same transactions independently of browser conditions - provides a measurement layer that is structurally insulated from those restrictions. By connecting that source to an existing conversion action and using transaction IDs to match and deduplicate events, advertisers can recover conversions that the tag failed to capture and supply more accurate values to Value-Based Bidding strategies.