When a Usage Limit Is Reached

Product analytics showing a steady count of actions blocked by a usage limit, plus support tickets asking when it resets, make this journey worth building. Prerequisites first: the limit-reached event names the limit, and the reset date, or its absence, comes from the entitlement record. The alternative path and any capacity option must be verifiable for the account, and you need push permission and an email address. If users hit the limit because of a wrong entitlement or a bug, fix that first; a message that explains a faulty block does not remove it.

Incremental continuation rate vs control

Success is how many more users keep doing the blocked task, through an alternative, added capacity or a renewed allowance, than in the control group; upgrades alone or a seen message are not the measure.

How it is counted: Among all limit events assigned at entry to either group, the share where the user continues the blocked task within the same follow-up window; the journey's effect is the gap between those two shares. Showing or clicking a message does not change the denominator, and users who could not continue stay in it.

Also track

• Continuation through the alternativeOf the users offered an alternative, the share who continue on it before the session ends; this is the journey's first goal and should be read before upgrades.
• Continuation after a capacity increaseFor users shown a higher plan or extra capacity, the share who increase capacity and return to their task; report it apart from the alternative branch, never summed with it.
• Usage after the resetUsers who received the renewed-allowance push and return to the task with the renewed allowance, as a share of those pushed; the count of pushes sent before the renewal was verified should be zero.
• Opt-outs and support ticketsTrack support tickets about the limit alongside push opt-outs and email unsubscribes; if the ticket count does not fall, revisit the explanation in the first message.

• Trigger and entryA usage limit that is reached and blocks an action starts the journey; a user who is approaching the limit does not enter and must not be addressed as blocked. Randomize accounts at entry, keeping a control group that gets none of this flow's messages and sees the limit only in the product's own interface.
• Who must not enterWarning accounts before the limit is reached is not this flow's job; the scope is one limit event, and one block never opens two flows. Accounts whose limit, alternative path and capacity options cannot be verified from the entitlement record stay out as well.
• Timing and channelsThe first in-app message names the limit, reset time and options. The alternative comes first, then a session-end wait; never sell the upgrade as the only way out while one stands. Next a higher plan, if capacity can be bought, with the same wait; everyone else gets push or email by reset timing.
• Exit and handoffWhen the user continues on the alternative or increases capacity, the journey ends in that exit. Everyone else closes at Informed once their message has gone, after the renewed-allowance push for a limit that resets soon. Nothing is handed off, so keep users who could not continue on any path visible in that exit.
• Frequency and consentFive touches is the longest path: three in-app messages and, for a limit that resets soon, two pushes; other branches end with a single email. Push goes only with permission and email needs a subscription; when the entitlement record holds no reset date, send nothing that implies a temporary wait.

1. 1If the share of users who continue is no better than in the control group, the messages only accompanied people who would have found a way anyway; more views or clicks do not change that. If upgrades rise while continuation through the alternative falls, the order has been broken; check the rule.
2. 2Keep the result tied to this order: alternative first, capacity second, reset information last. A capacity increase that began before the limit event or came through another offer is not this journey's result; count only continuation that happens after the limit event, within the same follow-up window.
3. 3Feed a small or unclear gap into the A/B test significance calculator as each group's limit events and continuations; if it reports the gap as not significant, collect more events before deciding, and avoid reading the small per-branch counts one by one.