Open Real Time Bidding (OpenRTB)

How Open Real Time Bidding OpenRTB Works

USER VISIT
    │
    ▼
PUBLISHER'S SITE/APP
    │
    └─ Ad Slot Available
    │
    ▼
AD EXCHANGE / SSP
    │
    ├─ Creates Bid Request (User, Device, Ad Info)
    │
    ▼
MULTIPLE DSPs (ADVERTISERS)
    │
    ├─ +--[FRAUD DETECTION FILTER]--+
    │  │  - IP/User Agent Analysis   │
    │  │  - Geo/Behavioral Checks    │
    │  │  - ads.txt/sellers.json     │
    │  +----------------------------+
    │
    ├─ Filtered Traffic -> Bids Placed
    │
    ▼
AD EXCHANGE (AUCTION)
    │
    └─ Highest Bid Wins
    │
    ▼
WINNING AD IS SERVED
    │
    ▼
USER

Open Real Time Bidding (OpenRTB) standardizes the communication for instantaneous ad auctions. The process begins the moment a user visits a website or opens an app, making an ad slot available. The publisher’s Supply-Side Platform (SSP) or ad exchange then packages information about this opportunity into a “bid request,” a data-rich message sent to multiple potential advertisers. This all happens in milliseconds.

The Bid Request

The bid request is the core of the OpenRTB process. It contains a wealth of non-personally identifiable information, such as the device type, operating system, user’s general location, and details about the ad placement itself. For fraud detection, this data is invaluable. Security systems can scrutinize these details for red flags, such as outdated user agents associated with bots or geographic data that doesn’t align with the IP address.

Real-Time Auction and Fraud Detection

Demand-Side Platforms (DSPs), representing advertisers, receive these bid requests. Before deciding whether to bid, their systems perform a rapid analysis to filter out fraudulent or low-quality impressions. This pre-bid detection is where OpenRTB’s structure is critical. It allows for the application of rules that check for known fraudulent IPs, suspicious device IDs, or inconsistencies that suggest bot activity. Traffic that passes this screening enters the auction. The DSP submits a bid, and if it’s the highest, their ad is served to the user.

Verification and Transparency

To further combat fraud, the OpenRTB ecosystem includes standards like ads.txt and sellers.json. Ads.txt allows publishers to publicly declare which companies are authorized to sell their ad inventory. DSPs can cross-reference the seller information in a bid request with the publisher’s ads.txt file. If the seller isn’t listed, the bid request is likely fraudulent and can be discarded, preventing ad spend from going to unauthorized resellers or domain spoofers.

ASCII Diagram Breakdown

USER VISIT to AD EXCHANGE: This shows the initial steps where a user’s action on a publisher’s property creates an ad opportunity, which is then sent to an ad exchange to be auctioned.

FRAUD DETECTION FILTER: This block represents the critical security layer at the DSP. It uses the data from the OpenRTB bid request to check against various fraud signatures before any money is bid.

Filtered Traffic to AUCTION: Only the bid requests that are deemed legitimate by the fraud detection filter proceed to the auction phase, ensuring advertisers bid on quality traffic.

WINNING AD IS SERVED: The final step shows the winning advertiser’s creative being delivered back to the publisher’s site and displayed to the user, completing the cycle.

🧠 Core Detection Logic

Example 1: Invalid Seller Verification via ads.txt

This logic checks if the seller of the ad inventory is authorized by the publisher. It parses the OpenRTB bid request to find the publisher’s domain and the seller’s ID, then compares it against the publisher’s public ads.txt file. It prevents domain spoofing and unauthorized inventory reselling.

FUNCTION is_seller_authorized(bid_request):
  publisher_domain = bid_request.site.domain
  seller_id = bid_request.source.seller_id
  
  adstxt_file = fetch_adstxt(publisher_domain)
  
  IF adstxt_file IS NOT found:
    RETURN REJECT // Fail-safe
  
  FOR each line IN adstxt_file:
    IF line.seller_id == seller_id:
      RETURN ALLOW
      
  RETURN REJECT // Seller not found in ads.txt

Example 2: Bot Detection via User Agent Analysis

This logic inspects the User-Agent (UA) string provided in the bid request. It flags UAs that are known to be used by data center servers, headless browsers, or outdated clients, which are common indicators of non-human traffic. This helps filter out simple bots before bidding.

