MediaGuard is HUMAN’s pre-bid solution for detecting advertising fraud. By analyzing information from the OpenRTB Bid object, we can make real-time predictions about the validity of each bid request you receive, then provide you with a recommendation to bid or not bid on a particular ad placement. You can then incorporate this recommendation into your bidding logic.
To use MediaGuard, you must deploy MediaGuard and FraudSensor in tandem. The post-bid data we collect via FraudSensor helps improve MediaGuard's predictive models. By using both of these solutions at the same time, the combined power of MediaGuard and FraudSensor creates a personalized data ecosystem that grants you access to the full range of HUMAN's insight and analysis.
How MediaGuard works
Every time MediaGuard scans an individual bid request, HUMAN returns a decision about that request. Our decision is distilled into a single data point that predicts whether the impression is valid or invalid. You can then incorporate this data point into your bidding process to automatically determine whether to bid on each specific ad placement.
To implement MediaGuard, you’ll need a server-to-server (S2S) integration through the MediaGuard API. This API has two interfaces based on different protocols: one that uses the Google Remote Procedure Call (gRPC) over HTTP2.0, and one that uses HTTP 1.1. Although these interfaces differ in implementation, they both offer the full scope of MediaGuard features.
The benefits of the MediaGuard SDK
HUMAN's MediaGuard SDK is available in Go, C++, and Java. Our SDK uses gRPC running on port 10000 to manage connections, balance loads, format requests, and collect timeout metrics for troubleshooting purposes. For optimal results, we recommend using a standard HUMAN SDK to integrate with MediaGuard.
The benefits of using our existing SDK include:
- It runs over HTTP 2.0, which multiplexes numerous streams over a single connection.
- All data is transferred using a condensed binary payload (protobuf).
- The SDK uses mTLS for authentication.
- The SDK includes a thin wrapper that sends request timing metrics to HUMAN, which helps us monitor and troubleshoot any latency issues that may arise.
Alternatively, you may choose to implement MediaGuard by building your own gRPC client (port 10000) or integrating via the HTTPS interface (port 443) using application/protobuf or application/json (preferred) transport. You can access the HTTP service using command line tools like cURL. The HTTP service also offers a health-check API endpoint that lets you check the status of a MediaGuard node.
The HTTP integration is not as performant as the gRPC integration, but it may be useful if there are other limiting factors that prevent you from using gRPC. The HTTP REST API offers the following benefits:
- Data is sent in the message body.
- The HTTP API uses Basic Authentication.
- Data is either formatted as a JSON payload or a Protocol Buffers payload.
- You'll need to send POST requests to MediaGuard; MediaGuard's decision will be returned in the message response body.
Additionally, any custom-built MediaGuard integrations must meet the following requirements:
- You must build some mechanism to manage connection pooling, since HTTP 1.1 does not manage connection pooling and MediaGuard does not handle connection pooling on its own servers.
- HUMAN does not automatically collect timeout information from custom-built MediaGuard integrations, so you will be asked to manually provide this information during troubleshooting.
- You must implement load balancing in your integration, since load balancing is not handled by MediaGuard’s clusters.
- An increased number of connections to each MediaGuard node will decrease the performance of that node. As a result, you may need to deploy an increased number of nodes to support your traffic than a comparable integration that uses gRPC with load balancing. Increasing the number of nodes deployed will increase the overall cost of your MediaGuard integration.