Closing the Loop: MediaGuard + FraudSensor

MediaGuard and FraudSensor are designed to work together. FraudSensor determines whether an ad was served to a bot or a human. HUMAN generalizes that post-bid data into a reputation database and retrains the MediaGuard model every two hours.

MediaGuard lets 0.5% of traffic flagged as sophisticated invalid traffic (SIVT) through, and 0.05% of traffic flagged as generalized invalid traffic (GIVT), so FraudSensor can rescan it and check the prediction.

Self-declaration is what separates a GIVT bot from an SIVT bot. If a known crawler stops declaring itself, this sample makes it much more likely that pre-bid MediaGuard will flag that crawler as SIVT.
The sampled impressions confirm that detection covers IVT techniques other than IAB Bots and Spiders user-agent violations.
Post-bid records that carry an IVT flag show which pre-bid features travel with that fraud, including IP address, user agent, publisher, and supply chain. For example, if a small amount of known crawler traffic reaches FraudSensor and is identified as Automated Browsing. MediaGuard can then flag that IP address, or the other pre-bid features that traveled with it, as IVT.

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 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 you integrate with gRPC (the Java, C++, or Go SDK, or your own client) or send protobuf over HTTP (application/protobuf), lookupId is 16 raw bytes. In Go that value is a []byte, in Java a ByteString, and in C++ a binary std::string. Convert those bytes to the canonical 36-character UUID string and keep big-endian (network) byte order. The SDK README for each language shows the conversion.

If you integrate with HTTP and JSON, lookupId is already that 36-character UUID string, such as 6ef4e4c2-99e7-4805-ae44-cd5f1d74266f.

HUMAN generates UUIDv4 values with the RFC 4122 variant, which uses big-endian byte order.

For example, when MediaGuard returns "lookupId": "d2260bd4-4d81-11e8-88da-600308952712", include pv=d2260bd4-4d81-11e8-88da-600308952712 in the detection tag served with the 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).