Real time bidding

How Real time bidding Works

[User Visits Page] → [Ad Slot Available] → [Publisher SSP sends Bid Request]
                                                     │
                                                     │
         +-------------------------------------------+
         │
         ▼
[Ad Exchange] → [Forwards Request to multiple DSPs]
                       │
                       │
+----------------------▼----------------------+
|          Demand-Side Platform (DSP)         |
| +-----------------------------------------+ |
| |      Fraud & Traffic Quality Filter     | |
| |  └─ 1. Analyze Request Data (IP, UA)    | |
| |  └─ 2. Check against Blocklists        | |
| |  └─ 3. Score for Fraud Risk            | |
| +-----------------------------------------+ |
|                 │                           |
|      (Is Traffic Valid?)                    |
|          YES │           NO │               |
|            ▼             ▼                |
|      [Submit Bid]    [Reject Request]       |
+----------------------┴----------------------+
                       │
                       │ (If Bid is Submitted)
                       ▼
[Ad Exchange holds Auction] → [Highest Bidder Wins] → [Ad is Served to User]

Real-time bidding (RTB) operates as a high-speed auction where ad impressions are bought and sold in the milliseconds it takes for a webpage to load. From a traffic security perspective, this process provides a critical window to analyze and filter out fraudulent activity before an advertiser’s budget is spent. The entire mechanism is designed for speed, but integrates security checks as a core component.

Bid Request Initiation

When a user visits a website with ad placements, the publisher’s Supply-Side Platform (SSP) sends a bid request to an ad exchange. This request contains a payload of non-personal data about the user and the page, including the user’s device type, operating system, IP address, and the publisher’s domain. This data packet is the first opportunity for fraud detection systems to begin their analysis.

Fraud Analysis at the DSP

The ad exchange forwards the bid request to multiple Demand-Side Platforms (DSPs). It is within the DSP that the core fraud detection logic operates. Before deciding whether to bid, the DSP’s integrated traffic protection system scrutinizes the request data. It checks the IP address against known bot and data center blocklists, analyzes the user agent for inconsistencies, and may score the impression opportunity based on historical data and behavioral patterns associated with fraud.

The Bidding Decision

Based on the fraud analysis, the DSP makes a split-second decision. If the traffic is flagged as suspicious or low-quality, the DSP simply does not place a bid, effectively blocking the fraudulent impression. If the traffic is deemed legitimate, the DSP submits a bid to the ad exchange. The exchange runs an auction, and the highest-bidding DSP wins the right to serve its ad. This pre-bid rejection is the essence of RTB-based fraud prevention.

Diagram Element Breakdown

[User Visits Page] → [Publisher SSP sends Bid Request]: This represents the start of the process, where an opportunity to show an ad is created. The bid request is the data package that security systems analyze.

[Ad Exchange]: This is the central marketplace connecting publishers and advertisers. It facilitates the auction but relies on the DSPs to vet the traffic quality.

[Demand-Side Platform (DSP)]: This is the advertiser’s platform. Its key role in security is the “Fraud & Traffic Quality Filter,” which acts as a gatekeeper, deciding whether a bid request is worthy of a bid.

[Reject Request]: This is a critical outcome in the security logic. Instead of just losing a bid, the DSP actively refuses to participate due to fraud risk, saving the advertiser’s money and preventing engagement with bad actors.

🧠 Core Detection Logic

Example 1: Data Center IP Filtering

This logic prevents bids on traffic originating from known data centers, which are a common source of non-human bot traffic. It works by checking the incoming IP address from the bid request against a maintained list of IP ranges belonging to hosting providers and VPNs.

FUNCTION handle_bid_request(request):
  ip_address = request.get('ip')
  is_datacenter_ip = check_datacenter_list(ip_address)

  IF is_datacenter_ip is TRUE:
    REJECT_BID(reason="Data Center IP")
  ELSE:
    PROCEED_TO_BID()
  END IF
END FUNCTION

