Bid request

How Bid request Works

User Action            Ad Server / SSP                  Fraud Detection Layer          Demand-Side Platform (DSP)
(Page Load)                                                                                   
     │                      │                                 │                                │
     ├─> 1. Impression -----│---------------------------------│--------------------------------┤
     │    Available         │                                 │                                │
     │                      ├─> 2. Generate Bid Request ------┤                                │
     │                      │    (User, Device, Ad Data)      │                                │
     │                      │                                 ├─> 3. Analyze Request Data ----┤
     │                      │                                 │    (IP, UA, Geo, Time)        │
     │                      │                                 │                                │
     │                      │                                 ├─? 4. Is it Fraudulent? -------┤
     │                      │                                 │      │                         │
     │                      │                                 │      └─ YES: Block Request   │
     │                      │                                 │      │                         │
     │                      │                                 │      └─ NO: Forward to DSP ---├─> 5. Evaluate & Bid
     │                      │                                 │                                │
     │                      ├<-------------------------------(optional)----------------------├─< 6. Return Bid
     │                      │                                 │                                │
     └<---------------------├─ 7. Serve Winning Ad ----------│--------------------------------┤

A bid request is the starting point of the real-time bidding (RTB) process, which occurs in the milliseconds after a user visits a website or app. When an ad slot becomes available, the publisher’s server or a supply-side platform (SSP) sends out a bid request to multiple demand-side platforms (DSPs). This request is a bundle of data about the available ad impression. For fraud protection systems, this initial data packet is the first and most critical opportunity to inspect traffic quality before an advertiser commits to a bid.

Request Initiation and Data Payload

When a user loads a webpage or app with ad placements, a signal is sent to the ad server, indicating an ad impression is available. The server then compiles a bid request containing valuable, non-personally identifiable information. Key data points include the user’s IP address, device type, operating system, user agent string, location (geo-data), publisher ID, and information about the ad placement itself. This data acts as a digital fingerprint for the impression, providing the raw material needed for fraud analysis. The entire process is automated and foundational to programmatic advertising.

Pre-Bid Fraud Analysis

Before the bid request is passed to advertisers, it is often intercepted by a fraud detection layer. This system analyzes the data payload in real time to search for anomalies that indicate non-human or invalid traffic. For example, it checks the IP address against known blacklists of data centers or proxy servers, which are common sources of bot traffic. It may also validate the user agent string to ensure it matches a legitimate browser or device profile and check for inconsistencies, such as a mobile user agent associated with a desktop screen resolution. This pre-bid filtration is crucial for preventing wasted ad spend.

Decisioning and Traffic Scoring

Based on the analysis, the fraud detection system makes a split-second decision. If the request is flagged as fraudulent (e.g., from a known botnet or exhibiting suspicious patterns), it is blocked and never sent to the DSPs. If the traffic appears legitimate, it is forwarded to the auction. Some advanced systems assign a “quality score” to the request, allowing advertisers to bid only on traffic that meets a certain trust threshold. This scoring mechanism provides a more nuanced approach than a simple block-or-allow decision, helping to balance fraud prevention with maximizing reach.

Breakdown of the ASCII Diagram

1. User Action & Impression Available

This represents the trigger for the entire process. A human user visits a website or opens a mobile app, creating an opportunity to display an ad. This is the origin of the “impression.”

2. Generate Bid Request

The publisher’s ad server or Supply-Side Platform (SSP) packages key information about the user and the context into a standardized format. This data packet is the bid request. It includes details like IP address, device type, location, and the site where the ad will appear.

3. Analyze Request Data

This is the core function of the fraud detection system. It intercepts the bid request and inspects its contents for signs of fraud before it reaches potential advertisers. The analysis focuses on technical indicators that can expose bots or other forms of invalid traffic.

4. Is it Fraudulent?

This represents the decision-making point. Based on its analysis, the system determines if the traffic is legitimate or not. If flagged as fraudulent (YES), the process stops, and the request is discarded. If deemed clean (NO), it proceeds.

5. Evaluate & Bid

The validated bid request is forwarded to the Demand-Side Platform (DSP), where advertisers’ algorithms evaluate the impression’s value based on their campaign targeting criteria and decide whether to place a bid.

6. Return Bid

The DSP sends its bid amount back to the ad exchange or SSP. The highest bidder wins the auction.

