Skip to main content
TrackingConsulting
Now booking · 2–4 day turnaround

Offline imports failing · Conversion tracking

Recover 40–80% of your Offline imports failing ad revenue.

Done-for-you 1st-party server-side tracking on Meta, Google, TikTok and Microsoft. Built in 2–4 days. You own the entire stack. No monthly SaaS fees.

✓ 30-minute call · No commitment · You leave with a written remediation plan even if we’re not the right fit.

Built in 2–4 daysOne-time fee95% accuracy guaranteed400-day cookie lifetime1st-party server-side

Built on — and certified for — the platforms that matter

Stape

Pro Partner

Meta

Tech Provider

Google

Tag Manager

TikTok

Events API

Microsoft

UET Partner

LinkedIn

CAPI Partner

Pinterest

CAPI Partner

Built on the same partner stack used by enterprise DTC brands.

Ariful Islam — Founder, Tracking Consulting

Meet your consultant

Ariful Islam

Founder · 8+ years in paid media & tracking

Verified earnings

$200K+

earned on Upwork

Top Rated Plus
4.9/5 · 300+

Verify the receipts

You work directly with Arif — no SDR, no account manager.

By the numbers

No fake testimonials. Just the math.

70+

Platforms supported

Shopify · Woo · Magento · BigCommerce · 65 more

8+ / 10

Meta EMQ guaranteed

in writing — keep working free until hit

2–4d

Build to live

accurate data flowing within 7 days

$0

Monthly fees, ever

one-time fixed price · you own the stack

400d

Cookie lifetime

max RFC 6265bis allows · 57× Safari ITP

9

Ad channels covered

Meta · Google · TikTok · MS · LI · Pin · Snap · Reddit · X

95%+

Tracking accuracy

verified vs Stripe · GA4 · ad-platform reports

30 min

Free founder call

no SDR · no pitch deck · written remediation plan

Numbers from realistic engagements. Your specific recovery depends on your iOS share, ad-blocker rate, and current setup — we’ll quantify it on the call.

Real clients · real videos · real outcomes

Don’t take our word for it. Watch the receipts.

Founders, marketers, and agency owners describing the before-and-after of their Offline imports failing tracking rebuild — in their own words, on camera.

The problem

Why the closed deals never make it back

Offline imports failing-specific issues
Leak #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.

Leak #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.

Leak #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.

Leak #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.

Who this is for

Honest about who we’re a fit for.

We don’t take every project. Here’s how to tell if we’re right for you.

Good fit

You’re a great fit if…

  • You run Offline imports failing (or are migrating to it)
  • You spend $5K+/month on paid ads (Meta, Google, TikTok, Microsoft, LinkedIn)
  • Your reported ROAS doesn’t match what your bank account is saying
  • You want to own your tracking stack — no monthly SaaS fees forever
  • You have 2–4 days to do this once and never think about it again
Not a fit

Skip us if…

  • You spend less than $500/month on paid ads (browser pixel is fine)
  • You want a SaaS dashboard with monthly fees forever (Triple Whale, Hyros)
  • You need attribution modeling — we fix the data foundation, not multi-touch reports
  • You want a 6-month enterprise consulting engagement (we ship in 4 days)
  • You expect us to manage your ad accounts (we don’t — that’s a different service)

If you’re still unsure, book the call anyway — we’ll tell you straight whether we can help.

Our position

If your reported ROAS disagrees with your bank account, you don’t have an attribution problem. You have a data foundation problem. No SaaS dashboard fixes that — only a rebuilt 1st-party server-side stack does.

Ariful Islam — Founder
The outcome

What changes when closed-won gets back to the platform

Bidding optimizes toward the stage that pays you

Server-side

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

8+ EMQ

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

Deduped

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

Backend-verified

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.

The full transformation report

Before vs after — built in 2–4 days, accurate data within 7 days

