For digital OOH, we cannot assume that the media being tracked was "always-on", since digital OOH changes the ad being displayed after a certain amount of time. In contrast to static OOH, which is always showing the media we are tracking, we must take into account the time that a particular ad played.

Therefore, in order to properly perform attribution on a campaign with digital OOH, we must receive ad roll logs from each vendor on the plan.

Not Proof of Plays

First, a description of ad roll logs are not. This is not equivalent to proof of play logs. Proof of play logs (POPs) are a common report produced by vendors in order to demonstrate to their customers that the order is being fulfilled. These are generally rolled-up, i.e. aggregated views of the underlying log data. A typical POP might look something like

This tells us how many times the ad roll in a given hour for a given unit. However, it does not tell us the specific times the ad rolled at for each unit. What we need to understand is, for each unit, what the exact time the campaign rolled.

🚧

No Aggregation, Please!

POP logs take underlying log data, group by certain fields such as Unit ID and hour, and report the count of the number of rolls in that period.

Ad logs report the exact time an ad rolled!

Ad Log File Types

There are two methods we use to ingest ad logs: one in which we receive two sets of files (dual files), and one in which we receive a single file.

Dual File

Most vendors operate with this method.

Units File

In one file, we receive a description of the digital units in a plan, similar to how we might receive data for static media. As such, this format is exactly the same as the rectangular file format for static:

• latitude - latitude of the OOH unit
• longitude - longitude of the OOH unit
• unit_id - unique identifier of the OOH unit

Optional fields include:

• facing - direction the unit is facing
• any additional fields to be used in a cut that relate to the unit itself, such as market or format.

Timestamp File

The second file we need is a description of the ad plays. The required fields are:

• timestamp - well-formed timestamp with unambiguous timezone. This usually refers to the start of the ad roll.
• unit_id - unique identifier of the OOH unit. This must match exactly the units provided in the unit file

Additionally, we need one of the following fields:

• duration - duration of the ad roll in seconds. This will be added to the timestamp above to determine the end time; OR
• end_timestamp - the time the ad stopped playing

Finally, any fields additional fields to be used in a cut that relate to the ad roll itself, such as creative_name or media_id, can be included in the timestamp file.

Self-Contained

This is the preferred format. This file is simple the two above files joined into one using the unit ID. As such, the required fields are:

• timestamp - well-formed timestamp with unambiguous timezone. This usually refers to the start of the ad roll.
• latitude - latitude of the OOH unit
• longitude - longitude of the OOH unit
• unit_id - unique identifier of the OOH unit.
• duration or end_timestamp - duration of ad roll in seconds or end timestamp for ad roll.

Optional fields:

• facing - direction the unit is facing
• additional cut fields such as market, format, or media_id

Ad Log Checklist

Operators should request a sample of ad logs from vendors. Here is a quick guide to check samples:

• Ensure there is no aggregation present
  • A tell-tale sign is if there is a computed column like "total plays", or if the time resolution is anything less than second-resolution.
• Ensure timestamp is well-formed, and that the timezone is unambiguous
• Ensure there is an end timestamp, or an ad roll duration field
• Ensure cut fields are present
• Ensure the log covers the entire buy, not a subset of units
  • This usually must be checked by asking the vendor, as the sample might be obtained before the campaign is live