Skip to main content

Closing the Loop: MediaGuard + FraudSensor

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 continuously 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.
NOTE

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.

NOTE

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.

NOTE

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 did not send the impression's corresponding bid request to MediaGuard, so MediaGuard did not have an opportunity to make an IVT prediction.
  • (1) Timeout: You sent the impression's corresponding bid request to MediaGuard, but MediaGuard timed out before it could respond.
  • (2) Error: You sent the impression's corresponding bid request to MediaGuard, but MediaGuard responded with an error.
  • (3) Success: You sent the impression's corresponding bid request to MediaGuard and MediaGuard successfully returned an IVT prediction. (Note that the IVT decision itself is irrelevant; both a successful IVT=true response and a successful IVT=false response would warrant a value of 3.)
  • (4) Other: Any other scenario, like a partial response that included an IVT prediction but was missing a list of IVT categories.

For example, if the MediaGuard API returns an ERROR: 400 response for a particular bid request, you must include to=2 in the detection tag served alongside the ensuing ad impression.