We deliver the 1st-party server-side stack in 2–4 business days. Each metric below measured 7 days pre-launch vs 7 days post-launch using your own ad-platform reports + Stripe + GA4. No 30-day waiting game.

Attribution accuracy

  • Reported ROAS vs Stripe match
    Before60% (35% drift)
    After95%+ match
  • iOS conversion match rate
    Before~58%
    After~92%
  • Cross-domain click-ID retention
    Before~40%
    After~95%
  • Server-attributed conversions
    Before0%
    After100%

Audience quality

  • Meta Event Match Quality
    Before4.5 / 10
    After8+ / 10
  • Cookie lifetime (Safari)
    Before7 days (ITP cap)
    After400 days (max allowed)
  • Lookalike seed-list size
    BeforeShrinking as signal decays
    AfterRebuilt from server-side matches
  • Identity match params sent
    Before1–2 (email maybe)
    After9 (email · phone · IP · UA · click_id · etc.)
  • Retargeting list health
    BeforeDecaying
    AfterCompounding

Bidding performance

  • Smart Bidding stability
    BeforeRetraining weekly
    AfterLocked-in
  • CPA trend
    BeforeDrifts up as signal degrades
    AfterBidding learns from complete data
  • ROAS variance week-over-week
    Before±35%
    After±5%
  • Conversion volume Meta sees
    Before65%
    After95%+

Compliance & ownership

  • GDPR / CCPA audit-ready
    BeforeWeak
    AfterAudit-clean
  • Consent Mode v2 wiring
    BeforeNot configured
    AfterFully wired + verified
  • 3rd-party cookie deprecation ready
    BeforeNo
    AfterYes
  • Data ownership
    BeforeVendor-locked
    After100% yours

Server-side

money events from your backend

8+ / 10

Meta EMQ guaranteed

95%+

tracking accuracy

A typical engagement

The shape of a typical Offline imports failing rebuild

We’re not going to invent a fake testimonial here. Instead — here’s the realistic pattern of what happens, anonymized but accurate to engagements we ship.

Day 0 — They arrive

A 7-figure Offline imports failing store spending ~$25K/month on Meta. Reported ROAS shows 4.1× in Ads Manager. Their bookkeeper’s number says 2.6×. The founder doesn’t know which is real, so they keep doubling down on what looks like a winning campaign — except cash flow tells a different story.

Day 1 — Audit

We screen-share. Within 20 minutes we’ve found the leaks: native pixel firing twice on iOS, CAPI dedup using the wrong event_id (Meta is double-counting), GA4 showing 38% (not set), and the Customer Events API never enabled. The 1.5× ROAS gap explains itself.

Day 2–3 — Build

Server-side GTM container goes live on data.theirstore.com. Meta CAPI rebuilt with full advanced matching. Google Enhanced Conversions wired. TikTok Events API turned on. All event_ids deterministic. iOS recovered.

Day 4 — Launch

Live-fire test purchases through every funnel step. Meta Event Match Quality goes from 4.5 to 8.7 — verified live in Events Manager. They get a Notion runbook + Loom walkthrough so their dev team can extend it.

Day 5–7 — Accuracy

Conversion data starts flowing cleanly. Day 7: reported ROAS reads 2.8× (matches Stripe within 5%). Lookalike audiences grow because Meta finally has clean seed data. Their CAC dashboard makes sense for the first time in a year.

Day 30 — The math compounds

Smart Bidding has 30 days of clean signal. CPA drops 18%. They scale Meta budget 40% because they finally trust the data. Net new revenue from the recovered tracking: roughly $14K/mo above what they were getting before.

Numbers above are realistic averages from engagements we’ve shipped. Your specific recovery depends on your iOS share, ad-blocker rate, and current setup — we’ll quantify it on the call.

The cookie window unlock

400-day cookie lifetime — the longest your browser allows

Default Offline imports failing setups put cookies on a 7–30 day timer. Safari ITP caps client-set cookies at 7 days. That kills your retargeting windows, shrinks lookalike audiences, and starves Smart Bidding of historical signal.

