Two-Campaign Frequency Cap & Audience Collision Calculator

A frozen allocation scenario, not a sending engine

Use this calculator before two promotional campaigns compete for the same people. It assumes each uncapped person has exactly one remaining slot, each already-capped person has zero, and each eligible person has one candidate request per campaign. Both campaigns share the same cap boundary. Consent and channel eligibility have already been checked. The calculation runs locally and neither connects to your messaging provider nor sends data to AI.

The model is intentionally small. It does not reproduce rolling-window expiry, queue timing, retries, concurrent reservations, channel-specific exceptions or a third campaign. A one-slot snapshot can represent the remaining capacity under a larger cap, but only if every scoped person really has either zero or one remaining slot. People with two or more slots require a different model.

Six counts and a priority choice

A and B are unique eligible people in each audience before this frequency cap. O is their intersection and cannot exceed either total. A-only = A − O and B-only = B − O. Enter already-capped people separately for A-only, B-only and both; these groups must not overlap. Each capped count is bounded by its group size.

All six counts must be supplied as whole numbers between zero and one billion. This maximum is an implementation safeguard, not an audience-quality claim. An empty field is not silently treated as zero. Use the optional scope field to record anonymous campaign labels, channel, timestamp and cap definition; keep private person identifiers out. Reset restores the labelled synthetic example. Editing any input clears the previous result so it cannot be mistaken for the revised scenario.

Reconcile people, requests and reasons

Let C_A, C_B and C_O be already-capped people in A-only, B-only and overlap. Available exclusive groups are X = A − O − C_A and Y = B − O − C_B. Available overlap is Z = O − C_O. With A first, allocation is A = X + Z and B = Y. With B first, allocation is A = X and B = Y + Z.

The union is A + B − O. Selected requests equal selected people, X + Y + Z, because each receives at most one selection. Prior-history blocked requests are C_A + C_B + 2C_O; collision-blocked requests are Z. These two reasons sum to total unselected requests: A + B − (X + Y + Z). Reversing priority moves exactly Z selections between campaigns and leaves selected unique reach unchanged.

Overlap percentage uses the union as denominator, not A or B. The selected-request percentage uses A + B. Both percentages are undefined when their denominator is zero; the tool displays that explicitly. The JSON export preserves the full calculation and assumptions rather than only rounded screen values.

Worked synthetic snapshot

A = 1,000, B = 800 and O = 400. Already capped: C_A = 100, C_B = 50 and C_O = 80. The union is 1,400; 230 people have no slot. Of 1,800 candidate requests, 310 are blocked by history and 320 by collision. A-first selects 820 A and 350 B; B-first selects 500 A and 670 B. Both select 1,170 people and leave 630 requests unselected. These are not actual campaign results or benchmarks.

If every overlap person is already capped, changing priority changes nothing. If the intersection is zero, priority also changes nothing. If all groups are already capped, selection is zero. These useful boundary cases help detect inputs accidentally copied from different snapshots.

What a result cannot tell you

Selection is not dispatch, delivery, reading, purchase or incremental impact. A larger share of selected messages is not automatically a better customer experience. Missing consent, stale identity resolution or incomplete history makes an arithmetically valid result operationally unsafe. Use the companion evidence worksheet to document these limitations and the technical article for a tested person-level replay.

The calculator does not recommend increasing limits, bypassing preferences or inventing a revenue value for suppressed messages. Provider configuration and a separately designed outcome evaluation must support any actual change.

Sources and boundaries

Reviewed 29 September 2026. Customer.io's message-limit documentation (updated 14 September) describes relative time windows and optional retry handling. Braze's rate-limit and frequency-cap documentation distinguishes throughput control from per-user pressure. This original snapshot model does not emulate either provider or recommend a universal message frequency.