Your Warehouse Should Push Audiences Back Into Your Channels

The last mile nobody builds

Over the past five years, most companies with any data ambition built the inbound half of a data stack. Pipelines pull GA4, Meta Ads, Google Ads, the store, and the email tool into BigQuery. Models clean it. Dashboards read it. Then it stops. The data that took months of engineering to centralize flows into reports and nowhere else, while the segmentation that actually moves revenue happens inside each channel tool, on that tool's partial view of the customer.

That is the wrong place for it. The warehouse is the only system that knows the whole customer: every order including the refunds, every session, every support ticket, every consent flag. Audiences should be defined there and flow from there back into the channels. The industry has two names for this pattern, reverse ETL and composable CDP, and adopting it is the difference between a warehouse that reports and a warehouse that acts.

One assumption runs underneath everything in this article: the warehouse is yours. If a vendor holds your data in their systems, the audiences you define there are theirs too. We make that argument separately in You Should Own Your Marketing Data Warehouse. Most Vendors Disagree.

Each tool sees a slice of the customer

Your email platform knows opens, clicks, and unsubscribes. It does not know margin, and it does not know that the customer returned half of what they bought. The ad platform knows impressions and its own attributed conversions, nothing about lifetime value or support history. The store knows orders but not ad exposure. Every one of these tools will happily let you build segments, on the slice it can see.

Try to build "high-LTV customers whose purchase frequency is declining" and the limitation stops being abstract. Lifetime value needs the full order history, net of refunds. Frequency decline needs order timestamps and a per-customer baseline. Churn risk might draw on email engagement and open tickets. No single tool holds all of those inputs, so each tool offers a caricature instead. The email platform's version is "has not opened in 60 days". The ad platform's version is a lookalike of recent purchasers. Neither is the audience you asked for.

Simpler questions hit the same wall. "Buyers who came from paid social and later returned an item" spans the ad platform and the store. "Email subscribers who also bought through the marketplace channel" spans the email tool and a sales feed it has never heard of. Marketing runs on cross-tool questions, and the tools answer single-tool questions.

The question is only answerable where the data is joined. That place already exists, and you already pay for it.

The CSV export ritual

You can tell a company has hit this wall by one behavior: an analyst runs a query in the warehouse, exports customer emails to a CSV, and uploads the file to Meta as a custom audience or into the email tool as a list. The ritual works, which is why it persists. It is also the worst version of the right idea.

It is manual, so it is on nobody's job description. It happens when someone remembers, and it stops when that person changes jobs. The time cost is easy to underestimate because each run feels small; two hours a week refreshing three lists across two channels is a hundred analyst hours a year, spent producing something that is out of date the moment it uploads.

It is stale on arrival. An audience drawn on Monday is wrong by Friday: buyers who should have dropped out of the winback list are still in it, and the brand pays to win back customers who bought yesterday. The list only decays until someone re-runs the ritual.

It is unauditable. Six months later a file called vip_customers_final_v3.csv is still targeting spend, and nobody can say which query produced it, whether consent was checked, or why a specific person is in it.

And it moves PII around in the open. Thousands of email addresses sit in downloads folders, Slack threads, and inboxes. One subject access request and the data protection officer discovers there is no answer to "where has this customer's data been?"

What warehouse-native activation means

Two definitions first, because the vendors use them loosely. Reverse ETL is the practice of syncing data from the warehouse into the operational tools where work happens: ad platforms, email tools, CRMs. The name is literal. ETL moves data from tools into the warehouse; reverse ETL moves it back out. A composable CDP is the broader idea that customer data platform capabilities, identity, audiences, and syncing, can be assembled as components on top of the warehouse you already run, instead of buying a packaged CDP that keeps a second copy of your customer data in its own cloud.

Mechanically the pattern has four parts.

1. An audience is a definition, not a list. It lives as SQL or a semantic-layer expression over warehouse tables. "Repeat buyers with declining frequency" is a query someone can read, review, and version.
2. Sync runs on a schedule. The definition is re-evaluated hourly or daily, and the adds and removes flow to each destination through its API, typically as hashed emails to ad platforms and as list membership to the email tool.
3. Membership maintains itself. A customer who places an order drops out of the winback audience on the next run. Nobody re-uploads anything.
4. Lineage runs backward. From any audience in any channel, you can trace to the exact definition and version that produced it, and to the sync runs that delivered it.

There is a specific reason to hold these definitions in a semantic layer rather than in loose SQL files. Audiences and metrics share terms. "Active subscriber" appears in your churn metric and in your suppression audience, and it had better mean the same thing in both places. When the definition lives once, a change to it propagates to the dashboard and the audience together, and the two can never diverge unnoticed.

You can assemble the syncing itself from parts, a scheduler, some Python, and each platform's audience API, and plenty of teams have. The maintenance burden of chasing API changes across five destinations is why a tool category grew around it. Either way, the architecture is the same, and the architecture is the part that matters.

The pattern, compared against the two alternatives most teams actually use:

Three audiences worth defining in the warehouse

