Overview
Each device can be assigned a set of sensors. Each sensor enables a specific behaviour in the platform — for example, the SENSOR_DEMOGRAPHICS sensor lets the device report the live audience it detects.
A device can hold at most one sensor of each type. Sensors that feed the same signal are of the same type, so they are mutually exclusive: a device cannot carry both SENSOR_DEMOGRAPHICS and SENSOR_ADVERTIMA, because both are demographic sensors that drive the seg signal.
A sensor-equipped device can send what it currently detects inline on the /v1alpha2/ads request, so the server selects flights for that live context. There are three independent signals:
| Signal | Parameter | Carries |
|---|---|---|
| Demographics | seg |
The audience the device currently detects. |
| Products | products |
The shopper’s basket for this request. |
| Position | retail_grocery_zone / retail_mall_zone, aisle |
Where the player currently is inside the store. |
The rules below govern all three.
When signals apply
Section titled “When signals apply”These rules hold for every inline signal, whichever parameter carries it:
- Online only. An inline signal with
offline=trueis rejected (400). Offline playlists match audience locally instead (see Matching audience offline). - Replaces stored context. An inline signal replaces the corresponding stored signal for this request. Send it and the request’s context for that facet comes entirely from it; omit it to fall back to whatever was pushed earlier out-of-band via
/adsignals. - Independent per facet. Each signal is orthogonal to the others: send one inline while relying on stored context for another, in any combination.
- Distinct from attribution. Attribution ids are not targeting signals; they follow their own rules and are unaffected by the above (see Basic request).