I fugleperspektivartikkelen (Del 0) slo vi fast at bid requestet er den kommersielle definisjonen av en annonsemulighet. Nå dykker vi ned i hvordan den muligheten faktisk blir solgt. Hvordan det bes om bud, hvordan auksjonen er strukturert, og hvilke systemer som tar de beslutningene – sett fra publisherens perspektiv.
Dette er auksjonens maskinrom.
Hvis bid requestet er beskrivelsen av annonsemuligheten, så er auksjonen og kontrollaget måten den muligheten faktisk blir solgt på. Dette laget styrer eksekveringen: hvordan og hvor auksjonen kjøres, hvilke bidders som er med, hvor lang tid de har, og hvem som kontrollerer hva.
Denne artikkelen forklarer arkitekturen i en header bidding-auksjon og introduserer de tekniske strukturene og beslutningene som former hver eneste auksjon. Vi ser ikke på selve demand-plattformene som SSP-er/DSP-er og deres relasjon til Prebid (ennå), men utelukkende på publisherens konfigurasjonsmuligheter og auksjonen på siden.
En enkelt auksjon involverer ofte:
Hver bidder mottar ett eller flere bid requests, avhengig av hvilke ad units de er mappet til. Prebid.js har en veldig god interaktiv demo. Den låner vi fra for å illustrere hvordan en auksjon settes opp. Husk at koden nedenfor langt fra er hele det nødvendige oppsettet – det er ulike utdrag fra den fulle koden på demo-siden.
La oss anta at du allerede har definert en enkel ad unit på siden din med Google Publisher Tags (GPT.js). I dette eksempelet kaller vi slottet div-1:
<head>
<script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<script>
googletag.cmd.push(function() {
googletag.defineSlot('/19968336/header-bid-tag-1', [[300, 250]], 'div-1')
.addService(googletag.pubads());
googletag.pubads().enableSingleRequest();
googletag.enableServices();
});
</script>
</head>
<body>
<div id='div-1' style="min-height:250px;">
<script type='text/javascript'>
googletag.cmd.push(function() {
googletag.display('div-1');
});
</script>
</div>
</body>
Nå konfigurerer vi Prebid.js til å delta i auksjonen. Det starter med å inkludere Prebid.js-biblioteket og definere den tilsvarende ad unit i JavaScript:
<head>
<script async src="https://cdn.jsdelivr.net/npm/prebid.js@latest/dist/not-for-prod/prebid.js"></script>
<script>
var adUnits = [{
code: '/19968336/header-bid-tag-1',
mediaTypes: {
banner: {
sizes: [[300, 250]]
}
},
bids: [{
bidder: 'appnexus',
params: {
placementId: 'XXXXXXX'
}
}]
}];
</script>
</head>
Her er hva som skjer:
code-verdien mapper til GPT-ad slottet.mediaTypes.banner.sizes definerer den ønskede størrelsen (300x250), slik at den matcher size mappingen i GPT.bids-arrayet angir vi én eller flere bid adapters – i dette tilfellet AppNexus (Xandr) – og sender med den placementId som den aktuelle bidderen krever.
Denne strukturen gjentas per ad unit. Når du skalerer til 10-15 bidders fordelt på 5-10 ad units, blir konfigurasjonene raskt store og uoversiktlige – særlig når hver bidder har ulike params. Det er en av grunnene til at Header Bidding Management-løsninger (HBM) som wrappers har vunnet frem siden Prebid ble lansert tilbake i 2015.
Prebid.js bruker deretter denne configen til å sende bid requests ut til hver adapter, generere requests i OpenRTB-stil og koordinere auksjonsflyten.
Dette er noen av de viktigste knappene publisheren kan skru på i Prebid-kontrollaget, og de fleste av dem konfigureres i pbjs.setConfig(). De samlede konfigurasjonsmulighetene er ganske omfattende og granulære. Hvis du er klar for det, finnes dokumentasjonen her.
Eksempel på de vanligste innstillingene:
pbjs.setConfig({
bidderTimeout: 1000,
useBidCache: true,
priceGranularity: {
buckets: [
{ max: 20, min: 0, increment: 0.01, precision: 2 },
{ max: 99, min: 21, increment: 1, precision: 2 }
]
},
auctionOptions: {
secondaryBidders: ["xandr", "criteo", "triplelift", "pubmatic"]
},
currency: {
adServerCurrency: "USD",
defaultRates: {
USD: { EUR: 0.92, DKK: 6.84, GBP: 0.8 }
}
},
floors: {
data: {
currency: "DKK",
default: 0.07,
schema: { fields: ['mediaType'] },
values: { '*': 0.07 }
}
}
});
Hva hver innstilling gjør:
Og konfigurasjonen ovenfor skraper bare i overflaten av hva som er mulig i Prebid.js.
For å forstå hvor mye kontroll Prebid gir i sine configs, går vi gjennom de viktigste timeout-lagene. Hvert lag påvirker sin egen del av flyten, og til sammen avgjør de hvor pålitelige, raske og inntektseffektive auksjonene dine kan være. Diagrammet nedenfor oppsummerer timeouts i Prebid.js og Prebid Server:
Prebid timeout-flyt
For en mer detaljert gjennomgang finnes Prebids timeout-dokumentasjon her, men nedenfor er en oversikt:
setTimeout() som publishere bør vurdere å etablere etter at Prebid.js-koden er lastet inn. Det er et sikkerhetsnett som kaller ad-server-callbacket hvis noe går galt. I alle normale scenarioer vil Prebid.js allerede ha kalt callbacket før denne timeouten nås. Verdien bør være vesentlig høyere enn auction timeouten.s2sConfig.timeout til en verdi som er lavere enn auction timeouten. Hvor mye lavere avhenger av brukernes gjennomsnittlige nettverksforsinkelse, men den bør trolig ligge i intervallet 50-75 % av auction timeouten. Verdien sendes i Prebid Servers OpenRTB som tmax.tmax-verdien er utløpt. Se Prebid Servers timeout-referanse for detaljer.
Alle disse lagene jobber sammen, men hvert lag tunes separat. Og det er nettopp dét som er Prebids styrke: Du kan skru kontrollen så stramt eller løst som stacken din krever.
En Prebid-auksjon kan i hovedsak kjøres på to måter: direkte i brukerens nettleser (client-side) eller på et eksternt infrastruktur-endpoint (server-side).
Client-side:
Server-side:
De fleste moderne publisher-oppsett bruker en hybridmodell, der noen bidders sendes gjennom Prebid.js (for å bevare cookie-basert identitet) og andre gjennom Prebid Server (av ytelseshensyn, eller fordi bidderen ikke støtter client-side eksekvering). Det gir det beste fra begge verdener: identitet og granulær kontroll fra klientsiden og serversidens skala og effektivitet – alt sammen uten å gjøre brukeropplevelsen tregere.
Auksjonen og kontrollaget er eksekveringslaget som avgjør hvordan bid requestet blir til beslutninger i sanntid. Fra hvordan ad units konfigureres i GPT og Prebid.js, via hvordan bidders velges ut og mappes til impressions, til hvordan timeouts, floors, valutaer og secondary-innstillinger defineres – alt løper gjennom denne kontrollogikken.
Det avgjør også hvor auksjonen kjøres: i nettleseren (client-side), på en ekstern server (server-side) eller begge deler. Og det valget påvirker direkte latency, identity match rates og fleksibilitet.
Å forstå dette laget hjelper med å forklare:
Til syvende og sist er header bidding ikke bare en teknologi. Det er et koordineringssystem. Og auksjonen og kontrollaget er der alle rørene møtes.
Det var den første artikkelen i denne serien i ni deler: Hva skjuler seg egentlig i et bid request?
La oss hjelpe deg med å få maksimalt ut av display-kampanjene dine.
