Bid Request Filtering

What Bid Request Filtering Does

Bid request filtering is a pre-bid control, so its purpose is not to optimise every request but to discard requests that should never reach a bidding decision. In practice, that means checking the supply path and request attributes early enough to reduce wasted spend, reduce exposure to invalid inventory, and keep the auction environment aligned with policy.

The screening logic usually sits between request intake and bid generation. It can be rule-based, model-based, or a combination of both, but the operational idea is the same, only requests that satisfy trust and quality criteria are allowed to continue.

What Gets Screened in a Bid Request

Filtering commonly looks at the fields that describe where the request came from and how it was assembled. Domain, app, placement, device, referrer and seller identifiers are useful because they help distinguish legitimate supply from spoofed, low-quality, or policy-breaking traffic.

This makes bid request filtering a supply-side trust control rather than a creative selection control. The decision is about whether the request deserves participation in the auction at all, not which creative should win.

• Domain and app data help identify whether the request matches approved inventory.
• Placement and referrer data help reveal suspicious routing, embedded traffic, or mismatched context.
• Device and seller identifiers help detect patterns associated with invalid supply or unauthorised intermediaries.

Why Filtering Matters for Auction Quality

Without filtering, buyers can waste bids on requests that are malformed, duplicated, deceptive, or outside policy. That degrades campaign performance, but it also creates a governance problem because the system may keep treating untrusted supply as if it were eligible inventory.

Bid request filtering is therefore part of the trust boundary for programmatic advertising. It protects decision quality before the auction starts, which is usually cheaper and more reliable than trying to clean up after a bid is placed.

When the filter is too permissive, organisations can overcount legitimate supply, bid into unwanted environments, or absorb fraud-adjacent traffic. When it is too strict, it can suppress valid inventory and reduce reach, so the design has to balance precision, business goals and false positive tolerance.

How Bid Request Filtering Is Operated

Effective filtering depends on clear policy ownership, up-to-date inventory rules, and continuous tuning. Teams usually maintain allowlists, blocklists, and scoring logic that reflect their current publisher relationships, campaign constraints, and fraud or quality findings.

It also needs observability. If requests are being rejected, operators should be able to explain why, distinguish deliberate filtering from accidental loss of eligible supply, and review whether the rule set still matches the current market and partner set. The practical question is not just whether requests are blocked, but whether the filter is still making defensible decisions.

Bid request filtering works best when it is treated as an evolving control, not a one-time configuration. Supply paths change, identifier quality varies, and new edge cases appear as exchanges, apps and sellers evolve.

Risk and Threat Considerations

Bid request filtering carries a material risk dimension because it sits directly on the path between request intake and spend. If the control is weak, attackers or bad actors can exploit spoofed domains, manipulated seller identifiers, or low-quality supply paths to trigger bids against inventory that should have been excluded.

Failure mechanism: The control fails when the request fields being checked are incomplete, spoofable, stale, or interpreted too narrowly, allowing invalid or unwanted supply to pass into the auction flow.

Impact: Buyers can waste budget, pollute performance data, and expose campaigns to fraudulent or policy-violating inventory, while defenders lose confidence in the quality of the supply path.

Practitioner Guidance

Why practitioners should care: Bid request filtering is only effective when the rule set reflects the current supply chain and campaign policy. If ownership is unclear, filters drift quickly and either block too much or too little.

Common misunderstanding: Filtering is sometimes treated as a simple blacklist problem, but the better model is layered validation of request provenance, context and eligibility. That approach is more resilient when supply relationships change.

Practitioner takeaway: Keep the filter logic explainable enough to support debugging and policy review, but strict enough that suspicious supply is rejected before it can influence bidding decisions.

Related resources from NHI Mgmt Group

• What breaks when request and response bodies are logged without filtering?
• Should organisations prioritise runtime monitoring over stricter API request filtering?
• Why does session context matter more than per-request filtering for agents?
• HTTP Request Filtering