A Publisher’s Guide to Prebid Server with AMP: How Real-Time Header Bidding Works

Serving fast, monetizable ad experiences on AMP pages has long challenged publishers. AMP accelerates page loads but comes with limitations—most notably, it blocks the use of in-page JavaScript wrappers like Prebid.js, restricting standard header bidding setups.

Prebid Server addresses this gap, letting publishers run header bidding workflows on AMP through its Real Time Configuration (RTC) support. For publishers aiming to maximize mobile revenue without sacrificing speed or user experience, understanding this setup is crucial.

How Header Bidding Works on AMP with Prebid Server

AMP’s primary goal is speed, but that speed comes at the cost of not allowing rich JavaScript on the page. That effectively eliminates Prebid.js and breaks the common header bidding flow. Prebid Server offers a solution using Real Time Configuration (RTC), a standardized AMP mechanism for server-to-server bidding.

The AMP RTC Flow: Step-by-Step

– Each ad slot on an AMP page makes an independent RTC call to Prebid Server, passing parameters like sizes and targeting data, typically using a stored request ID.
– Prebid Server looks up the stored configuration, merges in dynamic parameters, and runs a header bidding auction off-page.
– Results—specifically, ad server targeting keys—are returned to the AMP page.
– AMP aggregates targeting from all RTC providers and calls the ad server (such as GAM), which decides the winning creative.
– The actual winning creative is retrieved from a cache and rendered in the user’s browser via Prebid Universal Creative.

Common Publisher Mistakes to Avoid

– Failing to keep stored requests updated when bidder setups change will break AMP monetization.
– Not testing different RTC invocation options (such as vendor config vs. direct URL) may lead to targeting errors or unsupported parameters.
– Overlooking cache or timeout parameters can reduce yield and degrade ad experience for users on slow connections.

Configuring AMP Pages for Prebid Server

Setting up header bidding on AMP is not plug-and-play. Publishers must configure their AMP pages thoughtfully—both for reliability and yield.

Placing AMP RTC Tags

AMP uses the `` component with an `rtc-config` attribute to declare which RTC endpoints (like Prebid Server) should be called for each ad slot. This can be done either with pre-defined vendor strings (e.g., ‘prebidrubicon’) or direct URLs built with slot and account details. Vendor strings typically require a unique stored request ID, while direct URLs may allow more flexible parameterization.

Passing Key Parameters

Critical auction parameters—like slot sizes, page URL, GDPR consent, and custom targeting—must be configured in either the stored request or passed in the AMP RTC URL. For scale, maintaining a clean and consistent stored request strategy across your inventory is essential. Missed parameters will lead to failed auctions or inaccurate ad delivery.

What Happens Inside Prebid Server: Request Resolution and Auction

Once Prebid Server gets a request from AMP, it performs several backend operations that directly impact yield and targeting precision.

Stored Request Lookup

Prebid Server relies heavily on the `tag_id` (stored request ID). This determines the eligible bidders, key auction settings, and any base targeting logic. If this lookup fails—or if stored requests are out-of-sync with your live auction logic—the entire header bidding flow breaks.

Auction Execution and Response Shaping

Prebid Server enforces privacy rules, assembles the OpenRTB request with real-time AMP parameters, and executes the auction with available demand partners. The response is translated to AMP-compatible key-value pairs. These are not full bid payloads, but targeting keys your ad server will recognize when making the final ad selection.

Delivery and Display: Interaction with the Ad Server and Universal Creative

After receiving targeting from Prebid Server RTC calls, the AMP page communicates with the ad server, which selects the winner. Publishers must ensure the creative can be displayed securely and quickly.

Retrieving and Rendering the Winning Creative

When a Prebid bid wins in your ad server, the Prebid Universal Creative JavaScript is triggered from the ad server response. It then retrieves the actual creative (ad markup) from Prebid Server Cache using cache keys provided in the targeting response, and writes it into an AMP-safe iframe for display.

Troubleshooting Common Delivery Failures

Broken cache keys, mismatched targeting, or misconfigured RTC settings can prevent ads from rendering or result in fallback creatives. Publishers should monitor ad delivery logs and implement alerting when creative fails to load, especially for high-traffic AMP placements.

What this means for publishers

For publishers, Prebid Server with AMP means you can bring advanced header bidding demand to mobile pages without compromising page speed. However, success relies on careful configuration, regular updates to stored requests, and close coordination with your ad ops and development teams. This approach increases monetization options but also introduces new operational dependencies on Prebid Server, proper cache management, and robust monitoring.

Practical takeaway

To maximize AMP revenue using Prebid Server, publishers need to treat stored requests as active code—not set-and-forget configuration. Regularly audit bidder setups, targeting parameters, and cache integrations to ensure every ad slot on your AMP pages is auction-eligible.

Test both common AMP RTC integration patterns (vendor string and direct URL) to decide which fits your scale and workflow. Automate monitoring to catch setup failures before they impact revenue. Stay on top of Prebid, AMP, and ad server updates, and invest in robust documentation for your team. The investment in ongoing maintenance will pay off with faster, more profitable mobile experiences.