The Problem with Bringing Standard Ad Tech into AI Chat
When publishers first start thinking about monetizing their AI assistant products, the instinct is often to reach for the same toolchain they already use: load a header bidding library, drop in a third-party demand partner, and run the same data collection pipeline that powers their display inventory. It is the path of least resistance, and on a traditional web property it is entirely reasonable.
AI chat is different in ways that matter for privacy. Conversations carry sensitive content that a page URL never would. A user might ask their health information assistant about symptoms, their financial assistant about debt levels, or their mental health chatbot about anxiety. The content of those conversations is genuinely sensitive. Building an advertising layer on top of a system that stores or shares chat content, even anonymized, creates real compliance exposure for publishers and a legitimate trust problem with users.
We built Velocity to not do that. This post explains exactly what that means in technical and legal terms, and what it means practically for publishers evaluating compliance obligations.
What Velocity Does Not Store
Velocity does not log or store the content of conversation turns. The text of what a user asked and what the assistant responded is processed in memory to compute a relevance signal, and then discarded. We do not write it to a database, we do not send it to a third-party analytics endpoint, and we do not use it to build user profiles.
This is a design constraint, not just a policy. The Velocity SDK receives the conversation turn content, runs it through the contextual matching pipeline, receives a matched ad or a no-fill response, and that is the end of the data's lifecycle on our side. What remains in our system is an anonymized impression record: a timestamp, a topic category classification, an intent score, and an ad ID. No user identifier is attached. No conversation text is retained.
Publishers should verify this themselves rather than taking our word for it. Our data processing addendum (available to Platform tier publishers) describes exactly what data we receive, what we process, and what we retain. For publishers who need to complete a Data Protection Impact Assessment under GDPR or a risk review under CCPA, that document is the starting point.
Contextual Targeting vs. Behavioral Targeting: A Compliance Distinction
From a privacy law standpoint, contextual advertising and behavioral advertising sit in fundamentally different regulatory positions. The contextual targeting approach is also why Velocity's matching produces higher-quality signals than keyword-based alternatives. Behavioral advertising, which relies on tracking user activity over time across sessions and sites to build targeting profiles, requires consent in the EU under GDPR and falls within the definition of "sale" or "sharing" of personal information under CCPA in California. That is why the consent banner industry exists.
Contextual advertising, which targets based only on the content of the current page or session rather than tracked user history, does not require the same consent mechanisms in most jurisdictions. The IAB's technical standards distinguish between the two, and most privacy counsel we have spoken with treat in-session contextual targeting as operating outside the GDPR consent requirement for behavioral targeting specifically.
This does not mean contextual advertising is regulation-free. Publishers still need to disclose in their privacy policy that they use contextual advertising. The ads still need to be labeled as sponsored. And in some highly sensitive topic categories, contextual advertising may raise other issues even without behavioral tracking. A publisher running an AI assistant for a medical information service should consult their own legal counsel about how advertising in that context interacts with applicable health privacy laws, which sit in a different regulatory lane than general privacy law.
We are not saying Velocity eliminates all compliance work for publishers. What we are saying is that the compliance footprint of contextual-only advertising is substantially smaller and better defined than that of behavioral advertising. Publishers who have spent years dealing with consent management platform complexity will find that part of the stack is not needed here.
How the Ad Label Requirement Works
Every ad inserted through Velocity is labeled. The FTC's guidance on native advertising requires clear and conspicuous disclosure when sponsored content appears alongside editorial content. In a chat interface, "clear and conspicuous" means the sponsored label needs to be visible before the user reads the ad content, not in 8px gray text below it.
Our default sponsored card format puts the label as the first element, in 11px Manrope at a contrast ratio that exceeds WCAG AA. Publishers cannot remove or reposition it. They can adjust the styling slightly within the bounds we define: font color, card background, border style. The word "Sponsored" or "Sponsored by [advertiser name]" must appear and must be visually prominent.
This is one area where publisher control is deliberately limited. We think that trade-off is correct. A publisher who made the label hard to see might boost short-term click rates. They would also be in violation of FTC guidance and would be eroding exactly the kind of reader trust that makes their assistant worth using. We built the constraint into the SDK rather than making it a configuration option because optional compliance tends to drift.
Publisher Controls That Do Exist
Where we do give publishers significant control is in what categories of advertising can appear in their product. Publishers configure topic category exclusions that prevent ads from certain IAB taxonomy categories from ever being matched against their conversation turns. A publisher who runs an educational assistant for a children's audience can exclude all commercial advertising categories that are inappropriate for that context. A publisher with a mental health focus can exclude advertising categories that would be tactless against queries about anxiety or depression.
Category exclusions are configured in the publisher dashboard and apply globally to that publisher's integration. There is no per-turn override at the user level. This is intentional: per-turn user-level controls would require user data collection to implement correctly, which brings us back to the privacy tradeoffs we designed to avoid.
Why This Design Made Sense for an Early Team
We are honest that part of why we built Velocity this way is that we were a small team building from the ground up, and building a compliant-by-default system from scratch is considerably easier than bolting privacy controls onto an existing behavioral data pipeline. Constraints that feel limiting at first often produce cleaner architecture. Not storing conversation content meant we never built the infrastructure to store it, which means there is nothing to breach and nothing to audit for sensitive data exposure.
The result is a system that publishers in regulated industries can integrate without a legal review that takes longer than the technical integration. That was a deliberate design goal, not a happy accident. For publishers thinking about adding conversational advertising, the compliance story should be a factor alongside the revenue potential. We think those two things are more compatible here than the existing ad tech landscape might suggest.
