Scanner prompts

These prompts create Replay Vision scanners that follow the best practices from What we learned from our first 400k Replay Vision scans. Read the post to learn why each prompt is written this way.

Paste a prompt into PostHog AI or a coding agent connected to the PostHog MCP, or use the link below it. Replace the values in square brackets first. The agent inspects your project and creates the scanner.

Writing a prompt of your own? See what every scan already does so you don't spend words on it, and write prompts that work with it.

Map the use cases people bring to a product

text
set up a Replay Vision scanner that maps the use cases people bring to [product or feature] in this PostHog project.

first inspect the project's real events, urls, cohorts, and existing scanners. find the strongest high-intent event or page that proves someone used this product surface. do not invent an event name. exclude PostHog employees and test accounts where the project data supports that filter.

create a single-label classifier. each observation must classify one recording by the primary job visible in that session. draft 5 to 8 initial use-case tags from the product's real workflows. include exploring_only and inconclusive. allow one free-form tag only when the recording clearly shows a use case outside the initial taxonomy.

write the scanner prompt so it uses concrete evidence: the objects the user created, settings they changed, queries they wrote, filters they applied, and workflows they returned to. navigation alone does not prove intent. if the session contains several jobs, choose the dominant one. if the evidence is weak, choose inconclusive. require a short explanation with citations.

add a daily Digest that summarizes the use-case mix, recurring evidence, and genuinely new free-form tags across observations. the scanner must not compare sessions itself.

before enabling the scanner, estimate its monthly observation volume and credit use. check the remaining quota. if the estimate is material, create it paused and show me the estimate. otherwise create it, return its link, and tell me which first observations I should rate.

Set up the use-case scanner in PostHog AI

Compare behavior across experiment variants

text
set up Replay Vision for the experiment [experiment name or id] in this PostHog project.

first resolve the exact experiment. read its hypothesis, feature flag key, variants, exposure event, and the product surface that changes. if the experiment is ambiguous or has no usable hypothesis, ask me instead of inferring one from the name.

create one single-label classifier for all variants so every recording uses the same rubric. target recordings containing the $experiment_exposure event for the experiment's exact feature flag key and active variant values. exclude test accounts. do not create separate scanner prompts for each variant.

tailor the tags to the hypothesis. if the hypothesis does not imply a better rubric, start with: never_reached_changed_surface, completed_smoothly, completed_with_hesitation, confused_or_backtracked, error_or_dead_end, and inconclusive.

write the scanner prompt for one recording. it must ignore behavior before exposure, decide whether the user reached the changed surface, choose one tag from visible post-exposure behavior, and cite the decisive moments. it must not guess the variant, compare variants, infer causality, or generalize from the recording.

use the same model and prompt for every variant. use a mid-priced model for a clear fixed-tag rubric. move up a tier only if the hypothesis requires nuanced judgment from each recording.

test the scanner against representative recordings from every variant. then add a daily Digest that synthesizes the observation patterns. keep all cross-observation and cross-variant comparison in the Digest, a Scout, or product analytics, never in the scanner prompt.

before enabling the scanner, estimate its monthly observation volume and credit use. check the remaining quota. if the estimate is material, create it paused and show me the estimate. otherwise create it and return the scanner and Digest links.

Set up the experiment scanner in PostHog AI

Find product improvement ideas

text
set up a Replay Vision scanner that finds concrete product opportunities in [product or workflow] in this PostHog project.

inspect the real events, urls, cohorts, and existing scanners for this product. choose a recording query that requires substantive work, not a page visit alone. prefer one high-intent event plus the relevant product url and a minimum active duration. exclude employees and test accounts.

create a monitor that judges one recording at a time. allow inconclusive. return yes only when all three conditions are visible:
1. the user did substantive work in the target product.
2. their action sequence revealed an unmet higher-level job, repeated manual workaround, or missing decision loop.
3. one small product test follows directly from that evidence and could help similar users.

for a yes result, require four labeled parts: Evidence with timestamps, Unmet job, Smallest test, and Alternative explanation. ordinary friction, brief browsing, and generic "add AI" ideas are no. hidden or ambiguous decisive actions are inconclusive. do not include names, emails, ids, or verbatim sensitive content.

