The question usually arrives like this: sGTM or Data Manager? Because the two do not fill the same gap, the question itself is faulty. sGTM moves the moment of measurement to the server, Data Manager writes the record measurement never saw, afterwards. The right question is not which one to set up, it is which data travels which path.
I covered the sGTM side in two earlier posts: setup and tag configuration and hosting selection. I gathered the Data Manager side into three posts this month: the destination map, additional data source behaviour and the API implementation. This post draws the line between the two.
They Do Not Close the Same Loss
What separates the layers is where the data comes from.
| Dimension | sGTM | Data Manager |
|---|---|---|
| Destination surface | Vendor-independent: Google, Meta CAPI, TikTok, your own endpoint | Google products only |
| Trigger | Browser or app event, real time | Backend record, batched, after the event |
| What it recovers | Cookie lifetime, browser restrictions, client-side blocking | The record the tag never saw: phone, store, CRM, refund |
| Identity surface | Cookie, click ID, first-party storage | transaction_id, hashed user data, click ID in the record |
| Value updating | None, the value known at event time is written | Yes, permanently overrides on the matching row |
| Consent | Consent Mode signal, at event time | Row-level field or account-level default |
| Rhythm | At event time | Daily at most in the interface, caller-defined frequency in the API |
| Cost line | Server and maintenance | Data pipeline and scheduling |
The first row also frames the comparison. Data Manager is an ingestion layer writing to Google products: Google Ads, Display & Video 360, Campaign Manager 360, Search Ads 360, Google Analytics and Ad Manager. Meta, TikTok, LinkedIn or an email platform are not on that list. The documentation’s own definition says as much: a unified ingestion API for sending first-party data to multiple Google advertising products.1 sGTM is destination-independent: with ready-made tag templates, community templates and templates you write yourself, it can send server-to-server requests to any endpoint.
The practical consequence: in a setup that also advertises outside Google, Data Manager solves only one branch of the measurement architecture. The conversions API on the Meta side, its counterpart on the TikTok side and any need to write into your own warehouse still have to be handled separately. sGTM becomes the place where a single event stream gets duplicated and distributed to several destinations.
The second most overlooked row in the table is value updating. Once the tag has written a conversion, it cannot go back and touch that value. An uploaded record permanently overrides the tag value on the matching row.2 Refunds, partial refunds and post-order corrections can only be reported through the second path.
On the other hand, Data Manager’s rhythm is not real time. On a dashboard connector import frequency is daily at most.3 There is no such limit on the API side, but uploading is still a post-event operation. The signal the bidding algorithm needs at event time is carried by sGTM.
The Bond Is Built One Way
The real relationship between the two layers is technical and one-directional: the attribution identifier used during upload is mostly captured on the tag side.
In an additional data source upload the required fields are transaction ID and conversion time, plus at least one attribution identifier: hashed user data, or click IDs such as gclid, gbraid and wbraid.2 That click ID landing in the order record does not happen by itself; it has to be stored in first-party storage and written into the order record during the checkout flow.
In one account I measured, first-party cookie plus click ID capture settled at a practical ceiling around ninety percent, dropping a few points as the window widened; I covered the detail in the row level join post. The practical conclusion here: if the click ID was never captured, only hashed user data remains for the upload, so the matching material narrows from the start.
There is a contribution in the reverse direction too, but a weaker one: the value update on the Data Manager side can correct a faulty or incomplete amount written by the tag. That does not close a gap in the sGTM setup, it only corrects the outcome.
Four Scenarios, Four Different Answers
sGTM alone can be enough. A setup selling a digital product with no refunds, or negligible refunds, where the sale completes entirely on the web. There is almost no record the tag cannot see here, and the value is final at event time. Adding an upload layer brings maintenance load without bringing new information.
Data Manager alone can make sense. A setup where the weight of sales sits offline: orders taken by phone, sales closed through dealers, in-store sales. Web traffic plays a role on the advertising side, but the conversion itself completes elsewhere. What sGTM adds stays limited here, because the event to be measured does not happen in the browser. If there is a form or a search start on the web side, sGTM still helps, but the weight of the decision sits with the upload layer.
Both are needed. E-commerce, a refund cycle, multi-channel sales. The tag carries the immediate conversion and the bidding signal, the upload layer completes refunds, cancellations, phone orders and the purchases the tag missed. This group is the most crowded among the scenarios.
Advertising outside Google changes the equation. If Meta, TikTok or another platform takes a meaningful share of the budget, the sGTM side has to be built anyway, because Data Manager does not send data to those platforms. The question then stops being “which one” and becomes “will I additionally strengthen the Google side with an upload layer”.
The decision reduces to two questions. First: is the place where the conversion happens the same as the place where it becomes final. If they are the same, one layer is enough; if they differ, two layers are needed. Second: are ads running only on Google. If the answer is no, sGTM is already part of the equation.
The Cost of Moving to Data Manager Without sGTM
The answer to the ordering question follows from that. Building the upload layer first and leaving identity capture for later produces a loss that cannot be made up retroactively: if past orders carry no click ID, it cannot be added later, because that value only existed at the moment of the click.
So the recommended order starts on the identity side.
- Writing the click ID into first-party storage and carrying it into the order record during checkout.
- Producing the
transaction_idvalue in exactly the same format on the tag side and the backend side. - Bringing the upload layer live, using the first fourteen days for verification rather than bidding.4
- Starting to monitor diagnostics output.
The first two items belong to the sGTM side, the last two to Data Manager. What gets lost when the order breaks is not measurement, it is the past.
What the Layer Split Means for Consent
The two paths read consent at different points. On the sGTM side the signal arrives at event time and behaviour changes with Consent Mode state. On the Data Manager side consent is either sent as a row-level field or the account-level default applies.3
That difference produces an operational consequence: if consent state is not held in the backend record, the upload falls back to the account default, and what that default is happens to be a separate setting in the interface. So consent managed carefully on the sGTM side can end up subject to a different rule on the upload side without anyone noticing. In a setup running both layers, that is one of the first settings to check.
Summary Decision
| Situation | Recommendation |
|---|---|
| Conversion happens and becomes final on the web | sGTM, upload layer optional |
| Conversion happens off the web | Data Manager, sGTM secondary |
| Conversion starts on the web, becomes final elsewhere | Both, with the order starting at identity capture |
| There is refund and partial refund volume | Data Manager mandatory, value updating cannot be done another way |
| Ads also run on non-Google platforms | sGTM mandatory, Data Manager only strengthens the Google branch |
The most commonly skipped thing in setups running both layers is the order: an upload made before identity capture is built leaves a match loss on past orders that cannot be recovered. Reading the current setup against that order clarifies which job comes first.
Request a ReviewFootnotes
- 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.” ↩
- Boost your tag with additional data sources (Google Ads Data Manager Help). 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
- Manage your connections (Google Ads Data Manager Help). The page states that import frequency on the dashboard side is daily at most and that data has to be refreshed before the run. It also defines the account-level default consent setting for imported and uploaded data, and that values stated at connection and upload level override that default. ↩ ↩2
- Fix diagnostic alerts for multi-source conversions (Google Ads Data Manager Help). The trial 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 even if alerts are unresolved. ↩
- 01 Scope is asymmetric: Data Manager writes only to Google products, while sGTM writes to any destination that has a tag template or can have one written. If data needs to reach Meta, TikTok or your own endpoint, that job cannot be done with Data Manager.
- 02 The two layers close different losses. sGTM reduces the loss caused by browser restrictions and cookie lifetime; Data Manager carries the record the tag never saw: a phone order, an in-store sale, a lead closed in the CRM, a correction after a refund.
- 03 Value updating exists only on the Data Manager side. The tag writes what it knows at event time and cannot change it afterwards; an uploaded record permanently overrides the tag value on the matching row.
- 04 The bond is built one way: the click ID sGTM stores is used as the attribution identifier in the backend upload. If the click ID was never captured, only hashed user data remains and the match rate drops.
- 05 Only one scenario makes both mandatory. For a digital product with no refunds sGTM alone can be enough, for offline-weighted sales Data Manager takes the lead, and for e-commerce with a refund cycle both are needed; if ads run outside Google, sGTM is unavoidable regardless.
+ If I have sGTM, do I still need Data Manager?
Yes, because sGTM only carries events that reach the browser or the app. An order taken by phone, a sale completed in store, a lead closed in the CRM weeks later and a value correction after a refund are records no tag can see. The tag also cannot change the value it wrote at event time; an uploaded record can permanently update the value on the matching row. sGTM raises signal quality, Data Manager widens the scope.
+ If I have Data Manager, is sGTM worth setting up?
Yes, because Data Manager runs daily at most on the dashboard side and does not substitute for a real-time signal. More importantly, the attribution identifier used during upload is usually captured on the sGTM side: without a click ID held in first-party storage, only hashed user data remains. Setting up click ID capture before building the upload raises the match rate of every upload that follows.
+ Will the two count the same conversion twice?
Not as long as the deduplication rules are followed. When an additional data source is connected to a conversion action, matching runs on transaction_id and only within that conversion action. The risk lies in creating a new action instead of connecting to the existing one and leaving both active in the same goal set; in that case one transaction can be counted twice. So the double counting risk comes from the conversion action design, not from using the layers together.
+ In which order should they be set up?
Identity capture first, upload second. An upload made before the click ID is written to first-party storage and carried into the order record limits the matching material from the start. Once the identity side is working, the backend upload goes live, and because the first fourteen days are not biddable, that window is used for verification.
+ Does Data Manager avoid the cost that sGTM has?
There is no server cost, because there is no container to run on the Data Manager side; a dashboard connector or an API call is used instead. But the cost is not zero: building the data pipeline, field mapping, scheduling and diagnostics follow-up after upload all create work for the team. The difference is that the cost moves from infrastructure to data engineering.