FUNCTION check_user_agent(bid_request):
  user_agent = bid_request.device.ua
  
  known_bot_signatures = ["HeadlessChrome", "PhantomJS", "dataprovider", "Googlebot-Image"]
  
  IF user_agent IS NULL or user_agent IS EMPTY:
    RETURN "suspicious"
    
  FOR signature IN known_bot_signatures:
    IF signature IN user_agent:
      RETURN "bot"
      
  // Additional checks for outdated browser versions can be added here
  
  RETURN "human"

Example 3: Geo Mismatch Detection

This rule checks for inconsistencies between the user’s IP address location and the location data provided in the device object of the bid request. A significant mismatch can indicate that the location data is being spoofed to inflate the value of the impression for advertisers targeting specific regions.

FUNCTION verify_geo_data(bid_request):
  ip_address = bid_request.device.ip
  device_country = bid_request.device.geo.country
  
  ip_country = lookup_ip_location(ip_address)
  
  IF ip_country != device_country:
    // Log discrepancy for further analysis
    // Can add tolerance for proxy usage or minor inaccuracies
    RETURN REJECT
    
  RETURN ALLOW

📈 Practical Use Cases for Businesses

• Campaign Shielding – Protect advertising budgets by using OpenRTB data to pre-emptively block bids on traffic from known botnets, data centers, or fraudulent publishers. This ensures ad spend is focused on reaching real human users.
• Data Integrity – Improve the accuracy of marketing analytics and conversion tracking. By filtering out non-human traffic at the source, businesses ensure that metrics like CTR and conversion rates reflect genuine user engagement, leading to better optimization decisions.
• Return on Ad Spend (ROAS) Improvement – Increase ROAS by avoiding wasted impressions on fraudulent inventory. OpenRTB allows advertisers to verify sellers via ads.txt and sellers.json, ensuring they only bid on legitimate, authorized ad placements that have a higher chance of converting.
• Brand Safety Enforcement – Use data within the bid request, such as page URL and content categories, to prevent ads from appearing on undesirable or inappropriate websites. This protects brand reputation and ensures ads are shown in a contextually relevant environment.

Example 1: Geofencing Rule

A retail business wants to ensure its local ad campaign only targets users within a specific country. This pseudocode rejects any bid request where the device’s IP address is not from the target country, preventing budget waste on irrelevant impressions.

FUNCTION apply_geofencing(bid_request, target_country):
  ip_address = bid_request.device.ip
  
  // Use a geo-IP service to find the country
  request_country = get_country_from_ip(ip_address)
  
  IF request_country == target_country:
    RETURN "ALLOW_BID"
  ELSE:
    RETURN "REJECT_BID"

Example 2: Session Scoring Rule

An e-commerce platform wants to identify and block users generating an unnaturally high number of ad requests in a short time, a sign of bot activity. This logic scores sessions based on request frequency and blocks bids to high-scoring (suspicious) device IDs.

FUNCTION score_session_activity(device_id, timestamp):
  // Assumes a cache 'session_data' stores recent activity
  
  current_time = timestamp
  
  IF device_id NOT IN session_data:
    session_data[device_id] = {"requests": 1, "first_seen": current_time}
    RETURN "LOW_SCORE"
  
  session_data[device_id].requests += 1
  time_diff = current_time - session_data[device_id].first_seen
  
  // Example: more than 10 requests in 60 seconds is suspicious
  IF session_data[device_id].requests > 10 AND time_diff < 60:
    RETURN "HIGH_SCORE_BLOCK"
    
  RETURN "NORMAL_SCORE"

🐍 Python Code Examples

This function checks an IP address from a bid request against a blocklist of known fraudulent IPs. Maintaining such a list is a fundamental step in filtering out traffic from data centers and known bad actors.

# A set of known fraudulent IP addresses
FRAUDULENT_IPS = {"192.168.1.101", "10.0.0.54", "203.0.113.12"}

def filter_by_ip_blocklist(bid_request):
    """
    Checks if the device IP in a bid request is in a known fraud blocklist.
    """
    device_ip = bid_request.get("device", {}).get("ip")
    if device_ip in FRAUDULENT_IPS:
        print(f"Blocking bid from fraudulent IP: {device_ip}")
        return False
    return True

