# AI ad integration: publisher fallback checks

A publisher acceptance checklist for AI ad integration: rendering, latency budget, empty match, request failure, no-ad fallback, exclusions, frequency and measurement.

# AI ad integration: publisher fallback checks

An AI ad integration is ready to launch when it passes eight tests: sponsored content renders apart from the organic answer, the answer never waits past an agreed latency budget, empty matches and request failures both end in no ad, category exclusions and frequency caps hold, and every impression is counted once. Run them before launch, not after the first complaint.

The tests below are recommended acceptance checks for publishers of chat, companion, writing, study, coding and answer apps. They are not a claim that any vendor ships a particular SDK or guarantees particular response times. Scope and terms are agreed before going live, and these tests give that agreement something concrete to point at. Jolts connects advertisers with AI publishers through relevant, clearly labelled sponsored placements in AI conversations. The checklist reflects how a publisher can hold any partner, Jolts included, to that standard.

## What an AI ad integration has to prove before launch

An AI ad integration has to prove that the ad is the optional part of your product. If the sponsored placement fails, slows or misfires, the user should still get a complete, correct answer and never learn an ad was attempted.

That changes the question from "does it work?" to "what breaks when the ad doesn't?" Success is not that an ad appears. Success is that nothing breaks when an ad doesn't. A launch that shows ads in the demo and has never been tested with the ad service switched off is not ready.