7. Serve Winning Ad

The winning advertiser’s creative is sent back to the user’s browser or app and displayed in the ad slot, completing the process.

🧠 Core Detection Logic

Example 1: IP Address Blacklisting

This logic checks the incoming bid request’s IP address against a known database of fraudulent IPs, such as those associated with data centers, VPNs, or documented botnets. It is a fundamental, first-line defense that filters out a significant portion of non-human traffic before any deeper analysis is required.

FUNCTION check_ip(bid_request):
  ip = bid_request.device.ip
  IF ip IN known_fraudulent_ips_database:
    RETURN "BLOCK"
  ELSE:
    RETURN "ALLOW"

Example 2: User Agent and Device Mismatch

This heuristic inspects the user agent string and compares it with other device-specific data in the bid request. Fraudulent actors often generate synthetic requests with mismatched information, such as a mobile device user agent combined with a desktop screen resolution. This logic helps catch crudely constructed bot traffic.

FUNCTION validate_user_agent(bid_request):
  user_agent = bid_request.device.ua
  device_type = bid_request.device.devicetype

  // Example: Check if a known mobile UA is claiming to be a desktop
  is_mobile_ua = contains(user_agent, ["iPhone", "Android"])
  is_desktop_type = (device_type == "Desktop")

  IF is_mobile_ua AND is_desktop_type:
    RETURN "FLAG_AS_SUSPICIOUS"
  ELSE:
    RETURN "PASS"

Example 3: Impression Timestamp Anomaly

This logic analyzes the rate and timing of bid requests coming from a single device ID or IP address. A real user can only generate a limited number of ad impression requests within a short timeframe. An abnormally high frequency of requests suggests automated bot activity. This is effective against high-volume impression fraud.

FUNCTION check_timestamp_frequency(bid_request):
  device_id = bid_request.device.did
  current_time = now()

  // Get the timestamp of the last request from this device
  last_request_time = get_last_request_time(device_id)
  time_difference = current_time - last_request_time

  // Rule: Flag if more than 5 requests in 10 seconds
  IF time_difference < 2 seconds:
    increment_request_count(device_id)
    IF get_request_count(device_id) > 5:
      RETURN "BLOCK_HIGH_FREQUENCY"
  ELSE:
    reset_request_count(device_id)

  update_last_request_time(device_id, current_time)
  RETURN "ALLOW"

📈 Practical Use Cases for Businesses

• Campaign Budget Shielding – Pre-bid filtering of fraudulent requests ensures that advertising budgets are only spent on impressions seen by real humans, maximizing return on ad spend (ROAS).
• Data Integrity for Analytics – By blocking invalid traffic at the source, businesses ensure their campaign performance data (like CTR and conversion rates) remains clean and accurate, leading to better strategic decisions.
• Publisher Quality Control – Advertisers can use bid request data to identify and blacklist low-quality or fraudulent publishers who consistently send invalid traffic, thereby improving the overall quality of their inventory sources.
• Brand Safety Enhancement – Analyzing bid request information helps prevent ads from being served on inappropriate or non-brand-safe sites that are often associated with fraudulent operations.

Example 1: Geolocation Mismatch Rule

This pseudocode demonstrates how a business can reject bids where the device’s GPS-derived location is suspiciously different from the location inferred from its IP address, a common sign of location spoofing fraud.

FUNCTION check_geo_mismatch(bid_request):
  ip_country = get_country_from_ip(bid_request.device.ip)
  gps_country = bid_request.device.geo.country

  // Allow for cases where GPS is not available
  IF gps_country IS NOT NULL AND ip_country != gps_country:
    // Mismatch found, flag as fraudulent
    RETURN "REJECT_BID"
  ELSE:
    // No mismatch or not enough data, proceed
    RETURN "ACCEPT_BID"

Example 2: Session Anomaly Scoring

This logic assigns a risk score to a bid request based on how many suspicious indicators are present. A request with a blank device ID and coming from a blocklisted IP range would receive a high fraud score and be rejected, protecting the advertiser from layered fraud signals.

