I programmatisk annonsering blir bid requestet ofte behandlet som en teknisk detalj – en JSON-payload som bare utviklere og SSP-er trenger å forholde seg til.
Det er en feil.
Et bid request er ikke bare en melding. Det er den kommersielle definisjonen av en annonsemulighet. Hver auksjon. Hver beslutning om å by eller la være. Hver CPM. Alt starter med bid requestet.
Derfor vil denne serien i 9 deler (jepp, 9 deler) se på bid requests fra både et kommersielt perspektiv (hvordan kjøpere verdsetter inventory) og et teknisk perspektiv (den ad-tech-en som kjører bak kulissene når kampanjer møter publisher-inventory). Med min bakgrunn blir det først og fremst ad-tech-perspektivet som får plass i denne serien 🤓
La oss først få begrepene på plass
Før vi går i dybden, hjelper det å få noen sentrale begreper på plass:
- Bid request – Meldingen som sendes før det finnes noen bud. Den beskriver annonsemuligheten og ber kjøperne om å svare. Sendes fra publisheren.
- Bid – Et enkelt prisbud på en spesifikk annonsemulighet. Sendes fra kjøperen.
- Auksjon – Prosessen som sammenligner flere bud på den samme annonsemuligheten og kårer en vinner. Foregår hos publisheren.
- Impression – Når et kreativ (selve annonsefilen) lastes ned og rendres på brukerens enhet (dvs. at annonsen faktisk ble levert og vist).
- Ad unit – Plasseringen på siden som publisheren har definert, og der en impression kan finne sted. Kalles også ad-slot eller placement.
- Media types – De tillatte annonseformatene for en impression (banner, video, native, audio).
- Banner – Bilde- eller HTML-annonser som (ofte) rendres i plasseringer med faste størrelser.
- Video – Annonser som vises før (pre-roll), under (mid-roll), etter (post-roll) eller sammen med annet innhold (herunder in-stream og out-stream).
- Native – Annonser som defineres av assets og layoutregler fremfor faste størrelser, og som er designet for å matche innholdet rundt.
- Header bidding – En auksjon der flere kjøpere byr samtidig, før ad-serveren tar sin beslutning. Kjøres i nettleserens header.
- Prebid – Et open source-rammeverk for header bidding som brukes til å kjøre auksjoner og kommunisere med kjøpere.
- Client-side / Server-side – Om auksjonen kjøres i brukerens nettleser, eller om den sendes videre til en ekstern auksjonsserver som for eksempel Prebid Server. Kalles også C2S og S2S.
- OpenRTB – Open Real-Time Bidding: Den mest utbredte bransjestandarden, som definerer hvordan bid requests og bid responses er strukturert.
- SSP / DSP – Supply-Side Platforms selger inventory; Demand-Side Platforms kjøper det.
- Consent (samtykke) – De juridiske tillatelsene en bruker gir (eller avviser) til databehandling og personalisering av annonser – typisk kodet via rammeverk som TCF.
- TCF – Transparency & Consent Framework: Bransjestandarden i EU som standardiserer hvordan samtykke samles inn og sendes videre i bid requestet.
Disse begrepene utgjør det felles vokabularet i programmatic sett fra et teknisk perspektiv. Med den baselinen på plass kan vi zoome ut.
Så hva er et bid request egentlig?
Helt overordnet er et bid request en strukturert beskrivelse av én enkelt annonsemulighet, som sendes fra publisherens stack til potensielle kjøpere med ett enkelt spørsmål:
"Her er en annonsemulighet – vil du kjøpe den, og til hvilken pris?"
Alt i bid requestet finnes for å hjelpe kjøperen med å besvare nettopp dét spørsmålet.
De fem spørsmålene ethvert bid request må besvare
Uansett om du bruker Prebid, OpenRTB, client-side eller server-side header bidding, forsøker ethvert moderne bid request å besvare fem grunnleggende spørsmål:
- Hva selges? Er det et banner, en video eller en native-plassering? Hvilke størrelser, formater og begrensninger gjelder?
- Hvor selges det? Hvilket site, hvilken app eller hvilket miljø lever denne impressionen i? Hva er konteksten?
- Hvem ser muligens annonsen? Hva vet vi om brukeren via identitetsløsninger, first-party data eller kontekstuelle signaler?
- Under hvilke regler kan det selges? Hvilken personvernlovgivning gjelder? Hvilket samtykke er gitt (eller ikke gitt)?
- Hvordan skal auksjonen kjøres? Hvor mye tid er tilgjengelig? Hvem kjører auksjonen? Client-side eller server-side?
Hvis et bid request ikke kan besvare ett av disse 5 spørsmålene klart, vil bidderne enten by konservativt eller la være helt.
Derfor ser bid requests "kompliserte" ut
Hvis du noen gang har sett på et ekte bid request (eksempel fra jv.dk), har det sikkert føltes overveldende: nøstede objekter, extensions, ID-er, consent strings og supply chain-stier.
Den kompleksiteten finnes fordi et bid request må balansere tre motstridende hensyn:
- Standardisering: Kjøpere og selgere trenger et felles språk (OpenRTB).
- Fleksibilitet: Alle publishere, formater og markeder er forskjellige.
- Regulering & tillit: Personvernlovgivning, identitetstap og transparens i supply chain må alt sammen kodes inn i sanntid.
Resultatet er ikke pent, men det er med vilje. Og ja – noen ganger er det virkelig irriterende å jobbe med.
Derfor er det viktig (selv om du ikke skriver kode)
Uansett om du jobber med publishing, monetisering, ad operations, salg, produkt eller ad-tech, er det bid requestet som avgjør:
- Hvordan kjøpere verdsetter inventoryet ditt
- Hvilken demand som kan delta
- Hvordan identitet og samtykke påvirker yielden din
- Hvorfor to impressions som ser "identiske" ut, kan monetisere vidt forskjellig
Hvis du ikke forstår hva som ligger i bid requestene dine, har du ikke full kontroll over omsetningen din.
Dette kommer serien til å dekke
I de kommende artiklene plukker jeg bid requestet fra hverandre, én hovedkomponent om gangen – publisert ukentlig over de neste 9 ukene:
- Auksjonen & kontrollaget
- Impressionen (hva er til salgs?)
- Bidder-konfigurasjon & kommersiell kontekst
- Identitet & brukersignaler
- Personvern, samtykke & regulering
- Kontekst: Site, app, enhet & miljø
- OpenRTB & standardisering
- Tillit & transparens i supply chain
- Custom data & publisher-strategi
Hver artikkel fokuserer på hvorfor en gitt del finnes – ikke bare hvordan den ser ut.
Neste: Del 1 av 9: Auksjonen & kontrollaget →
