I programmatisk annonsering behandlas bid requesten ofta som en teknisk detalj – en JSON-payload som bara utvecklare och SSP:er behöver förhålla sig till.
Det är ett misstag.
En bid request är inte bara ett meddelande. Det är den kommersiella definitionen av en annonsmöjlighet. Varje auktion. Varje beslut om att bjuda eller låta bli. Varje CPM. Allt börjar med bid requesten.
Därför kommer den här serien i 9 delar (japp, 9 delar) att titta på bid requests både ur ett kommersiellt perspektiv (hur köpare värderar inventory) och ett tekniskt perspektiv (den adtech som körs bakom kulisserna när kampanjer möter publisher-inventory). Med min bakgrund blir det främst adtech-perspektivet som tar plats i den här serien 🤓
Låt oss först reda ut begreppen
Innan vi går på djupet hjälper det att få några centrala begrepp på plats:
- Bid request – Meddelandet som skickas innan det finns några bud. Det beskriver annonsmöjligheten och ber köparna att svara. Skickas från publishern.
- Bid – Ett enskilt prisbud på en specifik annonsmöjlighet. Skickas från köparen.
- Auktion – Processen som jämför flera bud på samma annonsmöjlighet och utser en vinnare. Sker hos publishern.
- Impression – När ett kreativ (själva annonsfilen) laddas ner och renderas på användarens enhet (dvs. att annonsen faktiskt levererades och visades).
- Ad unit – Den placering på sidan som publishern har definierat, och där en impression kan äga rum. Kallas också ad-slot eller placement.
- Media types – De tillåtna annonsformaten för en impression (banner, video, native, audio).
- Banner – Bild- eller HTML-annonser som (ofta) renderas i placeringar med fasta storlekar.
- Video – Annonser som visas före (pre-roll), under (mid-roll), efter (post-roll) eller tillsammans med annat innehåll (inklusive in-stream och out-stream).
- Native – Annonser som definieras av assets och layoutregler i stället för fasta storlekar, och som är designade för att matcha det omgivande innehållet.
- Header bidding – En auktion där flera köpare bjuder samtidigt, innan ad-servern fattar sitt beslut. Körs i webbläsarens header.
- Prebid – Ett open source-ramverk för header bidding som används för att köra auktioner och kommunicera med köpare.
- Client-side / Server-side – Om auktionen körs i användarens webbläsare, eller om den skickas vidare till en extern auktionsserver som t.ex. Prebid Server. Kallas också C2S och S2S.
- OpenRTB – Open Real-Time Bidding: Den mest utbredda branschstandarden, som definierar hur bid requests och bid responses är strukturerade.
- SSP / DSP – Supply-Side Platforms säljer inventory; Demand-Side Platforms köper det.
- Consent (samtycke) – De juridiska tillstånd en användare ger (eller nekar) till databehandling och personalisering av annonser – typiskt kodat via ramverk som TCF.
- TCF – Transparency & Consent Framework: Branschstandarden i EU som standardiserar hur samtycke samlas in och skickas vidare i bid requesten.
Dessa begrepp utgör det gemensamma ordförrådet i programmatic sett ur ett tekniskt perspektiv. Med den baslinjen på plats kan vi zooma ut.
Så vad är en bid request egentligen?
Helt övergripande är en bid request en strukturerad beskrivning av en enda annonsmöjlighet, som skickas från publisherns stack till potentiella köpare med en enkel fråga:
"Här är en annonsmöjlighet – vill du köpa den, och till vilket pris?"
Allt i bid requesten finns för att hjälpa köparen att besvara just den frågan.
De fem frågorna varje bid request måste besvara
Oavsett om du använder Prebid, OpenRTB, client-side eller server-side header bidding försöker varje modern bid request besvara fem grundläggande frågor:
- Vad säljs? Är det en banner, en video eller en native-placering? Vilka storlekar, format och begränsningar gäller?
- Var säljs det? Vilken sajt, vilken app eller vilken miljö lever denna impression i? Vad är kontexten?
- Vem ser möjligen annonsen? Vad vet vi om användaren via identitetslösningar, first-party-data eller kontextuella signaler?
- Under vilka regler får det säljas? Vilken integritetslagstiftning gäller? Vilket samtycke har getts (eller inte getts)?
- Hur ska auktionen köras? Hur mycket tid finns tillgänglig? Vem kör auktionen? Client-side eller server-side?
Om en bid request inte kan besvara en av dessa 5 frågor tydligt kommer bidders antingen att bjuda konservativt eller helt låta bli.
Därför ser bid requests "komplicerade" ut
Om du någonsin har tittat på en riktig bid request (exempel från jv.dk) har det säkert känts överväldigande: nästlade objekt, extensions, ID:n, consent strings och supply chain-vägar.
Den komplexiteten finns eftersom en bid request måste balansera tre motstridiga hänsyn:
- Standardisering: Köpare och säljare behöver ett gemensamt språk (OpenRTB).
- Flexibilitet: Alla publishers, format och marknader är olika.
- Reglering & tillit: Integritetslagstiftning, identitetsförlust och transparens i supply chain måste allt kodas in i realtid.
Resultatet är inte vackert, men det är avsiktligt. Och ja – ibland är det verkligen irriterande att arbeta med.
Därför är det viktigt (även om du inte skriver kod)
Oavsett om du arbetar med publishing, monetarisering, ad operations, försäljning, produkt eller adtech är det bid requesten som avgör:
- Hur köpare värderar ditt inventory
- Vilken demand som kan delta
- Hur identitet och samtycke påverkar din yield
- Varför två impressions som ser "identiska" ut kan monetarisera vitt skilt
Om du inte förstår vad som ligger i dina bid requests har du inte full kontroll över din omsättning.
Det här kommer serien att täcka
I de kommande artiklarna plockar jag isär bid requesten, en huvudkomponent i taget – publicerat veckovis under de kommande 9 veckorna:
- Auktionen & kontrollagret
- Impressionen (vad är till salu?)
- Bidder-konfiguration & kommersiell kontext
- Identitet & användarsignaler
- Integritet, samtycke & reglering
- Kontext: Sajt, app, enhet & miljö
- OpenRTB & standardisering
- Tillit & transparens i supply chain
- Custom data & publisher-strategi
Varje artikel fokuserar på varför en viss del finns – inte bara hur den ser ut.
Nästa: Del 1 av 9: Auktionen & kontrollagret →