FUNCTION score_bid_request_risk(bid_request):
  risk_score = 0

  // Condition 1: Blocklisted IP
  IF bid_request.device.ip IN blocklisted_ip_database:
    risk_score += 50

  // Condition 2: Missing Device ID
  IF bid_request.device.did IS NULL OR bid_request.device.did == "":
    risk_score += 30

  // Condition 3: Invalid User Agent
  IF is_invalid_user_agent(bid_request.device.ua):
    risk_score += 20

  // Decision Threshold
  IF risk_score >= 50:
    RETURN "REJECT_HIGH_RISK"
  ELSE:
    RETURN "ACCEPT_LOW_RISK"

🐍 Python Code Examples

This Python function simulates checking a bid request’s IP address against a predefined set of suspicious IP addresses. This is a common first line of defense in fraud detection to filter out known bad actors from data centers or botnets.

# A set of known fraudulent IP addresses
SUSPICIOUS_IPS = {"10.0.0.1", "192.168.1.101", "203.0.113.55"}

def filter_suspicious_ips(bid_request):
    """
    Checks if the IP address in a bid request is in a suspicious IP set.
    """
    ip_address = bid_request.get("device", {}).get("ip")
    if ip_address in SUSPICIOUS_IPS:
        print(f"Blocking fraudulent request from IP: {ip_address}")
        return False
    print(f"Allowing legitimate request from IP: {ip_address}")
    return True

# Example bid request dictionary
request = {"device": {"ip": "203.0.113.55", "ua": "BotBrowser/1.0"}}
filter_suspicious_ips(request)

This code analyzes the User-Agent string from a bid request to identify common non-human or bot-like signatures. By blocking requests with illegitimate user agents, advertisers can avoid serving ads to crawlers and other automated clients.

import re

def analyze_user_agent(bid_request):
    """
    Analyzes the User-Agent string for bot patterns.
    """
    user_agent = bid_request.get("device", {}).get("ua", "")
    # A simple regex to find common bot or crawler signatures
    bot_pattern = re.compile(r"bot|crawler|spider|headless", re.IGNORECASE)

    if bot_pattern.search(user_agent):
        print(f"Detected bot-like User-Agent: {user_agent}")
        return "FRAUD"
    else:
        print(f"User-Agent appears valid: {user_agent}")
        return "VALID"

# Example bid request from a bot
request = {"device": {"ip": "198.51.100.1", "ua": "GoogleBot/2.1"}}
analyze_user_agent(request)

Types of Bid request

• Pre-Bid Analysis

  This is the most common and effective type, where the bid request is analyzed for fraudulent signals in real-time before it’s sent to advertisers. This approach prevents bids on invalid traffic, directly saving ad spend and preserving the integrity of campaign data by stopping fraud at the source.

• Post-Bid Analysis

  In this method, the bid request data is logged and analyzed after the ad impression has already been served and paid for. While it doesn’t prevent initial financial loss, it helps identify fraudulent publishers or traffic sources over time, enabling advertisers to blacklist them from future campaigns and request refunds.

• Request Enrichment

  This variation involves augmenting the original bid request with third-party data before analysis. For example, the IP address from the request can be cross-referenced with a database to add information about its reputation, connection type (residential or data center), and known fraud history, allowing for a more accurate assessment.

• Session-Based Analysis

  Instead of analyzing a single bid request in isolation, this technique aggregates multiple requests from the same user or device over a short period. It focuses on detecting patterns indicative of fraud, such as an impossibly high number of ad requests or unnaturally linear behavior, which would be missed by single-request inspection.

🛡️ Common Detection Techniques

• IP Reputation Analysis – This technique involves checking the bid request’s IP address against databases of known malicious actors, data centers, VPNs, and proxies. It serves as a highly effective first-line filter to block a large volume of non-human traffic.
• User Agent Validation – This method parses the user agent string in the bid request to check for inconsistencies or signatures of known bots. A mismatch between the declared user agent and other device parameters (like screen size) is a strong indicator of fraud.
• Geographic Mismatch Detection – This technique compares the location derived from the IP address with the GPS coordinates (if available) in the bid request. A significant discrepancy often indicates that the location is being spoofed to attract higher-value, geo-targeted ads.
• Impression Frequency Capping – This analyzes the rate of bid requests from a single device or IP address over a specific time window. An unnaturally high frequency suggests automated activity, as a human user cannot generate impressions that rapidly.
• Header and Parameter Inspection – This technique scrutinizes all parameters within the bid request for anomalies. It looks for missing or malformed data, such as a blank device ID or an invalid app store ID, which often points to carelessly generated fraudulent traffic.

