Skip to content

AI ad frequency caps: a publisher pilot checklist

AI ad frequency caps explained for publishers: cap types, turn gaps, sensitive-topic exclusions, no-ad fallback and UX tests to agree before a pilot goes live.

Jolts Read as Markdown

AI ad frequency caps: a publisher pilot checklist

The best AI ad frequency caps are the ones you agree with your ad partner before launch: a per-conversation limit, a minimum gap between sponsored placements, a delayed first ad, and a rule that no suitable match means no ad. There is no universal number. The right cap depends on your app, your users and how much trust an ad placement spends.

That is why this post is a checklist, not a benchmark. Jolts connects advertisers with AI publishers through relevant, clearly labelled sponsored placements in AI conversations, and frequency is one of the things publishers and Jolts agree on a call before going live. The caps below are pilot policies to settle and implement together. Nothing here claims a proven optimal frequency, and any number you pick is a starting point to test.

What frequency capping means in an AI conversation (and why there is no universal good number)

Frequency capping in an AI conversation means limiting how many sponsored placements one person sees within a defined unit: a conversation, a session or a stretch of time. The IAB defines frequency capping as limiting how many times a particular user sees an ad within a campaign or a specified period, for example three times per day. The idea is old. The setting is new.

In display advertising, a cap protects against annoyance and wasted spend. In a chat, it protects something more fragile: the sense that the answer is for the user. A banner that appears twice is clutter. A sponsored card that appears after every reply is a different product.

So skip the search for the right number. A companion app with long, emotional sessions, a coding assistant with short bursts of focused work and a study tool used before exams will tolerate different loads. A rule that suits one will wreck another. Pick a conservative starting point, write it down, and let measured user experience move it.

The same logic applies to advice about caps from other channels. Rules of thumb from social ad platforms describe how those audiences respond to feed ads. They say nothing about a person mid-conversation. Treat any figure you did not measure in your own app as a hypothesis.

Do big AI platforms publish a standard frequency limit?

Not one you can copy. Each platform sets its own limits for its own inventory, and those limits belong to that platform. OpenAI Ads sells placements within ChatGPT, and Jolts cannot sell that inventory or speak for its rules. For your own app, the limit is yours to set. Decide it from your audience, your categories and the moments when a user would find an ad intrusive. At Jolts, frequency is one of the controls agreed with each publisher before launch.

Three cap types to choose from: per conversation, per session and per time window

Choose one primary cap type, then add a second as a backstop. Each answers a different failure.

Per conversation. A maximum number of sponsored placements in one thread. This is the most natural unit for an AI app because a conversation has a beginning, a topic and an end. It stops a long thread from becoming an ad stream. Its weakness: a user who opens ten short conversations in an hour sees ten ads.

Per session. A maximum across everything a user does between opening and leaving the app. It catches the many-short-threads pattern. You have to agree what ends a session (inactivity timeout, app close, sign-out), and the publisher has to be able to say so reliably.

Per time window. A maximum per hour, day or week, regardless of how conversations or sessions are cut. This cap protects heavy users and returning visitors. It also needs the publisher to recognise the same person over time, which raises data questions covered in AI ad request data: what publishers should share.

A workable pilot pairing: a per-conversation limit plus a daily or session-level backstop. Avoid stacking all three at launch. Every extra rule is one more thing to implement, log and debug.

Who implements the cap matters. Treat these as policies agreed between you and Jolts, with the exact mechanics settled per integration. Don't assume enforcement exists on any side until the scope is written down.

What are the best practices for capping ad frequency?

Start low and loosen only with evidence. Set a hard cap per conversation, add a gap between placements, and never repeat the same ad to the same user. Skip sensitive topics entirely and show no ad when nothing relevant matches. Review the cap against user feedback, not revenue alone. Jolts treats frequency, eligible categories and exclusions as publisher-set rules agreed before going live, so the publisher keeps control and can change them as the pilot teaches you more.

Where a cap should sit: turn gaps, first-ad timing and no repeated ads

A cap is a ceiling. Spacing rules decide how close to the ceiling a user ever feels. Agree three of them.

First-ad timing. Do not show a sponsored placement in the first turn. Let the assistant answer the user's first need before anything commercial appears. A rule like "no ad before the second exchange" is simple to test, and you can lengthen it if early drop-off rises.

Turn gaps. Set a minimum number of exchanges between sponsored placements in the same thread. Back-to-back ads are the fastest way to make a chat feel like a billboard. A gap also forces the matcher to wait for a new, relevant moment, which tends to help relevance as well as comfort.

No repeated ads. The same advertiser's card should not reappear in a thread because the user kept talking about the same topic. Define "repeat" precisely: same creative, same advertiser or same campaign. The stricter definition is safer in a pilot.

Skip short conversations entirely. If someone asks one question and leaves, a cap of one ad per conversation still shows an ad to everyone. A minimum conversation length before any placement is a sturdier policy than a lower cap.

Keep the sponsored placement visibly separate from the organic answer throughout. Spacing rules lose their value if the user can't tell what is sponsored. For more on that separation, see Sponsored offers in AI: keep ads separate from answers.

How often should sponsored follow-up questions appear?

There is no verified universal rate, and Jolts has no data on how other answer engines set theirs. A sensible default is to treat sponsored follow-ups like any other placement: hold the first one back until the user has had a useful organic answer, leave gaps of several turns between placements, and never repeat the same sponsor in one conversation. Keep sponsored content visibly separate from the organic answer. Then test the cap in a small pilot and tighten it if users stop engaging.

Sensitive topics, opt-outs and moments when the answer is no ad

Some conversations should never carry a placement, whatever the cap says. Write the exclusion list before the first live request.

