Real-Time Bidding Förklarat: Hur RTB och Header Bidding Fungerar

Real-time bidding (RTB) är auktionen per visning bakom det mesta programmatic advertising: när en sida med en annonsplats laddas, sänder en exchange ut en budförfrågan som beskriver platsen, sidan och en anonymiserad användare; efterfrågeplattformar utvärderar den och lägger bud; vinnarens annons renderas — allt på ungefär en tiondels sekund, innan sidan har målat färdigt. Header bidding är publisher-sida tekniken som låter många exchanges konkurrera om samma plats simultant, och OpenRTB är protokollet de alla talar. Den här guiden går igenom auktionen från början till slut, förklarar maskineriet runt den, och täcker den delen de flesta förklaringar hoppar över: var native-annonser passar in i modellen och var de bryter mot den.

Auktionen, steg för steg#

En visning, en auktion, sex steg:

1. En sida laddas och en annonsplats aktiveras. Publisherns sida begär en annons för en specifik placering — storlek, position, kontext.
2. Supply-sidan paketerar en budförfrågan. Publisherns supply-side platform (SSP) bygger en strukturerad förfrågan: platsdimensioner, sid-URL, användargeo, enhet, integritetsgodkända identifierare.
3. Exchange:n sprider ut den. En ad exchange sänder förfrågan till anslutna efterfrågepartners — dussintals av dem, parallellt.
4. Efterfrågeplattformar utvärderar och lägger bud. Varje demand-side platform (DSP) poängsätter visningen mot sina annonsörers målgruppsanpassning, budgetar och frekvenstak, svarar sedan med ett budpris och en kreativ — eller avstår.
5. Auktionen avslutas. Exchange:n väljer vinnaren (first-price, på dagens marknad), meddelar DSP:n och returnerar den vinnande kreativen.
6. Annonsen renderas och pengar flyttas. Kreativen visas, visningsspårare aktiveras och publishern betalas avslutningspriset minus avgifterna för alla i vägen.

Hela rundresan körs inom en strikt timeout — bud som kommer för sent räknas helt enkelt inte — vilket är varför ekosystemet är besatt av latens.

Rollbesättningen#

Gränserna suddas ständigt — stora SSPs driver exchanges, DSPs köper från varandra, och samma bolag kan sitta på båda sidor — vilket är en del av varför transparens i leveransvägen blev en branschfråga överhuvudtaget. För det bredare sammanhanget av hur dessa bitar sätts ihop till en köpstrategi, se programmatic advertising.

First-price vs second-price: varför auktionen ändrades#

Klassisk RTB körde second-price-auktioner: vinnaren betalade precis över tvåans bud, så att buda ditt sanna värde var säkert. Sedan satte header bidding samma visning i flera parallella auktioner samtidigt, och "second price" slutade betyda något — en second-price-vinst i en auktion fick fortfarande konkurrera first-price mot de andra auktionernas vinnare. Lägg till att exchanges tyst applicerade golv och avgifter, och prisupptäckten blev ogenomskinlig.

Branschen konvergerade mot first-price-auktioner: vinnaren betalar vad de bjöd. Enklare och ärligare, men den flyttade strategibördan till köparna — buda ditt takvärde varje gång och du betalar systematiskt för mycket, vilket är varför DSPs nu kör bid shading: algoritmer som uppskattar det lägsta vinnande priset och budar närmare det. Om du köper programmatic och din DSP:s shading är dålig, finansierar du skillnaden.

Header bidding: fixen för waterfall#

Innan header bidding körde publishers en waterfall: efterfråkekällor kallades en i taget i en fast prioriteringsordning, var och en fick en chans att köpa till ett förinställt golv innan förfrågan "passades tillbaka" till nästa. Resultat: den första källan i kön kunde köpa undervärderat inventory medan bättre bud längre ner aldrig såg visningen.

Header bidding inverterar detta. Ett skript i sidhuvudet (eller, i server-sida varianten, en proxy som sidan anropar en gång) begär bud från många SSPs och exchanges samtidigt, passerar sedan det bästa budet till publisherns ad server för att konkurrera med direktförsäljda kampanjer. Varje efterfråkekälla ser varje visning i samma ögonblick, på lika villkor.