Example 2: User Agent Anomaly Detection

This logic inspects the user agent string to find signs of automation or spoofing. Bots often use outdated, inconsistent, or headless browser user agents. This check validates that the user agent corresponds to a legitimate, modern browser and device combination.

FUNCTION handle_bid_request(request):
  user_agent = request.get('user_agent')

  # Check for known bot signatures or headless browser strings
  IF contains(user_agent, "bot") OR contains(user_agent, "HeadlessChrome"):
    REJECT_BID(reason="Bot-like User Agent")
    RETURN

  # Check for mismatch (e.g., mobile UA with desktop screen size)
  device_type = request.get('device.type')
  is_mobile_ua = contains(user_agent, "iPhone") OR contains(user_agent, "Android")

  IF is_mobile_ua AND device_type is "Desktop":
    REJECT_BID(reason="User Agent Mismatch")
  ELSE:
    PROCEED_TO_BID()
  END IF
END FUNCTION

Example 3: Impression Frequency Capping

This rule mitigates impression fraud from a single source trying to generate high volumes of ad requests. It tracks the number of bid requests from a single user ID or IP address over a short time window and rejects bids that exceed a reasonable threshold.

FUNCTION handle_bid_request(request):
  user_id = request.get('user.id')
  timestamp = now()

  # Get recent request timestamps for this user
  request_history = get_requests_for_user(user_id, within_last_minute=True)
  
  IF count(request_history) > 30: # Threshold: 30 requests/minute
    REJECT_BID(reason="Excessive Impression Frequency")
  ELSE:
    record_request(user_id, timestamp)
    PROCEED_TO_BID()
  END IF
END FUNCTION

📈 Practical Use Cases for Businesses

• Campaign Shielding – Proactively block bots and invalid traffic from ever seeing or clicking on ads, preventing budget waste before it occurs and protecting campaign performance metrics from being skewed.
• Analytics Integrity – Ensure that marketing analytics and performance data reflect real human engagement by filtering out fraudulent impressions and clicks at the source, leading to more accurate decision-making.
• Return on Ad Spend (ROAS) Optimization – Improve ROAS by focusing ad spend exclusively on legitimate, high-quality traffic, thereby increasing the likelihood of genuine conversions and reducing cost-per-acquisition (CPA).
• Brand Safety Enforcement – Prevent ads from being served on fraudulent or low-quality sites that use bots to generate traffic, protecting brand reputation from association with inappropriate content.

Example 1: Geographic Origin Filter

A business running a campaign targeted to the United States can use RTB logic to automatically reject any bid request originating from outside its target countries, a common tactic used by fraudsters to find less-guarded campaigns.

FUNCTION evaluate_bid(bid_request):
  # Get geographic data from the bid request
  country_code = bid_request.geo.country

  # Define the list of allowed campaign countries
  allowed_countries = ["USA", "CAN"]

  IF country_code NOT IN allowed_countries:
    // Reject the bid opportunity
    RETURN "NO_BID"
  ELSE:
    // Proceed with bidding logic
    RETURN "BID"
  END IF
END FUNCTION

Example 2: New Site Moratorium

To protect against newly created fraudulent websites, a business can implement a rule to avoid bidding on impressions from any domain that is less than 30 days old. This gives time for the industry to identify and blacklist new threats.

FUNCTION evaluate_bid(bid_request):
  // Get the publisher's domain from the bid request
  domain = bid_request.site.domain

  // Look up the domain's creation date from a database
  creation_date = get_domain_registration_date(domain)
  
  // Calculate domain age
  domain_age_days = (today() - creation_date).days

  IF domain_age_days < 30:
    // Domain is too new, reject the bid
    RETURN "NO_BID"
  ELSE:
    // Domain is established, proceed with bidding
    RETURN "BID"
  END IF
END FUNCTION

🐍 Python Code Examples

This code checks an IP address from a bid request against a simple list of suspicious prefixes. In a real system, this list would be a comprehensive and constantly updated database of known fraudulent IPs, such as those from data centers or botnets.

