I seks artikler har vi nu skilt bid requestet ad felt for felt. Impressionen. Brugeren. Enheden. Consent stringen. Hver sin skuffe i det samme skab.
Men jeg har i al stilhed sprunget det mest oplagte spørgsmål af alle over. Hvorfor betyder noget af det overhovedet noget for køberen i den anden ende?
Når din SSP sender "w": 300, "h": 250, hvorfor ved en DSP tre millisekunder og to tusind kilometer væk så, at det er en medium rectangle – og ikke, for eksempel, en pris i kroner? Ingen har ringet i forvejen. Der er ikke noget oversættelseslag pr. køber. De to systemer har efter al sandsynlighed aldrig mødt hinanden.
De er enige på grund af OpenRTB. Og her er det, de fleste tager en smule fejl af:
OpenRTB er ikke en spec, du implementerer. Det er en kontrakt, du underskriver – og halvdelen af den er med vilje efterladt blank.
Tre begreber, i al hast:
*Den så dagens lys inde i IAB tilbage i 2010, bygget af en koalition af tidlige SSP'er og DSP'er, der var trætte af at integrere med hinanden ét custom API ad gangen. Hele pointen var at holde op med det.
Det sidste begreb – ext – er det, denne artikel i virkeligheden handler om. Men lad os tage kontrakten i tre klausuler.
Det første job, OpenRTB udfører, er kedeligt og fuldstændig essentielt: Det giver alle de samme navneord.
Et site-objekt betyder et website. Et user-objekt betyder publikummet. device.geo betyder, hvor de er. Det er ikke din SSP's private definitioner, eller Googles – de tilhører standarden. Og det er præcis derfor, dit bid request er læseligt for en køber, der aldrig nogensinde har hørt om dit site.
Kører du Prebid, taler du allerede dette ordforråd – måske uden at bemærke det. Når du sætter first-party data, opfinder du ikke et format. Du udfylder OpenRTB-objekter:
pbjs.setConfig({
ortb2: {
site: { name: 'domain.dk', cat: ['IAB12'], keywords: 'news,sport' },
user: { yob: 1985, gender: 'M' },
device: { ua: navigator.userAgent }
}
});
Den ortb2-nøgle er ikke subtil navngivning. Det er bogstaveligt talt "OpenRTB 2.x". Prebid opfandt aldrig sit eget request-format – det taler OpenRTB under motorhjelmen og mapper din config direkte ind i objekterne ovenfor.* Hver adapter oversætter det derefter til præcis den dialekt, dens SSP forventer.
*Prebid Server gør det samme på serversiden og fyrer rigtige OpenRTB 2.x-requests af sted til hver bidder.
Det er grammatikken, der ligger stille og roligt under hvert objekt, vi har diskuteret siden del 0. Samme navneord, samme betydninger – tusind forskellige købere.
Her bliver det interessant, og her gør "kontrakt, ikke spec" sig fortjent til sin plads.
En spec i den rigide forstand siger: Her er felterne, det er alt, hvad der er, kom tilbage i næste version. Det nægter OpenRTB. Næsten hvert objekt bærer et ext – et eksplicit blankt felt, hvor du har lov til at skrive ting ind, som standarden aldrig har defineret.
Skal du sende en Prebid-specifik instruks til én bidder? imp.ext.prebid. Vil du vedhæfte et signal om siden, som intet standardfelt fanger? site.ext. Har en vendor en smart ny identifikator? Ind i et ext ryger den:
"imp": [{
"id": "1",
"banner": {
"w": 300,
"h": 250
},
"ext": {
"prebid": {
"bidder": {
"rubicon": {
"zoneId": "91011"
}
}
}
}
}],
"site": {
"domain": "fyens.dk",
"ext": {
"data": {
"section": "sport"
}
}
}
Bemærk de to niveauer. imp.ext handler om dette specifikke ad slot. site.ext handler om hele siden. Samme nødudgangs-idé, forskelligt scope – og at ramme det scope rigtigt er halvdelen af håndværket.
Hvorfor designe en standard med bevidste blanke felter? Fordi alternativet er værre. Uden ext skulle enhver reelt ny idé – et nyt ID, et nyt privacy-signal, et nyt format-hint – vente på en helt ny version af protokollen, som hele markedet derefter skulle tage i brug i samlet trop. Markeder bevæger sig ikke i komité-tempo.
ext er trykventilen. Det er dét, der lader en femten år gammel standard absorbere ting, dens forfattere aldrig havde forestillet sig – uden at ødelægge en eneste kørende auktion.
Standarden er bevidst ufuldstændig. Det er ikke en fejl. Det er selve featuren.
Så hvis ext er der, hvor nye idéer bor, hvad sker der så, når en idé rent faktisk vinder? Den rykker op.
Et signal starter i ext – ikke-standardiseret, lidt fragmenteret, hvor hver vendor gør det en anelse forskelligt. Hvis en stor nok del af markedet finder det nyttigt, forfremmer IAB det med tiden til kernespec'en med et rigtigt, navngivet felt. Det blanke felt bliver fortrykt i den næste version af kontrakten.
Det er ikke teoretisk. Det er størstedelen af, hvordan OpenRTB reelt har udviklet sig:
user.ext.eids i årevis. OpenRTB 2.6 forfremmede dem til et fuldgyldigt user.eids.source.ext.schain. Det er nu core, som source.schain.device.sua til at bære det signal på en fremtidssikret måde – side om side med det gamle device.ua.
Hver af dem: født i ext, rykket op til core. Kontrakten får tilføjelser – den bliver ikke revet i stykker.
Og vi ved præcis, hvordan det ser ud at rive den i stykker, for nogen prøvede. OpenRTB 3.0, tilbage i 2017, var en næsten total omskrivning – renere, strengere, mere sikker. Branchen kiggede på migreringsomkostningerne og takkede stille nej. Næsten ingen tog den i brug. 2.x var godt nok, og "godt nok og allerede i drift" slår "bedre, men disruptivt" hver eneste gang i denne branche.
Den træghed er prisen for en fælles kontrakt. Selvsamme stabilitet, der gør OpenRTB troværdig, gør den også langsom til at udbedre sine ru kanter – den er ordrig, den er snakkesalig, og den blev designet til en verden med langt mere stabile identifikatorer, end vi har i dag. Man tager rigiditeten med i købet sammen med pålideligheden.
To af de oprykkede signaler er store nok til at fortjene deres egne artikler – supply chain-objektet er del 8, og publisher-defineret first-party data er del 9. Indtil videre skal du bare holde fast i mønsteret: ext i dag, core i morgen.
Du har ikke skrevet denne kontrakt. Det kan du ikke. IAB udarbejder den, og markedet ratificerer den gennem adoption. Men du bestemmer, hvor komplet du udfylder den.
Et bid request med rige site-data, et udfyldt user.eids og rene first-party-signaler i ext – det er en køber, der ved præcis, hvad de byder på. Et halvtomt request er en køber, der misser med øjnene i mørket. Og en køber, der misser med øjnene i mørket, byder lavt – hvis de overhovedet byder. Felterne er gratis. Standarden rækker dig formularen. At lade den stå blank er at efterlade penge på bordet.
Det er en standards stille styrke. Den forvandler "beskriv dit inventory" fra en skræddersyet forhandling med hver enkelt køber til én formular – udfyldt én gang, forstået alle steder.
OpenRTB er en kontrakt, ikke en spec.
Værdien var aldrig noget enkelt felt. Den var enigheden om, at et felt betyder det samme i begge ender af ledningen.
Det her er syvende artikel i serien i ni dele Hvad gemmer der sig egentlig i et bid request?
Nye dele lander hver onsdag kl. 12:00 (CEST). Hvis det her var nyttigt – eller hvis du synes, jeg er lidt for glad for kontraktmetaforen – er kommentarfeltet og mine DM'er åbne. Jeg læser dem alle.
Og hvis du er nået helt hertil: tak. Din opmærksomhed er det mest knappe inventory, der findes. 🤓
Næste gang, del 8: Tillid & transparens i supply chain. Vi har nu slået fast, at alle taler det samme sprog – så det næste spørgsmål er, om du kan stole på, hvem der faktisk er med i samtalen. Det er her, schain, ads.txt og sellers.json kommer ind: den del af requestet, der beviser, at stien tilbage til dig er ægte.
Lad os hjælpe dig med at få maksimalt ud af dine display-kampagner.
