Store Sales in Google Ads 2026: Feeding In-Store Purchases Through the Data Manager API

For any retailer with physical locations, a large slice of revenue simply does not exist inside Google Ads. Someone taps an ad on their phone, walks into the shop three days later, and pays at the till. In the account that looks like a click with no conversion. Smart Bidding concludes the traffic is worthless and quietly starves it of budget. The algorithm is not wrong — it was never shown half of the outcome. The mechanism built to close that gap is store sales in Google Ads.

There are three ways to push offline results back into the account, and they get confused constantly: store visits, offline conversion import, and store sales in Google Ads. Three different mechanisms, three different data requirements, three different levels of precision. This piece covers what store sales actually does, what changed in 2026 once uploads moved into the Data Manager API, who is even eligible, and how to ship an implementation without spending a month in support threads.

Three ways to bring offline into Google Ads

Before configuring anything, work out which mechanism answers your question. They are not interchangeable, and “let’s set up all three” is the fastest route to double-counted revenue.

Mechanism	What it measures	What it needs from you	Precision
Store visits	A visit to a location after a click or impression	Nothing beyond a linked business profile and enough volume	Modelled estimate, not a list of individuals
Offline conversion import	A deal tied to one specific click	GCLID/GBRAID/WBRAID captured in your CRM at lead time	Exact click attribution — but only where the click ID survived
Store sales	An in-store purchase matched on customer data	Hashed email, phone or address from receipts and loyalty data	Partial match rate, applied across your whole transaction stream

The critical distinction sits between rows two and three. Offline conversion import depends on a click identifier that an in-store buyer almost never hands you — they filled in no form, they just showed up. Store sales needs no GCLID at all: it takes customer identifiers off the receipt, hashes them, and matches them to Google accounts that saw your advertising. That is why store sales is the retail answer and offline conversion import remains the lead-generation answer.

If the basics are still shaky, start next door rather than here. Offline conversion import in Google Ads covers the CRM-driven lead-gen path, and store visit conversions explains where that modelled offline column comes from — a column plenty of teams mistake for real sales.

How store sales matching works

The concept is simple; the details are unforgiving. You send Google a set of transactions: when the purchase happened, for how much, in which currency, at which location, and which customer identifiers it carries. Those identifiers are turned into SHA-256 hashes before they leave your systems. Google hashes its own data the same way and looks for overlaps. A match ties the transaction to an ad interaction, and the real basket value lands in your reports.

Which identifiers actually pull their weight

• Email — by far the strongest signal. Normalise before hashing: trim whitespace, lowercase everything.
• Phone — only in E.164 format (country code, leading plus, no spaces or brackets), then hashed.
• First name, last name, postcode, country code — a package deal, useless individually. Names are hashed; postcode and country travel in the clear.

The practical consequence: match rate is a function of how disciplined your till and loyalty programme are about capturing contact details. A receipt carrying both email and phone matches far better than one carrying a surname and a postcode. No API change will rescue a checkout flow that collects nothing.

Confidential matching and encryption

Google has pushed confidential matching since 2025 — matching inside a trusted execution environment where neither party sees the other’s raw data. The Data Manager API supports that mode alongside additional encryption of identifiers on top of hashing. In practice this is mostly ammunition for the conversation with legal and security: customer data is not “sent to Google” in the everyday sense, it participates in an encrypted match.

Your legal basis for processing is still entirely your problem. Consent to share data with a third party for advertising purposes has to exist, and the logic mirrors what you already do on the web — see the breakdown of Consent Mode v2 and privacy; only the collection point differs.

What changed in 2026: store sales moved to the Data Manager API

The headline change is infrastructural. Offline uploads used to live in the Google Ads API as a multi-stage offline job: create the job, add operations, run it, poll it, unpick the errors. Every stage had its own failure mode.

In May 2026, Data Manager API v1.6 brought store sales across in a fundamentally simpler shape: a single event-ingestion request instead of a multi-step job. It also added fields that had been conspicuously missing:

• event_location with store_id — transactions attach to a specific shop rather than the account as a whole;
• an expanded Item resource — merchant_id, merchant_feed_label, merchant_feed_language_code, conversion_value and custom variables;
• coupon_codes on cart data — the promo code from the receipt rides along with the transaction;
• third_party_user_data — restricted to data partners, not available to ordinary advertisers.

A second wave landed in September 2026: Data Manager gained direct integration with Google Analytics and Display & Video 360, a universal API built on IAB Tech Lab standards, and built-in diagnostics that flag data problems before they poison campaigns. Google’s direction of travel is unambiguous — every first-party upload is being funnelled into one pipe. If you have not looked at that pipe as a whole, start with the overview of Data Manager and first-party data, where store sales is one source among several rather than a universe of its own.

