An AI app should share the smallest signal that lets an ad match: a structured topic, a coarse intent and the placement details, not the full conversation. Add fields only when you can name the reason you are adding them. That is the whole principle behind good AI ad request data, and the rest of this guide turns it into a checklist you can run before you integrate with any ad network.
The payload is your decision, not the network's. Whatever you put in the request is what leaves your product, so it is also what your privacy policy, your users and your trust lead have to defend. This is an evaluation guide for publishers, not legal advice. Run your own plan past counsel for GDPR, CCPA and consent questions.
Jolts connects advertisers with AI publishers through relevant, clearly labelled sponsored placements in AI conversations. Its stance on data fits this guide: full conversations are not required by default, and structured topics or redacted summaries can provide context.
What an AI ad request is, and why the payload is your decision
An AI ad request is the message your app sends to an ad network when it wants to know whether a sponsored placement fits the current moment. It carries whatever context you decide to include, and the network answers with an ad or with nothing.
Nothing in the concept forces you to send the chat. You choose the fields. A request can be as thin as a topic label and a placement type, or as heavy as a full transcript with user identifiers attached. Networks and SDKs differ in what they ask for, so write down your own minimum before you read anyone's integration docs.
Every field is a liability you are choosing to take on. If you cannot say what the field improves, leave it out. That test, applied field by field, does more for privacy than any policy paragraph.
Contextual signal vs personal data: the line to draw first
Contextual signal describes the moment; personal data describes the person. Draw that line before anything else, because ads can be matched on the first without the second.
Contextual signal answers: what is this conversation about right now, and what is the user trying to decide? "Running shoes, flat feet, budget under $150" is contextual. It lets a matcher judge whether a stability shoe is relevant, and it says nothing about who is asking.
Personal data answers: who is this, what have they said before, and what can we infer about them over time? Chat history, memory, account identifiers and inferred traits all belong here. Industry guidance on conversational advertising points the same way: prefer contextual matching on the current topic over persistent profiles, don't retain raw conversations or hand them to advertisers, and don't turn sensitive chat content into lasting targeting categories.
That is also the honest answer to "AI app ads: contextual targeting vs personal data." Contextual targeting needs far less. Start there. If a use case seems to demand personal data, make the case in writing before it goes in the request.
One more distinction worth holding: a message that matters for matching is not the same as a message that should travel. A user asking how to patch a leaking daypack has no purchase decision in progress. Jolts' own writeup on what an ad matcher can learn from four fields makes the point that the repair turn is a request you can leave out entirely and let the assistant simply answer.
The data ladder: from topic label to redacted summary to full transcript
Climb the ladder one rung at a time, and stop at the lowest rung that gives acceptable matching. There are three rungs worth naming.
Rung 1: structured topic and intent. A category (for example, running footwear), a coarse intent such as researching, comparing or ready to buy, and a few constraints like price ceiling or required feature. This is the default starting point. It is small, easy to audit and easy to explain to users.
Rung 2: redacted summary. A short, machine- or human-written summary of the current need with names, contact details and other identifiers stripped before it leaves your app. Use it when topic labels are too blunt for your category, for example when a study or coding app has niche subtopics. You own the redaction step, so test it on messy real inputs.
Rung 3: full transcript. The raw conversation. Jolts' position is that this is not required by default. If a network asks for it, ask what matching quality it buys that rung 2 does not, how long it is kept, who can see it and whether it is used for anything beyond matching your request. If the answers are vague, stay on a lower rung.
Move up only with a named reason and a measured gap. "It might match better" is not a reason. "Topic labels returned no ad for 40% of comparison questions in our pilot, and the summary fixed it" is.
Fields worth sharing, fields to leave out, and an illustrative request
Here is a working split for the question "what data should an AI app share with an ad network?" Adapt it. It is a starting point, not a prescription.
Worth sharing
Topic or category of the current exchange
Coarse intent stage (researching, comparing, deciding)
Task constraints that shape relevance (price ceiling, required feature, destination region at city or country level if it matters)
Placement type and surface (message, card, carousel, poll) so the network knows what can render
Your publisher rules: eligible categories, excluded topics, frequency cap state
A per-request ID for counting and deduplication
Leave out by default
Raw user prompts and full transcripts
Names, emails, phone numbers, precise location and account identifiers
Chat history or memory across sessions
Anything touching sensitive categories such as health, finances in distress, relationships or legal trouble
Inferred traits about the person (income guesses, mood, demographics)
An illustrative request. This is a sketch of the shape a minimal request could take. It is an example for thinking, not a Jolts schema or a production endpoint:
{
"topic": "running footwear",
"intent_stage": "comparing",
"constraints": { "max_price_usd": 150, "need": "stability" },
"placement": "card",
"publisher_rules": { "excluded_topics": ["health_conditions"], "frequency_cap_ok": true },
"request_id": "r_8f21"
}Look at what is absent: no user text, no identity, no history. A matcher can still tell whether a stability shoe under $150 is relevant. If the topic is excluded or nothing fits, the correct response is no ad.
This also answers "monetizing an AI app with ads without sharing user prompts." The prompt stays in your app, and only a derived, structured description of the need goes out.
Questions to ask any ad network before you integrate
Ask these before the SDK goes anywhere near your build. They cover the ground that "ad network required data fields" and "what user data do ad networks collect from apps" searches are really after.
Which fields are required, and which are optional? Get the full list in writing. Required fields set your floor.
Can we run on structured topics or redacted summaries only? If the answer is no, find out why.
What does the SDK collect on its own? Device identifiers, IP, app-level signals and network calls can add data you never put in the request. Audit the SDK separately from the request.
What happens to request data after matching? Ask about storage, retention and reuse in specifics, and get the answer in the contract, not just a sales call.
Is request data used for anything other than serving our placement? Profile building, model training and cross-publisher sharing are the usual surprises.
Who receives the data downstream? Advertisers, partners and subprocessors.
How do consent and user rights work for the request flow? For GDPR and CCPA questions, such as consent for secondary advertising use, opt-outs and deletion, get your counsel to review the actual data flow, because the right answer depends on your users and your setup.
What can actually be measured with this payload? Thinner requests may limit attribution. Know the tradeoff up front.
If you want a broader buying checklist, see what publishers should compare in AI chatbot ad networks, and for the conversation to have first, before the SDK.
Pair the data with controls: categories, frequency, exclusions, labelling and no-ad fallback
Data minimization is half the design. Controls are the other half. A thin request with no guardrails still gives you ads in places you did not want them.
Set these with any network before launch:
Eligible categories. Name what can appear. Everything else is out.
Excluded topics. Decide which conversations never get an ad, such as sensitive subjects, and make sure the exclusion is checked before a request is even built.
Frequency. Cap how often a user sees a sponsored placement per session or per day.
Labelling. Keep sponsored content visibly separate from the organic answer and clearly marked. Users should never wonder which part is the assistant and which is the advertiser. More on this in keeping sponsored offers separate from answers.
User controls. Give people an easy way to turn off ad personalization and understand what informs ads.
No-ad fallback. When nothing suitable matches, show nothing. A blank is a valid, desirable outcome, and your layout should handle it without a gap or a filler.
Jolts publisher onboarding covers these same items: eligible categories, frequency, exclusions, shared data, rendering, measurement and no-ad fallback. The principle is simple. No suitable match means no ad.
How to scope a first pilot around the smallest useful payload
Pilot on the lowest rung of the ladder and let evidence, not hope, move you up. A scoped first pilot looks like this:
Pick one surface and one or two categories. Narrow scope makes results readable.
Start with topic and intent only. Rung 1, nothing more.
Write down your exclusions and frequency cap first. Controls come before traffic.
Define success in advance. Match rate, how often the right answer was no ad, user feedback and what the network can count.
Review the misses. Where did a thin request produce no ad or a poor one? Only those cases justify moving to a redacted summary.
Document every field you add and why. If you cannot name the reason, remove it.
Bring this to the first conversation with a network. Jolts begins with a call to confirm audience fit, placement availability, scope and terms, and publisher details such as shared data, revenue share, event counting, fees and payout timing are agreed before going live. A pilot defined around the smallest useful payload gives that call something concrete to review.
Start with the topic label and make every extra field earn its place
The strongest AI ad request data is the smallest set of fields you can defend out loud. Begin with a structured topic, a coarse intent and your own rules, keep prompts and identities in your app, and add detail only when a measured gap names the reason. If you are an AI-app publisher ready to scope that kind of pilot, book a call with Jolts and bring your draft field list, your excluded topics and your frequency cap.