We set 1st-party cookies via HTTP headers on your own subdomain — exempt from ITP’s 7-day cap. Lifetime: 400 days. The maximum Chrome, Firefox and Safari currently permit.

  • 57× longer retargeting window vs Safari default

    Reach users who saw your ad 6 months ago instead of last week.

  • Bigger lookalike seed pools

    More retained users in your custom audience = better lookalike quality on Meta, Google, TikTok.

  • Smart Bidding has 13× more signal history

    Algorithms optimize on 400 days of behavior, not 7 days. CPA stabilizes faster.

  • Critical for high-AOV / long-consideration purchases

    If your average buyer takes 30+ days to convert, default cookies miss them. 400-day cookies don’t.

Cookie lifetime — head to head

How long cookies survive in real-world traffic

Safari ITP (default)7 days
Chrome / Firefox (typical)30 days
Meta default retargeting window90 days
Google Ads default cookie540 days(but capped by browser)
Our 1st-party server-side400 days

400 days is the hard maximum enforced by RFC 6265bis (Chrome 104+, Safari 17+, Firefox 110+). We set it via HTTP Set-Cookie: Max-Age=34560000 on your subdomain. Survives Safari ITP’s 7-day client-side cap.

Under the hood

What’s actually happening on your server-side stack

Six capabilities your default Offline imports failing setup doesn’t have. Built on the same Stape Pro stack used by enterprise DTC brands.

Cookie window

Cookie Keeper

400-day 1st-party cookies

Set via HTTP headers on your subdomain — the maximum browsers allow. Survives Safari ITP’s 7-day cap that kills retargeting.

Ad-block resistance

Custom Loader

Custom-loaded GTM scripts

Your gtm.js and analytics scripts load through a custom path on YOUR domain. uBlock, AdBlock Plus, Brave can’t identify them as trackers.

Attribution

Click ID Restorer

Click ID restoration

fbclid / gclid / ttclid / wbraid recovered from the URL and persisted server-side. Multi-redirect funnels stop dropping attribution. Safari user IDs restored.

Profit signal

POAS Data Feed

POAS — Profit on Ad Spend

Send actual profit data (not revenue) to Meta / Google. Smart Bidding optimizes for the metric that matters: net margin, not gross revenue.

Identity

User ID

Cross-session User ID

Stable userID generated server-side from IP + UA + SSL fingerprint. Stitches anonymous → known → returning visitors across 400 days.

Audience signal

GEO Headers

GeoIP enrichment

Country, region, city, postal code passed to Meta / Google CAPI from your server — without exposing the raw user IP to the browser.

Compliance

Anonymizer

PII hashing by default

Email, phone, name, address are SHA-256 hashed on your server before they leave for Meta or Google. Zero raw PII in transit.

Quality filtering

Bot Detection

Bot traffic detection

Bot/scraper traffic identified at the gateway and blocked from polluting your audiences. Smart Bidding optimizes against humans, not bots.

Reliability

Dedup logic

Browser ↔ server dedup

Deterministic event_id and event_time so Meta / Google never double-count. Your reported ROAS stops contradicting Stripe.

Reputation

Dedicated IP

Dedicated outbound IP

Your sGTM gets a dedicated static IP for outgoing CAPI requests. Better deliverability to Meta, Google, TikTok — no shared-IP noise.

Residency

Multi-region

EU / US region routing

GDPR-conscious stores route their CAPI traffic through EU regions (Stape EU or self-hosted GCR europe-west). No US data hop.

Data warehouse

BigQuery export

BigQuery + Looker dashboard

Server logs + GA4 raw events streamed to BigQuery. Looker Studio dashboard branded for your team. Premium tier.

We’re official Stape Pro partners — every Power-Up above is enabled and configured for you. Or we self-host the equivalent on your Cloud Run / GKE if your traffic justifies the cost crossover. You pick.

Live data flow

What your stack is doing — right now

