The Campaign Collision Review Framework

CAMPAIGN COLLISION REVIEW — original Growthcraft synthesis
Decision owner / lifecycle operator / data owner / reviewer:
Anonymous campaign A and B / channel / cap-rule version:
UTC snapshot and identity key definition (do not paste customer IDs):

1. ESTABLISH ELIGIBILITY
Consent and subscription scope checked before candidate generation:
Exactly one request per eligible person per campaign:
Transactional and mandatory communications reviewed outside this model:
Other campaigns, retries and eligibility changes excluded? Evidence:

2. RECONCILE AUDIENCE AND HISTORY
A eligible people / B eligible people / intersection:
A-only / B-only / both (disjoint groups):
Already capped counts in each group:
Remaining slots are exactly one or zero for every person? Evidence:
Time-window semantics, timezone and counted message event:
Missing history / identity merges / unmatched records:

3. COMPARE BOTH ORDERS
Local calculator JSON reference:
A-first allocation / B-first allocation:
Requests suppressed by previous history / new collision:
Priority owner and customer-task justification:
Selected is not delivered; no assumed revenue from reallocated slots:

4. VERIFY AND HAND OFF
Provider configuration checked by operator:
Shadow replay sample and discrepancy reasons:
Hold / collect evidence / human review for bounded test:
Owner, deadline, consent guardrail and rollback trigger:
Outcome measurement plan (separate from allocation arithmetic):

Use this when campaigns compete, not when choosing a universal cap

This original review framework helps lifecycle marketers at consumer brands, apps and SaaS startups explain why eligible audience counts do not equal selected messages. It is a narrow implementation companion to the broader lifecycle control-tower article: two campaigns compete for one remaining slot per uncapped person. It does not select the optimal frequency, establish consent, send messages or rank offers by predicted revenue.

Prerequisites are two frozen eligible audiences, a common person identity rule, a history snapshot and an explicit cap boundary. Obtain aggregate counts through a reviewed internal process. Do not upload customer lists to this website. When a person can receive two additional messages, a third campaign competes, or a retry may release a slot later, use a richer person-event replay instead of forcing those cases into this tool.

Gate 1 — settle eligibility before allocation

The lifecycle operator documents why each person is eligible for each promotional campaign. Consent, subscription preferences, channel availability and campaign entry conditions are upstream checks, not consequences of priority. The decision owner describes the customer task served by each message, such as completing an already-started setup versus receiving a broad promotion. A high-priority flag cannot make an ineligible message eligible.

Keep necessary transactional communications in their correctly reviewed operational process. Do not call a promotion transactional to escape a limit. The worksheet is not a legal assessment; the appropriate policy owner must review market-specific requirements. A common technical cap is not proof that an international campaign is compliant.

Gate 2 — build three disjoint groups

The data owner records A-only, B-only and both. If A contains 1,000 people, B contains 800 and the intersection contains 400, the groups are 600, 400 and 400. Their sum is the union of 1,400 unique people; adding A and B gives 1,800 candidate requests instead. That difference is the collision surface, not an error to conceal.

Within each group, count people whose remaining slot is already consumed. The synthetic counts are 100 A-only, 50 B-only and 80 overlap people. These 230 people block 310 candidate requests because an already-capped overlap person has two candidate requests. Verify that blocked counts never exceed their own group and that history uses the same identity and snapshot boundary as the audiences.

Gate 3 — compare two explicit orders

After history, 500 A-only people, 350 B-only people and 320 overlap people remain available. A-first selects 820 A messages and 350 B messages. B-first selects 500 A messages and 670 B messages. Both select 1,170 people; changing priority reallocates 320 slots and does not create more unique reach. Total requests not selected are 630: 310 from prior history and 320 from the current collision.

The decision owner must justify which customer task should get the contested slots. Do not multiply all 320 by an attributed conversion rate and label the answer incremental revenue. If the team needs an outcome comparison, design an appropriate controlled experiment with the analyst. This allocation review is a prerequisite for interpreting exposure, not evidence of which message causes better outcomes.

Gate 4 — validate a shadow replay before an operational change

The operator checks actual workspace settings, message-level exceptions, history events and retry behaviour. The analyst compares a bounded read-only replay with provider evidence and categorises differences: changed eligibility, missing history, identity duplication, another campaign, expired candidates or delivery failures. Do not alter the cap merely to make the counts agree.

Choose hold, collect evidence or human review for a bounded test. Name an owner and date for each unresolved issue. Keep a rollback condition for unexpected duplicate contact or preference violations. The worksheet ends with a reviewable decision record, not automatic activation. A complete snapshot can still be the wrong representation of a live system.

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.