Consider a hypothetical store selling 5M euros a year across roughly 40,000 orders, with a modeled customer_summary table, one row per customer, built from orders, sessions, and support tickets with SQLMesh or dbt. At that size the stakes are concrete. Forty thousand orders means around 3,300 buyers a month who should drop out of prospecting the moment they purchase, and every week of lag on that exclusion is a real invoice for advertising to people who just bought.

These three audiences earn their keep quickly, and none of them can be expressed in a single channel tool.

Repeat buyers with declining frequency

SELECT customer_id
FROM analytics.customer_summary
WHERE lifetime_orders >= 3
  AND days_since_last_order > 1.5 * avg_days_between_orders
  AND marketing_consent = TRUE

The per-customer baseline is the point. A coffee subscriber who normally orders every 21 days and has gone 35 is drifting; a skincare customer on a 90-day cycle at day 35 is fine. Channel tools offer fixed windows ("no purchase in 60 days") that treat both the same. This audience feeds a winback flow in the email tool and, just as usefully, a suppression list so prospecting budget stops being spent on people who merely need a nudge.

High-AOV first-timers

SELECT customer_id
FROM analytics.customer_summary
WHERE lifetime_orders = 1
  AND first_order_value >= 150
  AND first_order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND marketing_consent = TRUE

If the average first order is around 75, these customers started at double it. They get a second-purchase flow with no discount in it, because a discount teaches a full-price buyer to wait for the next one. The same definition doubles as an exclusion from every discount-led campaign in every channel, which is where the ritual CSV approach always breaks down: exclusions need to be current to be safe.

Subscribers with open support tickets

SELECT s.customer_id
FROM analytics.subscriptions s
JOIN analytics.support_tickets t USING (customer_id)
WHERE s.status = 'active'
  AND t.status = 'open'
  AND t.opened_at >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY)

A suppression audience: no promotional email, no upsell ads, until the ticket closes. Nothing tests a subscriber's patience like an upsell in the middle of a complaint. Suppression audiences tend to pay back before targeting audiences do, because saved spend and avoided churn show up immediately and require no creative work. This one needs subscription state joined to the support system, a join that exists nowhere except your warehouse.

That ordering is also the sensible rollout plan. Start with suppressions: the recent-buyer exclusion and the open-ticket hold prove the pipeline works, save money in the first week, and carry little risk while trust in the definitions is still building. Targeting audiences come after the team has watched membership refresh correctly for a few cycles.

Governance lives next to the data

The compliance argument for this pattern is at least as strong as the revenue argument.

Consent sits next to behavior. marketing_consent = TRUE is a WHERE clause in every audience definition, checked on every run, rather than a hope that someone scrubbed the list before uploading it. When consent is withdrawn, the customer falls out of every synced audience on the next refresh, automatically.

Exclusions are enforced once. Do-not-contact records, regional restrictions, whatever your legal team requires: expressed in one place, inherited by every audience, instead of re-implemented per tool by whoever built that tool's segment.

And there is an answer for the auditor. When the DPO asks why a customer saw a retargeting ad, the answer is a definition, a version, and a sync log. Compare that with reconstructing which CSV it was, exported by whom, from which laptop. Retention policies get simpler for the same reason: when the warehouse deletes a customer under a retention rule, the deletion propagates outward on the next sync instead of lingering in a forgotten list somewhere.

For agencies the governance point compounds across clients, because twenty clients means twenty consent regimes and twenty audit trails. That is a big part of why we argue agencies should run one governed layer across their book: One Semantic Layer, Twenty Clients.

Where Verity fits

Verity is built along this line: managed pipelines land your marketing sources in your own BigQuery, SQLMesh models with tests and lineage shape them, and segments are defined on the semantic layer next to your metrics, on the same governed tables. Activation, pushing those segments out into your channels, is the direction the platform is built toward. The definitions and the governance come first, because they are the part most stacks never get right.

Frequently asked questions

Is reverse ETL the same thing as a CDP?

No. Reverse ETL is the pipe: it syncs warehouse data into operational tools. A packaged CDP bundles storage, identity resolution, audience building, and syncing into one product that keeps its own copy of your customer data. The composable approach uses reverse ETL as one component on top of your warehouse, so there is no second copy to reconcile.

Do we need identity resolution before any of this is useful?

It helps, but it is not the entry ticket. For most ecommerce brands, the customer ID from the store, matched on email, covers the large majority of cases, and all three audiences above work with it. Invest in proper identity stitching when anonymous web behavior or multiple purchase systems start materially changing who qualifies for an audience.

What match rates should we expect when syncing to ad platforms?

Ad platforms match hashed emails and phone numbers against their logged-in users. As a rule of thumb, consumer brands see somewhere between 40 and 70 percent of a list matched, and sending phone numbers alongside emails raises it. Email channels match one to one, which is a reason to activate there first.

Does this pattern help or hurt GDPR compliance?

The architecture helps: consent checked in every definition, PII moving system to system instead of by file, and an audit trail from ad to definition. It does not replace the legal work. You still need a lawful basis for the processing, and your DPO should review the destinations and the hashing before the first sync runs.