Write the definition of working before you write integration code. Eight tests cover it: rendering, latency, empty match, request failure, exclusions, frequency, measurement, and the no-ad fallback that sits under all of them. Teams that skip this step often discover the real requirements in production, with users watching. The publisher conversation that should come first is covered in [Before the SDK: the publisher conversation worth having](https://jolts.xyz/blog/publisher-pilot-before-sdk).

## Rendering test: is the sponsored placement visibly separate from the organic answer?

The sponsored placement passes only if a user can tell, at a glance and without reading, that it is not part of the answer. Separation is a design requirement, an ethical one, and a legal one.

On the legal side, the FTC’s general native-advertising guidance points the same way: ads must not mislead consumers about being advertising, and necessary disclosures must be clear and prominent. Use an unmistakable label such as "Ad" or "Sponsored" next to the paid content, close to the claim it qualifies. Don't bury it in terms or show it somewhere else. This is a general summary, not legal advice; check requirements for the markets you serve.

Run these checks:

- Place the sponsored card in its own container, outside the text stream of the answer.
- Confirm the label is visible on every surface: web, mobile, dark mode, narrow widths.
- Screenshot ten real answers with a placement and ask someone outside the team to point to the ad. If they hesitate, fail the test.
- Confirm the answer text never references, summarizes or leans toward the sponsor.

The principle is explored further in [Sponsored offers in AI: keep ads separate from answers](https://jolts.xyz/blog/sponsored-offers-in-ai-keep-ads-separate-from-answers). Trust is the asset you are protecting. Labelling is the cheapest way to keep it.

## Latency budget test: what the publisher agrees the answer may wait for

The latency budget is a number the publisher chooses, not a number a vendor promises. Decide how long the answer may wait for an ad decision, write it into the pilot scope, and test that the product honors it.

The key design choice is what happens at the deadline. Two patterns are common:

- **Answer first, ad second.** The answer renders immediately and the placement fills in only if a decision arrives inside the budget.
- **Parallel request with a hard timeout.** The ad request runs alongside the model call and is abandoned at the deadline.

Either is fine. What fails the test is any design where a slow ad service slows the answer.

To test it, add artificial delay to the ad path: double the budget, then ten times it. The answer should render at the same speed every time. Also test the late arrival. A card that appears after the user has moved to the next turn is worse than no card. Decide whether late decisions are discarded or held, and verify that behavior. [The sponsored card that arrived one turn late](https://jolts.xyz/blog/the-card-that-arrived-one-turn-late) walks through that edge case.

## Empty match and request failure tests: when the right outcome is no ad

Both an empty match and a failed request must end in the same visible result: no ad, and an unchanged answer. The two cases differ underneath, so test them separately.

An empty match is a healthy outcome. The request succeeded, but no campaign fits the topic, the placement rules or the exclusions. A no-ad response is the correct answer, and it should be common in sensitive or niche contexts. If your integration treats it as an error, or worse, backfills with something loosely related, fix that before launch.

A request failure is the unhealthy case: timeout, network error, malformed response, service outage. Test each by force:

- Return an empty match and confirm the layout collapses with no blank box, spinner or "loading" artifact.
- Return an error response and confirm nothing is logged to the user.
- Return garbage and confirm the parser rejects it.
- Kill the connection mid-response.

In all four, the organic answer must be identical to the no-ad baseline. Build the test set deliberately, because the right ad is often no ad. [Build a test set where the right ad is no ad](https://jolts.xyz/blog/a-test-set-for-showing-nothing) describes how.

## Control tests: category exclusions and frequency caps

Exclusions and frequency caps pass when the controls you agreed with your partner hold on real conversations, not just in a settings page. This is where brand safety actually lives.

**Exclusions.** List the categories and topics you will not carry: health crises, grief, legal trouble, minors' content, competitors of your own product, anything your users would find tasteless next to a sponsor. Then build prompts that sit on the line. A recipe question is fine; a question about eating disorders is not. Run each against the integration and confirm no ad appears. Test phrasing variants and other languages, since a topic filter that works in English only is half a filter.

**Frequency.** Decide the cap in advance, for example how many placements per session or per day, and how many in a row. Then simulate a long session, a user who asks twenty related questions, and a returning user. Confirm the cap holds across reconnects and new devices as far as your identity model allows.

Categories, frequency, shared data and exclusions are all items to settle before going live, alongside the commercial side covered in [AI ad pilot terms: publisher revenue share and payouts](https://jolts.xyz/blog/ai-ad-pilot-terms-publisher-revenue-share-and-payouts).

## Measurement checks: what can be counted, and counted once

Measurement passes when each event type has a written definition and each real-world impression produces exactly one count. Counting rules are agreed before launch, so the test is whether the integration matches the agreement.

Write down what counts as an impression: rendered in the DOM, rendered and visible, visible for a set time? Do the same for clicks. Then try to break the count:

- Reconnect the chat and reload the history. Does the same ad count again? [The chat reconnected. Did you count the ad twice?](https://jolts.xyz/blog/one-impression-after-reconnect) covers this.
- Scroll a card out of view and back.
- Double-click a link.
- Open the app in two tabs.
- Throttle the network so the event retries.

Each should yield one impression and one click, not two. Compare your logs against the partner's reporting for a sample day and reconcile any gap before it becomes a payout dispute.

Be honest about what counting cannot tell you. A click can be real without being incremental, as [A click can be real without being incremental](https://jolts.xyz/blog/clicks-attribution-and-lift) argues, so don't promise outcomes that your measurement can't support. Finally, review what you send out with each request. The smallest signal that allows a match is usually a structured topic, not the transcript. See [AI ad request data: what publishers should share](https://jolts.xyz/blog/ai-ad-request-data-what-publishers-should-share) for the data side, including what to ask about privacy and GDPR-style obligations: share the minimum, document it, and confirm with counsel.

## A one-page acceptance checklist to take into a pilot call

Bring one page to the pilot call. Each line is a test, an owner and a pass condition, and the partner should be able to answer every line before launch.

| Test | Pass condition |
| --- | --- |
| Rendering | Sponsored card sits outside the answer, labelled "Ad" or "Sponsored" on every surface |
| Latency budget | Publisher-set number written down; answer speed unchanged when the ad path is slowed |
| Late arrival | Decisions after the deadline are discarded or handled as agreed |
| Empty match | No ad, no blank space, no backfill |
| Request failure | Timeout, error, malformed response and dropped connection all fall back to no ad |
| Exclusions | Agreed categories and topics return no ad across phrasing variants |
| Frequency | Cap holds across a long session, reconnect and return visit |
| Measurement | Definitions written; one count per real impression; logs reconcile with partner reports |
| Data shared | Field list agreed; no full transcript by default |
| Terms | Revenue share, counting, fees and payout timing agreed before going live |

How does this compare with picking between networks? The checklist works for any partner, which is the point. For a view of the field, see [AI chatbot ad networks: what publishers should compare](https://jolts.xyz/blog/ai-chatbot-ad-networks-what-publishers-should-compare) and [Contextual ads in AI conversations: platforms to compare](https://jolts.xyz/blog/contextual-ads-in-ai-conversations-platforms-to-compare).

When you evaluate any partner's revenue share, ask how events are counted and when payouts arrive, not just the percentage. With Jolts, integration scope and terms are confirmed on a call before launch, and publishers agree categories, frequency, excluded topics, shared data, revenue share, event counting, fees and payout timing up front.

## Take this checklist into a scoped pilot call with Jolts

An AI ad integration is trustworthy when its failures are invisible: no ad, no delay, no double count, no sponsor in your answer. If you can pass these eight tests on a small scope, you can widen it with evidence instead of hope. Jolts is building with early partners and agrees audience fit, placement availability, scope and terms on a call before anything goes live. Book that call, bring this page, and make the partner answer every line.