Learn

← Track E: Server-Side and Advanced Media
L4-L5

E2

Cookie sync and stored requests

In this lesson you will
  • Explain why server-side bidders’ IDs must be synced (/cookie_sync), including cooperative syncing.
  • Explain stored requests: OpenRTB blocks stored server-side and merged via ortb2Imp, central for mobile-app and AMP.

Move a bidder server-side and it suddenly cannot recognize anyone, 0% match rate on day one. The fix is cookie sync: a handshake that teaches the server which user is which. Until it runs, server-side demand bids blind.

Server-side bidders’ IDs must be synced through the /cookie_sync endpoint. Cooperative syncing lets bidders share sync slots, so the page is not flooded with sync pixels.

Key idea

A freshly onboarded s2s bidder starts near 0% match rate and climbs as syncs accumulate. It is not broken, it is warming up. Judge it after the sync population matures, not on launch day.

Stored requests

Stored requests are OpenRTB blocks kept on the server and merged into the request via ortb2Imp, so the client sends a small reference instead of a full config. They are central to mobile-app and AMP delivery, where the client cannot carry a heavy Prebid setup.

Quick check

A new server-side bidder shows a 0% match rate on launch day. Broken, or expected?

Key concepts
/cookie_sync and cooperative syncingStored requestsortb2Imp mergeMobile-app and AMP delivery
Going deeper

To really lock this in: trace why a freshly onboarded s2s bidder has a 0% match rate and how cooperative sync resolves it, then design a stored-request layout.

Where this leads
DEBUG

Proposed cookie-sync timeline simulator.

Bidcliq Academy · E2: Cookie sync and stored requests