I sex artiklar har vi nu plockat isär bid requestet fält för fält. Impressionen. Användaren. Enheten. Consent-strängen. Varsin låda i samma skåp.
Men jag har i all tysthet hoppat över den mest självklara frågan av alla. Varför betyder något av det här över huvud taget något för köparen i andra änden?
När din SSP skickar "w": 300, "h": 250, hur vet då en DSP tre millisekunder och två tusen kilometer bort att det är en medium rectangle – och inte, till exempel, ett pris i kronor? Ingen har ringt i förväg. Det finns inget översättningslager per köpare. De två systemen har med all sannolikhet aldrig mötts.
De är överens tack vare OpenRTB. Och här är det de flesta missförstår en aning:
OpenRTB är inte en spec du implementerar. Det är ett kontrakt du skriver under – och hälften av det är med avsikt lämnat blankt.
Tre begrepp, i all hast:
*Den såg dagens ljus inne i IAB redan 2010, byggd av en koalition av tidiga SSP:er och DSP:er som var trötta på att integrera med varandra ett custom-API i taget. Hela poängen var att sluta med det.
Det sista begreppet – ext – är det den här artikeln egentligen handlar om. Men låt oss ta kontraktet i tre klausuler.
Det första jobbet OpenRTB utför är tråkigt och fullständigt essentiellt: Det ger alla samma substantiv.
Ett site-objekt betyder en webbplats. Ett user-objekt betyder publiken. device.geo betyder var de befinner sig. Det är inte din SSP:s privata definitioner, eller Googles – de tillhör standarden. Och det är precis därför ditt bid request är läsbart för en köpare som aldrig någonsin har hört talas om din sajt.
Kör du Prebid talar du redan det här ordförrådet – kanske utan att märka det. När du sätter first-party data uppfinner du inte ett format. Du fyller i OpenRTB-objekt:
pbjs.setConfig({
ortb2: {
site: { name: 'domain.dk', cat: ['IAB12'], keywords: 'news,sport' },
user: { yob: 1985, gender: 'M' },
device: { ua: navigator.userAgent }
}
});
Den där ortb2-nyckeln är inte subtil namngivning. Det är bokstavligen "OpenRTB 2.x". Prebid uppfann aldrig sitt eget request-format – det talar OpenRTB under huven och mappar din config direkt in i objekten ovan.* Varje adapter översätter det sedan till exakt den dialekt dess SSP förväntar sig.
*Prebid Server gör samma sak på serversidan och skjuter iväg riktiga OpenRTB 2.x-requests till varje bidder.
Det är grammatiken som ligger stilla och tyst under varje objekt vi har diskuterat sedan del 0. Samma substantiv, samma betydelser – tusen olika köpare.
Här blir det intressant, och här gör "kontrakt, inte spec" skäl för sin plats.
En spec i rigid mening säger: Här är fälten, det är allt som finns, återkom i nästa version. Det vägrar OpenRTB. Nästan varje objekt bär ett ext – ett explicit blankt fält där du får skriva in sådant som standarden aldrig har definierat.
Visualisering genererad med claude.ai
Behöver du skicka en Prebid-specifik instruktion till en enskild bidder? imp.ext.prebid. Vill du bifoga en signal om sajten som inget standardfält fångar? site.ext. Har en vendor en smart ny identifierare? In i ett ext åker den:
"imp": [{
"id": "1",
"banner": {
"w": 300,
"h": 250
},
"ext": {
"prebid": {
"bidder": {
"rubicon": {
"zoneId": "91011"
}
}
}
}
}],
"site": {
"domain": "fyens.dk",
"ext": {
"data": {
"section": "sport"
}
}
}
Notera de två nivåerna. imp.ext handlar om just denna ad slot. site.ext handlar om hela sajten. Samma nödutgångsidé, olika scope – och att pricka rätt scope är halva hantverket.
Varför designa en standard med medvetet blanka fält? För att alternativet är värre. Utan ext skulle varje verkligt ny idé – ett nytt ID, en ny privacy-signal, ett nytt format-hint – behöva vänta på en helt ny version av protokollet, som hela marknaden sedan skulle ta i bruk i samlad tropp. Marknader rör sig inte i kommittétempo.
ext är tryckventilen. Det är det som låter en femton år gammal standard absorbera saker dess författare aldrig hade föreställt sig – utan att förstöra en enda pågående auktion.
Standarden är medvetet ofullständig. Det är inte ett fel. Det är själva featuren.
Så om ext är där nya idéer bor, vad händer då när en idé faktiskt vinner? Den flyttar upp.
En signal börjar i ext – icke-standardiserad, lite fragmenterad, där varje vendor gör det aningen olika. Om en tillräckligt stor del av marknaden finner den användbar befordrar IAB den med tiden till kärnspecen med ett riktigt, namngivet fält. Det blanka fältet blir förtryckt i nästa version av kontraktet.
Visualisering genererad med claude.ai
Det är inte teoretiskt. Det är merparten av hur OpenRTB faktiskt har utvecklats:
user.ext.eids i åratal. OpenRTB 2.6 befordrade dem till ett fullvärdigt user.eids.source.ext.schain. Det är nu core, som source.schain.device.sua för att bära den signalen på ett framtidssäkrat sätt – sida vid sida med det gamla device.ua.
Var och en av dem: född i ext, uppflyttad till core. Kontraktet får tillägg – det rivs inte sönder.
Och vi vet precis hur det ser ut att riva sönder det, för någon försökte. OpenRTB 3.0, tillbaka 2017, var en nästan total omskrivning – renare, striktare, säkrare. Branschen tittade på migreringskostnaderna och tackade stilla nej. Nästan ingen tog den i bruk. 2.x var bra nog, och "bra nog och redan i drift" slår "bättre, men disruptivt" varje gång i den här branschen.
Den trögheten är priset för ett gemensamt kontrakt. Samma stabilitet som gör OpenRTB trovärdig gör den också långsam på att slipa sina råa kanter – den är ordrik, den är pratig, och den designades för en värld med långt stabilare identifierare än vi har i dag. Man får rigiditeten på köpet tillsammans med pålitligheten.
Två av de uppflyttade signalerna är stora nog att förtjäna egna artiklar – supply chain-objektet är del 8, och publisher-definierad first-party data är del 9. Tills vidare räcker det att hålla fast vid mönstret: ext i dag, core i morgon.
Du har inte skrivit det här kontraktet. Det kan du inte. IAB utarbetar det, och marknaden ratificerar det genom adoption. Men du bestämmer hur komplett du fyller i det.
Ett bid request med rik site-data, ett ifyllt user.eids och rena first-party-signaler i ext – det är en köpare som vet exakt vad de bjuder på. Ett halvtomt request är en köpare som kisar i mörkret. Och en köpare som kisar i mörkret bjuder lågt – om de över huvud taget bjuder. Fälten är gratis. Standarden räcker dig formuläret. Att lämna det blankt är att lämna pengar på bordet.
Det är en standards stilla styrka. Den förvandlar "beskriv ditt inventory" från en skräddarsydd förhandling med varje enskild köpare till ett formulär – ifyllt en gång, förstått överallt.
OpenRTB är ett kontrakt, inte en spec.
Värdet var aldrig något enskilt fält. Det var enigheten om att ett fält betyder samma sak i båda ändar av tråden.
Det här är den sjunde artikeln i serien i nio delar Vad döljer sig egentligen i ett bid request?
Nästa gång, del 8: Tillit & transparens i supply chain. Vi har nu slagit fast att alla talar samma språk – så nästa fråga är om du kan lita på vem som faktiskt är med i samtalet. Det är här schain, ads.txt och sellers.json kommer in: den del av requestet som bevisar att vägen tillbaka till dig är äkta.
Låt oss hjälpa dig att få ut maximalt av dina displaykampanjer.
