I programmatisk annoncering bliver bid requestet ofte behandlet som en teknisk detalje – en JSON-payload, som kun udviklere og SSP'er behøver at forholde sig til.
Det er en fejl.
Et bid request er ikke bare en besked. Det er den kommercielle definition af en annoncemulighed. Hver auktion. Hver beslutning om at byde eller lade være. Hver CPM. Det hele starter med bid requestet.
Derfor vil denne serie i 9 dele (jep, 9 dele) se på bid requests fra både et kommercielt perspektiv (hvordan købere værdisætter inventory) og et teknisk perspektiv (den ad-tech, der kører bag kulisserne, når kampagner møder publisher-inventory). Med min baggrund bliver det primært ad-tech-perspektivet, der fylder i denne serie 🤓
Lad os først få styr på begreberne
Før vi går i dybden, hjælper det at få nogle centrale begreber på plads:
- Bid request – Beskeden, der sendes, før der findes nogen bud. Den beskriver annoncemuligheden og beder køberne om at svare. Sendes fra publisheren.
- Bid – Et enkelt prisbud på en specifik annoncemulighed. Sendes fra køberen.
- Auktion – Processen, der sammenligner flere bud på den samme annoncemulighed og udvælger en vinder. Foregår hos publisheren.
- Impression – Når et kreativ (selve annoncefilen) downloades og renderes på brugerens enhed (dvs. at annoncen rent faktisk blev leveret og vist).
- Ad unit – Den placering på siden, som publisheren har defineret, og hvor en impression kan finde sted. Kaldes også ad-slot eller placement.
- Media types – De tilladte annonceformater for en impression (banner, video, native, audio).
- Banner – Billed- eller HTML-annoncer, der (ofte) renderes i placeringer med faste størrelser.
- Video – Annoncer, der vises før (pre-roll), under (mid-roll), efter (post-roll) eller sammen med andet indhold (herunder in-stream og out-stream).
- Native – Annoncer, der defineres af assets og layoutregler frem for faste størrelser, og som er designet til at matche det omkringliggende indhold.
- Header bidding – En auktion, hvor flere købere byder samtidig, før ad-serveren træffer sin beslutning. Afvikles i browserens header.
- Prebid – Et open source-framework til header bidding, der bruges til at afvikle auktioner og kommunikere med købere.
- Client-side / Server-side – Om auktionen afvikles i brugerens browser, eller om den sendes videre til en ekstern auktionsserver som fx Prebid Server. Kaldes også C2S og S2S.
- OpenRTB – Open Real-Time Bidding: Den mest udbredte branchestandard, som definerer, hvordan bid requests og bid responses er struktureret.
- SSP / DSP – Supply-Side Platforms sælger inventory; Demand-Side Platforms køber det.
- Consent (samtykke) – De juridiske tilladelser, en bruger giver (eller afviser) til databehandling og personalisering af annoncer – typisk kodet via frameworks som TCF.
- TCF – Transparency & Consent Framework: Branchestandarden i EU, der standardiserer, hvordan samtykke indsamles og sendes videre i bid requestet.
Disse begreber udgør det fælles ordforråd i programmatic set fra et teknisk perspektiv. Med den baseline på plads kan vi zoome ud.
Så hvad er et bid request egentlig?
Helt overordnet er et bid request en struktureret beskrivelse af én enkelt annoncemulighed, som sendes fra publisherens stack til potentielle købere med ét simpelt spørgsmål:
"Her er en annoncemulighed – vil du købe den, og til hvilken pris?"
Alt i bid requestet findes for at hjælpe køberen med at besvare netop dét spørgsmål.
De fem spørgsmål, ethvert bid request skal besvare
Uanset om du bruger Prebid, OpenRTB, client-side eller server-side header bidding, forsøger ethvert moderne bid request at besvare fem grundlæggende spørgsmål:
- Hvad sælges der? Er det et banner, en video eller en native-placering? Hvilke størrelser, formater og begrænsninger gælder?
- Hvor sælges det? Hvilket site, hvilken app eller hvilket miljø lever denne impression i? Hvad er konteksten?
- Hvem ser muligvis annoncen? Hvad ved vi om brugeren via identitetsløsninger, first-party data eller kontekstuelle signaler?
- Under hvilke regler må det sælges? Hvilken privatlivslovgivning gælder? Hvilket samtykke er der givet (eller ikke givet)?
- Hvordan skal auktionen afvikles? Hvor meget tid er der til rådighed? Hvem kører auktionen? Client-side eller server-side?
Hvis et bid request ikke kan besvare ét af disse 5 spørgsmål klart, vil bidderne enten byde konservativt eller helt lade være.
Derfor ser bid requests "komplicerede" ud
Hvis du nogensinde har kigget på et rigtigt bid request (eksempel fra jv.dk), har det sikkert føltes overvældende: nestede objekter, extensions, ID'er, consent strings og supply chain-stier.
Den kompleksitet findes, fordi et bid request skal balancere tre modsatrettede hensyn:
- Standardisering: Købere og sælgere har brug for et fælles sprog (OpenRTB).
- Fleksibilitet: Alle publishere, formater og markeder er forskellige.
- Regulering & tillid: Privatlivslovgivning, identitetstab og transparens i supply chain skal alt sammen indkodes i realtid.
Resultatet er ikke kønt, men det er med vilje. Og ja – nogle gange er det virkelig irriterende at arbejde med.
Derfor er det vigtigt (også selvom du ikke skriver kode)
Uanset om du arbejder med publishing, monetarisering, ad operations, salg, produkt eller ad-tech, er det bid requestet, der afgør:
- Hvordan købere værdisætter dit inventory
- Hvilken demand der kan deltage
- Hvordan identitet og samtykke påvirker din yield
- Hvorfor to impressions, der ser "identiske" ud, kan monetarisere vidt forskelligt
Hvis du ikke forstår, hvad der ligger i dine bid requests, har du ikke fuld kontrol over din omsætning.
Det kommer serien til at dække
I de kommende artikler skiller jeg bid requestet ad, én hovedkomponent ad gangen – udgivet ugentligt over de næste 9 uger:
- Auktionen & kontrollaget
- Impressionen (hvad er til salg?)
- Bidder-konfiguration & kommerciel kontekst
- Identitet & brugersignaler
- Privatliv, samtykke & regulering
- Kontekst: Site, app, enhed & miljø
- OpenRTB & standardisering
- Tillid & transparens i supply chain
- Custom data & publisher-strategi
Hver artikel fokuserer på, hvorfor en given del findes – ikke kun hvordan den ser ud.
Serien udkommer hver onsdag kl. 12:00 (CEST)! Hvis du har lært noget eller har fået lyst til at dykke dybere ned i emnet, er du meget velkommen til at kommentere eller skrive til mig i DM'erne.
Og hvis du læser det her, sætter jeg stor pris på, at du har taget dig tid i en travl hverdag til at læse min artikel. Vi ses (forhåbentlig) i næste artikel: Auktionen & kontrollaget