The same release cycle introduced a metric quantifying how many extra conversions your first-party setup recovered. How to read it — and why the number usually lands below the marketing claims — is covered in the piece on Data Strength in Google Ads.

Who is eligible to use store sales in Google Ads

Time to manage expectations. Store sales ingestion is restricted to allowlisted accounts, and Google names the categories explicitly: retailers, restaurants, and automotive OEMs or regional dealer groups. This is not a toggle in the interface. It requires a confirmed business category, data that meets the requirements, and a review.

What that means in practice:

• A pure e-commerce brand with no physical locations will not get store sales — and does not need it. Web conversions plus enhanced conversions already cover the ground.
• A services business with a long sales cycle belongs on CRM-driven offline conversion import, not store sales.
• Affiliate and media-buying teams driving traffic to someone else’s offer will never qualify: the transactions happen elsewhere, you hold no customer identifiers, and the advertiser sends you a postback rather than receipts.

That last point is worth stating plainly, because offline measurement attracts a lot of noise. If your model is buying traffic for partner offers, your measurement stack is a tracker and postbacks, and your growth levers sit elsewhere: account quality, campaign structure, how fast you clear review. PPC Rebels helps with that infrastructure side — agency Google Ads accounts and launch support — but no tooling lets you measure another advertiser’s in-store revenue.

Preparing the data: your transaction schema

Nine failed implementations out of ten break on data, not on the API. The minimum field set your backend or warehouse has to produce:

• Customer identifiers — email and/or phone, normalised and hashed; where possible the name + postcode + country package as a fallback match path.
• Transaction timestamp — with an explicit time zone. This is its own trap: an ad account’s time zone is permanent, and if your till exports local shop time, your reporting will drift. The full picture is in the breakdown of Google Ads account time zone and currency.
• Amount and currency — the receipt amount with an explicit currency code, not a figure pre-converted into your account currency.
• Transaction ID — an end-to-end key for deduplication. Without it, re-running yesterday’s upload doubles your revenue.
• store_id — if you want results split by location instead of one undifferentiated pool.
• Basket contents — if you run a product feed and want offline purchases tied back to specific products.

Three decisions to make before the first upload

1. What counts as a conversion. The whole basket, or individual line items? This decision shapes every downstream report and is painful to reverse.
2. How returns are handled. An in-store return is not a negative row in tomorrow’s file; it is a conversion adjustment. The mechanics are in the piece on conversion adjustments. Ignore returns and bidding will optimise toward revenue that came back through the door.
3. How you prevent double counting. A click-and-collect order can arrive both as a web conversion and as an in-store transaction. You need a filter at export time: anything paid online never enters the store sales file.

A rollout plan that survives contact with reality

1. Confirm eligibility first. Before any development, establish with your Google representative that the account sits in an accepted category. API access is not permission to send store sales.
2. Inventory your sources. POS, loyalty programme, payment processor, ERP — write down where receipts and contacts actually live, and who owns each system.
3. Settle the legal basis. Consent, processing policy, retention. This runs longer than the engineering; budget weeks, not days.
4. Design the schema. Map your fields onto the Data Manager API model: transaction, identifiers, location, items, currency, timestamp.
5. Build normalisation and hashing on your side. The hash is computed by you; raw identifiers never leave.
6. Test on a narrow slice — one week, one location — and reconcile against the till report before scaling.
7. Set a cadence. Daily or weekly is the workable range. A quarterly batch will technically be accepted and will arrive far too late to influence bidding.
8. Instrument it. Error logs, counts of sent versus accepted transactions, an alert on volume dropping. A silently broken pipeline is the most expensive failure in measurement, because nobody notices for a month.

Reading the results

The first number everyone looks at is match rate. There is no universal benchmark — it reflects how well you collect contact details. As a rough orientation: if fewer than one in five transactions match, the problem is almost certainly identifier quality rather than Google’s matching. Check phone normalisation and the share of receipts with no email before blaming anything else.

Second, watch the upload window. Transactions that arrive too late lose their optimisation value even when they still appear in reports. That is precisely why infrequent batch uploads hollow out the whole project.

Third, watch the effect on bidding. Only fold store sales into a campaign goal once the stream is steady. Dropping one enormous historical upload onto a trained campaign is a step change in the data, and the strategy will react to it — rarely the way you hoped. Before you flip that switch, revisit how Google Ads bidding strategies behave when conversion composition changes: the rule about never changing goal and data in the same week applies here too.

Offline data does not change your report; it changes the algorithm’s decisions. While the stream is unstable, the honest move is to keep store sales as a secondary conversion and withhold control of bidding.

