Proposal for Viewability in OpenRTB

Background

Per IAB, a viewable impression requires "a minimum of 50 percent of pixels in view for a minimum of 1 second".

Currently OpenRTB standard doesn’t explicitly address ad viewability.

Viewability at Bidding Time

At the time of bid request, it's unknown if impression will be in view after a second, so there are the following options:

1. Provide historic viewability of the placement. Some exchanges already track this and certain 3d party platforms that perform viewability measurements provide an API to such data. Proposal: add a field in bid request that will provide the historic viewability.
2. Pass "initial viewability", i.e. if the placement at the time of bid request has a minimum of 50 percent of pixels in view. OpenRTB section 5.4 already describes “Ad Position” (esp. “Above the Fold”, “Below the Fold”), but neither OpenRTB standard nor QAG defines what it means exactly (there is no "50% pixels" criteria). Proposal: a "50% pixels" criteria should be added to these definitions.

Actual Viewability (Post-Bid)

Actual viewability can be measured the following ways:

1. Without IFRAMEs: by using JavaScript (can be implemented in ad markup)
2. With IFRAMEs: by implementing IAB SafeFrame (requires exchange and publishers to support it) or by using 3d parties, who employ various browser tricks to understand if IFRAME is visible (can be implemented in ad markup)
3. In apps: can't be obtained directly(?), so the app must explicitly report it

In all cases, the proposal is to:

1. Add a flag in Bid Request that tells if exchange supports viewability tracking on this bid
2. Add pixels in Bid Response that will be explicitly called by the exchange when impression comes into view

Summary of Proposed Changes

Comparing to OpenRTB 2.3:

1. New request object imp.viewability; optional viewability object.
2. New request field imp.viewability.track; integer; optional, default 0; 1 indicates that the exchange supports viewability tracking on this bid, 0 = otherwise.
3. New request object imp.viewability.score[n]; optional array of in-view scores by vendor.
4. New request field imp.viewability.score[n].inview; integer; optional, default "unknown"; Historic viewability of the placement, value between 0 and 100 representing an historical percent of impressions which are in view.
5. New request field imp.viewability.score[n].vendor; string; optional, default "SSP's or publisher's own measurement"; represents the top-level corporate domain (without "www") of the organization responsible for viewability measurement. The goal is to allow for vendor extensibility while ensuring common vendors are represented equivalently across exchanges. Optional, missing value indicates the exchange as technology vendor.
6. Changes to banner.pos and video.pos: extend definitions of above fold or below fold to mean "50% or more" for above fold and "less than 50%" for below fold. Also imp.native currently doesn't have this field, so in future major versions its worth promoting pos from banner / video to imp level.
7. New response field bid.viewtrack[]; array of strings; Array of viewability tracking URLs, expected to return a 1x1 image or 204 response. These URLs are called by exchange once impression becomes viewable (as per IAB definition).

Scoring

An in-view score is an integer value between 0 and 100, defined as the likelihood of the active impression being considered "in view", according to the IAB definition.

Undefined are the details of this calculation, including

• length of the historical time window used to produce an aggregate score
• dimensions on which the score is aggregated, for example page URL, ad slot and ad size.

Examples

Request

{
    "id": "48a6666792dc1ebfb68f8fb16aaa7bb5e6f0cccf",
    "at": 2,
    "tmax": 120,
    "imp": [
        {
            "id": "1",
            "tagid": "30174",
            "viewability": {
             "track": 1,
             "score": [
              {
                "inview": 87,
                "vendor": "integralads.com"
              },
              {
                "inview": 23,
                "vendor": "example.com"
              }
             ]
            },
            "banner": {
                "w": 300,
                "h": 250,
                "pos": 1,
                "battr": [],
                "topframe": 1
            }
        }
    ],
    "site": {
        "id": "12345",
        "name": "Example Site",
        "domain": "example.com",
        "cat": [
            "IAB1-1",
            "IAB1-3"
        ],
        "page": "http://www.example.com/foo?bar=1",
        "publisher": {
            "id": "67890"
        }
    },
    "device": {
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4",
        "ip": "192.168.1.10",
        "geo": {
            "country": "NLD",
            "region": "NB",
            "type": 2
        },
        "language": "en",
        "js": 1,
        "devicetype": 2
    },
    "user": {
        "id": "fe845197532eb8b02a11a1576b12e7957ab7d26f",
        "buyeruid": "2761F376-7D7A-472A-8392-0735FF36F74C"
    }
}

Response

{
    "id": "48a6666792dc1ebfb68f8fb16aaa7bb5e6f0cccf",
    "seatbid": [
        {
            "seat": "731",
            "bid": [
                {
                    "price": 2.250013,
                    "adm": "<script type='javascript' src='http://example.com/dsp/creative?id=12345678&auction=${AUCTION_ID}&price=${AUCTION_PRICE}'></script>",
                    "adomain": [
                        "highbidder.com"
                    ],
                    "crid": "12345678",
                    "dealid": "XYZ-123-456",
                    "id": "1",
                    "impid": "1",
                    "viewtrack": [
                        "http://www.example.com/pixel1/inview?id=48a6666792dc1ebfb68f8fb16aaa7bb5e6f0cccf",
                        "http://www.example.com/pixel2/inview?crid=12345678"
                    ]
                }
            ]
        }
    ]
}

Trust and Fraud

Subject of trust and fraud is outside of scope of this document. DSPs should take additional steps to validate correct use of initial viewability and correct reporting of actual viewability (e.g., doing spot checks or using a 3d party).