Closing the Loop: MediaGuard + FraudSensor

Like any dynamic duo, MediaGuard and FraudSensor work better together—learn how to harness their combined power.

Closing the Loop: MediaGuard + FraudSensor

Like any dynamic duo, MediaGuard and FraudSensor work better together—learn how to harness their combined power.

FraudSensor is used to determine whether or not an Ad is served to a bot or a human. That data is then generalized into a reputation database which is used to retrain the MediaGuard model every 4 hours. MediaGuard will allow .5% of traffic flagged as SIVT through so that it can be rescanned by FraudSensor to ensure that MediaGuard is making the correct prediction. MediaGuard will also allow bot traffic flagged as GIVT through at a rate of .05%. Bypassing on GIVT records does provide MediaGuard and FraudSensor with specific value.

The only difference between a GIVT bot and an SIVT bot is self-declaration. If a known crawler were to stop self-declaring, the bypass method we have in place dramatically increases the chances that pre-bid MediaGuard will be able to flag it as SIVT quickly.
The bypassed record ensures that IVT techniques are in-place other than IAB Bots and Spiders UA violations.
The post-bid records that have IVT flagging on them identify correlations across a large number of pre-bid features (IP, UA, publisher, supply chain, etc.). For example, a small number of known crawler traffic proceeds to post-bid Fraudsensor, and is identified as having Automated Browsing traffic on it, now MediaGuard will be more likely to flag that IP address or other pre-bid features as IVT.

MediaGuard and FraudSensor are designed to work together. By comparing MediaGuard’s pre-bid predictions with FraudSensor’s post-bid detection and analysis, HUMAN can create a “closed-loop” ecosystem with data that’s richer than the sum of its parts.

The benefits of closing the loop are twofold: not only does this ecosystem provide you with a more complete picture of the ad inventory that you bid on and the impressions that you serve, it also helps us here at HUMAN verify that MediaGuard’s predictions are accurate and lets us continually refine our detection models to identify sophisticated invalid traffic.

Components

A combined MediaGuard + FraudSensor integration has three distinct components. All three of these components work together: MediaGuard’s pre-bid component helps you decide whether to bid on the ad inventory offered in a particular bid request, and FraudSensor’s two post-bid components provide you with more information about the ad impressions that follow.

A MediaGuard integration (pre-bid): Every time you receive a bid request, you should send the details of this bid request to MediaGuard. MediaGuard will return our prediction of whether the bid request is a form of invalid traffic. Based on this response, you can then choose to bid (or not bid) on the ad inventory being sold.
FraudSensor’s detection tag (post-bid): If you make a bid on the ad inventory and win, you’ll need to serve a detection tag alongside the ensuing ad impression. This detection tag is a lightweight code snippet that collects the signals that power FraudSensor’s post-bid IVT analysis.
An Impression Sync integration (post-bid): Optionally, for every detection tag you serve, you can either make a separate postback call to HUMAN or share information about the associated impressions via Snowflake. This Impression Sync data helps us identify any fraudsters who try to evade our detection tags.

Since you may not bid on (or win) every bid request you receive, not every prediction returned by MediaGuard will have a corresponding ad impression. In these cases, you won’t need to serve a detection tag or make an Impression Sync call, which also means you won’t need to close the loop for those bid requests—you can’t close the loop if FraudSensor never recorded an impression in the first place!

How to close the loop

After you’ve set up the necessary components, you’ll still need to create a link between your MediaGuard and FraudSensor integrations. This link is what enables us to join your pre-bid MediaGuard data and your post-bid FraudSensor data.

MediaGuard and FraudSensor won’t automatically share data with each other. To close the loop between them, you must follow the instructions outlined here.

Prediction ID (pv)

Whenever you send the details of a bid request to MediaGuard (either via the MediaGuard API or the MediaGuard SDK), MediaGuard’s response will include a field called lookupId. Since MediaGuard assigns a unique lookupId value to each incoming bid request, we can use this field to close the loop between MediaGuard data and FraudSensor data.

To link a bid request with its corresponding ad impression, you’ll need to take the value of MediaGuard’s lookupId field and feed it back through FraudSensor’s detection tag as the Prediction ID (pv) tag parameter.

If your MediaGuard integration is built on the MediaGuard API, lookupId will return a UUID string, which you can pass to FraudSensor’s detection tag without any additional steps.

