Sponsored Answer Units for Assistant and Chat Surfaces

What you are buying is the decision about when the unit fires, not the sentence inside it. On assistant surfaces, a sponsored card that appears on more than roughly one in twenty conversational turns gets dismissed hard enough that the publisher pulls the format within a quarter, and the advertiser is left with a case study nobody can repeat. So the first artefact I hand over is a trigger taxonomy: the intent clusters where a sponsored answer is genuinely the better answer, and the much larger set where it is interference. Surfaces this covers: Sponsored follow-up and answer slots on general assistants, retail assistants of the Rufus type, vertical copilots inside SaaS products, developer assistants, and the in-product assistant you own yourself. The last of these is where most of my work sits, because you control the retrieval layer and can implement a trigger rule instead of negotiating for one. The unit specification: A response contract, written as JSON schema, that the surface renders rather than paraphrases: headline, one evidence line with a figure in it, one line of scope, disclosure string, and a signed click URL carrying campaign, session and position. Fields are length-capped so the unit cannot expand into the answer, and the schema forbids the model rewriting the claim line. A rewritten claim is a compliance incident, not a creative variation. Trigger design: Intent clusters are defined against a labelled prompt set drawn from the surface's own logs where you have them, and constructed where you do not. Each cluster gets a fire rule, a suppression rule and a position. Suppression matters more than firing: queries showing distress, a competitor already named by the user, a support intent, or a regulated question all suppress. Disclosure: Labelled to FTC 16 CFR Part 255 for US traffic and Article 26 of the DSA for EU users, in the same weight and size as body text, above the claim rather than beneath it. If your legal team wants the disclosure smaller, I am the wrong person for the project. Evaluation before launch: A prompt set of several hundred queries per cluster, run against the live surface and scored on three axes: does the unit read as an answer, does it fire where it should, does it fire where it should not. Model version changes are treated as a release and the same set is re-run, because a provider swapping the underlying model changes the response distribution without telling you. Measurement: No third-party cookie exists here and no viewability vendor measures it. Impressions come from the surface's server logs, clicks from your endpoint via signed parameters, and the two are reconciled daily. A gap over about two percent is a bug or a bot, and I will stop the campaign to find out which. What I do not do: I do not write content whose purpose is to get a model to recommend a product without a disclosure. I do not design units meant to be indistinguishable from organic answers; that is the thing that gets the format banned for everyone. I do not take on health or credit claims unless your counsel signs the claim line in writing before it ships. Who this is not for: Teams with no engineering access to the surface, and advertisers whose only reported number is impressions. If the buy is being judged on reach, a display network gives you more of it for less money and you should go there instead. How it runs: Four to six weeks. Week one is the prompt corpus and cluster labelling, week two the schema and copy, weeks three and four evaluation and revisions with your surface team, then launch supervision through the first fortnight of live traffic.