use a high-quality model because a person may act on one yes result. add a daily Digest that groups repeated unmet jobs and smallest tests across observations with links to the source recordings.

before enabling the scanner, estimate its monthly observation volume and credit use. check the remaining quota. if the estimate is material, create it paused and show me the estimate. otherwise create it, return its link, and identify the first observations I should rate.

Set up the product-opportunity scanner in PostHog AI

Find self-contradictions and dead ends

text
set up a Replay Vision monitor for self-contradictions and dead ends in [product surface] in this PostHog project.

inspect the real product urls and high-intent events. target recordings that used this surface and contain enough active time to show both halves of a problem. exclude employees and test accounts where appropriate.

the scanner watches one recording. allow inconclusive. return yes only when the recording visibly shows both halves of one contradiction or dead end. examples include:
- a control claims to enable something, but a later screen says it is disabled.
- the product advances as if an action succeeded, but a later step shows nothing was saved.
- the final submit reveals a blocking requirement that the preceding flow never mentioned.
- an error points to a fix or setting that does not exist where the product sends the user.
- a control sends the user away from the flow it asked them to finish.

for a yes result, require the user's task, the first visible claim or label, the contradicting behavior, citations to both moments, and whether the user recovered, retried, hunted through settings, or abandoned.

ordinary validation errors, user mistakes they immediately correct, slowness, styling problems, missing features, and browsing are no. if either half is hidden, return inconclusive.

use a high-quality model. a small yes pile is better than broad coverage. add a daily Digest or alert for yes observations.

before enabling the scanner, estimate its monthly observation volume and credit use. check the remaining quota. if the estimate is material, create it paused and show me the estimate. otherwise create it and return its link.

Set up the contradiction scanner in PostHog AI

Review sessions before low-NPS responses

text
set up a retrospective Replay Vision workflow for low-NPS responses to [survey name or id] in this PostHog project.

first resolve the exact survey and its NPS question. find responses in [score range] during [date range], including each response timestamp and person. for each respondent, select up to [n] eligible session recordings that ended before the response. do not substitute sessions after the response.

create a paused summarizer scanner. run it separately against each selected recording so every observation describes one session. the per-recording prompt should return these labeled lines:
- Journey: the main workflow visible in this recording.
- Friction: the strongest visible slowdown, error, dead end, or repeated hunting.
- Outcome: what the user completed, abandoned, or left unresolved.
- Evidence: citations to the decisive moments.

the scanner must not infer sentiment from the NPS score, explain why the person chose it, compare sessions, or claim that visible friction caused the response. if a recording is too short or inactive, say inconclusive.

after the observations finish, use a Digest or Scout to synthesize repeated workflows and friction across the pre-response recordings. preserve links to the source observations. keep the individual score, response, and cross-session comparison outside the scanner prompt.

before running scans, estimate the credit use for the selected sessions and check the remaining quota. return the scanner link, the number of selected recordings, and any respondents with no eligible pre-response recording.

Set up the low-NPS review in PostHog AI

Watch the first sessions from high-ICP signups

text
set up a Replay Vision scanner for the first sessions of high-ICP signups in this PostHog project.

inspect the project's canonical signup event and the real cohort or group property that defines high ICP. do not assume the event or property name. target the recording containing signup for people in that cohort. exclude employees and test accounts.

create a summarizer because each observation should reconstruct one first-session journey. require these labeled lines:
- Journey: the path from signup through product selection and setup.
- Product evaluated: the product or workflow supported by visible evidence.
- Friction: the single strongest blocker or slowdown, naming the exact screen, control, field, docs page, or error.
- Outcome: the last meaningful state reached, including whether data arrived or a real workflow completed.
- Evidence: citations to the decisive moments.

the scanner must use visible evidence and say inconclusive when the session is too short or inactive. it must not compare people, infer account value from behavior, or treat every departure as failure.

add a daily Digest that summarizes repeated entry paths, evaluated products, blockers, and outcomes across observations.

before enabling the scanner, estimate its monthly observation volume and credit use. check the remaining quota. if the estimate is material, create it paused and show me the estimate. otherwise create it and return its link.

