Real-Time Signals (for Bid Optimization) Implementation Guide

Overview

You can receive Real-Time Signals (for Bid Optimization) (RTS) on specific events in the browser collected by Integral Ad Science's (IAS) technology. RTS uses piggyback functionality for display and video ads for desktop and mobile web. Additionally, IAS added RTS support for display ads with mobile app. RTS works for both platforms which host the creative, or agencies which deliver the creative.

Piggyback functionality is when IAS calls your piggybacks for specific events which allows you to understand an ad's effectiveness and attribution models to analyze viewable ads.

RTS is sent directly to you using your piggybacks.

*Figure 1 Partner implementation of RTS*

Standard Events

Specifically, RTS is sent for the following ad events for web, mobile web, and mobile app (Display only) environments:

• measurable (Display and Video)

• at least 50 % in view for at least 1 second (Display)

• at least 50 % in view for at least 2 seconds (Video)

• at least 50 % in view for at least 5 seconds (Display and Video)

• at least 50 % in view for at least 15 seconds (Display and Video)

• 100 % in view for any amount of time (Display)

The initial viewability event (at least 1 second for Display, and 2 seconds for Video) only needs one pixel. IAS fires the pixel at the appropriate time.

Custom Events

IAS's Custom Metrics Framework enables you to create more stringent viewability standards, and to receive events when the metrics are met for desktop, mobile web, and mobile app (Display only) environments. You can define a custom metric by percent in view (PIV) and time in view (TIV). You can set the PIV and TIV by creative type and distribution channel (desktop, mobile web, or mobile app). With the Custom Metrics Framework, you can measure up to 30 seconds of TIV.

Note: it is a best practice to include fewer than 10 events per page (which translates to 10 pixels or light-weight functions).

Contact your IAS Client Services manager to define and activate custom viewability metrics.

Piggybacks

You need to provide your IAS Client Services manager with details on your piggyback. Each event triggers a dedicated piggyback.

You have 2 options to format the piggyback pixel:

• URL fired as an image pixel served over HTTPS

• JavaScript function that is fired at event time

Your piggyback can include information specific to the ad event (for example, a user ID, campaign, and placement parameters) passed to IAS by the platform or ad server. In many cases, these parameters allow you to use collected data for analytics and optimization.

Macros

Your piggyback can receive the following data IAS collects as macros. For example, here is a URL and JavaScript sample piggyback which uses 2 macros for the display event of at least 15 seconds in view:

• URL

• JavaScript

URL

JavaScript

The JavaScript function can take a context object as an optional parameter. The object has a property, iasImpId, which is the ad ID:

Product limitations:

• Multiple pixels cannot be fired on the same event.

• 100 % of the piggyback pixels may not fire due to network conditions, user behavior, or browser limitations.

Implementation and Use Cases

RTS is provided in real-time, and allows you to conduct your own performance analysis.

An example use case is if you want to ensure you are only evaluating viewable ads when calculating attribution. You can use RTS so that datasets within the DMP only consists of ads that were in view for more than 1 second.

Agency

In a typical agency-side implementation, the advertiser ad server loads the IAS script tag into the browser. The ad server parameterizes the IAS tag with placement and campaign level identifiers, as well as with other values that the client needs to be passed in the piggyback pixels.

Piggyback pixels are triggered when IAS code makes specific measurements in real time. For example, if the client only needs to register viewable ads, its "viewability" pixel is only sent when IAS measures the ad being in view for a specified length of time (for example, for 1 second).

The main use case for agencies is the ability to join data from multiple sources to IAS viewability metrics.

Platform

In a typical platform side implementation, the IAS monitoring pixel is implemented via the platform's console. The platform client selects a series of "alerts" (viewable 1 second, viewable 5 seconds, measurable, etc.), provides IAS with a pixel for each alert, and specifies the parameters (for example, placement, campaign, ad ID, bid ID, etc.) which should be passed in these pixels.

The main use case for platforms is to return data to a real-time engine so you can optimize towards viewable ads, and for additional analytics purposes.

Implementation Steps

Platform

1) You provide an IAS Client Services manager with pixel tags or URLs.

These pixels should be the ones that platform uses to call their optimization engine (usually segment pixels). Each pixel fires on a specific event (for example, when the ad is determined as being viewable).

2) You need to specify the variables you need to be passed by IAS in the piggyback pixels. Your ad server needs to pass the values of these variables into an IAS pixel by populating the ad server macros. IAS provides you with a campaign monitoring pixel which should be implemented in the platform's console.

3) IAS implements your pixels as piggybacks to the campaign monitoring pixel.

Agencies and Advertisers

1) You provide an IAS Client Services representative with pixel tags, URLs or functions which fires on specific events (for example, when an ad is viewable).

The third-party vendor should provide the pixels that you use to record, log, and store ad data such as their ad server (for example DCM) or their chosen third-party platform.

Below are examples of the client pixel template:

3rd Party Pixel:

DFA Pixel:

2) Tell IAS the variables you need IAS to pass through the piggyback. The ad server must pass the values for these variables into the IAS macros

3) IAS provides you with the pixel, which should be implemented in your ad server (for example DCM). There are two implementation options in DCM (other ad servers provide similar capabilities; please consult an IAS Client Services representative for additional information).

Option 1 (HTML): Place the full HTML as a custom creative HTML tracker in DFA/DCM.

Option 2 (JavaScript URL only): Place just the URL in a JavaScript-capable tracking slot in DFA/DCM (such as JavaScript tracker, or Survey URL).

4) IAS integrates your pixels as piggybacks to the Campaign Monitoring or the Open Web pixel.

RTS Testing

To ensure accuracy and uniformity in piggybacks firing, IAS requires you to commit to a testing phase for each new piggyback pixel.

There are 2 points of process in testing.

1) Initial testing using a test page you provide to ensure the implementation is successful. Testing assesses:

a) Functionality of reading parameters from pixel implemented and populating macros.

b) Functionality of piggybacks loading into the browser.

c) Functionality of piggybacks firing from the browser on specific/desired event.

2) Testing over a period of time (recommended 3 days) to ensure piggybacks are firing consistently on desired events.

You must provide an IAS Client Service manager with a report comparing daily aggregated count of piggyback calls you received for each event compared with expected number of calls as reported through the pixel.

The expectation is the piggyback pixel call counts match within 10 % of the parent pixel count on the event on desktop and 20 % on mobile web environments. You will work with the IAS Client Services manager to analyze if the test failure is due to something specific to the users in the test, or if the error is a network issue causing a high discrepancy. The Client Services manager will decide if it is viable for you to use RTS.

For example, here's a report for piggyback configured to fire on viewability: