Implementing the 51Degrees RTD Module in Prebid: Device Intelligence for Better Bidding
Device fragmentation and constant browser changes make accurate identification of user devices a moving target for publishers. Yet, understanding what devices your audience uses is crucial to maximize bid values and deliver ad campaigns effectively.
The 51Degrees RTD (Real-Time Data) module for Prebid.js addresses these challenges by enriching bid requests with granular, up-to-date device data. This guide explains what this means for your header bidding setup, how to implement it, and the real-world impact on monetization.
How the 51Degrees RTD Module Powers Device Detection in Prebid
The 51Degrees RTD module integrates directly with Prebid.js to enhance bid requests with rich device intelligence. Instead of relying on static rules, it calls a dynamic script served from 51Degrees’ cloud (or your own server), which interprets current browsing evidence—like user agent headers and API data—at runtime. This design ensures that your Prebid setup keeps pace with new device models, OS versions, and changing browser behaviors, all without manual code updates.
What Device Data Is Added to the OpenRTB Request?
The module populates critical fields in the device object, including type (mobile, tablet, desktop), manufacturer, model, screen dimensions, pixel density, and more. It also adds a unique permanent device ID and tracks whether third-party cookies are enabled. This level of detail allows demand partners to bid more precisely, especially for campaigns with device- or environment-specific requirements.
Real-World Example: Better Yield Through Accurate Device Targeting
Consider a scenario where a brand wants to target only high-end iOS devices with large screens. Without the 51Degrees module, some iPads and iPhones might not be properly identified, and the demand partner could underbid or skip eligible impressions. With 51Degrees, the RTD module can distinguish between various Apple models—even though iOS doesn’t expose this via common APIs—delivering complete device resolution and unlocking incremental revenue.
Integration and Configuration: Key Steps for Publishers
Integrating the 51Degrees RTD module is straightforward but requires careful attention to prerequisites and configuration to ensure reliable operation and optimal performance.
Resource Key and Cloud vs On-Premise Setup
You’ll need a resource key to use 51Degrees with the cloud service—this is free and easy to obtain from their configurator. If you require more control or scale, on-premise hosting is also an option (supporting .NET, Java, Node, PHP, Python). For most, cloud is fastest to test and deploy.
User Agent Client Hint (UA-CH) Permissions: The Most Overlooked Step
Modern browsers limit third-party access to high-entropy device data by default. Publishers must explicitly allow 51Degrees’ domain to access UA-CH headers, either by adding a meta tag to the page or setting Permissions-Policy headers on responses. Skipping this can result in incomplete device data or slower fallback logic, harming auction speed and bid accuracy.
Prebid.js Configurations and Typical Pitfalls
In your Prebid.js config, include the 51Degrees RTD provider under realTimeData.dataProviders. Set ‘waitForIt’ to true (or auctionDelay will be ignored), and specify a suitable auction delay—250ms is recommended. A common mistake is to set only the resourceKey without updating permissions for UA-CH, resulting in suboptimal performance.
Understanding Fallbacks and Browser-Specific Behavior
Device detection is challenging due to uneven browser and platform support for necessary APIs. The 51Degrees module uses the fastest, most reliable method available for each context, with automatic fallback handling.
Why Not Just Use getHighEntropyValues()?
While Chrome supports getHighEntropyValues (GHEV), not all browsers do, and future changes may restrict its utility further (such as privacy budgets). 51Degrees prefers delegated UA-CH headers where possible, only falling back to GHEV if absolutely necessary. On iOS, where neither option is available, the module employs custom heuristics to identify device models, uniquely empowering publishers to distinguish between Apple devices.
Concrete Scenarios—From Chrome to Safari and Firefox
• Chrome: With proper UA-CH delegation, publishers get maximum device data with lowest latency. If not configured, expect slower, less reliable fallbacks.
• iOS (Safari, Chrome): No GHEV support, but 51Degrees still identifies models, capturing value other device solutions miss.
• Firefox: Lacks GHEV and UA-CH features, so detection is limited by browser constraints but handled gracefully by the module.
What this means for publishers
By equipping header bidding auctions with complete, granular device information, publishers arm demand partners with what they need to bid confidently. This improves fill rates and CPMs for device-targeted campaigns, reduces missed bid opportunities, and future-proofs your stack against device fragmentation. Operationally, expect fewer troubleshooting headaches when campaigns require niche device targeting, and a smoother path toward a cookieless or privacy-regulated landscape.
Practical takeaway
Publishers should prioritize enabling the 51Degrees RTD module if maximizing device-targeted yield is a priority. Start with the free cloud solution, secure a resource key, and ensure UA-CH permissions are correctly configured—this step is critical and easily overlooked. Monitor test auctions with debug mode enabled to confirm device data is being populated as expected.
Be aware that the quality of device data is only as good as your Permissions-Policy setup—review this if you see unexpected results. Regularly update your Prebid build, and reassess delay settings to balance auction speed and data completeness.
Ultimately, integrating the 51Degrees RTD module sharpens your ad inventory’s value for buyers, smooths over browser fragmentation headaches, and gives publishers practical control over how device-level intelligence drives monetization.
