A fatigue rule that suppresses 810,000 people, including 300,000 who should receive
A telecom sends three newsletters a week to 6 million profiles plus occasional promotions. A fatigue rule limits each profile to two marketing messages in a rolling seven days across newsletters and promotions. A launch targets 2 million profiles; the preview shows 810,000 excluded, including 300,000 active customers who received nothing in the last ten days. The delivery uses dynamic content with four variants keyed on a custom segment field on the profile, and personalization pulls a store name through a link to a Store resource. In the proof, variant C renders the fallback for every proof profile and the store name is blank for 12% of the audience. The campaign owner wants to launch tonight and asks you to switch the fatigue rule off, then fix it afterwards.
1. Diagnose the 300,000 apparently false exclusions. What evidence would you collect, and which rule properties are the likely culprits?
Read the worked answer
Stop reading the preview as one number and split it by rule. The delivery's exclusion log attributes each excluded profile to a specific rule. If the 300,000 belong to a different rule than the fatigue rule, the whole diagnosis changes.
Then check the fatigue rule's properties:
- Period: a rolling seven days is not a calendar week. A calendar-week implementation can exclude someone who received two messages on Sunday.
- Counting point: events counted at preparation versus at send, and whether failed or rejected messages count.
- Scope: typologies, folders and channels. Rules that count transactional or trigger messages will suppress marketing for people who only received a password reset.
- Double application: a rule attached both to the delivery and to the folder typology can be counted twice.
Cheap test: take 1,000 of the 300,000, list their broadLogs for the last ten days and count. If they received fewer than two, the rule's inputs are wrong, not the audience. Fix scope and period, then re-simulate and compare counts before touching the launch.
2. Variant C always renders the fallback and the store name is blank for 12%. Is this a rendering bug or a data bug, and how do you prove it and fix it?
Read the worked answer
It is almost certainly a data problem, and the two symptoms probably share a cause. The variant condition compares the segment field to a value. If the field is empty, holds a code rather than a label, differs in case, or carries trailing spaces, the condition evaluates false and ACS renders the fallback.
Prove it on the real target, not on proofs. Run a count by segment value including nulls across the 2 million targeted profiles. Then check whether the field is actually available at render time: a custom field reached through a link can be null, and a null condition silently fails rather than erroring.
The store name being blank for 12% points the same way. Check those profiles for a null store foreign key, a link to a store that is no longer active, or a language mismatch on the store record.
Fix: normalise the segment codes at import, make the condition null-safe, add a deliberate otherwise variant for nulls, and repair or exclude the profiles with no valid store. Proof to one profile per segment value rather than one generic internal profile, because a small internal proof list will not contain the null case.
3. The campaign owner asks you to disable the fatigue rule for tonight. How do you respond, and what would you actually approve?
Read the worked answer
No, not by disabling it. A fatigue rule is a deliverability and customer-experience control. Turning it off to hit a date moves the cost to complaint rates, unsubscribe rates and eventually inbox placement, and it sets a precedent that every future launch can override the control.
What I would approve is a narrow, documented exception:
- Keep the rule and exclude this specific campaign from its scope for a defined period and volume, or create a campaign-specific typology version with a higher allowance.
- Get an explicit owner sign-off, so the decision appears in the audit trail.
- Release in a controlled way: a 10% split first, comparing complaints and unsubscribes against the previous launch before releasing the rest.
- If volume is the real driver, spread the launch over two days or use waves.
I would also say that the exception should not be needed at all. The 300,000 false positives mean the rule is misconfigured. The correct outcome is a rule that suppresses the right people, not a rule that is switched off. Fix the rule and the launch date can probably still be met.