If your MediaGuard integration is built on the MediaGuard SDK, lookupId will return a base64-encoded raw byte value. You must convert this raw byte value to a UUID string, then pass the resulting UUID string to FraudSensor’s detection tag.

For example, if the MediaGuard API returns "lookupId": "d2260bd4-4d81-11e8-88da-600308952712" for a particular bid request, you must include pv=d2260bd4-4d81-11e8-88da-600308952712 in the detection tag served alongside the ensuing ad impression. If the MediaGuard SDK returns "lookupId": "gUpKy2IcRPyqzwAApkz3xA" for a particular bid request, you must convert this value to a UUID string, then include pv=814a4acb-621c-44fc-aacf-a64cf7c4 in the detection tag served alongside the ensuing ad impression.

Prediction Timeout (to)

Additionally, you’ll need to send information about MediaGuard’s behavior to FraudSensor via the Prediction Timeout (to) detection tag parameter. This field helps us measure and troubleshoot MediaGuard’s performance.

Prediction Timeout is an integer with possible values between 0 and 4. For each ad impression you serve, you must configure the Prediction Timeout tag parameter to match the value that describes how MediaGuard interacted with the impression’s corresponding bid request:

(0) N/A: You didn’t send the impression’s corresponding bid request to MediaGuard, so MediaGuard didn’t have an opportunity to make an IVT prediction.
(1) Timeout: You sent the impression’s corresponding bid request to MediaGuard, but MediaGuard timed out without responding.
(2) Error response: You sent the impression’s corresponding bid request to MediaGuard, but MediaGuard responded with an error.
(3) Successful response: You sent the impression’s corresponding bid request to MediaGuard, and MediaGuard successfully returned an IVT prediction.
(4) Other: Any other interaction not covered by the above categories.

For more information, see Prediction Timeout (to).

The only difference between a GIVT bot and an SIVT bot is self-declaration. If a known crawler were to stop self-declaring, the bypass method we have in place dramatically increases the chances that pre-bid MediaGuard will be able to flag it as SIVT quickly.
The bypassed record ensures that IVT techniques are in-place other than IAB Bots and Spiders UA violations.
The post-bid records that have IVT flagging on them identify correlations across a large number of pre-bid features (IP, UA, publisher, supply chain, etc.). For example, a small number of known crawler traffic proceeds to post-bid Fraudsensor, and is identified as having Automated Browsing traffic on it, now MediaGuard will be more likely to flag that IP address or other pre-bid features as IVT.

Components

A MediaGuard integration (pre-bid): Every time you receive a bid request, you should send the details of this bid request to MediaGuard. MediaGuard will return our prediction of whether the bid request is a form of invalid traffic. Based on this response, you can then choose to bid (or not bid) on the ad inventory being sold.
FraudSensor’s detection tag (post-bid): If you make a bid on the ad inventory and win, you’ll need to serve a detection tag alongside the ensuing ad impression. This detection tag is a lightweight code snippet that collects the signals that power FraudSensor’s post-bid IVT analysis.
An Impression Sync integration (post-bid): Optionally, for every detection tag you serve, you can either make a separate postback call to HUMAN or share information about the associated impressions via Snowflake. This Impression Sync data helps us identify any fraudsters who try to evade our detection tags.

How to close the loop

MediaGuard and FraudSensor won’t automatically share data with each other. To close the loop between them, you must follow the instructions outlined here.

Prediction ID (pv)

If your MediaGuard integration is built on the MediaGuard API, lookupId will return a UUID string, which you can pass to FraudSensor’s detection tag without any additional steps.

Prediction Timeout (to)

(0) N/A: You didn’t send the impression’s corresponding bid request to MediaGuard, so MediaGuard didn’t have an opportunity to make an IVT prediction.
(1) Timeout: You sent the impression’s corresponding bid request to MediaGuard, but MediaGuard timed out without responding.
(2) Error response: You sent the impression’s corresponding bid request to MediaGuard, but MediaGuard responded with an error.
(3) Successful response: You sent the impression’s corresponding bid request to MediaGuard, and MediaGuard successfully returned an IVT prediction.
(4) Other: Any other interaction not covered by the above categories.

For more information, see Prediction Timeout (to).