Cross-platform suppression with consent propagation
You've implemented basic suppression on Meta. Retargeting spend dropped, but not by as much as expected. The reason: every other paid retargeting channel is still firing. Google Display, TikTok, programmatic display, retargeting partners the brand forgot it signed up for two years ago. Each one needs its own suppression audience. The setup varies by platform across latency profiles, identifier formats, consent posture, and audience expiry rules. And under GDPR, the suppression audience itself is a use of personal data for advertising, which means consent state has to propagate alongside the conversion event.
What actually delivers the outcome is broader. Suppress everywhere, within the consent envelope, within an acceptable latency window, with re-introduction logic when the retargeting window closes.
Reduce retargeting ad spend on converted users across all paid retargeting channels. Realistic effect: thirty to fifty percent reduction in total retargeting spend on the converted segment, depending on how many channels were previously leaking. Measure yours before you start: export last month's retargeting audiences per platform and match them against conversions; the overlap is what this recipe recovers. Defensible under audit for consent handling. Customers re-enter prospecting campaigns at the appropriate point in the post-purchase cycle, so repeat purchase acquisition isn't sacrificed for the sake of suppression.
A capability layer that can do identity resolution at scale, propagate consent state, push to multiple ad platform audience APIs with platform-specific identifier transformations, and manage audience expiry on a per-platform basis. In a composable stack, this is typically a CDP plus a reverse-ETL layer plus a consent management platform, with the warehouse as the source of truth. In a hybrid stack, this is the CDP doing the heavy lifting with explicit configuration for each platform destination. Packaged suites can do parts of this but tend to struggle with the consent propagation layer when the consent management platform is separate from the suite.
Compare the tools on Martech Stack Builder
Seven roles, often reporting through three or four different VPs. The Staff list is half the reason this recipe is high readiness, and most of the reason it's a Workshop conversation rather than a documentation page. Teams that try to ship this with marketing ops alone discover the consent and identity layers ten weeks in, by which point the project has lost momentum. The structured Staff list above carries the per-role detail. The work splits across paid media (audience and campaign), engineering and CDP ownership (pipeline and identity), legal and privacy ops (consent and audit), and analytics (measurement).
Work in this order. The first two steps decide whether the rest is worth building.
The patterns behind the steps: suppression and exclusion logic (1, 2 and 5), anonymous-to-known stitching (3), consent-scoped signal collection and consent state propagation across systems (4), identity decay management (6), and audit trail generation at the decision point (7).
The first failure is treating this as a configuration problem rather than an orchestration problem. Teams set up the destination connectors and assume the platform handles the propagation. It doesn't. Each platform has its own identifier requirements, its own consent posture, its own latency profile, its own audience expiry behavior. The orchestration logic that holds those together is what makes this a recipe.
Measurement is the second place this falls apart. The counterfactual is invisible: you can't directly observe the ads that would have been served if suppression hadn't worked. Most teams measure success by looking at retargeting spend before and after, which is a coarse signal and conflates seasonal effects, campaign changes, and platform algorithm shifts. Cleaner measurement requires a holdout, which most teams resist because it means deliberately wasting some spend to prove the rest of it isn't being wasted. Without measurement, this recipe drifts back into basic-recipe territory because nobody can prove the cross-platform layer is delivering.
The re-introduction logic is the third failure mode worth flagging. Customers who bought thirty days ago should be returning to prospecting audiences. Customers who bought eighteen months ago should arguably be in win-back campaigns, not suppressed forever. The platform-by-platform expiry logic is fiddly and gets neglected, and the result is a slowly growing exclusion pool that erodes acquisition reach over time.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The orchestration sequence, the platform-by-platform identifier strategy, the consent propagation specifics, the holdout design for measurement: those are the conversations that take the recipe from credible-on-paper to delivering in production.
If the consent-propagation layer keeps surfacing as the failure point and the team isn't sure whether it's an orchestration bug or a deeper stack problem, that pattern usually signals decay in the underlying systems before it shows up anywhere else. second law of martech is the diagnostic for assessing where the decay sits before it bleeds into the next use case.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Let the system act on its own inside clear bounds, escalate the ambiguous cases, and learn from how the human resolved them
Stop bidding against yourself for the same person across Meta, Google, TikTok, and the rest, by maintaining a single live audience exclusion the platforms read
Push first-party signals (predicted value, churn flag, recent conversion) to ad platforms as bid modifiers so the platforms stop paying premium for impressions that will not convert