# When a Usage Limit Is Reached Page: https://alidemirbas.com.tr/en/lab/journeys/usage-limit-capacity-path Limit reached → show options → alternative, capacity or reset ## Purpose When someone hits a usage limit, explain the available alternative, extra capacity and reset timing according to their situation. Goal: Access & Entitlement Change · Category: Activation & Usage ## Steps - **Trigger**: Usage limit reached - **Action**: In-app: Which limit was reached, when it resets and the options - **Decision**: Is there another way to continue now? - Yes: In-app: Offer the available alternative path - No: Can more capacity be purchased? - **Action**: In-app: Offer the available alternative path - **Wait**: Wait until the session ends - **Decision**: Did the user continue with the alternative? - Yes: Continuing on the alternative path - No: Can more capacity be purchased? - **Decision**: Can more capacity be purchased? - Yes: In-app: Show a higher plan or extra-capacity option - No: When does the limit reset? - **Action**: In-app: Show a higher plan or extra-capacity option - **Wait**: Wait until the session ends - **Decision**: Was capacity increased? - Yes: Continuing on the upgraded plan - No: When does the limit reset? - **Decision**: When does the limit reset? - Soon: Push: Your limit resets soon - Later: Email: Reset date and what can be done until then - No automatic reset: Email: The limit is permanent; available capacity options - **Action**: Push: Your limit resets soon - **Wait**: Wait until the reset - **Action**: Push: Your usage allowance has renewed - **Action**: Email: Reset date and what can be done until then - **Action**: Email: The limit is permanent; available capacity options - **Exit**: Continuing on the alternative path - **Exit**: Continuing on the upgraded plan - **Exit**: Informed; continues with the available option ## Guardrails - Do not describe a user as blocked before the limit is reached. - Do not present an upgrade as the only option when a usable alternative exists. ## Core rule Check the available paths in order; show a usable alternative before presenting an upgrade as the only option. ## When to set it up 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. ## How to set it up - **Trigger and entry**: A 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 enter**: Warning 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 channels**: The 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 handoff**: When 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 consent**: Five 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. ## How to measure success **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. 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 alternative**: Of 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 increase**: For 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 reset**: Users 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 tickets**: Track 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. ## What to watch when reading the result - If 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. - Keep 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. - Feed a small or unclear gap into the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test) 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. ## Frequently Asked Questions ### Should a usage limit immediately trigger an upsell? Explain the limit and its reset time first. Offer an existing alternative route when available. Additional capacity or a higher plan is a later option when it addresses a real need and the offer is valid. ### What should I say when the limit never resets? Do not imply a temporary wait. Explain the permanent limit and genuine capacity options. For resetting limits, use the authoritative entitlement record and verify the reset before announcing renewed access. ### Should usage-limit success be measured only by upgrades? Completing the task through an existing alternative is also useful. Report alternative continuation, capacity increases and usage after reset separately. Keep users who cannot continue in the analysis so the blocked task remains visible.