Avvägningarna är operativa: client-side header bidding lägger till sidlatens och JavaScript-vikt; server-side byter ut det mot lägre cookie-match-rates. De flesta sofistikerade publishers kör en hybrid. För köpare är den praktiska konsekvensen enklare: dagarna av att hitta systematiskt underprissatt inventory i en dåligt konfigurerad waterfall är förbi — fördel kommer nu från kreativ och funnel, inte auktionsarbitrage.

OpenRTB och transparensskiktet#

OpenRTB — en IAB Tech Lab-standard — är JSON-protokollet som budförfrågan och svaret färdas över: standardiserade objekt som beskriver visningen, sajten, enheten, användaren och budet självt. Det är därför en DSP kan prata med femtio exchanges utan femtio integrationer.

Runt protokollet finns ett offentligt transparensskikt byggt för att bekämpa bedrägeri och oklar vidareförsäljning:

• ads.txt — en fil på publisherns domän som listar vem som är auktoriserad att sälja dess inventory.
• sellers.json — spegelbilden: exchanges publicerar vilka de representerar.
• The schain object — varje OpenRTB-förfrågan bär på kedjan av mellanhänder som visningen passerat genom.

Dessa artefakter är offentliga av design — vilket betyder att utomstående observatörer kan granska programmatic-vägar, inte bara deltagare. Den granskningsbarheten är grunden för modern supply-chain-analys.

Var native-annonser passar — och var de inte gör det#

Här är delen display-centrerade förklaringar får fel. De stora native-nätverken — Taboola, Outbrain, MGID, Revcontent — säljer inte primärt genom de öppna RTB-rören. Var och en driver sin egen slutna marknadsplats: annonsörer budar inom nätverkets plattform, och native-ad-auktionen sker nätverksinternt för varje widget-plats, per användare, per sidvisning.

RTB-koncept gäller fortfarande — det är en real-time-auktion per visning med golv och pacing — men den konkurrerande arenan är annorlunda. Ditt Taboola-bud konkurrerar mot andra Taboola-annonsörer, inte mot den öppna exchange:n. OpenRTB har en Native Ads-spec, och native-inventory flödar programmatic vid kanterna; nätverk säljer också vidare varandras efterfrågan, vilket producerar leveransvägar med fler hopp än en typisk display-visning. Vi spårade riktiga exempel på dessa kedjor — widget till nätverk till återförsäljare till annonsör — i the native ad supply chain, explained.

Praktiska konsekvenser för en mediabuyer:

• DSP-verktyg ser mestadels inte native-nätverksauktioner. Programmatic-dashboards kommer inte berätta vad som körs på Taboola.
• Konkurrens är nätverkslokal. Att vinna på MGID handlar om att slå MGID:s annonsörer i din geo och bransch, inte den globala programmatic-marknaden.
• Leveranskedjan är ändå observerbart. Eftersom serverade annonser och deras förfrågekedjor är offentliga kan oberoende observatörer klassificera vem som serverade vad — tekniken bakom how ad spy tools capture native ads.

Varför detta spelar roll när du köper#

Tre arbetskonklusioner från mekaniken:

1. Känn din väg, känn dina avgifter. Varje mellanhand i kedjan tar ett snitt innan publishern betalas; på vidareförsålt native-inventory multipliceras hoppen. Färre hopp betyder generellt att mer av din dollar köper uppmärksamhet.

2. First-price ändrade budgivning. Buda inte ditt takvärde reflexmässigt; förstå vilken shading din plattform applicerar — och på native-nätverks interna auktioner, testa budnivåer empiriskt eftersom ingen shading görs åt dig.

3. På native ersätter konkurrensanalys auktionsdata. Du kan inte fråga Taboolas auktion, men du kan observera dess utdata. OpenAdLibrary:s leveranskedjeklassificering — byggd från 6,8 miljoner+ annonsobservationer över 49 nätverk (juli 2026) — visar vilka nätverk och återförsäljare som faktiskt serverade en annons, per kreativ, i ad intelligence platform. Att läsa den serverade verkligheten slår att gissa på auktionen.

RTB är en enkel idé utförd i absurd skala: en auktion per visning, avslutad innan sidan målas. Förstå auktionen, protokollet och vägarna — och programmatic-akronymsoppan reduceras till rörledningar.