Set up the high-ICP scanner in PostHog AI

Ask a coding agent to design scanners

text
read this blog post: https://posthog.com/blog/a-scanner-that-watches-everything-sees-nothing. then inspect our product code, PostHog event schema, cohorts, recordings, and existing Replay Vision scanners.

propose five scanners grounded in what this product actually does. each proposal must include:
- one visible question applied to one recording.
- the scanner type and why it matches the output.
- a narrow recording query using real events, urls, cohorts, and duration filters.
- the exact per-recording output shape, including no or inconclusive behavior.
- the model, sampling mode, and estimated monthly observations and credits.
- the cross-observation question for its Digest or Scout.
- the first observations a human should rate.

reject ideas that require one scanner observation to compare sessions, infer hidden intent, or discover what matters without a product question. do not invent event names.

rank the five ideas by expected product value and evidence quality. recommend one. do not create anything until I choose.

after I choose, estimate the scanner against the remaining quota, create it safely, test it against representative recordings, add an appropriate Digest or alert, and return the links.

Design scanners with PostHog AI

What every scan already does

PostHog wraps your prompt in instructions every scan follows, whatever the scanner type. Your prompt doesn't need to repeat them:

Evidence first. Every claim rests on a moment in the video or an analytics event. Where the two disagree, the events win, because the replay can show things the user never saw. When the recording ends before something finishes, the scan says the outcome is unknown instead of guessing.
Recording limits. Masked content, content that wasn't recorded (canvas drawings, embedded pages from other sites, video playback), and quirks of rebuilding a page from snapshots are treated as limits of the recording, not bugs. Unrecorded iframes and canvases show in the video as a striped box labeled "not recorded". The scan judges them from events, requests, and what the user does next.
Normal use. Repeated clicks on a control that responds, reading or idling, waits that end, validation messages, and paywalls count as normal use, unless the user gets stuck. When your question is about one of these, such as slow loads, your prompt decides instead.
Privacy. Answers never include personal data – names, emails, phone numbers, addresses, IDs – about the user or anyone else.
Off-topic sessions. When a recording never reaches what your prompt asks about, the scan says so and keeps its confidence low instead of stretching an unrelated part of the session to fit.
Notability. Separately from your question, every scan rates how worth watching the session is, and What to watch uses it. You don't need to ask a scanner to flag interesting sessions.
Citations. Answers cite key moments as timestamps you can click to seek the recording.

Write prompts that work with it

Name the signals that decide the answer. After watching the video, a scan gets one round of lookups: it picks the stretches of the video it wants analytics events for, then answers. A monitor only answers yes when the events back up at least one moment. Naming what decides the answer – the error message, the submit click, your order_completed event – helps it look in the right places.
Give the question a direction. PostHog condenses your prompt into one question, shown on every observation, and judges whether a yes or a high score is good or bad news, so it can color results green or red. A prompt that asks about one outcome ("Did the user complete checkout?") gets a clear direction. For a scorer whose scale names a problem, such as frustration or friction, a high score counts as bad.
Ask for identity only when you need it. If your question needs to know who the session belongs to, ask for that explicitly. The scan then names the person from your project's person and group records, never from what's on screen, and keeps everyone else's data out. If an answer includes personal data the question didn't ask for, PostHog has it rewritten without that data, and fails the scan if the rewrite still has it. See troubleshooting.
Record network requests to tell broken from slow. A failed request and a slow one look the same on video. With network recording on, scans can also look up the failed and slow requests around a moment, so a prompt about errors or stalled pages can tell them apart.
Record what your users see. Scans can only judge what the recording captured. If your product draws key screens on a canvas or inside an iframe, turn on canvas recording or iframe recording so the recording holds something for the scan to see.
Describe your product and your events. Scans read PostHog AI memory as background on what your product does, and the descriptions you give your custom events on the events management page. Both help the model read your product's screens and events correctly.
Say where your product differs from the defaults. Repeating the built-in rules adds nothing. Telling the scan what is normal in your product does, for example "the map on the search page is drawn on a canvas, so a gray map area alone is not an error".
Keep rating results. Ratings and notes teach each scanner rules that sharpen how it applies your prompt. See improving scanners with ratings.