Start with topics: health crises, mental health, grief, legal trouble, financial distress and anything involving minors are common candidates. Your own app will add more. A companion app and a coding assistant won't share the same list. Jolts publisher onboarding covers eligible categories and excluded topics as explicit items, so bring yours to the call.

Then add moments, not just topics:

  • A user is mid-task and blocked, for example a failing deploy or a deadline.

  • The user has expressed frustration with the assistant.

  • Support, billing or account conversations.

  • A checkout or confirmation step where a distraction costs the user money.

  • Any thread where the user has opted out of sponsored content.

Opt-outs deserve their own line in the pilot terms. Decide whether paid tiers are ad-free, whether free users can dismiss a placement, and whether a dismissal should suppress further placements for a period. Decide, too, what signal reaches the matcher. Because full conversations are not required by default, structured topics or redacted summaries can carry the context, and an exclusion can be expressed as a topic the matcher is told to skip. The tradeoffs of what to share are laid out in AI ad request data: what publishers should share.

When in doubt, the answer is no ad. A missed impression costs a fraction of a lost user.

Designing the no-ad fallback so a cap or a missed match never breaks the answer

A cap reached, a sensitive topic or a request with no suitable match all end the same way: nothing sponsored appears, and the answer arrives untouched. That path must be designed, not left as an error state.

Three rules keep it clean:

  1. The answer never waits for the ad. If the ad request is slow or fails, render the answer without it. A timeout should mean no ad, not a spinner.

  2. No empty frame. Do not reserve space for a placement that did not arrive. A blank box or a layout jump reads as a bug.

  3. Treat "no ad" as a normal outcome. Log it as a legitimate result, so a high no-ad rate shows up as a signal about matching and caps, not as an outage.

Jolts works on this basis: no suitable match means no ad. That makes the fallback the default behaviour of the system, not an exception to build around. Your job as publisher is to make sure your rendering code treats that state as ordinary.

The fallback also protects your cap policy. If a cap is enforced in two places, say your app and the ad side, the safe resolution of any disagreement is to show nothing. For a deeper checklist, see AI ad integration: publisher fallback checks and Build a test set where the right ad is no ad.

How to test the user experience before and during a pilot

Test with the cap you can defend, then lower it if the signals turn. Don't launch at a number chosen to hit a revenue target.

Before launch

  • Replay realistic conversations from your own app, not synthetic ones, and mark where the policy would allow a placement. Read them as a user. Would you tolerate each one?

  • Run edge cases: very long threads, rapid-fire short threads, a user who reopens the app repeatedly, a reconnect mid-thread. Check that the same impression is not counted twice, as in The chat reconnected. Did you count the ad twice?.

  • Confirm every exclusion rule fires on its test cases and that the no-ad path renders cleanly.

During the pilot

  • Watch the metrics a cap should protect: conversation abandonment, return rate, task completion, complaints and support tickets that mention ads.

  • Compare cohorts with different caps if your volume allows, one change at a time.

  • Keep a way to lower or pause the cap quickly. Agree who can ask for that change and how fast it takes effect.

Set the threshold for action in advance. If complaints rise or retention slips after a cap change, you lower the cap, and you decided that before you saw the data. Pilot terms such as revenue share and counting rules belong in the same conversation, and they are covered in AI ad pilot terms: publisher revenue share and payouts.

A frequency checklist to bring to the first pilot call (and how Jolts approaches it)

Bring this list and leave with an answer to each line.

  • Cap unit: per conversation, per session, per time window, or a pairing. Which one is primary?

  • Cap value: the starting number, labelled as a test value with a date to review it.

  • Session definition: what ends a session, and who can detect it.

  • First-ad timing: the earliest turn a placement may appear.

  • Turn gap: minimum exchanges between placements in one thread.

  • Repeat rule: what counts as the same ad and how long it stays suppressed.

  • Minimum conversation length: below it, no ad.

  • Excluded topics and moments: the written list, with an owner who updates it.

  • Opt-outs: which users see no ads and how a dismissal is handled.

  • No-ad fallback: timeout behaviour, no empty frame, how no-ad outcomes are logged.

  • Where each rule is implemented: in your app, on the Jolts side or both, and what happens when they disagree.

  • Review trigger: which metric movement lowers the cap, and who decides.

Jolts approaches frequency the way it approaches the rest of onboarding. Categories, frequency, exclusions, shared data, rendering, measurement and the no-ad fallback are agreed with each publisher before going live, on a call that confirms audience fit, placement availability and scope. Jolts is at an early stage and builds with early partners, so your list shapes the pilot. Frequency rules are pilot policies you settle together, not a dashboard feature to assume.

For the commercial side of the same call, read Before the SDK: the publisher conversation worth having and the Jolts publishers page.

What guidelines should govern ads in chat responses?

Four rules cover most of it. Label every sponsored placement clearly. Keep it separate from the organic answer so the answer is never altered. Show no ad when there is no relevant match. Share only the context needed for matching, such as structured topics or redacted summaries rather than full conversations. These are the principles Jolts builds on: publishers set categories, exclusions and frequency, and the no-ad fallback is agreed up front. Treat them as a starting point and adapt them to your users and your policies.

Bring your own cap to the call and let the pilot test it

A frequency cap is a promise to your users about how much sponsorship they will tolerate on your behalf, so the number should come from your product, not from a benchmark. Pick a conservative cap type, space the placements, write the exclusions and make no-ad a normal outcome. Then test and adjust. If you run an AI app and want to set these rules with a partner, book a call with Jolts, bring the checklist above and agree the first cap together before anything goes live.

Your next opportunity is in the conversation.

Advertise your brand or monetize your AI app. Find your starting point.

Book a call