A Powerful Idea That’s Harder Than It Looks

If you sell subscriptions online and you’re running Google Ads, you should be using Offline Conversion Import. Without it, you’re missing a powerful optimization signal: lifetime value.

By default, Google optimizes your ads for clicks. If you’ve gone further and added conversion tracking to your site, Google can optimize for purchases instead — which is better. And if you include the transaction value in your conversion tags, Google can optimize for revenue. Each step is meaningfully better than the last.

But if you sell subscriptions, the initial purchase is just the beginning of the story. The majority of your revenue is probably from the recurring subscription revenue, which occurs “offline” (i.e. you can’t track it using a simple conversion tag). It is important to tell Google the rest of the story so they can optimize your ads for lifetime value (LTV).

Without LTV optimization, Google will try to direct your ads to anyone who completes the initial purchase, treating all purchases the same regardless of whether they stay for one month or twenty.

This article shares some lessons from our journey in helping our customers turn on LTV optimization using Offline Conversion Import (we will call it OCI for short).

How Offline Conversion Import Works

When someone clicks a Google ad, Google assigns that click a unique identifier called a GCLID — a Google Click ID and appends it to the URL when directing the user to your website. Your website must capture that GCLID and remember it until purchase. At the time of purchase, the GCLID must be stored alongside the user’s account in your database. Then, as that customer pays their monthly bill over time, your system sends the GCLID back to Google along with the recurring transaction values. Google connects the dots and starts learning who your long-term subscribers actually are.

At minimum, you only need to send the GCLID and confirmation that a transaction occurred. Better implementations include the dollar amount. The most powerful implementations also send hashed customer identifiers — email, phone, name, address — encrypted using SHA-256, so no raw personal data leaves your systems. Google uses those hashed identifiers to match against their own data and build richer audience models.

This same pattern exists on other platforms too — Meta Conversions API, TikTok, and others — though we’ve done our deepest work on the Google side.

Where It Gets Complicated

On paper, this is elegant. In practice, it’s one of the harder things we’ve tried to help a client implement. We’ve been helping a client attempt this for several months now, but they still don’t have it working. That’s not a story we tell proudly, but it’s an honest one, and we think the reasons why are worth sharing.

Note that Google’s documentation about Offline Conversion Import recommends that, if you’re considering Offline Conversion Import, perhaps you should “upgrade” to “Enhanced Conversions for Leads” – that’s because it’s a lot easier to do and it has real benefits. But it still doesn’t optimize your ads for lifetime value…if you want to optimize for lifetime value, you’ll have to take the red pill and go deep.

The definition of done problem. Nobody — us included — clearly defined what “finished” looked like before work began. First successful OCI upload? Two weeks of the algorithm running on the new signal? A measurable shift in cost per subscriber? Without a finish line, the team couldn’t tell how far they’d run. When they got tired and the budget got tight, they stopped — even though they were close.

The validation problem. We planned for the technical implementation but didn’t plan for validation. How do we know that the data being uploaded are correct? Someone needs to actually pull transaction records from the database and confirm those values match what’s being sent to Google. Simple in concept. But to do that, the developer needs to be logging every outbound conversion event — an audit trail showing what data left the building, when, and for which customer. Our developer didn’t build that logging because we never told him validation was coming. By the time we realized we needed it, the project had already lost steam.

The accountability gap. This is the one that runs underneath all the others. Developers understand that sending bad data to Google has real financial consequences — if the algorithm learns from wrong signals, it optimizes in the wrong direction, and undoing that takes time and money. So when you ask a developer to take on OCI, they’ll want safeguards. More infrastructure. More checkpoints. And they’ll want someone to look at the data and say “yes, this is right” before anything goes live. The problem is that most marketers aren’t equipped to be that validation partner. They can’t pull the database records, read the logs, or confirm the hashing is correct. So, the developer is left holding a high-risk change with no one qualified to sign off, and the project fragments.

A year after the first attempt stalled, the client’s Google representative came to their office and spent time re-explaining the value. The intensity around the project increased. The structural challenges did not. They’re still trying.

The Saga Continues

We’re not at a point where we can hand you a foolproof playbook. But here’s what we’ve learned so far:
The technical pieces — capturing the GCLID, storing it with the user, building the pipeline to send data back to Google — are solvable. Developers can figure that out. What’s harder is everything around it: getting the stakeholder and the developer aligned on what they’re actually building, defining done before the first line of code gets written, and making sure someone on the marketing side can actually validate the data before it goes live.

The other thing we’ve learned is that this project needs someone in the middle — someone who understands both the technical plumbing and the marketing objective, and who can keep both sides oriented when they’d otherwise lose patience with each other. Developers and marketers, left to their own devices, tend to get stuck and give up. Not because either group is incompetent, but because they’re solving different parts of the same problem and nobody’s holding the whole picture. At Confidence Interval, this is a natural strength of ours: our developers have marketing experience, and our marketers have development experience.

We haven’t gotten it perfectly right yet. But we know where the landmines are now, which is more than we could say a few months ago. If you’re attempting this too, we’d genuinely enjoy comparing notes.