# Example bid request snippet
bid_req = {"device": {"ip": "203.0.113.12"}}
is_traffic_clean = filter_by_ip_blocklist(bid_req)

This code analyzes bid requests to detect abnormal click frequency from a single device, which is a strong indicator of bot activity or click farms. It tracks the number of requests per device ID within a time window to identify suspicious patterns.

from collections import defaultdict
import time

# In a real system, this would be a distributed cache like Redis
request_counts = defaultdict(list)
TIME_WINDOW = 60  # seconds
REQUEST_THRESHOLD = 20 # max requests per window

def detect_high_frequency_requests(device_id):
    """
    Flags a device ID if it exceeds a request threshold within a time window.
    """
    current_time = time.time()
    
    # Remove timestamps outside the window
    request_counts[device_id] = [t for t in request_counts[device_id] if current_time - t < TIME_WINDOW]
    
    # Add current request timestamp
    request_counts[device_id].append(current_time)
    
    if len(request_counts[device_id]) > REQUEST_THRESHOLD:
        print(f"High frequency detected for device: {device_id}")
        return True # Indicates fraud
    return False

# Simulate requests
device_a = "aa11-bb22-cc33"
for _ in range(25):
    detect_high_frequency_requests(device_a)

Types of Open Real Time Bidding OpenRTB

• `ads.txt` and `app-ads.txt` Integration - These are not types of OpenRTB, but critical supporting standards. Publishers list authorized sellers in a public text file. Bidders use OpenRTB to get the seller's information and cross-verify it with the ads.txt file, preventing unauthorized inventory sales and domain spoofing.
• `sellers.json` and SupplyChain Object - Sellers.json is a file where SSPs and exchanges list the sellers they represent. The SupplyChain Object is passed within the OpenRTB bid request and provides a full view of all intermediaries involved in the ad transaction. Together, they provide end-to-end transparency, helping buyers identify and block fraudulent paths.
• `user.ext` and `device.ext` for Custom Signals - The OpenRTB protocol allows for extension objects (`ext`). Ad tech vendors can use these to pass proprietary anti-fraud signals, such as traffic quality scores or bot likelihood percentages, directly within the bid request. This enables more sophisticated, custom filtering logic.
• Encrypted Signals (`ads.cert`) - Part of newer OpenRTB specifications, `ads.cert` introduced a method for cryptographically signing bid requests. This authenticates the inventory and ensures that data within the bid request, like the domain or user ID, has not been tampered with by intermediaries in the supply chain.

🛡️ Common Detection Techniques

• IP Reputation Analysis – This technique involves checking the IP address from the OpenRTB bid request against known blocklists. These lists contain IPs associated with data centers, VPNs, and proxies often used by bots, allowing for immediate filtering of non-human traffic.
• User-Agent and Device Fingerprinting – Systems analyze the user-agent string and other device attributes (e.g., screen size, OS) in the bid request. Inconsistencies or signatures associated with automated browsers or known botnets are flagged as fraudulent.
• Behavioral Analysis – This method tracks user activity over time, such as click frequency, conversion rates, and session duration, tied to a device ID from the bid request. Unnaturally high frequencies or other non-human patterns are used to identify and block bots.
• Supply Chain Verification – This technique leverages the `sellers.json` and SupplyChain Object in OpenRTB. It verifies that every intermediary in the ad transaction path is a legitimate, known entity, which helps eliminate fraud from unauthorized resellers.
• Geographic Validation – This involves comparing the location data derived from the IP address with the GPS or user-provided location in the bid request. Significant mismatches often indicate that the location is being spoofed to fraudulently increase the bid price.

🧰 Popular Tools & Services