🧰 Popular Tools & Services

Tool	Description	Pros	Cons
Pre-Bid Threat Scanner	A real-time API that analyzes incoming bid requests, checking parameters like IP, user agent, and device ID against threat intelligence databases to block invalid traffic before a bid is made.	Prevents ad spend on fraudulent impressions; improves data hygiene; fast response time.	May introduce minor latency; can have false positives; relies on updated threat data.
Traffic Quality Dashboard	An analytics platform that aggregates and visualizes data from bid requests to identify suspicious patterns, fraudulent publishers, and anomalous traffic sources over time.	Provides deep insights; helps in publisher blacklisting; useful for post-bid analysis and refunds.	Does not block fraud in real-time; requires manual analysis and action.
IP & Device Intel API	A data enrichment service that adds a reputation score to bid requests based on the IP address and device fingerprint. It identifies connections from data centers, VPNs, or TOR nodes.	Enhances detection accuracy; provides valuable context; integrates easily with other systems.	Adds cost per query; effectiveness depends on the quality of the enrichment data.
Machine Learning Fraud Modeler	A platform that uses machine learning to analyze bid request patterns and predict the likelihood of fraud. It adapts to new fraud techniques by learning from historical and real-time data streams.	Can detect new and sophisticated fraud types; highly scalable; improves over time.	Complex to set up and tune; may require large datasets for training; can be a “black box.”

📊 KPI & Metrics

Tracking Key Performance Indicators (KPIs) is essential for evaluating the effectiveness of bid request analysis in fraud prevention. It’s important to measure not only the accuracy of the detection models but also their direct impact on advertising campaign outcomes and budget efficiency. Monitoring these metrics helps justify investment in traffic protection and fine-tune detection rules.

Metric Name	Description	Business Relevance
Fraud Detection Rate (FDR)	The percentage of total incoming bid requests correctly identified and blocked as fraudulent.	Measures the core effectiveness of the fraud filter in catching invalid traffic.
False Positive Rate (FPR)	The percentage of legitimate bid requests incorrectly flagged as fraudulent.	Indicates if the system is too aggressive, potentially blocking valuable, clean traffic and reducing campaign reach.
Blocked Bid Request Volume	The total number of bid requests blocked by the fraud detection system over a period.	Helps quantify the scale of the fraud being prevented and demonstrates the system’s workload.
Ad Spend Waste Reduction	The estimated amount of ad budget saved by not bidding on fraudulent impressions.	Directly measures the ROI of the fraud prevention solution in clear financial terms.
Clean Traffic Click-Through Rate (CTR)	The CTR calculated only from traffic that has passed through the fraud filters.	Provides a more accurate measure of true user engagement and campaign performance.

These metrics are typically monitored through real-time dashboards that pull data from ad server logs and the fraud detection platform. Alerts are often configured to trigger when a metric deviates significantly from its baseline, signaling a potential new fraud attack or a problem with the filters. This feedback loop is crucial for continuously optimizing detection rules and adapting to the evolving tactics of fraudsters.

🆚 Comparison with Other Detection Methods

Real-Time vs. Post-Click Analysis

Analyzing bid requests is a pre-bid, real-time detection method. Its primary advantage is preventing ad spend on fraudulent traffic before it occurs. In contrast, post-click analysis (or post-bid analysis) examines traffic data after the click or impression has already been paid for. While post-click analysis is useful for identifying fraud patterns and requesting refunds, it is a reactive measure. Pre-bid request analysis is proactive, saving budget and keeping performance data clean from the start.

Scalability and Speed

Bid request analysis must operate within the strict time constraints of real-time bidding, often under 100 milliseconds. This demands highly efficient and scalable systems. Signature-based methods, which check against known patterns of fraud, are very fast but less effective against new or sophisticated attacks. Behavioral analytics, which analyzes user actions over time, is more powerful but can be slower and more resource-intensive, making it better suited for post-bid or near-real-time analysis rather than instantaneous pre-bid decisions.

Effectiveness and Accuracy

Bid request analysis is highly effective against common forms of invalid traffic like data center bots, simple location spoofing, and malformed requests. However, it can be less effective against sophisticated bots that perfectly mimic human device and browser signals. Methods like CAPTCHAs are highly accurate at separating humans from bots but are intrusive and not applicable within the RTB framework. Behavioral analytics can catch more advanced bots but may have a higher rate of false positives if not tuned properly.