def is_suspicious_ip(ip_address):
    """Checks if an IP address is on a blocklist."""
    suspicious_prefixes = ["192.168.1.", "10.0.0.", "23.96."] # Example prefixes
    for prefix in suspicious_prefixes:
        if ip_address.startswith(prefix):
            print(f"Blocking suspicious IP: {ip_address}")
            return True
    return False

# Simulate a bid request
bid_request_ip = "23.96.10.4"
if not is_suspicious_ip(bid_request_ip):
    print("IP is clean, proceeding with bid.")

This example demonstrates analyzing a user-agent string to identify non-human traffic. It flags requests from common libraries used for web scraping and automation, which are not representative of genuine user traffic.

def is_bot_user_agent(user_agent):
    """Identifies user agents associated with bots."""
    bot_signatures = ["python-requests", "curl", "Go-http-client", "Bot"]
    for signature in bot_signatures:
        if signature.lower() in user_agent.lower():
            print(f"Blocking bot user agent: {user_agent}")
            return True
    return False

# Simulate a bid request
bid_request_ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
if not is_bot_user_agent(bid_request_ua):
    print("User agent is clean, proceeding with bid.")

Types of Real time bidding

• Pre-bid Filtering
  – This is the most common and effective type for fraud prevention. It analyzes bid request data (like IP, user agent, and device ID) to reject suspicious impressions before a bid is ever placed, preventing any ad spend on fraudulent traffic.
• Post-bid Analysis
  – While not strictly a real-time prevention method, this involves analyzing data after winning an impression to identify fraudulent patterns. The insights are then used to update pre-bid filters and blocklists for future auctions.
• Contextual and Behavioral Targeting
  – This method focuses on the context of the page and the user's historical behavior. It helps avoid fraud by only bidding on impressions that align with specific, hard-to-spoof criteria, inherently filtering out irrelevant or nonsensical bot traffic.
• Private Marketplace (PMP) Bidding
  – By participating in invite-only auctions with a curated group of trusted publishers, advertisers can significantly reduce their exposure to fraud. This type of RTB relies on a pre-vetted, high-quality inventory rather than open-market filtering.

🛡️ Common Detection Techniques

• IP Address Reputation Scoring – This technique involves checking the bid request's IP address against databases of known threats. It helps block traffic originating from data centers, proxy services, and IP addresses with a history of fraudulent activity.
• User-Agent and Device Fingerprinting – This method analyzes the user-agent string and other device parameters for inconsistencies. It can detect anomalies that suggest emulation or bot activity, such as a mobile user-agent on a desktop device.
• Behavioral Analysis – By analyzing patterns in bid requests over time, this technique identifies non-human behavior. It flags suspicious activity like abnormally high request frequency from a single user or impossibly fast navigation through websites.
• Geographic Mismatch Detection – This technique compares the IP address's geolocation with other location data in the bid request (e.g., user-provided data). A significant mismatch can indicate the use of a VPN or GPS spoofing to commit fraud.
• Co-visitation Analysis – This advanced method identifies fraudulent publishers by analyzing user overlap between sites. If a large group of "users" only ever visits a small, isolated cluster of websites, it is a strong indicator of a botnet generating fake traffic.

🧰 Popular Tools & Services

