I fugleperspektiv-artiklen [link til del 0] slog vi fast, at bid requestet er den kommercielle definition af en annoncemulighed. Nu dykker vi ned i, hvordan den mulighed rent faktisk bliver solgt. Hvordan der anmodes om bud, hvordan auktionen er struktureret, og hvilke systemer der træffer de beslutninger – set fra publisherens perspektiv.
Det her er auktionens maskinrum.
Hvis bid requestet er beskrivelsen af annoncemuligheden, så er auktionen og kontrollaget måden, den mulighed rent faktisk bliver solgt på. Dette lag styrer eksekveringen: hvordan og hvor auktionen afvikles, hvilke bidders der er med, hvor lang tid de har, og hvem der kontrollerer hvad.
Denne artikel forklarer arkitekturen i en header bidding-auktion og introducerer de tekniske strukturer og beslutninger, der former hver eneste auktion. Vi kigger ikke på selve demand-platformene som SSP'er/DSP'er og deres relation til Prebid (endnu), men udelukkende på publisherens konfigurationsmuligheder og auktionen på siden.
En enkelt auktion involverer ofte:
Hver bidder modtager ét eller flere bid requests, afhængigt af hvilke ad units de er mappet til. Prebid.js har en rigtig god interaktiv demo [link: Prebid.org demo]. Den låner vi fra for at illustrere, hvordan en auktion sættes op. Husk på, at koden herunder langt fra er hele det nødvendige setup – det er forskellige udpluk fra den fulde kode på demo-siden.
Lad os antage, at du allerede har defineret en simpel ad unit på din side med Google Publisher Tags (GPT.js). I dette eksempel kalder 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>
Nu konfigurerer vi Prebid.js til at deltage i auktionen. Det starter med at 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, hvad der sker:
code-værdien mapper til GPT-ad slottet.mediaTypes.banner.sizes definerer den ønskede størrelse (300x250), så den matcher size mappingen i GPT.bids-arrayet angiver vi én eller flere bid adapters – i dette tilfælde AppNexus (Xandr) – og medsender det placementId, som den pågældende bidder kræver.
Denne struktur gentages pr. ad unit. Når du skalerer til 10-15 bidders fordelt på 5-10 ad units, bliver konfigurationerne hurtigt store og uoverskuelige – især når hver bidder har forskellige params. Det er en af grundene til, at Header Bidding Management-løsninger (HBM) som wrappers har vundet frem, siden Prebid blev lanceret tilbage i 2015.
Prebid.js bruger derefter denne config til at sende bid requests ud til hver adapter, generere requests i OpenRTB-stil og koordinere auktionsflowet.
Det her er nogle af de vigtigste knapper, publisheren kan skrue på i Prebid-kontrollaget, og de fleste af dem konfigureres i pbjs.setConfig(). De samlede konfigurationsmuligheder er ret omfattende og granulære. Hvis du er frisk på det, findes dokumentationen her [link: Prebid setConfig docs].
Eksempel på de mest almindelige indstillinger:
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 }
}
}
});
Hvad hver indstilling gør:
Og konfigurationen ovenfor kradser kun i overfladen af, hvad der er muligt i Prebid.js.
For at forstå, hvor meget kontrol Prebid giver i sine configs, gennemgår vi de vigtigste timeout-lag. Hvert lag påvirker sin egen del af flowet, og tilsammen afgør de, hvor pålidelige, hurtige og omsætningseffektive dine auktioner kan være. Diagrammet nedenfor opsummerer timeouts i Prebid.js og Prebid Server:
For en mere detaljeret gennemgang findes Prebids timeout-dokumentation her [link], men herunder er et overblik:
setTimeout(), som publishers bør overveje at etablere, efter Prebid.js-koden er indlæst. Det er et sikkerhedsnet, der kalder ad-server-callbacket, hvis noget går galt. I alle normale scenarier vil Prebid.js allerede have kaldt callbacket, før denne timeout nås. Værdien bør være væsentligt højere end auction timeouten.s2sConfig.timeout til en værdi, der er lavere end auction timeouten. Hvor meget lavere afhænger af brugernes gennemsnitlige netværksforsinkelse, men den bør formentlig ligge i intervallet 50-75 % af auction timeouten. Værdien sendes i Prebid Servers OpenRTB som tmax.tmax-værdi er udløbet. Se Prebid Servers timeout-reference for detaljer.
Alle disse lag arbejder sammen, men hvert lag tunes separat. Og det er netop dét, der er Prebids styrke: Du kan skrue kontrollen så stramt eller løst, som dit stack kræver.
En Prebid-auktion kan primært afvikles på to måder: direkte i brugerens browser (client-side) eller på et eksternt infrastruktur-endpoint (server-side).
Client-side:
Server-side:
De fleste moderne publisher-setups bruger en hybridmodel, hvor nogle bidders sendes gennem Prebid.js (for at bevare cookie-baseret identitet) og andre gennem Prebid Server (af performance-hensyn, eller fordi bidderen ikke understøtter client-side eksekvering). Det giver det bedste fra begge verdener: identitet og granulær kontrol fra klientsiden og serversidens skala og effektivitet – alt sammen uden at gøre brugeroplevelsen langsommere.
Auktionen og kontrollaget er eksekveringslaget, der afgør, hvordan bid requestet bliver til beslutninger i realtid. Fra hvordan ad units konfigureres i GPT og Prebid.js, over hvordan bidders udvælges og mappes til impressions, til hvordan timeouts, floors, valutaer og secondary-indstillinger defineres – alt løber gennem denne kontrollogik.
Det afgør også, hvor auktionen afvikles: i browseren (client-side), på en ekstern server (server-side) eller begge dele. Og det valg påvirker direkte latency, identity match rates og fleksibilitet.
At forstå dette lag hjælper med at forklare:
I sidste ende er header bidding ikke bare en teknologi. Det er et koordineringssystem. Og auktionen og kontrollaget er dér, hvor alle rørene mødes.
Det var første artikel i denne serie i ni dele: Hvad gemmer der sig egentlig i et bid request?
Serien udkommer hver onsdag kl. 12:00 (CEST)! Hvis du har lært noget eller har fået lyst til at dykke dybere ned i emnet, er du meget velkommen til at kommentere eller skrive til mig i DM'erne.
Og hvis du læser det her, sætter jeg stor pris på, at du har taget dig tid i en travl hverdag til at læse min artikel. Vi ses (forhåbentlig) i næste artikel: Impressionen (hvad er til salg?)
Lad os hjælpe dig med at få maksimalt ud af dine display-kampagner.
