MediaGuard is HUMAN’s pre-bid solution for detecting advertising fraud. By using information from the OpenRTB Bid object to make real-time predictions about the validity of each ad impression you receive, MediaGuard returns a recommendation to bid or not bid on each ad request, which you can then incorporate into your bidding logic.
MediaGuard must be deployed in tandem with FraudSensor. The post-bid data collected by FraudSensor is used to improve MediaGuard’s predictive models. When used at the same time, the combination of FraudSensor and MediaGuard creates a personalized traffic 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 impression.
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.
Using 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.
Custom integrations
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.
There are also several general considerations that apply to users with custom integrations:
- You’ll need to monitor MediaGuard for timeouts and, in the event that timeouts begin to spike, decrease the number of requests to MediaGuard rather than increasing requests. Ramping up requests will compound the issue, but ramping down requests will give MediaGuard’s system enough time to catch up.
- For any of the available MediaGuard integration options, you’ll need to create a Lookup Request for each bid opportunity. This request should contain parameters from the OpenRTB Bid object.
- We encourage you to provide as much data in your lookup requests as possible. Even if some signals are not available for a given request, MediaGuard can still return decisioning based on the data you provide. However, the more data you supply in each request, the more accurate MediaGuard’s responses will be.