Get your Offline imports failing tracking to 95%+ accuracy guaranteed in writing.
The pipeline works: click, lead, call, proposal, signed contract. The platform only ever hears about step two. So Smart Bidding optimizes toward the cheapest form fill it can find, and the campaigns that produce actual customers look expensive on the report. We build the loop back — click ID stored at submit, deal value returned at close, failures surfaced instead of swallowed.
Free30 minutesNo obligation
By Ariful IslamOffline imports failing · what breaks
Why the closed deals never make it back — Offline imports failing
- 01
The upload runs and quietly partial-fails
The Google Ads API returns partial_failure_error per row. If the integration doesn't read that field, the job logs a clean success while every single row was rejected for "click not found" or a mismatched conversion action.
- 02
The click aged out before the deal closed
Google accepts click conversions inside a 90-day window. A sales cycle that closes in month four has no eligible click ID left, and nobody notices because the rejects are invisible.
- 03
conversion_date_time has no timezone offset
The field needs a full offset matching the account's timezone, like 2026-08-07 14:32:00-05:00. Missing or wrong, and rows are rejected outright or credited to the wrong day, which quietly distorts every report built on them.
- 04
The conversion action isn't the importable kind
An action created as a Website conversion can't accept uploads. Imports need an action created for import from clicks or from calls — and on Meta, either an offline event set or the CRM lead_id path for Lead Ads.
Offline imports failing · the fix
What changes when closed-won gets back to the platform — Offline imports failing
Bidding optimizes toward the stage that pays you
The algorithm learns which clicks turn into qualified pipeline rather than which turn into fastest form fills. Those are frequently different audiences, and until now only one of them was visible.
Lead quality becomes visible per campaign and keyword
You can finally see that one campaign produces cheap leads that never close, and another produces expensive ones that do. That report is usually the most uncomfortable and most useful thing we hand over.
Uploads that tell you when they fail
Every job surfaces per-row rejections with the reason, into somewhere a person actually looks. A green checkmark that means nothing is worse than no automation at all.
One reconciliation between the CRM and the platform
A recurring match of uploaded deals against what the platform recorded, so a broken credential or a renamed field shows up within days instead of at the quarterly review.
Offline imports failing · normal or broken
Some rows will never match. Uploads that never fail are the problem.
Offline import has a real ceiling: click windows expire, and some leads never carried an ID in the first place. The failure worth paying to fix is the job that reports a clean success while rejecting every single row underneath.
Normal, not a fault
Some rows legitimately won't match
Leads that arrived organically, from a referral, or from a click older than Google's 90-day window have no eligible ID to key on. A match rate below 100% is the shape of the channel, not evidence of a bug.
Conversions land on the click date, not the close date
Google credits an uploaded conversion back to the day of the click, so last month's report changes after today's upload. Old rows moving retroactively is correct behavior and catches everyone out once.
Reported cost per lead rises after the loop goes live
Bidding stops chasing the cheapest form fill it can find, so CPL gets worse on paper. Watch cost per qualified lead or cost per closed deal instead — that trade is the entire point of the exercise.
Enhanced Conversions for Leads matches some, not all
Hashed email and phone is a weaker key than a click ID. Landing a share of long-cycle deals is what the fallback is for. Treating it as a replacement for storing click IDs is what isn't normal.
Actually broken
The job logs success and Google Ads shows nothing
The API accepts the request at the top level and rejects rows underneath in partial_failure_error. An integration that only checks the HTTP status will report clean runs forever while importing zero conversions.
Every row rejects with the identical reason
"Click not found", "click too old" or "conversion action doesn't accept uploads" across the whole file is one config error, not a data problem — usually the wrong action type or a truncated click ID.
Conversions land a day early or late, consistently
conversion_date_time without an offset, or with one that doesn't match the account timezone. Rows get credited to the wrong day, and every report and bid adjustment built on them drifts with it.
One deal counted as a web lead and again at closed-won
No join key between the on-site event and the upload, so a single customer is counted twice and bidding then optimizes toward your own inflated number. Worse than missing data, because it looks like success.
Offline imports failing · diagnose
Find the rejected rows before you rebuild anything — Offline imports failing
The reason is almost always written down already, in a results file nobody has opened.
- 01
Open the upload history in Google Ads
Tools, then Data manager or Conversions, then Uploads. Every past job is listed with its result. Download the results file for a run you believed had succeeded and read it line by line.
- 02
Read partial_failure_error, not the HTTP status
If you're calling the API directly, log the full response body for one run. The per-row reason is plain text: click not found, click too old, or conversion action can't accept uploads.
- 03
Check the conversion action's type
Open the action's settings. An importable action names its source as an import, from clicks or from calls. A Website conversion action cannot accept uploads no matter how correct your file is.
- 04
Count the characters in one stored click ID
Pull a gclid straight out of your CRM and compare it against one captured live from an ad click. A short one means the field truncated it, and every row keyed on it will fail the same way.
- 05
Check your deal ages against the click window
Query the CRM for closed deals and subtract the stored click timestamp from the close date. Anything past 90 days was never eligible for click upload and needs the hashed fallback instead.
- 06
Verify the timezone offset in one row of the file
conversion_date_time needs a full offset matching the account timezone, for example 2026-08-07 14:32:00-05:00. Missing offset, rejected row, and the error message rarely says so plainly.
Offline imports failing · prove
How we prove closed deals actually made it back — Offline imports failing
Your CRM is the source of truth here, not the platform. Everything we build gets checked back against closed-won.
Source of truth
Your CRM closed-won records
- Upload ten known deals by hand and read the per-row result for every single one, not just the request-level status.
- Compare CRM closed-won counts for a window against the conversions Google Ads recorded for the same import action.
- Confirm uploaded values match the contract amounts in the CRM, in the deal's own currency, not a placeholder amount.
- Check no deal appears both as a web conversion and an offline import, keyed on the order or deal ID as a join key.
- Force a failure on purpose by sending one expired click ID, and confirm the alert reaches a human who reads it.
- Re-run the reconciliation weekly for the first month so a renamed field or an expired credential surfaces in days.
Offline imports failing · free audit
What we check in the free audit
- Open the upload history in Google Ads
- Read partial_failure_error, not the HTTP status
- Check the conversion action's type
- Count the characters in one stored click ID
- Check your deal ages against the click window
- Verify the timezone offset in one row of the file
Checked against
Your CRM closed-won records
Free30 minutesNo obligation
Offline imports failing · when not to buy
When the offline loop isn't the right investment
Offline import earns its keep on long sales cycles with real deal values, and not much anywhere else.
- Your conversion completes on the site in the same session — checkout, self-serve signup, instant booking. Server-side purchase tracking covers it.
- You close a handful of deals a month. There isn't enough signal for bidding to learn from, and offer work will beat any upload pipeline.
- You're on HubSpot or Salesforce with a native connector, a short cycle and gclid mapped. Turn it on and read the results file first.
- Cycles regularly run past 90 days and you hold no email or phone to hash. Fix the bidding stage before perfecting closed-won uploads.
Offline imports failing · what we deliver
What we build into the offline loop
Importable conversion actions, one per pipeline stage
Separate actions for MQL, SQL and closed-won so you can bid on one and report on the others, each created for import with counting and windows set to match the sales cycle.
Click IDs stored in full, with the click time
gclid, gbraid, wbraid, fbclid and msclkid captured at form submit into long-text CRM fields, with the timestamp stored alongside so window eligibility can be checked before a row is even sent.
A scheduled upload job with real error handling
Daily jobs against the Google Ads API and Meta's offline endpoint that read partial_failure_error row by row and alert on rejects rather than logging success and moving on.
Enhanced Conversions for Leads as the fallback path
When the click ID is missing or aged past the window, hashed email and phone go up instead, so a long-cycle deal still has a route home.
Value taken from the closed amount, not a placeholder
The real contract or invoice value in the deal's own currency, mapped from the CRM field your sales team actually fills in — which we verify, because it's often not the one you'd expect.
Deduplication against the web conversion
The deal or order ID as the join key, so a lead already counted on the site isn't counted a second time at closed-won and inflating your own numbers back at you.
Written guarantee
95%+ tracking accuracy
Measured against Your CRM closed-won records. Miss it and we keep working at no cost.
FAQ
Offline imports failing questions, answered
Try the easy version first. If you're on HubSpot or Salesforce with a native Google Ads connector and a short sales cycle, enabling it and mapping the gclid field may be the whole job — go do that before paying anyone. It gets hard in three specific places: when the native connector partial-fails silently and reports success anyway, when your cycle runs past the 90-day click window, and when you need Meta and Microsoft fed from the same pipeline. The build isn't exotic. The debugging is where the hours go.
Almost always partial failure. The API accepts the request at the top level and rejects individual rows underneath, returning the reasons in partial_failure_error. Integrations that only check the HTTP status see a 200 and declare victory. Read the per-row errors and the cause is usually right there in plain text: click not found, click too old, or conversion action doesn't accept uploads.
The earliest stage that both correlates with revenue and has enough volume to learn from. Bidding straight on closed-won at eight deals a month starves Smart Bidding of data. SQL or a qualified-opportunity stage is usually the workable compromise, with closed-won uploaded as a secondary action for reporting and value calibration.
The click ID is no longer eligible, so it goes back through Enhanced Conversions for Leads instead — hashed email and phone matched against Google's record of the click. It's a weaker match than a click ID, and you should expect it to land some of the time rather than all of it. For genuinely long cycles, bidding on an earlier stage matters more than perfecting the closed-won upload.
Yes, through different doors. Meta takes offline events via the Conversions API against an offline event set, or via lead_id when the lead came from a Meta Lead Ad, which is the strongest match available there. Microsoft uses msclkid, stored the same way as a gclid. Same pipeline, three destinations, one CRM as the source of truth.
Probably, and that's the point. When the algorithm stops chasing the cheapest form fills, reported CPL usually rises. The number to watch after this goes live is cost per qualified lead or cost per closed deal, and you'll have that number for the first time. Anyone who tells you both metrics improve immediately is guessing.
If your conversion completes on the website in the same session — ecommerce checkout, self-serve signup, instant booking — offline import adds nothing that server-side purchase tracking doesn't already give you. It's also hard to justify at very low deal volume, where there simply isn't enough signal for bidding to learn from, and your time is better spent on the offer.
More on Offline imports failing
- GuideOffline Conversion Tracking: Send Closed Deals Back to Google Ads and Meta
- Guidegclid Missing? The Click-ID Rescue Guide (Auto-Tagging, Redirects, Consent)
- Offline conversions not importingWhy are my Google Ads offline conversions not importing?
- Enhanced vs offlineEnhanced Conversions vs offline conversion import
- Enhanced ConversionsEnhanced Conversions enrich the conversions that already fire. First we make sur…
Free · 30 min
Let's find out why your uploads are being rejected
WhatsAppFree30 minutesNo obligation
