> ## Documentation Index
> Fetch the complete documentation index at: https://conveo.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Event Detection

> Detect predefined behavioural events on a participant's camera or shared screen as they work through a task, then have the AI moderator probe them as follow-up questions once the task is done.

Event detection runs in two clearly separated phases:

1. **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.
2. **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.

<Note>
  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.
</Note>

***

## 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

1. Open your **Topic Guide**.
2. Click an open-ended question to edit it.
3. Open the **Video analysis** dropdown (under the question text).
4. 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     |

If you pick **Screen sharing**, Conveo automatically enables the "Request screen sharing" requirement in the study's [Advanced Settings](/setup-to-launch/detailed-topic-guide-settings) so the participant is prompted to share their screen at the start of the interview.

The source selector shows a red outline until you've picked one — the question can't go live without it.

### 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.    |

Set most events to one of the shallower depths, and reserve **2+ follow-ups** for the one or two events that justify spending interview time.

***

## 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](/setup-to-launch/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).