Tool	Description	Pros	Cons
Pre-Bid Threat Intelligence Platform	A service that provides real-time data feeds (e.g., fraudulent IP lists, bot signatures) that plug directly into a DSP. It uses this data to analyze OpenRTB bid requests and block threats before a bid is placed.	Very fast; stops fraud at the earliest point; highly scalable.	Can be costly; may not catch sophisticated or new types of fraud that are not yet on lists.
Integrated DSP Fraud Filters	Built-in fraud detection modules within a Demand-Side Platform. These systems automatically parse OpenRTB bid requests for suspicious patterns, check ads.txt, and apply internal filtering rules without needing a third-party tool.	Seamless integration; often included with the DSP service; easy to enable.	Functionality can be a "black box" with little customization; may be less advanced than specialized third-party tools.
Third-Party Ad Verification Service	A post-bid or in-flight analysis tool that places a tag on the ad creative. It analyzes the environment where the ad is served to measure viewability, brand safety, and detect fraud that was missed pre-bid.	Catches sophisticated fraud like ad stacking or pixel stuffing; provides detailed post-campaign reporting.	Does not prevent the initial bid on fraudulent traffic; adds to ad-serving latency.
Supply Path Optimization (SPO) Algorithm	An automated system that uses OpenRTB SupplyChain Object data to identify the most direct and transparent paths to publisher inventory. It prioritizes routes with fewer intermediaries, reducing the risk of fraud.	Increases efficiency and transparency; lowers risk of intermediary fraud; improves ROAS.	Requires a DSP that fully supports the SupplyChain Object; effectiveness depends on industry-wide adoption.

📊 KPI & Metrics

When deploying fraud protection based on OpenRTB, it's crucial to track metrics that measure both the accuracy of the detection system and its impact on business goals. Monitoring these Key Performance Indicators (KPIs) helps ensure that filters are blocking invalid traffic effectively without inadvertently harming campaign performance.

Metric Name	Description	Business Relevance
Invalid Traffic (IVT) Rate	The percentage of total ad traffic identified as fraudulent or non-human.	A primary indicator of overall traffic quality and the effectiveness of fraud filters.
Bid Request Rejection Rate	The percentage of incoming OpenRTB bid requests that are discarded due to failing fraud checks.	Measures how aggressively the pre-bid system is filtering traffic before auctions occur.
False Positive Rate	The percentage of legitimate traffic that is incorrectly flagged as fraudulent.	Crucial for ensuring that fraud filters do not block valuable, human users and harm campaign reach.
Viewable CPM (vCPM)	The cost per thousand viewable impressions, excluding non-viewable and fraudulent ones.	Indicates if the ad spend is efficiently reaching real audiences, as cleaner traffic typically has higher viewability.
Suspicious Seller Rate	The percentage of bid requests from sellers not authorized in a publisher's ads.txt file.	Directly measures the effectiveness of using ads.txt verification to combat inventory fraud.

These metrics are typically monitored through real-time dashboards connected to the bidding platform's logging systems. Alerts can be configured to trigger when KPIs deviate from established benchmarks, allowing fraud analysis teams to investigate anomalies. The feedback from this monitoring is used to continuously refine and optimize the filtering rules, adapting to new threats while maximizing campaign performance.

🆚 Comparison with Other Detection Methods

Real-Time vs. Batch Processing

OpenRTB enables pre-bid detection, which analyzes and blocks fraud in real time, before an ad is purchased. This is highly effective at preventing wasted ad spend. In contrast, post-bid analysis involves processing server logs after the fact (batch processing). While post-bid can uncover complex fraud patterns, it is reactive and often only helps with clawbacks rather than preventing the initial financial loss.

Data Granularity and Context

The structured data in an OpenRTB bid request (e.g., device ID, location, app details) provides rich, granular context for making a decision on a single impression. This is more sophisticated than traditional signature-based filters, which often rely on blocking known bad IPs or domains. While signature-based methods are fast, they are less adaptable to new threats and can be easily bypassed by sophisticated bots.

Scalability and Speed

Pre-bid detection using OpenRTB must operate within milliseconds to be viable. This demands highly efficient and scalable systems. CAPTCHA challenges, another detection method, are not suitable for this environment as they interrupt the user experience and are not applicable to programmatic auctions. OpenRTB-based detection is designed for massive scale, handling millions of requests per second, whereas methods like manual review or deep-packet inspection do not scale for RTB environments.

⚠️ Limitations & Drawbacks

While OpenRTB is fundamental to modern fraud detection, its pre-bid nature and reliance on the data provided within the bid request create certain limitations. It is not a complete solution and may be less effective against sophisticated, evolving fraud tactics that are only detectable after the ad has been served.

