Increasing impressions per user can lift revenue immediately. The user cost arrives through a different set of metrics: shorter sessions, lower return rate, more accidental clicks and weaker reviews. Because those effects cross revenue and product ownership, frequency should be designed as a product rule rather than left as an ad-server default.
A durable policy combines eligible moments, time-based caps, session-based caps and cohort measurement. It gives commercial teams room to optimize while giving product teams explicit control over interruption.
- Define where an ad may appear before deciding how often it may appear.
- Use both time-based and session-based limits for interruptive formats.
- Measure incremental revenue against session depth and retention.
- Create stricter rules for new, returning and high-value user cohorts where appropriate.
Start with the moment, not the cap
An interstitial at a natural transition feels different from the same interstitial arriving during input, navigation or content consumption. Map the user journey and classify moments as eligible, conditional or prohibited. Only then should the team set a cap.
For rewarded formats, the value exchange should be clear and initiated through an eligible choice. For app-open inventory, monetization should stay within genuine loading states. Banners and native units need layout rules that prevent content obstruction and accidental interaction.
Use layered frequency controls
A single daily cap is rarely enough. Combine a minimum interval between exposures, a session cap and a longer rolling cap. The interval prevents back-to-back interruption, the session cap protects concentrated use and the rolling cap limits cumulative fatigue.
Define the scope clearly. A cap can apply to one placement, one format, a group of formats or the whole app experience. When multiple controls apply, the most restrictive rule should win. Keep the logic visible to product and analytics teams rather than burying it in an ad-platform account.
Segment users by experience, not just value
New users are still learning the product and may be more sensitive to interruption. Returning users may tolerate a different cadence. Subscribers, payers and users in a recovery or support flow often require distinct policies. Segmentation should protect the experience; it should not become a reason to overwhelm users who appear less valuable.
Keep the number of policies manageable. A few explainable cohorts are easier to test, audit and maintain than dozens of opaque rules.
Measure the frequency curve
Test exposure levels as a curve rather than comparing “ads on” with “ads off.” For each cell, measure revenue per active user, impressions per session, session depth, D1 and D7 retention, latency and accidental-click indicators. The useful point is often where incremental revenue begins to flatten while experience costs accelerate.
Allow exposed cohorts to mature before declaring a result. A test that optimizes same-day revenue cannot rule out a retention cost that appears later in the week.
Write a policy the whole team can operate
Document eligible moments, prohibited states, cap hierarchy, cohort exceptions, preload behavior, fallback behavior and the metrics that trigger rollback. Assign an owner and review the policy after major product or demand changes.
This is the difference between a frequency setting and a frequency strategy: one limits delivery, while the other connects delivery to the product outcome the business wants to preserve.
Questions teams ask
What is ad frequency capping?
Frequency capping limits how many times an ad or format can be shown to a user within a defined period, session or placement scope.
How often should an app show interstitial ads?
There is no universal number. Interstitials should appear only at eligible transitions and be tested with time, session and retention guardrails for the specific app.
Can lower ad frequency increase revenue?
It can improve session depth, return rate, viewability or advertiser quality enough to offset fewer impressions. The effect must be measured against the app’s own baseline.