Guides
Beacons
Beacons record impressions, clicks, and other ad events. Serving responses include signed tracking URLs for your player or application to call when each event occurs. Impression events determine billable delivery; duplicate events are counted once.
URL format
Connect beacons after your player or renderer can show an ad. They let delivery reports distinguish a returned ad from an impression, playback milestone or click that actually occurred. The URLs below illustrate the format; your application must use the signed URLs from its own serving response.
https://events.acme.example/impression?e=<sealed payload>
https://events.acme.example/complete?e=<sealed payload>
https://events.acme.example/error?e=<sealed payload>&code=[ERRORCODE]The path identifies the event. The serving cell signs the payload for that decision, and the beacon service verifies it with the tenant's key. Use the URL exactly as returned. Send a GET when the event occurs; the response is a 1×1 pixel or an empty HTTP 200. A VAST player handles these calls, while OpenRTB wrappers and Decision API integrations must send the events they observe.
| Kind | When it fires |
|---|---|
impression | Records billable delivery when the ad is shown. Repeated calls with the same key are counted once. |
start, firstquartile, midpoint, thirdquartile, complete | Video progress; the VAST document carries them as Tracking events. |
click | Records a click through ClickTracking or click_url. The creative’s landing-page URL opens the destination. |
nurl, burl | OpenRTB win and billing notices when a buyer's bid wins; the platform fires them, a wrapper does not. |
error | The VAST Error URL with the [ERRORCODE] macro; feeds the error-rate diagnostics. |
breakstart, breakend | Ad-pod boundaries for server-side pods. |
stitched_impression | The impression as seen by a stitching (SSAI) session. |
viewable, not_viewable | Viewability outcomes from the player or a verification vendor. |
player_skip | The viewer skipped the ad. |
companion_view | A companion ad was displayed (once per companion). |
Idempotency and timing
Each event has a stable key derived from the decision and event kind, so duplicate player callbacks count once. The tenant and placement settings determine the delivery window. Events received after that window are recorded but are not billed. Accepted events update delivery reports, live counters, and the decision funnel.
Conversions and user sync
The same service hosts /conversion (attribution from your site or app, also available in bulk
through the admin API's conversion ingest) and the user-sync pair /sync and
/setuid, gated by the privacy signals the request carried.
Connect delivery notifications
Use webhooks to send recorded delivery events to another application. The measurement guide explains how to compare player events with reports.