The order record has been matched to the ad click, the shared key has been chosen, the rows have been joined. The next step is writing that record back into Google Ads. The common expectation here is that uploaded data is a second source added alongside what the tag collects. The behaviour is not that: an additional data source becomes the single authority on value within the conversion action it is connected to.1
That distinction is invisible during setup and the bill arrives later. Every behaviour below is written in the official documentation, and all of them belong to questions the setup screen never asks.
In the August series I first covered bringing two dashboards onto a common footing, then joining at row level and choosing a join key. The question of which record gets written to which account type sits in the Data Manager destination map post. This post covers the behaviours at the moment the matched record is written back.
Eligibility First: Not Every Conversion Action Can Be Connected
An additional data source can only be connected to website conversion actions created manually with the tag or Google Tag Manager. Conversions imported from Google Analytics and URL-based conversion actions are out of scope.1
Because those two types are common, the requirement rules out quite a few accounts in practice. In a setup built by importing GA4 key events into Ads, the conversion action itself has to be moved to the tag side first, so the work starts before any additional source gets connected.
Creating a New Conversion Action Produces Double Counting Risk
The most appealing option during setup is creating a separate conversion action so the existing one is left untouched. The documentation explicitly treats this as risky, and the reasoning is mechanical: deduplication only happens within a single conversion action, between the tag and the additional source. There is no deduplication across two different conversion actions.1
The result: if the new action and the old one are active together in the same campaign’s goal set, one transaction gets counted twice. The recommended path is connecting the additional source to the existing conversion action. If a separate action is unavoidable, removing the old one from the goal set is mandatory.
The Uploaded Value Overrides the Tag Value
Matching runs on transaction_id and the outcome splits into three scenarios.
| Scenario | Field | Result |
|---|---|---|
transaction_id matches a tag event | Conversion value and currency | The uploaded value overrides the tag value, permanently |
transaction_id matches a tag event | Other fields, for example GCLID | Ignored, the values recorded by the tag remain |
transaction_id matches no event | All submitted data | A new conversion event is created and attributed using the identifiers sent |
On the value side three separate behaviours get confused with one another, and all three reach reporting: zero is a valid value, used for a full refund. Leaving the field empty means “do not update this record”. Every numeric input feeds directly into reporting and value-based bidding strategies.1
The practical rule that follows is deciding before setup how refunded orders will be represented in the upload. Not sending the refund row at all and sending it with a zero value are not the same thing; the first leaves the amount written by the tag as it is, the second zeroes out that order’s contribution.
Currency Is Not Converted
Uploaded values have to be in the same format and the same currency as the tag. The system does not convert units: if the tag reports in units while the upload is in cents, the value goes up a hundredfold.1
The insidious part of this error is where the alert threshold sits. On the diagnostics side the Review your uploaded conversion values warning only appears when a difference greater than a thousand percent, meaning more than tenfold, forms between the tag and the additional source within two days.2 A hundredfold difference clears that threshold and therefore becomes visible. Because the threshold is defined that way, the conclusion is this: smaller unit errors, such as tax-inclusive and tax-exclusive amounts getting mixed, accumulate in reports without producing an alert.
Match Rate: The Ten Percent Threshold and Format Checks
If the transaction_id match between the tag and the additional source stays below ten percent within two days, the Your conversions may be overcounted alert appears.2 The alert signals not data loss but that the two sides write the same identifier differently.
The checklist is short and the documentation lists it item by item:
| Type of difference | Example |
|---|---|
| Prefix or suffix | order-12345 and 12345 |
| Letter case | abc-123 and ABC-123 |
| Data type | 12345 and 12345.0 |
| Leading zeros | 00123 and 123 |
| Placeholder value | undefined, order_id |
If the formatting side is clean, the second place to look is coverage. A low overlap rate can also come from the tag collecting transaction_id only intermittently. The common root cause the documentation points to is faulty tagging logic on a subset of conversion pages. The identifier needs to be carried on every tag send.2
The same alert also appears in connection-level diagnostics, meaning the problem is reported both on the conversion side and on the data source side.3
The Fourteen Day Window: This Is Exactly the Correction Period
When an additional source is connected to a biddable conversion action, meaning one marked Primary in the interface, a fourteen day trial period starts, and the clock begins the moment the first offline upload is received. During that period the additional source data appears in reporting, in overlap estimates and in diagnostics output, but does not enter bidding. Value updating is also disabled during that period, so the amount written by the tag is not overridden in reporting. Existing tag conversions continue to be used in bidding as normal.2
At the end of the period the additional source data enters bidding automatically. The documentation is unambiguous here: unresolved alerts in diagnostics do not prevent that transition.2
So the fourteen days are not a waiting period, they are a correction window. The work to do in that window is measuring the match rate and the value difference and closing the formatting errors. When the window is missed, faulty data does not just stay in reports, it starts entering the bidding strategy.
Reading the Alerts
Diagnostics output splits into four levels, and the levels carry the same meaning regardless of platform.2
| Level | Meaning |
|---|---|
Excellent | Setup is active with no symptom affecting performance |
Good | Active, but at least one improvement suggestion exists, for example a single identifier being sent |
Needs attention | Active and receiving data, with an issue affecting performance |
Urgent | Urgent issue: the source has stopped, there is no matching, or a tenfold value difference exists |
Two alerts deserve extra attention. The first is the tag stopping data flow: a tag that previously sent data staying silent for forty-eight hours counts as urgent, and in multi-source setups that window is seven days.2 The second is transaction_id being missing or invalid in the tag. That makes deduplication stop working outright.
Diagnostics on the connection side sits separately, and there the concrete definition of “urgent” is given: a previously working connection not running for forty-eight hours and data dropping to zero.3
Source Selection and Upload Rhythm
The documentation lists three concrete expectations for an additional data source.1
- The source has to be a complete and authoritative record of the relevant transactions, such as an e-commerce backend or a CRM. An export taken from another tag-based analytics system is not suitable, because it carries the same signal loss.
- Uploading should happen as soon as possible after the conversion event, preferably within twenty-four hours.
- Values have to be in the same format and the same unit as the tag.
The first item gets skipped in most setups. Uploading a GA4 export as an additional source does not bring back the conversions the tag missed; the documentation’s warning points the same way: because GA4 carries the same signal loss, what gets uploaded is a copy of the incomplete data.1 The point of an additional source is carrying the order that is known with certainty on the payment side, independently of the measurement layer.
A Checklist for the First Two Weeks After Setup
- Verify the conversion action is a website conversion created manually with the tag or GTM.
- Check whether the additional source was connected to the existing conversion action or a new action was created. If a new action was created, remove the old one from the goal set.
- Wait two days after the first upload and read the match rate; if it is below ten percent, work through the formatting list in order.
- Compare value units between the tag and the additional source on a single order, because deviations below the tenfold threshold produce no alert.
- Decide how the refund policy will be represented on the upload side: a zero value, or not sending the row at all.
- Clear diagnostics before day fourteen, because at the end of the period the data enters bidding regardless of alerts.
Everything up to this point can be done through the interface. The programmatic side of uploading, meaning authentication setup, hashing and normalisation rules, optional encryption and reading diagnostics after upload, is the subject of the API implementation post.
Corrections made after uploading has started get squeezed into a fourteen day window. Checking the conversion action's eligibility, the identifier format and the value unit beforehand lets that window be spent on verification rather than repair.
Request a ReviewFootnotes
- Boost your tag with additional data sources (Google Ads Data Manager Help). The eligibility requirement, the double counting warning, the matching table and the source selection expectations are on this page. The value behaviour verbatim: “Your additional data source becomes the source of truth for conversion value. When a transaction_id matches an existing tag event, the Conversion Value from your upload will permanently overwrite the value originally recorded by the tag.” The required fields are transaction ID and conversion date and time, plus at least one attribution identifier: hashed user data or GCLID, GBRAID, WBRAID. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
- Fix diagnostic alerts for multi-source conversions (Google Ads Data Manager Help). The value difference alert threshold is more than a thousand percent within two days, meaning tenfold. The match alert is a match below ten percent within two days. The format difference list and the coverage check are on the same page. The trial period items are also here: the period starts when the first offline upload is received, during that period data enters reporting but not bidding, and at the end it is included in bidding automatically with the phrase “regardless of any diagnostic alerts”. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
- Troubleshoot connection issues (Google Ads Data Manager Help). Connection quality states and the definition of an urgent state: a previously working connection not running in the last forty-eight hours and data dropping to zero. The same page also lists the match rate alert on the connection side and gives other diagnoses such as credentials, formatting and missing columns. ↩ ↩2
- 01 The uploaded conversion value permanently overrides the value the tag wrote on the matching row. Zero is a valid value (a full refund), while leaving the field empty means do not update. Uploading without knowing that difference affects reporting and value-based bidding together.
- 02 Currency is not converted automatically. If the tag reports in units while the upload is made in cents, the value goes up a hundredfold; diagnostics only raises an alert at a tenfold difference, so smaller deviations stay silent.
- 03 Deduplication only works within a single conversion action. Creating a new conversion action and keeping it in the same goal set as the old one means one order gets counted twice.
- 04 A transaction_id match below ten percent over two days produces an alert. The cause is usually a formatting difference or the tag not sending the ID on every ping, not data loss.
- 05 The first fourteen days are not biddable, and value updating is also disabled during that period. At the end of it the data enters bidding automatically even if the alerts are unresolved, so once the correction window is missed, faulty data starts affecting budget directly.
+ Does the uploaded conversion value change the value written by the tag?
Yes, on matching rows it does, and permanently. An additional data source is treated as the source of truth for value within the conversion action it is connected to. For fields other than value and currency the situation reverses: when transaction_id matches, other fields such as GCLID are ignored and the values recorded by the tag remain. Rows with no match are created as new conversion events and attributed using the identifiers that were sent. The only exception is the first fourteen days of the setup: value updating is disabled during that period.
+ What is the difference between an empty value and a zero value?
Zero is a valid value used for situations such as a full refund, meaning it pulls that row's value down to zero. If a record's value should not be touched at all, the field is left empty. Because every numeric input feeds directly into reporting and value-based bidding strategies, sending refunded orders as zero and not sending them at all produce different outcomes.
+ Is creating a separate conversion action safer?
No, it creates risk instead. Deduplication only works within a single conversion action, between the tag and the additional source. If two different conversion actions are active together in the same campaign's goals, one transaction can be counted twice. Google's recommendation is to connect the additional source to the existing conversion action. If a new action has to be created, the old one needs to be removed from the same goal set.
+ Where should you look when the match rate comes out low?
At formatting first. A prefix or suffix difference, a case difference, a number written with decimals, leading zeros getting lost and placeholder values leaking through are the five most common causes. If those are clean, the second place to look is coverage: does the tag carry transaction_id on every send. The common root cause of low overlap is the ID being collected intermittently because of faulty tagging logic on some conversion pages.
+ When does the fourteen day trial period start?
It starts when the first offline upload is received for each conversion action. During that period the data from the additional source appears in reporting, in overlap estimates and in diagnostics output but does not enter bidding; existing tag conversions continue to be used in bidding as normal. When the period expires, the additional source data enters bidding automatically, and unresolved alerts in diagnostics do not prevent that.