Implementation worksheet · 5 min read
A Contextual Upsell Prompt Exclusion Policy
Keep exclusion separate from targeting and evaluate it last, at display time. Targeting answers 'does this user look ready'; exclusion answers 'is it appropriate to ask right now'. The list is short and mostly obvious once written: an open support ticket, a recent failed payment, a feature already included in their plan, a recent declined upgrade prompt, an active outage affecting them, a user in the middle of a task, and anyone who has dismissed this prompt twice. Log which rule excluded each user, because an exclusion layer nobody can audit is indistinguishable from one that silently stopped running.
Contextual upsell is the most defensible in-app prompt — it appears because someone is actually doing the thing the paid feature helps with. It is also the one where a mistimed appearance does the most damage, because asking for money from someone mid-problem reads as opportunism rather than helpfulness.
Put it into practice
1. Keep exclusion out of the targeting score
Targeting is continuous and comparative; exclusion is binary and absolute. Encoding 'has an open support ticket' as a negative weight means a highly engaged user can outscore their own exclusion. Two layers, evaluated in order, is the only version that behaves correctly at the edges — and the edges are where the damage is.
2. Evaluate exclusions at display time, not at segment build
A user's state changes between qualifying and seeing the prompt. The support ticket opened this morning is only visible if you check now. One query at display prevents the whole 'the segment was built on Monday' category.
3. Exclude during an outage affecting that user
Asking someone to upgrade while their service is degraded is the single worst-timed prompt in the product. Wire the exclusion to whatever signals degraded service for that account, and default to excluding when the signal is unavailable rather than proceeding.
4. Respect prior refusals for a meaningful period
Dismissed once is a maybe; dismissed twice is a no. Record dismissals per prompt per user and suppress for a stated period rather than re-asking on the next qualifying action, which is what an untracked prompt does by default.
5. Check entitlement before asking
Upselling a feature someone already has on their plan is the error that makes the whole system look unaware. It happens when targeting uses behaviour and never checks the plan. One condition prevents it.
6. Log the excluding rule and count per rule
Per user, per display attempt, which rule excluded. Then watch the counts: a rule excluding zero users is probably broken rather than unnecessary, and a rule excluding most of your audience is probably too broad. Both are invisible without per-rule counts, and the silent-zero case is the likelier one.
The exclusion list
Copy this structure into your review document and record your observed result for each row.
| Rule | Source of truth | Evaluated at display | Logged |
|---|---|---|---|
| Open support ticket | support system | ||
| Recent failed payment | billing | ||
| Feature already in their plan | entitlement | ||
| Dismissed this prompt twice | prompt history | ||
| Declined an upgrade recently | billing / prompt history | ||
| Active outage affecting this account | status signal | ||
| Mid-task or unsaved state | client state | ||
| In onboarding | onboarding state | ||
| Internal or test account | account property |
A failure worth checking
The silent-zero rule. A status field is renamed upstream, and the open-ticket exclusion quietly matches nobody. Nothing errors — the prompt simply reaches a slightly larger audience and the conversion numbers look marginally better, which is the opposite of an alarm. It surfaces as a complaint from a customer who was asked to upgrade while waiting on an unresolved ticket. Per-rule exclusion counts, reviewed alongside the conversion numbers, turn this into something that looked odd on a Tuesday.
Common questions
Is this not the same as targeting?
No, and merging them is the common mistake. Targeting identifies the right user; exclusion identifies the wrong moment. The same person is a good target on Monday and a bad one on Tuesday because they opened a ticket, and only a separate binary layer represents that correctly.
Who owns the exclusion list?
Whoever is accountable for the customer relationship rather than whoever owns the conversion metric. The rules encode judgements about when it is acceptable to ask a customer for money, and the person measured on upgrades is not the right person to arbitrate that.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.