Every conversion fires through your subdomain, gets enriched with hashed identity params, deduped against the browser pixel, then forwarded to Meta CAPI, Google EC, TikTok Events API and Microsoft UET in parallel.

You see this stream live in your sGTM debug console — not a SaaS dashboard you rent. It’s your data, on your server, on your subdomain.

  • p99 latency< 80ms
  • Avg. event payload9 identity params
  • Browser → Server dedupDeterministic event_id
  • Failure handlingRetry · queue · dead-letter
sgtm-debug · data.fix.com
streaming
10:42:18[INFO ]evt=PageView | id=ev_a3f2.. | ua=ios17 | ip_hash=ok
10:42:18[OK ]→ meta.capi status=200 emq_pred=8.6
10:42:18[OK ]→ google.ec status=200 match=enhanced
10:42:24[INFO ]evt=AddToCart | id=ev_b1c8.. | val=$84.00
10:42:24[DEDUP]browser↔server merged on event_id=b1c8..
10:42:24[OK ]→ meta.capi status=200 emq_pred=8.7
10:42:24[OK ]→ tiktok.eventsapi status=200
10:42:31[INFO ]evt=Purchase | id=ev_c9d4.. | val=$184.00
10:42:31[POAS ]profit=$58.42 sent (margin 31.7%)
10:42:31[OK ]→ meta.capi status=200 emq=8.8 ✓
10:42:31[OK ]→ google.ec status=200 ✓
10:42:31[OK ]→ microsoft.uet status=200 ✓
10:42:33[BOT ]blocked: ua=AhrefsBot · 1 evt suppressed
uptime: 99.98%all channels healthy
Every paid-media channel · 1st-party server-side

CAPI / Events API ready for every ad platform you run

One server-side gateway. Every major ad platform fed real conversion data, deduped, with full identity match.

Meta

Conversions API

Server-side

Google

Enhanced Conv.

Server-side

TikTok

Events API

Server-side

Microsoft

UET Server

Server-side

LinkedIn

CAPI

Server-side

Pinterest

CAPI

Server-side

Snapchat

CAPI

Server-side

Reddit

CAPI

Server-side

X / Twitter

Events API

Server-side
What you get

What we build into the offline loop

Item 01

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.

Item 02

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.

Item 03

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.

Item 04

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.

Item 05

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.

Item 06

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.

The honest math

Three ways to fix your tracking. One of them makes sense.

Option 1

Hire a senior tracking engineer

$15K–$25Kin dev cost

or 2–4 weeks of senior FTE time

  • 2–4 weeks before anything ships
  • Misses iOS / Safari / dedup edge cases
  • No EMQ guarantee — it’s “done” when they say so
  • Pixel debugging is not their day job

Option 2

Triple Whale / Hyros / Northbeam

$300–$2,000/month forever

$18K–$120K over 5 years

  • You rent a dashboard — they own your data
  • Cancel and you lose attribution overnight
  • Per-event / per-visitor pricing surprises
  • Still doesn’t fix your underlying tracking
Recommended

Option 3 — us

Done-for-you 1st-party server-side

$400–$1,800one-time

pay once · own the stack forever

  • Live in 2–4 days · accurate data within 7
  • iOS / Safari / dedup all handled by default
  • Meta EMQ 8+ guaranteed in writing
  • You own everything — server, container, runbook

We’re upfront: if you have a senior in-house dev with capacity and 4 weeks, hiring is fine. If you spend $1M+/yr on ads and want a SaaS dashboard layered on top, Triple Whale works. For most paid-ad advertisers between, we’re the math that makes sense.

From the founder’s desk
Ariful Islam — Founder
Available now

Ariful Islam

Founder & lead engineer

  • Experience8+ years in tracking
  • Engagements300+ DTC brands shipped
  • Specialty1st-party sGTM · CAPI
  • PartnerStape Pro · Meta Tech

“I’ll personally walk through your tracking on the call. No SDR. No sales pitch.”

