RTB Data: Understanding Real-Time Bidding for OSINT and GEOINT
RTB data–short for real-time bidding–has become a significant source of device location information for intelligence operations, but it’s a difficult ecosystem to understand. It originates from programmatic advertising, a $600+ billion global marketplace where digital ad impressions are bought and sold through automated auctions. Major ad exchanges process trillions of bid requests annually, each of which may contain location signals from devices.
This post is a guide to the basics of RTB data and the larger real-time bidding ecosystem for teams in the GEOINT space.
The RTB and Programmatic Advertising Ecosystem
Programmatic advertising operates through specialized platforms that automate the buying and selling of digital ad space. When someone opens a mobile app or visits a website with available ad inventory, an automated auction determines which advertisement gets displayed. These auctions follow technical standards that define how information flows between platforms.
Three types of platforms run this system. Supply-side platforms (SSPs) represent publishers and app developers who have ad space to sell. Demand-side platforms (DSPs) represent advertisers who want to buy that space. Ad exchanges sit in the middle like auction houses, connecting supply and demand. Each platform plays a role in generating and transmitting the data that is captured and made commercially available.
How RTB Auctions Generate Location Data
The auction starts when ad inventory becomes available. Someone opens a mobile app with ad-supported content, creating an opportunity to display an advertisement. The app's software development kit (SDK) recognizes this and communicates with the app developer's SSP.
The SSP constructs a bid request in accordance with the OpenRTB protocol specification. For mobile apps, this is typically a standardized data package (JSON format) that includes dozens of potential data fields. The SSP sends this bid request to one or more ad exchanges.
Most exchanges impose strict latency requirements. The entire auction cycle (from bid request to ad delivery) must complete within 100-200 milliseconds depending on whether it's mobile web or an in-app placement. This tight timing constraint has major implications for data quality.
The bid request broadcasts to multiple DSPs simultaneously through the exchange. Each DSP has 50-120 milliseconds to evaluate the opportunity and submit a bid if interested and the highest bidder wins. Their ad is sent back through the exchange to the SSP and into the app, and the user sees the advertisement.
What Bid Requests Actually Contain
The OpenRTB specification defines over 150 possible data fields that can appear in a bid request. Device information includes the manufacturer, model, operating system, mobile advertising identifier (IDFA for iOS or AAID for Android), carrier, and connection type (wifi or cellular). But what isn’t captured or sold is the name or phone number of whoever saw the ad. All of this is anonymous.
The location source field indicates where the location data originated. Generally, it’s either device derived (GPS, wifi, cell tower) or IP derived. The precision of the location captured can vary on type, but also on the app or device itself. Some types of data collection are very broad and while others can be precise, but an SDK might not require precision. This means the location data aspect of RTB data, though significant in scale, has significant variability in precision.
Another problem is that the bid requests contain whatever location information the device's operating system provides at the moment the ad opportunity occurs. The "seconds since location was captured" field theoretically indicates how stale the location data is, but this field is not always populated. Research on mobile advertising data shows that up to 20-30% of location signals in bid requests are cached, meaning they represent where the device was minutes or hours earlier rather than its current position.
The Multi-Hop Journey Through Ad Tech Infrastructure
A single bid request often gets copied and sent to multiple platforms simultaneously. After the SSP creates the initial bid request, it typically sends copies to 5-15 different ad exchanges at once. Each exchange then forwards the bid request to 10-50 DSPs that have relationships with that exchange.
One ad impression might result in a bid request being transmitted to 75-750 different platforms within milliseconds. Each platform in this chain receives the complete bid request data, including all location information, regardless of whether it submits a bid or wins the auction.
This broad distribution is intentional. More potential buyers seeing an advertising opportunity means more competitive auctions and higher revenue. But this also means RTB data propagates widely throughout the advertising ecosystem. Any company operating a DSP, exchange, or other platform in the bidstream can potentially collect and store this data.
Industry estimates suggest that a typical high-traffic mobile app might see each impression generate bid requests to 100+ platforms. Multiply this by thousands of apps and billions of daily active users, and you understand why RTB data sources can claim coverage of hundreds of millions or billions of devices.
Why RTB Data Varies Between Providers
Your access point within the bidstream determines what you can collect. A company operating a DSP receives bid requests only for opportunities that match its advertisers' targeting criteria. If their advertisers focus on retail, they might see extensive data from shopping apps but limited exposure to news or gaming apps.
A company with exchange-level access sees significantly more. Exchanges sit at choke points where requests from multiple SSPs flow through to multiple DSPs. An exchange with relationships to major SSPs and DSPs might observe 50-200 billion bid requests daily.
The timing of data collection matters. Some providers capture bid requests as auctions start (before any bidding occurs), accessing raw information transmitted by SSPs. Others collect data after auctions complete, potentially receiving modified information. Some exchanges normalize or enrich location data before forwarding bid requests to DSPs, which means later-stage collection might include location estimates not present in the original request.
RTB Data for Intelligence Operations
Understanding RTB infrastructure matters because the auction-based origin of this data creates both opportunities and challenges that differ from other location intelligence sources.
Signal Density and Geographic Coverage
RTB data's main advantage is scale. The programmatic advertising ecosystem reaches approximately 5 billion internet users globally through hundreds of thousands of ad-supported websites and mobile applications. Mobile in-app advertising alone generates an estimated 30-50 billion daily bid requests in the United States.
This density enables population-level analytics that would be difficult with more limited data sources. Tracking movement patterns around critical infrastructure, identifying gathering points, or analyzing cross-border flows all benefit from the breadth of RTB data.
But coverage is not uniform. Signal density correlates directly with advertising activity. Free-to-play mobile games, social media apps, and news applications generate high volumes of bid requests because they're heavily monetized through advertising. Productivity apps, paid applications, and communication tools generate fewer signals, and geographic coverage skews toward regions with mature digital advertising markets.
The Speed-Quality Tradeoff: Complementing SDK-Based Intelligence
Real-time bidding's 100-200 millisecond timeline creates fundamental tension between speed and data quality. Location information transmitted in bid requests represents whatever the device's operating system provides at that instant, with no opportunity for verification. Research examining advertising-derived location data shows that 20-30% of bid requests contain cached locations from minutes or hours earlier, and 30-50% use IP-derived approximations rather than GPS. Horizontal accuracy values span an enormous range, from under 10 meters to over 50,000 meters within the same dataset.
This is why RTB data works best when combined with other geolocation data sources rather than as a standalone dataset. SDK-based data collection, in which location information is gathered directly from applications with explicit user consent and built-in quality controls, provides higher-fidelity signals for specific devices or geographic areas.
The optimal approach integrates RTB's scale and coverage with SDK data's accuracy and verification. RTB data identifies patterns across large populations or detects anomalies requiring further investigation. SDK data provides the precision necessary for tactical analysis or specific targeting when investigations require confidence about actual device presence and patterns at specific location (e.g. pattern of life analysis.)
Conclusion
For intelligence professionals, understanding how RTB auctions work, what the OpenRTB specification actually defines, and how data propagates through exchanges matters when evaluating this increasingly common intelligence source. RTB data's value comes not from replacing purpose-built collection methods but from complementing them with scale and coverage that reflect the reach of a $600 billion global advertising ecosystem.
Want to explore how different location intelligence sources compare for OSINT operations? Contact us to speak with an expert about integrating RTB data or SDK data with other collection methods.