⚠️ Limitations & Drawbacks

While analyzing bid requests is a cornerstone of fraud prevention, the method has inherent limitations, particularly when dealing with sophisticated fraudsters or specific technical constraints. Its effectiveness can be diminished in certain scenarios, making it just one part of a multi-layered security approach.

• Sophisticated Bot Mimicry – Advanced bots can generate bid requests with parameters that perfectly mimic legitimate human users, making them difficult to distinguish using standard data point analysis.
• High Resource Consumption – Processing billions of bid requests in real-time requires significant computational power and infrastructure, which can be costly to maintain.
• Latency Sensitivity – The analysis must be completed in milliseconds to not delay the ad auction. This time constraint limits the complexity of detection algorithms that can be run pre-bid.
• Encrypted or Limited Data – As privacy regulations tighten, some data fields in bid requests may become obscured or unavailable, reducing the signals available for fraud detection.
• False Positives – Overly aggressive filtering rules can incorrectly flag legitimate users who may be using VPNs for privacy or have unusual device configurations, leading to lost advertising opportunities.
• Adversarial Adaptation – Fraudsters constantly change their tactics. A rule that works today to detect anomalies in bid requests might be obsolete tomorrow, requiring continuous updates and monitoring.

In cases of highly sophisticated or rapidly evolving fraud, fallback strategies like post-bid analysis, behavioral modeling, or third-party traffic scoring become more suitable complements.

❓ Frequently Asked Questions

How does bid request analysis handle sophisticated bots that mimic human behavior?

While basic bid request analysis may be fooled, advanced systems look for subtle, aggregated patterns that bots often fail to replicate. This includes analyzing the frequency and timing of requests from a single source or cross-referencing data with historical behavior to identify non-human patterns that aren’t apparent in a single request.

Does analyzing bid requests for fraud slow down the ad serving process?

Fraud detection systems are engineered to operate with extremely low latency, often making a decision in just a few milliseconds. While any processing adds a minuscule delay, it is designed to fit within the sub-100-millisecond window required for real-time bidding, so it does not noticeably impact the ad serving speed.

What are the most critical data points within a bid request for fraud detection?

The most critical data points are the IP address, user agent string, device ID, and publisher ID. The IP address helps identify traffic from data centers or known fraudulent sources. The user agent and device ID help detect bots and inconsistencies, while the publisher ID is used to track and block fraudulent inventory sources.

Can bid request filtering block legitimate users by mistake?

Yes, this is known as a “false positive.” It can happen if a legitimate user has an unusual setup, such as using a VPN or having a browser that sends unconventional data. Fraud prevention systems are constantly tuned to minimize false positives by focusing on definite fraud signals rather than just suspicious ones.

Is bid request analysis effective against click injection or click spamming?

Partially. Bid request analysis can detect some forms of click spam if the requests originate from a suspicious IP or show bot-like patterns at the impression level. However, click injection often happens on the device after a legitimate impression, making it harder to detect at the pre-bid stage. Post-install analysis is typically more effective for these fraud types.

🧾 Summary

A bid request is a data packet sent when an ad space is available on a website or app, initiating a real-time auction. In fraud protection, analyzing this request pre-bid is the first line of defense. It allows systems to inspect data like IP addresses and device types to identify and block non-human traffic before advertisers spend money, thereby protecting budgets and ensuring campaign data integrity.

🔗 Related Articles

• What is a Bid Request & How it Facilitates Programmatic Advertising – https://www.adpushup.com/blog/what-is-bid-request/
• AI for Fraud Detection in Real-Time Bidding – https://leocelis.com/blog/ai-for-fraud-detection-in-real-time-bidding/
• Guarding the Gates: Detecting Fraudulent Activity in Real-Time Bidding Systems – https://medium.com/@pierpaoloboffi/guarding-the-gates-detecting-fraudulent-activity-in-real-time-bidding-systems-58448835850e
• OpenRTB (Real-Time Bidding) – IAB Tech Lab – https://iabtechlab.com/standards/openrtb/
• Mobile Click Fraud Detection & Prevention: Avoid Ad Fraud – https://liftoff.io/glossary/mobile-ad-fraud/