Why are my Google Ads offline conversions not importing?
An offline conversion import that reports success but matches nothing has one of four problems: the gclid was never captured at first touch so there is nothing to match on, the click is older than the 90-day import window, the conversion time is formatted wrong or sits in the wrong timezone, or the conversion action named in the file doesn't exactly match one in the account. The upload succeeding tells you the file parsed — it says nothing about whether anything matched, and those are different results.
Free30 minutesNo obligation
Offline conversions not importing · what breaks
What this looks like when it's happening to you — Offline conversions not importing
- 01
Uploads succeed, conversions never appear
The interface reports the file processed and the account shows nothing.
- 02
A low match rate you can't explain
Some rows land, most don't, with no obvious pattern.
- 03
It worked and then quietly stopped
Usually after a CRM field rename nobody connected to advertising.
Offline conversions not importing · the fix
What changes once it's fixed — Offline conversions not importing
Closed revenue reaches the account
Bidding can optimise toward deals instead of form fills.
Match rate becomes a number you watch
Rather than an assumption nobody has tested.
Failures raise an alert
So a silent break is caught in days rather than at quarter end.
Offline conversions not importing · architecture
Why your conversion data was wrong in the first place
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to offline conversions not importing, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
Offline conversions not importing · normal or broken
Some of this is supposed to happen — Offline conversions not importing
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
Not every deal matching
Some customers never clicked an ad. A match rate below 100% is expected.
A delay before conversions appear
Imported conversions are credited to the original click date and can take a day to surface.
Actually broken
No gclid on the CRM record
The most common cause by a wide margin, and it can't be fixed retroactively.
Click outside the import window
Deals closing beyond 90 days can't be imported against the original click.
Wrong conversion time format or timezone
Google rejects or misplaces the row; a timezone error can push conversions outside the window entirely.
Conversion action name mismatch
The name in the file must match the account exactly, including case and spacing.
Offline conversions not importing · diagnose
How we find out why are my google ads offline conversions not importing
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Check whether any CRM record holds a gclid
Filter for non-empty. If the answer is none, that is the entire finding.
- 02
Read the upload result detail, not just the status
Google reports rows received versus matched. Those are different numbers.
- 03
Check the age of the clicks being uploaded
Against the 90-day window.
- 04
Verify time format and timezone
Against the account's configured timezone, not the server's.
- 05
Compare the action name character by character
Trailing spaces are a real and frequent cause.
Offline conversions not importing · prove
How we prove it's actually fixed — Offline conversions not importing
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your CRM's closed-won records
- gclid present on the large majority of CRM records created from paid traffic.
- Match rate read from Google's upload detail, not inferred from the upload succeeding.
- One deal traced end to end from click through to the conversion appearing in the account.
- Reconciled against your crm's closed-won records for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
Offline conversions not importing · free audit
What we check in the free audit
- Check whether any CRM record holds a gclid
- Read the upload result detail, not just the status
- Check the age of the clicks being uploaded
- Verify time format and timezone
- Compare the action name character by character
Checked against
Your CRM's closed-won records
Free30 minutesNo obligation
Offline conversions not importing · when not to buy
When you don't need us for this — Offline conversions not importing
Most of these you can do yourself, and we would rather you did.
- You've never checked whether the gclid is on your CRM records — do that first, free, before anything else.
- Your sales cycle closes inside a week, where standard conversion tracking already covers you.
- You upload a handful of deals a month and can check each one by hand.
Offline conversions not importing · what we deliver
What we do about it — Offline conversions not importing
Click ID captured at first touch and stored
gclid, and gbraid or wbraid for iOS app traffic, written to a first-party cookie and then onto the CRM record.
Upload format corrected
Conversion time in the right format and timezone, action name matched exactly, values numeric.
Monitoring on the job
A failed or zero-match upload notifies someone instead of passing silently.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
Offline conversions not importing questions, answered
90 days from the click. Deals closing later can't be attributed to that click at all, which is why the capture step matters more than the upload step.
Only via Enhanced Conversions for Leads, which matches on hashed email or phone instead. Less precise, but it works where the click ID was never captured.
Almost always a renamed or remapped CRM field. The upload keeps succeeding and matching nothing.
It needs the right format and timezone. An hours-off error is usually harmless; a timezone error can move rows outside the window.
More on Offline conversions not importing
Free · 30 min
Get offline conversions not importing diagnosed properly
Free30 minutesNo obligation
