Stop sending the same offer through email, push, and SMS in the same hour, so the customer experiences one message about one thing rather than three timed competitions for their attention
The customer who receives an email about the spring sale at 10am, a push notification about the spring sale at 10:08am, and an SMS about the spring sale at 10:12am does not experience three reminders. They experience one brand that does not know what it is doing. Each channel ran on its own schedule, each was correct in isolation, and the cumulative effect is the brand looking uncoordinated to the customer most likely to act on the offer. The frequency cap caught nothing because three different message types fit within any reasonable rate limit; the cap counts messages not content.
The fix is a content-level deduplication layer on top of the volume-level frequency cap. The send-time check looks at the cross-channel contact log, asks whether the customer has already received the same message in the dedup window, and either suppresses the redundant send or holds it for the moment the customer has not engaged with the prior one. The recipe is medium-low readiness because the mechanism is well-understood, the harder part is the message-equivalence rule (when do two messages count as "the same") and the channel priority order (which channel wins when a collision is detected).
This recipe builds the dedup as a real layer rather than relying on each channel's local view of the customer's recent contact.
A measurable reduction in cross-channel message collisions, where the same content reaches the customer on more than one channel within a defined window. The metric is the cross-channel message collision rate: the share of sends across channels that would have collided under the rule, against a baseline measured before the dedup was applied. The value shows up in the customer-attention picture (one message about one thing rather than three near-duplicates) and in the per-channel engagement (the channels that survive the dedup carry higher engagement because they are not competing with the brand's own other channels for the same moment).
The second outcome is the operational visibility of how often the collisions were happening before. Most teams substantially under-estimate the rate; surfacing it is the leading indicator the team needs to know whether the recipe is doing the work.
A real-time contact log that the send-time check can read with low latency, plus a send-time check inserted into every outbound path that reads the log and the dedup window rule before the send goes out. Composable stacks suit this because the contact log is the source of truth and the orchestration layer reads it; packaged stacks may have a per-channel contact log that the others cannot read, and the question is whether a shared log can be retrofitted. The capability that decides whether the recipe is effective is the dedup window: a window too short produces nominal dedup with most collisions still happening within it; a window too long suppresses legitimate follow-up sends and degrades the customer's overall engagement. The window has to be tuned per message type, with the rule explicit.
Compare the tools on Martech Stack Builder
Marketing ops owns the dedup window, the channel priority order, and the message-equivalence rules that decide what counts as the same message. Data engineering owns the contact log, the fingerprinting, and the send-time dedup check inserted into the send paths. Analytics measures the collision rate against the baseline and the post-dedup engagement lift, which is how the team knows the recipe is producing the value it was meant to. The recipe ships in weeks where the contact log is already shared or readily shareable; longer where each channel's contact data lives in a separate vendor and the integration is the substantial work.
Work in this order. The dedup is only as complete as the contact log it reads.
Frequency and fatigue management across channels covers steps 1, 2 and 4, channel eligibility check steps 3 and 5, and suppression and exclusion logic step 6.
The first failure is the dedup that is too fingerprint-strict. A rule that considers two messages distinct because they have different subject lines or different personalization tokens, even when the offer and the content are the same, fails to dedup the collisions the recipe was built to catch. The fingerprint has to focus on the offer and content, not on the surface variation, or the dedup is nominal.
The second is the dedup that is too aggressive. A rule that treats any send about the spring sale as the same message blocks a legitimate follow-up send a few days later, suppressing engagement the brand would have earned. The dedup window has to be short enough to avoid suppressing real follow-up sequences, and the rules have to distinguish the same-message collision from a legitimate cadenced sequence.
The third is the per-channel contact log that nobody can read. A team that ships the dedup at the orchestration layer but cannot see the contact log of the legacy SMS vendor produces dedup that catches some collisions and not others, and the cases that fall through are the cases the customer notices. The contact log has to be authoritative across every channel, or the dedup is partial in ways that are not visible to the team.
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