Table of Contents
Offline Conversion Tracking for Retail & Marketplace Sales
Introduction
Roughly 80% of a typical omnichannel brand's sales happen somewhere its ad platforms cannot see. When a purchase happens on a shelf at Target, in a Costco aisle, or inside an Amazon order, none of that data reaches Meta, Google, or TikTok.
When a brand keeps buying ads against the 20% that runs through its own site, the algorithms keep optimizing toward that slice as if it were the whole business.
Offline conversion tracking is how you close that retail data gap. This guide covers what offline conversion tracking actually is, what each platform requires in 2026 (the Google path changed materially this year), and the part most guides skip entirely: where the buyer data comes from in the first place.
For each platform, there are two ways to get there. You can set it up manually, which requires building and maintaining the integration yourself (exporting purchase files, hashing identifiers, mapping fields to each platform's spec, and uploading) on a schedule somebody has to own.
Or, you can connect Brij Signal once and have each verified purchase forwarded automatically as it happens. Both paths are documented below, so you can decide which one your team should be spending its time on.
What is Offline Conversion Tracking?
An offline conversion is any purchase or valuable action that happens outside the channel where the ad was served, such as an in-store transaction, a marketplace order, or a subscription activated later.
Offline conversion tracking is the practice of sending those events back to the ad platform as conversion data, so the platform can (a) attribute them to the campaigns that influenced them and (b) use them to optimize future delivery.
Mechanically, it works by matching. You send the platform a purchase event containing hashed customer identifiers — email, phone, name, address — plus the transaction details. The platform hashes the same identifiers on its side, looks for overlap with people who saw or clicked your ads, and credits the conversion where it finds a match.
There are two major benefits to implementing offline conversion tracking: measurement recovery, and algorithmic improvement
Measurement Recovery
Sales that were always happening start appearing in your reporting. Reported ROAS rises, not because performance changed, but because you stopped hiding revenue from your own dashboards.
Algorithmic Improvement
Once the platform can see your complete purchase set, its bidding and audience models have far more to learn from. This effect is slower, compounding, and the more valuable of the two — but it takes weeks of clean event volume before it shows up.
Why Offline Conversion Tracking Matters in 2026
Between 2021 and 2026, three things changed at once.
Ad Buying Became Algorithmic
Advantage+ and Performance Max don't take much manual direction. You feed them conversion signal and a budget; the model does the rest. That makes signal quality the primary lever you still control, and an incomplete signal set is now a structural handicap rather than a reporting annoyance.
Browser-side Tracking Eroded
ITP, ad blockers, consent gating, and iOS restrictions mean a meaningful share of even your online conversions never reach the pixel. Server-side event delivery stopped being an optimization and became table stakes.
Retail and Marketplace Growth Outpaced DTC.
For most CPG and consumer brands, the fastest-growing channels are precisely the ones that report nothing back. The measurement gap widened as the channel mix shifted.
Put together: the channels doing the most volume are the ones your optimization engine knows the least about.
Why Common Offline Data "Solutions" Fail
Before the platform integrations, it's worth being honest about where the data comes from. This is the actual bottleneck, and it's why most offline conversion tracking projects stall.
Retailer POS and Sell-Through Reports
- What you get: units sold by store, by week, sometimes by day.
- Why it doesn't work for this: it's aggregate. No customer identifiers, no way to match anything. It tells you how much sold, never who bought. Useful for the sales team, useless to a Conversions API.
Syndicated Panel Aata (Nielsen, Circana, SPINS)
- What you get: category and share benchmarking, projected volumes.
- Why it doesn't work for this: it's modeled from a sample and delivered on a lag. There is no individual, matchable buyer at the other end of it.
Receipt-Panel and Cashback Apps
- What you get: verified purchase data at real scale, fast.
- Why it doesn't work for this: the shopper's relationship is with the app, not with you. You receive an anonymized aggregate — insight you can read but not a customer you can own, match, or market to. The identity is the asset, and in that model the identity stays with the panel.
Brand-Owned Purchase Capture
- What you get: a verified purchase tied to a customer who has identified themselves directly to you.
- How it works: you give the shopper a reason to raise their hand at or after the moment of purchase — a QR code on pack or at shelf, product or warranty registration, a rebate, a sweepstakes entry, a receipt upload — and they hand you their email and phone in exchange for something they actually want.
That last one is the only path that produces what the platforms need: a real customer identifier attached to a verified purchase, owned by you. Everything downstream in this guide depends on having it.
The Anatomy of an Offline Conversion Event
Every platform wants roughly the same payload. The vocabulary differs; the substance doesn't.
Match Keys (The Identifiers)
Email and phone do most of the work. Name, city, state, ZIP, and country add incremental matching. A stable external_id — your own customer ID — is worth including everywhere it's supported, because it improves both matching and deduplication.
All PII must be normalized (lowercase, trimmed, phone in E.164) and then SHA-256 hashed before it leaves your systems. Normalize before hashing, or the hashes won't line up with the platform's.
Event Metadata
The event name (Purchase), the timestamp of the actual transaction — not your upload time — and a unique event or order ID for deduplication.
Transaction Detail
Value as a bare number with no currency symbol, currency as an ISO code, and ideally line items. Sending real values rather than a flat placeholder is what lets value-based bidding function at all.
Source Designation
A field telling the platform this happened in the physical world rather than on your site. Get this wrong and events get misclassified or rejected outright.
Consent Signals
Important when operating in a regulated region.
Two failure modes account for most broken implementations: hashing something that shouldn't be hashed (click IDs, device IDs), and sending events with a timestamp outside the platform's acceptance window. Both fail quietly.
Building vs. Automating Offline Conversion Tracking
Every platform section below can be executed either way. It's worth understanding the difference before you scope the project, because the two paths have very different ongoing costs.
Manual Build
You export purchases from wherever they live, normalize and hash the identifiers, map every field to each platform's specification, and upload on a recurring schedule. Three platforms means three separate integrations, three field mappings, three sets of timing rules, and three diagnostics panels somebody needs to check.
The build is a defined project. The maintenance is permanent, and when a platform changes its API, as Meta did in 2025 and Google did this year, you re-engineer.
Here's a more detailed breakdown of the manual build route, piece by piece:
- Sourcing identified buyers: You solve this separately; nothing here works without it
- Normalizing + SHA-256 hashing: Your engineers, per platform spec
- Payload formatting: Three integrations, three field mappings
- Upload cadence: Batch exports on a schedule someone owns
- Acceptance windows: You track 7-day and 62-day limits; late rows rejected silently
- Deduplication: You build and maintain order/event ID logic
- Rejected-event monitoring: Someone remembers to check the diagnostics panel
- Platform API migrations: Re-engineering each time
- CRM + lifecycle activation: A second, separate build
Automation (Brij Signal)
Brij Signal captures the verified purchase at the moment the shopper identifies themselves — a QR scan on pack, a product registration, a rebate claim, a receipt upload.
Then, it forwards it as a conversion event to Meta, Google, and TikTok Ads through their Conversions APIs, plus your CRM and email/SMS platform, without a batch file in the loop.
One connection, and events flow as purchases are verified rather than whenever the next upload runs.
Here's a more detailed breakdown of the Brij Signal route, piece by piece:
- Sourcing identified buyers: Included — QR, registration, rebate, and receipt-upload capture
- Normalizing + SHA-256 hashing: Handled
- Payload formatting: One connection, three destinations
- Upload cadence: Event fires as each purchase is verified
- Acceptance windows: Events arrive fresh, nowhere near the window
- Deduplication: Handled
- Rejected-event monitoring: Monitored
- Platform API migrations: Handled on Brij's side
- CRM + lifecycle activation: Same verified events are passed in parallel
The manual path is entirely viable, and if you have engineering capacity and a reliable stream of identified retail buyers already, the sections below tell you exactly how to do it. The question is whether sustaining three integrations and a recurring upload job is the highest use of that capacity.
Meta: Offline Conversions Now Run through the Conversions API
The most important thing to know: the standalone Offline Conversions API is gone.
Meta deprecated it in May 2025, and Graph API v16 was the last version to support it. The CSV-upload-to-an-offline-event-set workflow that most published tutorials still describe no longer exists. A large number of guides on the open web have not been updated.
Everything now flows through the same Conversions API endpoint as your web events. What distinguishes an in-store purchase from a site purchase is a single parameter.
How to send in-store and marketplace purchases:
- Use a dataset. Datasets replaced offline event sets and consolidate web, app, store, and messaging events into one interface. Link the dataset to the ad accounts you want the events to attribute to, in Business Settings — skip this and your events land but credit nothing.
- Set action_source to physical_store for in-store transactions. Use system_generated for CRM- or backend-originated events. Website events stay website. This is the single most consequential field in the payload.
- Send hashed identifiers in user_data. SHA-256 for email, phone, first and last name, date of birth, and external_id. Do not hash fbp, fbc, lead_id, or mobile advertiser IDs — Meta needs those raw, and hashing them is a common silent failure.
- Respect the timing windows. Standard CAPI events must carry an event_time within 7 days; a single event older than that returns an error and Meta rejects the entire request rather than the offending row. For events marked physical_store, Meta's guidance is to upload transactions within 62 days of the conversion.
- Deduplicate on order_id. Note that offline events deduplicate only against other offline events — not against pixel events — so an in-store purchase and a web purchase for the same person are treated as two distinct conversions, which is usually what you want.
How to tell whether it's working: Events Manager reports an Event Match Quality score from 1 to 10 for each event source. EMQ is the closest thing Meta gives you to a direct readout on identifier quality, and it moves when you add match keys. Treat anything under 6 as a data hygiene problem rather than a Meta problem.
Doing this Manually vs. with Brij Signal
Every step above is yours to build and keep running: the dataset wiring, the action_source logic, the hashing rules including the fields that must not be hashed, the order_id dedup scheme, and a recurring export that stays inside the acceptance window.
The window is the part that bites. Batch on a weekly cadence and a purchase captured on day one is already six days old before it uploads — and because Meta rejects an entire request when a single row exceeds 7 days, one stale record can silently drop the whole batch.
With Brij Signal, the event fires when the shopper registers the purchase, so it reaches Meta the same day rather than whenever the next export runs.
The dataset connection, physical_store designation, hashing, and deduplication are handled, and the migration off the deprecated Offline Conversions API was absorbed on Brij's side rather than becoming an engineering ticket on yours.
Brands using Brij Signal are seeing EMQs of 9+, along with 30%+ uplifts in attributed conversions on Meta.
Google Ads: Conversion Imports vs. Identifier-Based Matching
Google's offline measurement splits into two mechanisms that get muddled together constantly, and picking the wrong one wastes a quarter.
Click-Based Offline Conversion Imports
You captured a GCLID (or GBRAID/WBRAID) when the customer clicked, stored it against their record, and later upload the conversion tied to that click ID. This is built for lead-gen: an ad click, then a sale closed by phone or in a showroom.
It does not fit retail purchases, because the person who bought your product at Kroger never clicked anything.
Identifier-Based Matching
You upload hashed customer data and transaction details, and Google matches against signed-in users who engaged with your ads. This is the retail path. Two flavors matter:
- Store sales conversions: Purpose-built for offline transactions, submitted via offline user data jobs with SHA-256 normalized identifiers, transaction amounts, timestamps, and EEA consent flags where applicable. This is allowlist-gated — you need your Google rep to enable it, so start that conversation early.
- Enhanced conversions for leads: The upgraded form of offline conversion import that supplements click IDs with user-provided data. Better than legacy OCI if you have both.
The 2026 change nobody has updated their documentation for: Google consolidated first-party data ingestion into the Data Manager API, and the old pathways are closing behind it.
- April 1, 2026: Customer Match uploads through the Google Ads API stopped working for new integrations; new Customer Match work must use the Data Manager API.
- April 2026: Google Ads began accepting user-provided data from website tags, Data Manager, and API connections simultaneously, so you no longer choose between implementation methods. Existing users are being migrated automatically.
- May 2026: Data Manager API v1.6 added store sales measurement, handling it through the same endpoint structure as other conversion types instead of separate upload jobs.
- June 15, 2026: The Google Ads API stopped accepting new adopters for offline conversion imports and enhanced conversions for leads. Accounts already importing before the cutoff can continue while they migrate.
The business capability isn't going away; the plumbing moved. If you're scoping offline conversion tracking for Google today, scope it against the Data Manager API and don't let a vendor build you a fresh UploadClickConversions integration.
Doing this Manually vs. with Brij Signal
Google is the clearest illustration of what the manual path actually costs. Any team that built a UploadClickConversions integration in 2024 has spent 2026 rebuilding it against the Data Manager API. Anyone who wired Customer Match through the Google Ads API rebuilt that too, in April.
On top of the migration work, the manual path means constructing offline user data jobs, managing per-request identifier limits, attaching EEA consent flags, and running the upload as an asynchronous job somebody monitors.
Brij Signal sends verified purchases into Google as they're captured, and platform-side migrations like this year's Data Manager consolidation get handled once, centrally, rather than by every brand's engineering team in parallel.
One thing automation does not remove: store sales conversions are allowlist-gated on Google's side, so you'll still need your Google rep to enable access regardless of which path you take. Start that request early.
Brands using Brij signal are seeing up to a 50% uplift in Google-attributed conversions.
TikTok: Events API, with an approval step
TikTok handles offline conversions through its Events API for offline events, using offline event sets configured in TikTok Events Manager.
The mechanics will feel familiar: server-to-server delivery, SHA-256 hashed email and phone as the primary match keys, event_id for deduplication against pixel events, and an acceptance window of roughly 7 days from the transaction.
The wrinkle is procedural. TikTok's offline events program is approval-gated — participants must be approved by TikTok, historically routed through TikTok or LiveRamp representatives. Build the approval timeline into your project plan; it is not a self-serve toggle you flip on a Tuesday.
Worth the effort even at lower spend, for one reason: TikTok custom audiences built from pixel purchase events are capped by the pixel's match rate. Server-side events carrying real email data raise that ceiling, which means more of your actual buyers make it into the seed audience TikTok uses to build lookalikes.
Doing this Manually vs. with Brij Signal
TikTok is usually the platform that gets deferred. It's typically the smallest share of spend, and building a third bespoke integration for it rarely survives prioritization, so brands run TikTok on pixel data alone and quietly accept a lower audience ceiling.
That calculus changes when the offline feed already exists. With Brij Signal, TikTok is another destination for the same verified purchase event rather than a separate project competing for engineering time, so it stops being the one you never get to. As with Google, the approval step is TikTok's own and applies either way — plan for it rather than around it.
What to Expect, and on What Timeline
Set expectations across three horizons.
Week One
Events start appearing. Your job here is diagnostic, not performance. Check acceptance rates, match rates, and EMQ. Fix rejected events before you evaluate anything else.
Weeks Two to Four:
Attributed conversions climb as previously invisible purchases get credited. Reported ROAS rises. Nothing about your media has improved yet; your reporting has simply stopped lying to you.
Say this out loud to your leadership before it happens, or someone will build a forecast on it.
Month Two Onward:
The optimization effect. Bidding models trained on your complete purchase set — not just the DTC slice — start allocating differently. Audience quality improves because your seeds now include buyers you previously couldn't identify.
On Efficiency
Feeding total sales rather than a fraction of them gives the algorithms a materially better picture of who converts, and acquisition efficiency generally improves as a result.
How much depends on your channel mix, spend level, and how much of your volume was invisible to begin with. Anyone quoting you a specific percentage before seeing your data is guessing.
Match Rate is Your Leading Indicator
Below 50% is a problem worth stopping to fix. Clean hashed email and phone feeds typically land in the 70–90% range. Brij's feeds average a 99.7% match rate, because the identifiers come directly from customers who registered rather than from probabilistic stitching.
Six Mistakes that Quietly Kill These Implementations
- Hashing the wrong fields: Click IDs and device IDs go raw. Hash them and matching collapses without an obvious error.
- Timestamping the upload instead of the transaction. The event time must be when the purchase happened. Get this wrong and you'll silently blow past acceptance windows.
- Batching on too slow a cadence: A weekly or monthly upload burns most of your acceptance window before the file is even generated, and it delays every optimization signal by the length of the interval. If you're uploading manually, upload daily. If that's not sustainable, that's the argument for automating the feed.
- Sending a flat placeholder value: Value-based bidding needs real transaction amounts. A hardcoded $1 teaches the algorithm that every customer is identical.
- Never checking diagnostics again: Events Manager and the Google Ads diagnostics panel both report rejections. Most teams look once during setup and never return — and a manual pipeline gives you no other way to find out it broke.
- Treating the API as the project: The integration is a few weeks of engineering. Building a durable stream of identified retail buyers is the actual work, and no API solves it for you.
How Brij Fits
Brij exists to solve the fourth problem in that list; the supply of identified buyers.
The mechanism is shelf to signal. A shopper buys your product in retail or on a marketplace. They scan a QR code on pack, register the product, claim a rebate, or upload a receipt — and in doing so identify themselves to you directly.
Brij verifies the purchase and forwards it as a deterministic conversion event to Meta, Google, and TikTok Ads through their Conversions APIs, and to your CRM and email/SMS platform at the same time.
Because that hand-off is automatic, there's no export, no hashing script, no upload calendar, and no batch to fall outside an acceptance window. The event moves when the purchase is verified.
The parallel CRM delivery is what makes this compound rather than just report. The same verified purchase event that sharpens your ad targeting also enters your lifecycle flows, so acquisition efficiency and customer lifetime value move together instead of trading against each other.
Building that twice — once for the ad platforms, once for the CRM — is a common outcome of the manual path.
Two distinctions worth being precise about:
Signal is Deterministic, Not Modeled
Brij is not multi-touch attribution, marketing mix modeling, or incrementality testing. It's the deterministic offline purchase data that sits underneath all three and makes their outputs better. If you run an MMM, better inputs improve it.
You Own Your Data
In a receipt-panel model, the shopper belongs to the panel and you receive anonymized aggregate insight. With Brij, the shopper identifies themselves to your brand — your customer, your data, your Conversions API connection.
Brij is SOC 2 Type 1 compliant, GDPR- and CCPA-aligned, with SHA-256 hashing throughout and customer data that remains brand-owned.
FAQ
What is an offline conversion?
Any purchase or valuable action that happens outside the channel where the ad was served — an in-store purchase, a marketplace order, a phone sale, or a subscription activated after the browsing session ended.
How do I measure offline conversions?
Send the transaction to the ad platform as a server-side conversion event containing hashed customer identifiers (email, phone, name, address) plus the transaction value and timestamp. The platform matches those identifiers against people who saw or clicked your ads and credits the conversion accordingly.
Can I still upload offline conversions to Facebook with a CSV?
No. Meta deprecated the standalone Offline Conversions API and the offline-event-set CSV workflow in May 2025. Offline events now go through the standard Conversions API with action_source set to physical_store.
How do I track offline conversions in Google Ads without a GCLID?
Use identifier-based matching rather than click-based import. Store sales conversions accept hashed customer data and transaction details without any click ID — it requires allowlisting through your Google rep, and as of 2026 should be implemented through the Data Manager API.
Do I have to upload offline conversions manually?
No. You can build the integrations yourself and run recurring exports, or connect a platform that forwards each verified purchase automatically as it's captured. Manual uploads work, but they add latency equal to your upload interval, consume most of the platform acceptance window before the file is generated, and require someone to own the schedule and monitor rejections indefinitely.
How often should I upload if I'm doing it manually?
Daily. Weekly uploads mean a purchase captured on day one is already six days old when it lands, which puts it at the edge of Meta's 7-day acceptance window — and one over-age row causes Meta to reject the entire request rather than the individual record.
How far back can I upload an offline purchase?
It varies by platform. Meta accepts standard Conversions API events with timestamps up to 7 days old and advises uploading physical_store transactions within 62 days of the conversion. TikTok's window is roughly 7 days. Check current platform documentation before you build, since these change.
What is a good match rate for offline conversions?
Below 50% signals a data hygiene problem worth fixing before you evaluate anything else. Clean feeds with verified email and phone typically reach 70–90%. Feeds built from direct customer registration can run substantially higher.
Does offline conversion tracking lower CAC?
Indirectly, and not immediately. First your reporting gets accurate, which raises reported ROAS without changing performance. Then, over subsequent weeks, the platform's bidding and audience models improve because they can finally see your total sales rather than a fraction. The size of that efficiency gain varies by brand.
Is this the same as multi-touch attribution or MMM?
No. Those are modeling approaches that estimate credit across touchpoints. Offline conversion tracking supplies deterministic purchase data — the raw signal those models are usually missing for retail and marketplace sales.
The Takeaway
The APIs are the straightforward part. Meta consolidated offline events into the Conversions API. Google moved first-party ingestion into the Data Manager API. TikTok will approve your offline events program if you ask. A competent engineering team can wire all three in a few weeks.
Keeping them wired is the less glamorous half. Three integrations, a recurring upload job, per-platform timing rules, and a migration every time a platform reorganizes its ingestion isa permanent line item, and it's the reason so many brands get one platform live and never finish the other two.
And the hard part sits further upstream still: having a real, verified, identified buyer at the end of every retail and marketplace purchase. Solve that, automate the delivery, and the integrations stop being a project at all.
See how Brij turns shelf purchases into deterministic signal for Meta, Google, and TikTok Ads — book a demo.
