I seks artikler har vi nå plukket bid requestet fra hverandre felt for felt. Impressionen. Brukeren. Enheten. Consent stringen. Hver sin skuff i det samme skapet.
Men jeg har i all stillhet hoppet over det mest opplagte spørsmålet av alle. Hvorfor betyr noe av dette i det hele tatt noe for kjøperen i den andre enden?
Når din SSP sender "w": 300, "h": 250, hvorfor vet en DSP tre millisekunder og to tusen kilometer unna at det er en medium rectangle – og ikke, for eksempel, en pris i kroner? Ingen har ringt på forhånd. Det finnes ikke noe oversettelseslag per kjøper. De to systemene har etter all sannsynlighet aldri møtt hverandre.
De er enige på grunn av OpenRTB. Og her er det de fleste tar litt feil av:
OpenRTB er ikke en spec du implementerer. Det er en kontrakt du signerer – og halvparten av den er med vilje latt stå blank.
Tre begreper, i all hast:
*Den så dagens lys inne i IAB tilbake i 2010, bygget av en koalisjon av tidlige SSP-er og DSP-er som var lei av å integrere med hverandre ett custom API om gangen. Hele poenget var å slutte med det.
Det siste begrepet – ext – er det denne artikkelen egentlig handler om. Men la oss ta kontrakten i tre klausuler.
Den første jobben OpenRTB gjør, er kjedelig og fullstendig essensiell: Den gir alle de samme substantivene.
Et site-objekt betyr et nettsted. Et user-objekt betyr publikummet. device.geo betyr hvor de er. Det er ikke din SSPs private definisjoner, eller Googles – de tilhører standarden. Og det er nettopp derfor bid requestet ditt er lesbart for en kjøper som aldri noensinne har hørt om nettstedet ditt.
Kjører du Prebid, bruker du allerede dette ordforrådet – kanskje uten å merke det. Når du setter first-party data, finner du ikke opp et format. Du fyller ut 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økkelen er ikke subtil navngivning. Det er bokstavelig talt "OpenRTB 2.x". Prebid fant aldri opp sitt eget request-format – det snakker OpenRTB under panseret og mapper configen din direkte inn i objektene ovenfor.* Hver adapter oversetter det deretter til nøyaktig den dialekten dens SSP forventer.
*Prebid Server gjør det samme på serversiden og fyrer av ekte OpenRTB 2.x-requests til hver bidder.
Det er grammatikken som ligger stille og rolig under hvert objekt vi har diskutert siden del 0. Samme substantiver, samme betydninger – tusen forskjellige kjøpere.
Her blir det interessant, og her gjør "kontrakt, ikke spec" seg fortjent til plassen sin.
En spec i den rigide forstand sier: Her er feltene, det er alt som finnes, kom tilbake i neste versjon. Det nekter OpenRTB. Nesten hvert objekt bærer et ext – et eksplisitt blankt felt der du har lov til å skrive inn ting som standarden aldri har definert.
Visualisering generert med claude.ai
Skal du sende en Prebid-spesifikk instruks til én bidder? imp.ext.prebid. Vil du legge ved et signal om siden som intet standardfelt fanger? site.ext. Har en vendor en smart ny identifikator? Inn i et ext går den:
"imp": [{
"id": "1",
"banner": {
"w": 300,
"h": 250
},
"ext": {
"prebid": {
"bidder": {
"rubicon": {
"zoneId": "91011"
}
}
}
}
}],
"site": {
"domain": "fyens.dk",
"ext": {
"data": {
"section": "sport"
}
}
}
Merk de to nivåene. imp.ext handler om dette spesifikke ad slotet. site.ext handler om hele siden. Samme nødutgangs-idé, forskjellig scope – og å treffe det scopet riktig er halvparten av håndverket.
Hvorfor designe en standard med bevisste blanke felter? Fordi alternativet er verre. Uten ext måtte enhver reelt ny idé – en ny ID, et nytt privacy-signal, et nytt format-hint – vente på en helt ny versjon av protokollen, som hele markedet deretter måtte ta i bruk i samlet flokk. Markeder beveger seg ikke i komité-tempo.
ext er trykkventilen. Det er det som lar en femten år gammel standard absorbere ting forfatterne aldri hadde forestilt seg – uten å ødelegge en eneste kjørende auksjon.
Standarden er bevisst ufullstendig. Det er ikke en feil. Det er selve featuren.
Så hvis ext er der nye ideer bor, hva skjer da når en idé faktisk vinner? Den rykker opp.
Et signal starter i ext – ikke-standardisert, litt fragmentert, der hver vendor gjør det en anelse forskjellig. Hvis en stor nok del av markedet finner det nyttig, forfremmer IAB det med tiden til kjernespecen med et ekte, navngitt felt. Det blanke feltet blir forhåndstrykt i neste versjon av kontrakten.
Visualisering generert med claude.ai
Det er ikke teoretisk. Det er størstedelen av hvordan OpenRTB faktisk har utviklet seg:
user.ext.eids i årevis. OpenRTB 2.6 forfremmet dem til et fullverdig user.eids.source.ext.schain. Det er nå core, som source.schain.device.sua for å bære det signalet på en fremtidssikret måte – side om side med det gamle device.ua.
Hver av dem: født i ext, rykket opp til core. Kontrakten får tilføyelser – den blir ikke revet i stykker.
Og vi vet nøyaktig hvordan det ser ut å rive den i stykker, for noen prøvde. OpenRTB 3.0, tilbake i 2017, var en nesten total omskriving – renere, strengere, sikrere. Bransjen så på migreringskostnadene og takket stille nei. Nesten ingen tok den i bruk. 2.x var godt nok, og "godt nok og allerede i drift" slår "bedre, men disruptivt" hver eneste gang i denne bransjen.
Den tregheten er prisen for en felles kontrakt. Den selvsamme stabiliteten som gjør OpenRTB troverdig, gjør den også treg til å slipe ned sine røffe kanter – den er ordrik, den er pratsom, og den ble designet for en verden med langt mer stabile identifikatorer enn vi har i dag. Man tar rigiditeten med på kjøpet sammen med påliteligheten.
To av de opprykkede signalene er store nok til å fortjene sine egne artikler – supply chain-objektet er del 8, og publisher-definert first-party data er del 9. Inntil videre skal du bare holde fast i mønsteret: ext i dag, core i morgen.
Du har ikke skrevet denne kontrakten. Det kan du ikke. IAB utarbeider den, og markedet ratifiserer den gjennom adopsjon. Men du bestemmer hvor komplett du fyller den ut.
Et bid request med rike site-data, et utfylt user.eids og rene first-party-signaler i ext – det er en kjøper som vet nøyaktig hva de byr på. Et halvtomt request er en kjøper som myser i mørket. Og en kjøper som myser i mørket, byr lavt – hvis de i det hele tatt byr. Feltene er gratis. Standarden rekker deg skjemaet. Å la det stå blankt er å legge igjen penger på bordet.
Det er en standards stille styrke. Den forvandler "beskriv ditt inventory" fra en skreddersydd forhandling med hver enkelt kjøper til ett skjema – fylt ut én gang, forstått overalt.
OpenRTB er en kontrakt, ikke en spec.
Verdien var aldri noe enkelt felt. Den var enigheten om at et felt betyr det samme i begge ender av ledningen.
Dette er sjuende artikkel i serien i ni deler Hva skjuler det seg egentlig i et bid request?
Neste gang, del 8: Tillit & transparens i supply chain. Vi har nå slått fast at alle snakker det samme språket – så det neste spørsmålet er om du kan stole på hvem som faktisk er med i samtalen. Det er her schain, ads.txt og sellers.json kommer inn: den delen av requestet som beviser at stien tilbake til deg er ekte.
La oss hjelpe deg med å få maksimalt ut av display-kampanjene dine.