Tool	Description	Pros	Cons
Pre-Bid Traffic Scorer	A service that integrates with a DSP to analyze incoming bid requests in real time. It uses a combination of rules and machine learning to provide a "fraud score" for each impression opportunity.	Proactive blocking, high accuracy with machine learning, reduces wasted ad spend significantly.	Can add milliseconds of latency to the bidding process, may require complex integration.
IP & Device Blocklist API	Provides real-time access to curated lists of fraudulent IP addresses, user agents, and device IDs. The DSP can query this API before bidding to filter out known bad actors.	Fast and easy to implement, effective against common and known fraud sources.	Not effective against new or sophisticated fraud, requires constant updates from the vendor.
Ad Verification Platform	Offers post-bid analysis to measure viewability, brand safety, and invalid traffic (IVT). It provides detailed reports that help advertisers refine their bidding strategies and publisher blocklists.	Provides comprehensive analytics, validates traffic quality, helps in recovering ad spend from publishers.	Reactive rather than proactive, does not stop the initial ad spend on fraudulent impressions.
Click Fraud Protection Service	Specializes in identifying and blocking invalid clicks on search and social ads, often by blocking IP addresses. Some services can be adapted to pre-bid environments by providing their IP blocklists.	Excellent at protecting CPC campaigns, detailed click-level reporting, can improve lead quality.	Primarily focused on clicks, not impression fraud; IP blocking alone is often insufficient for sophisticated bots.

📊 KPI & Metrics

To effectively deploy Real-time Bidding for fraud protection, it is crucial to track metrics that measure both the accuracy of the detection technology and its impact on business outcomes. Monitoring these KPIs ensures that security measures are not only blocking fraud but also preserving legitimate traffic and improving overall campaign efficiency.

Metric Name	Description	Business Relevance
Invalid Traffic (IVT) Rate	The percentage of total bid requests identified and blocked as fraudulent.	Indicates the overall level of threat and the effectiveness of the pre-bid filtering system.
False Positive Rate	The percentage of legitimate impressions incorrectly flagged as fraudulent.	A high rate can harm campaign reach and scale by unnecessarily blocking valid users.
Bid Rejection Rate	The total percentage of bid requests rejected due to fraud filters.	Helps in understanding the direct impact of security rules on bidding activity.
Cost Per Acquisition (CPA) Improvement	The reduction in the cost to acquire a customer after implementing fraud filters.	Directly measures the financial impact of focusing spend on higher-quality, human traffic.
Return on Ad Spend (ROAS)	The overall return on investment from advertising campaigns protected by RTB filters.	The ultimate measure of success, showing if blocking fraud leads to better business outcomes.

These metrics are typically monitored through real-time dashboards that aggregate data from the Demand-Side Platform (DSP) and third-party verification tools. Alerts are often configured to notify teams of sudden spikes in invalid traffic or abnormal changes in key metrics. This continuous feedback loop is used to fine-tune fraud detection rules, adjust filter sensitivity, and optimize the balance between protection and campaign scale.

🆚 Comparison with Other Detection Methods

Real-time vs. Post-Click Analysis

Real-time bidding (RTB) fraud detection analyzes and blocks threats before a bid is made, preventing ad spend waste entirely. In contrast, post-click analysis (or post-bid analysis) reviews traffic after the click or impression has already occurred and been paid for. While post-click is useful for identifying fraud patterns and seeking refunds, RTB is a proactive shield. RTB is faster and more efficient at prevention, whereas post-click is a reactive, forensic tool.

Dynamic Filtering vs. Static Blocklists

Static blocklists, such as lists of known fraudulent IPs or domains, are a component of RTB security but are insufficient on their own. They cannot adapt to new threats. Dynamic RTB filtering, which often uses machine learning, analyzes behaviors and context in real-time. This makes it far more effective against sophisticated bots and new fraud schemes that can easily circumvent static lists. RTB provides an adaptive defense, while static lists are a rigid, easily bypassed one.

Pre-Bid vs. CAPTCHA Challenges

CAPTCHAs are designed to differentiate humans from bots at a specific interaction point, like a form submission. While effective in that context, they are not suitable for the high-speed, high-volume environment of programmatic advertising. RTB fraud detection works invisibly in the background without disrupting user experience. It is highly scalable and operates in milliseconds, making it the only feasible method for filtering billions of daily ad impressions.

⚠️ Limitations & Drawbacks

While powerful, Real-time Bidding for fraud detection has limitations and may not be a complete solution. Its effectiveness can be constrained by data quality, latency requirements, and the sophistication of fraudulent actors, making it less effective in certain scenarios.

