How Conversaic works
The runtime accepts publisher context, evaluates whether a recommendation should appear, returns a placement payload when allowed, and records downstream events for attribution.
Request lifecycle
1. Context
Publisher sends prompt, topic, placement key, language, and optional geography.
2. Decision
Runtime checks intent, offer eligibility, publisher policy, and sensitive contexts.
3. Response
API returns a placement payload or a no-placement result.
4. Events
Frontend reports impression and click events only when the placement renders.
Decision stages
| Stage | Checks | Possible result |
|---|---|---|
| Intent | Does the prompt contain a useful recommendation moment? | Continue or return no placement. |
| Offer | Is there an active offer for the topic, geography, and language? | Select candidate or return no placement. |
| Policy | Does publisher policy allow this category and surface? | Allow or suppress. |
| Payload | Can the selected offer render with a visible label? | Return payload or suppress. |
| Tracking | Are placement and offer identifiers available? | Trackable placement or launch block. |
Response types
Placement payload
Returned when the request is commercially relevant, an eligible offer exists, policy allows the surface, and the placement can be labeled.
No-placement response
Returned when the match is weak, the context is sensitive, the offer pool has no safe candidate, or publisher rules block the surface.
Publisher rendering rule
| API result | UI behavior |
|---|---|
| Placement payload | Render the card, show the disclosure label, then report impression. |
| No placement | Leave the answer flow unchanged. Do not show an empty sponsor frame. |
| Tracking metadata missing | Do not render the placement in production. |
| Blocked category | Suppress the surface even if a commercial offer exists. |
No-placement is not an error. It is the expected response whenever Conversaic cannot produce a relevant and policy-approved recommendation.