I’ve spent 8 years rebuilding tracking for DTC brands, SaaS founders, agencies, and one thing I’ve learned: most tracking problems aren’t technical — they’re trust problems. You don’t know who to believe. Your current vendor swears it’s fine. Meta’s reports look great. Stripe says otherwise.

On our call, I’ll personally show you exactly what’s leaking, exactly what it would cost to recover, and whether you should hire us at all. If your current setup is genuinely fine, I’ll tell you. If a $400 browser-side fix is enough, I’ll say so. No upsell pressure.

Book the call. Worst case, you walk away with a free 47-point audit checklist. Best case, we deliver your 1st-party server-side stack in 2–4 days and your data is fully accurate within 7 days.

Arif— Founder

How it works

Built in 2–4 days. Accurate data within 7.

We deliver the entire 1st-party server-side stack in 2–4 business days. You start collecting accurate, deduped conversion data the moment it goes live — and within 7 days every signal is flowing cleanly to Meta, Google, TikTok and the rest.

1Day 1

Kickoff + audit

30-min call. We map your current pixels, GTM, dataLayer, consent setup, and ad-platform integrations. You get a written report of every leak.

2Day 2–3

Build the stack

Server-side GTM container deployed on your subdomain. Meta CAPI · Google EC · TikTok Events API · Microsoft UET wired. Identity match + dedup configured.

3Day 4

QA + go-live

Live-fire test purchases across every funnel step. Meta EMQ verified at 8+. Tag Assistant + Pixel Helper passes. Side-by-side report delivered.

4Day 5–7

Verify accuracy

Your data flows clean. Within 7 days every signal — Meta, Google, TikTok, Microsoft — is fully accurate. Notion runbook + Loom walkthrough handoff.

Diagnose it honestly

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.

Diagnostic sequence

Find the rejected rows before you rebuild anything

The reason is almost always written down already, in a results file nobody has opened.

  1. 1

    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.

  2. 2

    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.

  3. 3

    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.

  4. 4

    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.

  5. 5

    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.

  6. 6

    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.

Source-of-truth validation

How we prove closed deals actually made it back

Your CRM is the source of truth here, not the platform. Everything we build gets checked back against closed-won.

Source of truthYour 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.

Straight talk

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.

Got questions?

The honest answers.

No buzzwords, no upsell. If we don’t know, we say so.

01Can I fix this myself?

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.

02The upload says success but nothing appears in Google Ads. Why?

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.

03Which pipeline stage should I bid on?

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.

04What happens when a deal closes after 90 days?

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.

05Does this work for Meta and Microsoft too?

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.

06Won't this make my cost per lead look worse?

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.

07When do we NOT need this?

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.

Still have questions? Book a 30-min call — bring them all.

The call

What happens on your free 30-min call

No pitch deck, no SDR, no upsell pressure. Founder-led. Bring your ad-platform screens and your Offline imports failing setup — we’ll work through it together.

Min 1–5

We get the lay of your store

What you sell, what you spend on ads, who handles dev. Quick context-gathering — no questionnaire upfront.

Min 5–15

We audit your tracking live

Screen-share. We open your Meta Events Manager, GTM, and ad reports. You see exactly which conversions are leaking.

Min 15–25

We map a fix

What needs rebuilding, what stays. The exact Offline imports failing setup we'd ship and what it would recover for you.

Min 25–30

Decide. Or don’t.

If we're a fit, we send a 1-page proposal in writing. If not, you walk away with a free remediation plan you can hand to anyone.

No pitch deckFounder-led, not SDRYou leave with a written planZero commitment
Free · 30 minutes · No commitment

Let's find out why your uploads are being rejected

Send a sample of your upload payload or a screenshot of the import history. I'll tell you which field is wrong — the timezone offset, the action type, or the click window — usually within a day.

Free · 30-min consultation · No commitment · Replies in under 2 hours · Available worldwide via WhatsApp

95% guarantee · fixed-fee