• Inability to Detect Post-Bid Fraud – OpenRTB-based checks happen before the bid, so they cannot detect fraud types like ad stacking or pixel stuffing, where ads are hidden or made invisible at render time.
• Reliance on Signal Accuracy – The effectiveness of fraud detection depends entirely on the accuracy and completeness of the data in the bid request. Fraudsters can manipulate these signals (e.g., spoofing user agents or locations) to bypass filters.
• Latency Sensitivity – All pre-bid analysis must be completed in milliseconds. Complex detection models or slow data lookups can cause timeouts, forcing a bidder to either bid without full analysis or lose the impression opportunity.
• Challenges with Encrypted Traffic – While standards like `ads.cert` aim to secure the supply chain, not all inventory is signed. Unencrypted or incomplete information can limit visibility and create blind spots for fraud detection.
• Vulnerability to Sophisticated Bots – Advanced bots can mimic human behavior closely, making them difficult to distinguish based on bid request data alone. Detecting them often requires post-bid behavioral analysis that OpenRTB cannot facilitate.
• Limited Scope for Creative-Based Fraud – Pre-bid analysis focuses on the traffic source, not the ad creative itself. It cannot prevent malicious creatives (malvertising) from being submitted by a demand source.

Due to these drawbacks, a robust anti-fraud strategy often requires a hybrid approach, combining pre-bid OpenRTB filtering with post-bid analysis and other verification methods.

❓ Frequently Asked Questions

Does OpenRTB guarantee fraud-free traffic?

No, OpenRTB does not guarantee fraud-free traffic. It is a protocol that provides the data necessary for fraud detection systems to analyze bid requests before a purchase is made. While it is highly effective at filtering many types of invalid traffic, sophisticated bots and post-bid fraud like ad stacking can still bypass these pre-bid checks.

How do ads.txt and sellers.json enhance OpenRTB for fraud prevention?

Ads.txt allows publishers to publicly declare authorized sellers of their inventory. Sellers.json allows intermediaries like exchanges to list the sellers they represent. Within an OpenRTB transaction, a buyer can use this information to verify that the entity selling the impression is legitimate, effectively preventing domain spoofing and unauthorized reselling.

Can fraudsters manipulate OpenRTB bid requests?

Yes, fraudsters can and do manipulate data within OpenRTB bid requests. They may spoof user agents to appear as high-value devices, falsify location data to attract higher bids, or use other techniques to make their fraudulent traffic look legitimate. This is why multi-layered detection techniques are necessary.

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

Pre-bid detection uses OpenRTB data to analyze and block fraudulent impressions before an advertiser's money is spent. Post-bid detection analyzes traffic after the ad has been served, which is useful for identifying more complex fraud and for seeking refunds, but it does not prevent the initial waste of ad spend.

Is OpenRTB only for display ads?

No. While it started with display, the OpenRTB protocol has evolved to support a wide range of ad formats, including video, audio, and native ads. The data signals and fraud detection principles apply across all formats, helping to secure advertising in channels like connected TV (CTV) and streaming audio.

🧾 Summary

OpenRTB is a crucial protocol in digital advertising that facilitates real-time, pre-bid fraud detection. By standardizing the data in ad auction requests, it enables advertisers to analyze traffic for signs of bots, spoofing, and other invalid activity before committing ad spend. Complemented by transparency standards like ads.txt and sellers.json, OpenRTB provides the foundational framework for protecting campaign budgets and improving ad ecosystem integrity.

🔗 Related Articles

• Sellers.JSON & OpenRTB Supply Chain Object Marketplace - https://pubmatic.com/news/blog/new-quality-initiatives-creating-a-cleaner-marketplace-with-sellers-json-openrtb-supply-chain-object/
• OpenRTB - IAB Tech Lab - https://iabtechlab.com/standards/openrtb/
• What Is OpenRTB 2.6? - Index Exchange - https://www.indexexchange.com/blog/what-is-openrtb-2-6/
• digital ad fraud handbook | IAB Australia - https://iabaustralia.com.au/resource/digital-ad-fraud-handbook/
• Key Benefits of OpenRTB for Publishers & Advertisers - Rishabh Software - https://www.rishabhsoft.com/blog/key-benefits-of-openrtb