Event tracking methods
Event tracking methods say how a tracker fires when an ad event happens: as an image pixel or as a JavaScript tag. AdCOM uses the list in the Event object (a buyer's tracker on an ad) and the EventSpec object (methods a placement supports), so it is an OpenRTB 3.0 signal. OpenRTB 2.x carries the same codes inside Native 1.2 eventtrackers, in the native request and response JSON.
Values
| Value | Name | What it means |
|---|---|---|
1 | Image-Pixel | The tracker URL is requested as a 1x1 image when the event occurs. |
2 | JavaScript | The tracker URL is loaded as a script tag when the event occurs, allowing measurement code to run. |
500+ | Vendor-specific codes | Vendor-specific methods, for example a measurement company's own integration. |
How to use it
Placements declare which methods they support for each event type, and buyers should only return trackers in a supported method. A JavaScript tracker can also name the API framework it relies on, such as OMID (API framework 7), through the api field of AdCOM's Event and EventSpec objects. Values 500 and above are vendor-specific and can identify measurement companies with their own integrations. In Native 1.2 the methods field on the request side is an array named methods, while each response tracker carries a single method.
Common mistakes
- Returning a JavaScript tracker to a placement that only declared image pixels. Renderers that cannot execute scripts, which is common on CTV, will drop it.
- Sending a JavaScript URL with method 1. The renderer will load the script as an image and nothing will run.
Validation
On OpenRTB 2.6 snapshots, RTBlint reports a value outside this list as openrtb.value.invalid. Paste a request into the tester to check the values you send.
Related lists
- Display context types
- Display placement types
- Creative subtypes for display
- Native data asset types
- Native image asset types
- Event types
- Click types
- Audit status codes
- Size units
All lists are on the enumerated lists index.