What implementation actually costs

Store sales is not an evening’s work for one marketer. A realistic team: an engineer or analyst who builds the export and integration, the POS owner who signs off on field availability, a lawyer or DPO who approves the processing basis, and the paid-media specialist deciding what counts as a conversion.

On timelines, the long pole is approval rather than code. The technical build is a matter of weeks in a simple setup; legal review and eligibility confirmation can stretch to a month or more, especially when data sits across several systems with different owners. Planning a launch “in time for the sale” only makes sense with at least a quarter of runway.

Then there is maintenance. POS upgrades, schema changes, credential rotation — someone has to own this permanently. If nobody can, it is more honest not to start: a broken upload is worse than no upload, because it produces the illusion of a complete picture on top of incomplete data.

What to check one month in

• Does total in-store revenue in the account reconcile with the till report for the same period, adjusted for match rate?
• Has the share of rejected transactions risen after the latest POS release?
• Is the lag between purchase and reported conversion stable?
• Did bidding behaviour shift after the offline conversion entered the goal — and did it shift the right way?

Common mistakes and what they cost

• No transaction ID. Re-uploads duplicate revenue, reported ROAS climbs, actual money does not, and bidding starts overpaying for traffic.
• Timestamps without a time zone. Transactions smear across adjacent days, and daily analysis plus ad scheduling stop matching reality.
• Pre-converted currency. Double conversion, mismatches against finance, reports that will never reconcile.
• Online orders in the store sales file. Double counting, inflated offline performance, budget shifted on a false signal.
• Returns never sent. The algorithm optimises toward cancelled revenue — brutal in categories with high return rates.
• Fire-and-forget pipelines. A POS update breaks the export, nobody notices, and six weeks later campaigns have retrained on partial data.

When store sales is the wrong project

If offline is a small share of turnover and receipts rarely carry contact details, the implementation will not pay for itself. Better to extract everything available from what you already have: a clean web signal through server-side tagging with sGTM, enhanced conversions, and tidy audiences. On that last point — most accounts leak first-party value exactly where it is cheapest to fix, in the lists themselves. Thresholds and membership duration are unpacked in the piece on the Google Ads Audience Manager.

If you are still building the measurement stack and unsure what to fix first, the prioritisation logic is laid out in the Google Ads guide, and a hands-on review of your own conversion setup fits naturally into structured training.

FAQ

How is store sales different from offline conversion import?

Offline conversion import ties a deal to one specific click using a GCLID stored in your CRM. Store sales uses no click identifier at all — it matches transactions on hashed customer data. The first is a lead-generation tool, the second is a retail tool.

Do I need a GCLID for store sales?

No. That is the entire point: an in-store buyer never handed you a click identifier, so matching runs on email, phone, or the name-plus-postcode-plus-country package.

Who can upload store sales data?

Allowlisted accounts in retail, restaurants, and automotive OEM or regional dealer categories. Eligibility is confirmed before development begins; having technical API access does not substitute for it.

What match rate should I expect?

There is no universal figure — it depends on how well you capture contact details at the till. As orientation, a match rate below roughly one in five transactions almost always points at identifier quality or normalisation rather than Google’s matching.

How often should I upload?

Daily or weekly. Rare batch uploads will pass validation but arrive too late to influence bidding, which erases most of the value of the project.

What did Data Manager API v1.6 change for store sales?

Ingestion moved to a single event request instead of a multi-step offline job, transactions can be tied to a specific shop through store_id, the item resource expanded, and coupon codes can travel with cart data.

How do I avoid double counting click-and-collect?

Filter at export: anything paid online never enters the store sales file, even when the goods were handed over in store. Pair that with a consistent transaction ID so repeat uploads deduplicate cleanly.

How are returns handled?

Through conversion adjustments, not by dropping rows from the next file. A return has to retract previously credited value, otherwise bidding keeps optimising toward revenue that no longer exists.

Is it safe to send customer data?

Identifiers are hashed on your side before transmission, and matching supports confidential matching plus additional encryption. The legal basis for processing and the collection of consent, however, remain entirely yours.

Does store sales work for affiliate traffic?

No. The transactions belong to the advertiser, and a media buyer has no access to receipts or customer identifiers. For affiliate models the measurement layer is a tracker with postbacks, not offline uploads.

Should I add store sales to the campaign goal immediately?

Not while the stream is still unstable. Keep the conversion secondary, confirm that volume and match rate hold steady, and only then let it influence bidding.

The point of store sales is not a better-looking report. It is that the algorithm finally sees the half of the revenue you were buying clicks for. Until the data arrives clean and on time, keeping it out of optimisation is the safer trade.