Event detection runs in two clearly separated phases:
- During the task — silent observation. The moderator stays out of the way while the participant works. Frames from their camera or shared screen are analysed in the background and any events you defined are logged. No probes are asked while the task is in progress — this is deliberate, so the participant’s natural behaviour isn’t biased by mid-task interruptions.
- After the task — follow-up probing. Once the participant signals they’re done (their first response after the task — typically “I’m finished” or a summary), the moderator runs through the events it observed one at a time, asking a reflective follow-up about each at the depth you chose. When all events have been probed, the question completes.
Use event detection for usability tests, prototype walkthroughs, shop-along studies (online browsing or in-store mobile-camera shopping), in-home product use — any situation where the what and the when of a participant’s behaviour matters more than what they remember to mention afterwards.
Event detection is currently in pilot and available to selected organizations. If you don’t see the Event detection option in the question editor, it isn’t enabled for your workspace yet — reach out to your Conveo contact.
When to use it
Event detection is for open-ended task questions where you want the AI moderator to react to specific observed behaviours, rather than relying only on what the participant chooses to mention afterwards:
- Online shop-along. “Browse [retailer] and pick a pair of trainers you’d actually buy.” — watch for
user opens a filter, user adds an item to the cart, user compares two products, user abandons the flow.
- In-store shop-along. “Walk through the store with your phone camera and pick out a snack for tonight.” — watch for
user picks up a product, user reads the back of the pack, user puts a product back on the shelf, user moves to a different aisle.
- App / prototype usability. “Try to set up a recurring transfer in the app.” — watch for
user opens the transfers menu, user toggles the recurring option, user backtracks.
- In-home product use. “Make a coffee with this machine.” — watch for
user inserts a pod, user presses the brew button, user spills.
It is not a replacement for the question’s transcript or the moderator’s normal probing — it adds another signal source on top of them.
Turning it on for a question
- Open your Topic Guide.
- Click an open-ended question to edit it.
- Open the Video analysis dropdown (under the question text).
- Choose Event detection.
A panel appears under the question with two sections: Source and Events to look for.
Picking a source
Each event-detection question analyses one source — either the participant’s camera or their shared screen, never both:
| Source | What it sees | Typical use |
|---|
| Camera | The participant’s webcam or phone camera | In-home product use, physical tasks, anything off-screen |
| Screen sharing | The window or tab the participant is sharing | App walkthroughs, prototype tests, website usability |
Listing events
Click Add event to add one row per behaviour you want to detect. For each row:
- Description — a short, plain sentence describing what should be visible. “user adds an item to the cart”, “user opens the filter menu”, “user closes the app”. Use at least 5 characters; up to 200.
- Probing depth — how much the moderator should probe when this event happens.
You can list up to 10 events per question. Click the trash icon on a row to remove it.
When everything is filled in and prompts have generated, the status pill in the top-right of the panel switches to Active.
Probing depth, per event
Each event has its own follow-up budget for the post-task probing phase. Use shallower depths for events you just want logged, deeper ones for the moments you really care about:
| Depth | Use when |
|---|
| No follow-up questions | You want the event tracked but skipped during probing. |
| 0–1 follow-ups | A quick “what just happened?” is enough. |
| 1–2 follow-ups | Worth a short follow-up exchange. |
| 2+ follow-ups | This is one of the moments the whole study hinges on. |
| Automatic probing | Let the moderator judge per event based on context. |
What the participant sees
The participant doesn’t see the event list, and they don’t get interrupted during the task. The moderator reads the question and then stays silent while the participant works through it — no live commentary, no in-the-moment probes on detected events. They just get on with the task while frames are analysed in the background.
The probing only starts once the participant gives their first response after the task — typically “I’m done”, “OK that’s it”, or a quick summary of what they did. At that point the moderator works through the observed events one at a time, framing each as a reflective follow-up — “I noticed you spent a while in the filter menu — what were you looking for there?” Each event is asked about separately, at the depth you chose. When all events have been probed (or skipped because their depth was “no follow-up”), the question completes and the interview moves on.
For screen-sharing questions, the participant is prompted to share a window or tab at the start of the interview (the same way as any screen-recorded study). For in-store shop-alongs, the participant uses their phone camera and is expected to hold it so the shelves and products they’re looking at are visible.
Tips
- Describe what’s visible, not what’s intended. “user opens the filter menu” works; “user is confused by the filter menu” doesn’t — the AI sees pixels, not intent.
- One observable thing per event. Splitting “adds item and goes to checkout” into two events gives the moderator two distinct moments to probe.
- Be specific about UI labels and physical objects. “user clicks the green Continue button” is easier to detect reliably than “user proceeds”.
- Don’t list 10 events if you only care about 3. Every event you add competes for the moderator’s attention and inflates the probing budget.
- Test it. Walk through the task yourself with Testing your study before launching — if your own events don’t reliably trigger, the descriptions need tightening or the source is wrong (e.g. you described an on-screen action but picked the camera source).