• Latency Sensitivity – The entire analysis must complete in milliseconds; complex detection logic can increase latency, causing the bid to be missed, even if the traffic is legitimate.
• Incomplete Data – Bid requests may lack crucial data points needed for accurate fraud assessment, making it difficult to confidently identify some types of sophisticated bots.
• False Positives – Overly aggressive filtering rules can incorrectly block legitimate users who share characteristics with bots (e.g., using a VPN), thereby reducing campaign reach.
• Adversarial Attacks – Fraudsters constantly evolve their methods to mimic human behavior more closely, making it a continuous cat-and-mouse game to keep detection models updated.
• Limited View of Clicks – Pre-bid analysis focuses on impression quality and cannot inherently stop click-based fraud that occurs after the ad is served, such as delayed or repeated fraudulent clicks.
• Encrypted Traffic Challenges – Increasing privacy measures and encryption can sometimes mask signals that fraud detection systems rely on, making it harder to distinguish between real users and bots.

In cases of highly sophisticated or click-based fraud, a hybrid approach combining pre-bid RTB filtering with post-bid analysis is often more suitable.

❓ Frequently Asked Questions

How does RTB handle new or unknown fraud techniques?

Many RTB fraud solutions use machine learning and anomaly detection. These systems establish a baseline for normal user behavior and can flag new, suspicious patterns even if they haven't been seen before. This allows them to adapt to evolving fraud tactics better than static, rule-based systems.

Does using fraud detection in RTB slow down ad loading times?

No, the fraud analysis happens on the server side within the Demand-Side Platform (DSP) before the ad is ever sent to the user's browser. The entire process, including the fraud check, must complete within a strict timeframe (typically under 100 milliseconds) or the bid opportunity is lost. This ensures no perceptible delay for the user.

Can Real-time Bidding stop all types of ad fraud?

No, RTB is most effective at stopping general and sophisticated invalid traffic (GIVT and SIVT) at the impression level. It is less effective against fraud that requires post-impression context, such as conversion fraud or certain types of click fraud where the click happens long after the impression. A layered security approach is recommended.

What is the difference between pre-bid and post-bid fraud detection?

Pre-bid detection happens within the RTB framework before an advertiser decides to bid, thus preventing ad spend on fraudulent impressions. Post-bid detection analyzes traffic after the ad has been served and paid for, which is useful for reporting and seeking refunds but does not prevent the initial waste.

Is RTB fraud detection effective for mobile app traffic?

Yes, the principles are the same. In mobile RTB, bid requests contain device-specific information (like device ID, OS version, and app ID) that is analyzed. Detection techniques are adapted to identify mobile-specific fraud, such as emulated devices, SDK spoofing, and click injection.

🧾 Summary

Real-time bidding serves as a critical first line of defense in digital advertising security. By analyzing ad impression opportunities in milliseconds before a purchase decision is made, it allows advertisers to proactively filter and reject fraudulent traffic from bots and other non-human sources. This pre-bid validation is essential for preventing budget waste, protecting campaign analytics, and improving overall return on investment.

🔗 Related Articles

• AI for Fraud Detection in Real-Time Bidding - Leo Celis Blog – https://blog.leocelis.com/ai-for-fraud-detection-in-real-time-bidding/
• Guarding the Gates: Detecting Fraudulent Activity in Real-Time Bidding Systems - Medium – https://medium.com/@pushpak.haflongbar/guarding-the-gates-detecting-fraudulent-activity-in-real-time-bidding-systems-a77e92534e6c
• Header Bidding vs Real-Time Bidding (RTB): What's the Difference? - MNTN – https://mountain.com/blog/header-bidding-vs-real-time-bidding-rtb/
• How Real-Time Bidding Works & Why It's Vital For Marketers - Fraudlogix – https://fraudlogix.com/how-real-time-bidding-works/
• What is Real-Time Bidding? The Guide to RTB - CHEQ – https://cheq.ai/blog/what-is-real-time-bidding/