Ad platforms like Facebook and Google Ads optimize for the conversions they can see. If the only conversion they see is a form fill, they optimize for form fills — targeting more people that look like the people who fill out forms. But the people who fill out forms aren't the same as the people who actually convert.

For many of our clients, the most valuable conversions happen offline.

1. Sales-driven conversions. A home services company's leads request quotes on the website, but customers enroll weeks later in a contract management system.
2. Phone conversions. A healthcare franchise's patients click ads and then call to book appointments.
3. Third-party platform conversions. A vacation rental platform gets bookings through VRBO, where they can't add tracking pixels.
4. Subscriptions and renewals. All of these clients have recurring payments where, even if the first purchase happens online, the renewal happens automatically in an offline billing system like Stripe.

These are the main conversion events. And the ad platforms can't see any of them with standard web tracking.

That's what server-side tracking tools like Facebook CAPI and Google Ads Enhanced Conversions are for. But to get the full benefits of server-side tracking, you need to send as much accurate and complete conversion data as possible.

The best way to do that is to reverse ETL conversions from the data warehouse - ie sync real, source of truth conversions from the warehouse directly to the ad platforms.

We've built exactly that for all three of these clients. Same approach, same pattern — real conversions with real revenue data and full attribution, sent from the warehouse to Facebook CAPI, Google Ads Enhanced Conversions, and other marketing platforms.

See a live demo of the dashboards and event mappings we build on top of these conversion tables.

Ad Platforms Are Optimization Engines, Not Reporting Tools

Here's why this matters: you're not making traditional targeting decisions anymore. You're feeding a black-box machine learning algorithm that decides who sees your ads, when, and at what price. You can adjust budgets and audiences at the margins, but the algorithm is doing the real work — and the most important input it has is your conversion data.

Every missing conversion, every unattributed sale, every estimated value instead of a real dollar amount is a gap in the training data the algorithm uses to decide where to spend your money. Incomplete data doesn't mean incomplete reports — it means the algorithm is actively making worse decisions because of worse inputs.

What These Clients Were Doing Before

Every one of these clients had some form of conversion tracking in place before we started. It just wasn't enough.

Marketing teams set up pixels that worked for the subset of conversions that happen in a browser, like lead form submissions. Ad blockers and Safari's Intelligent Tracking Prevention eroded even that signal over time. Some set up server-side Google Tag Manager to improve reliability — but because it's still ultimately triggered by browser events it does nothing for conversions that happen offline.

Some had their development teams stand up custom servers to send conversions directly to the platforms. These never captured all the data and broke constantly. The dev team will get to that fix next sprint.

A few experimented with manual CSV uploads of offline conversions. Tedious, error-prone, and always behind. Josey goes on vacation and Facebook performance drops.

The common thread: conversion tracking was owned by whoever happened to be closest to the problem — marketing configuring tag manager, dev standing up webhook servers, an analyst uploading CSVs. None of them had the full picture.

Server-side conversion tracking is a data problem. It should be owned by the data team, built on the data infrastructure. The warehouse already has the conversions from the systems of record, the resolved customer identities, and the attribution linking ad clicks to outcomes. The data is already there — it just needs to be formatted for the platforms.

What We Built

Using dbt and our dbt-nexus package, we quickly built a conversion pipeline for each client that pulls together everything the ad platforms need: the conversion event, the revenue amount, the person's contact information, and the ad click that caused it. One model assembles all of that into a canonical table, and maps columns to the format expected by each platform — Facebook CAPI, Google Ads Enhanced Conversions, and others. Adding a new destination requires about 30 lines of SQL instead of a whole new pipeline.

Each of these clients had different systems of record for their conversions — contract management for the home services company, an appointment scheduling platform for the healthcare franchise, a booking system plus VRBO for the vacation rental platform. And each used different tools for web tracking — Google Analytics, Segment, and others. But all these sources land in the same warehouse and get stitched into a unified picture. The sources are different, but the pattern is the same.

Attribution. Attaching click IDs was easy because dbt-nexus lets us build any attribution model we need. So we built last_fbclid and last_gclid models that trace the most recent Facebook or Google ad click back to the person who converted — even when the click happened weeks before the conversion. These models work regardless of where the click data originated (Segment, GA4, whatever) because dbt-nexus normalizes it all. See the attribution models reference for the full pattern.

Identity. Because we already have identity resolution (documented in entity resolution), we know who converted. Not just a cookie or an anonymous session — we know their email address, phone number and/or mailing address. That's critical for server-side conversions. Facebook and Google use this PII to match conversions to users on their platforms. The more identity data you send, the higher your match rate, and the better the optimization.

Privacy. Some of our clients have serious privacy requirements — HIPAA for the healthcare franchise, GDPR for the booking platform. The warehouse approach is a major advantage here. Every field we send to a platform is explicitly selected in SQL that's under source control and goes through code review. We can see exactly what data is going out, to whom, and audit the full history of changes. Good luck doing that with a pixel that fires whatever the tag manager is configured to collect.

Revenue. Conversion values come directly from the system of record — actual contract premiums, actual payment amounts, actual booking revenue. Not estimated values assigned in a tag manager. The same numbers finance uses to count revenue.

Observability. For every client, we build dashboards on top of the conversion tables that show exactly what's being sent: how many conversions by type, what percentage have email and phone for matching, what percentage have an attributed click ID, total revenue, and a row-level view of every event. See a live example of what these dashboards look like (with sample data). Before anything goes to Facebook or Google, you can inspect every record. When something looks off, you can drill into the data immediately — not discover the problem weeks later from a campaign report that doesn't add up.

Every change to the conversion logic is a git commit. When conversion counts shift, you know exactly what changed and when.

Backfill. Because the conversions already existed in the warehouse, we didn't start from zero. The day each pipeline went live, we backfilled months of historical conversions — giving the algorithm a running start instead of a cold start. And when a reverse ETL sync failed or a platform API went down, we didn't lose data. The conversions were still in the warehouse. We fixed the issue, re-synced, and everything caught up. With pixels and webhooks, a failure means lost data. With this approach, it meant an irrelevant delay with an immediate fix.

The Results

More conversion data. Real events that were previously invisible, with real revenue from the system of record, now flowing to the platforms.

**Better optimization. **The platforms receive actual conversions with actual dollar amounts and optimize for revenue — not form fills, not estimated values, not proxy metrics.

Better targeting. The platforms now know what an actual buyer looks like — not just someone who fills out a form — and find more people like them.

Higher ROAS. Because the platforms are finally measuring and optimizing against real business outcomes with real values.

One client told us: "our Facebook ads performance just automatically got better." No campaign changes, no creative updates, no audience adjustments. Just better data feeding a better algorithm.

That's the compounding effect. Better conversion data leads to better optimization, which leads to better audiences, which leads to better lookalikes, which leads to more of the right customers. The algorithm gets smarter over time as it sees the full picture.

The full technical pattern — canonical model, destination projections, and delivery — is documented in our dbt-nexus marketing conversions guide.