I fågelperspektivsartikeln (Del 0) slog vi fast att bid requesten är den kommersiella definitionen av en annonsmöjlighet. Nu dyker vi ner i hur den möjligheten faktiskt säljs. Hur bud begärs in, hur auktionen är strukturerad och vilka system som fattar de besluten – sett ur publisherns perspektiv.
Det här är auktionens maskinrum.
Om bid requesten är beskrivningen av annonsmöjligheten, så är auktionen och kontrollagret sättet den möjligheten faktiskt säljs på. Det här lagret styr exekveringen: hur och var auktionen körs, vilka bidders som är med, hur lång tid de har och vem som kontrollerar vad.
Den här artikeln förklarar arkitekturen i en header bidding-auktion och introducerar de tekniska strukturer och beslut som formar varje enskild auktion. Vi tittar inte på själva demand-plattformarna som SSP:er/DSP:er och deras relation till Prebid (ännu), utan uteslutande på publisherns konfigurationsmöjligheter och auktionen på sidan.
En enskild auktion involverar ofta:
Varje bidder tar emot en eller flera bid requests, beroende på vilka ad units de är mappade till. Prebid.js har en riktigt bra interaktiv demo. Den lånar vi från för att illustrera hur en auktion sätts upp. Kom ihåg att koden nedan långt ifrån är hela det nödvändiga setupet – det är olika utdrag ur den fullständiga koden på demosidan.
Låt oss anta att du redan har definierat en enkel ad unit på din sida med Google Publisher Tags (GPT.js). I det här exemplet kallar vi slotten 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 konfigurerar vi Prebid.js för att delta i auktionen. Det börjar med att inkludera Prebid.js-biblioteket och definiera motsvarande 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>
Här är vad som händer:
code-värdet mappar till GPT-ad slotten.mediaTypes.banner.sizes definierar den önskade storleken (300x250), så att den matchar size mappingen i GPT.bids-arrayen anger vi en eller flera bid adapters – i det här fallet AppNexus (Xandr) – och skickar med det placementId som den aktuella biddern kräver.
Den här strukturen upprepas per ad unit. När du skalar till 10-15 bidders fördelade på 5-10 ad units blir konfigurationerna snabbt stora och svåröverskådliga – särskilt när varje bidder har olika params. Det är en av anledningarna till att Header Bidding Management-lösningar (HBM) som wrappers har vunnit mark sedan Prebid lanserades 2015.
Prebid.js använder därefter denna config för att skicka ut bid requests till varje adapter, generera requests i OpenRTB-stil och koordinera auktionsflödet.
Det här är några av de viktigaste rattarna publishern kan skruva på i Prebid-kontrollagret, och de flesta av dem konfigureras i pbjs.setConfig(). De samlade konfigurationsmöjligheterna är ganska omfattande och granulära. Om du är sugen på det finns dokumentationen här.
Exempel på de vanligaste inställningarna:
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 }
}
}
});
Vad varje inställning gör:
Och konfigurationen ovan skrapar bara på ytan av vad som är möjligt i Prebid.js.
För att förstå hur mycket kontroll Prebid ger i sina configs går vi igenom de viktigaste timeout-lagren. Varje lager påverkar sin egen del av flödet, och tillsammans avgör de hur pålitliga, snabba och omsättningseffektiva dina auktioner kan vara. Diagrammet nedan sammanfattar timeouts i Prebid.js och Prebid Server:
Prebid timeout-flöde
För en mer detaljerad genomgång finns Prebids timeout-dokumentation här, men nedan följer en översikt:
setTimeout() som publishers bör överväga att etablera efter att Prebid.js-koden har laddats in. Det är ett skyddsnät som anropar ad-server-callbacken om något går fel. I alla normala scenarier har Prebid.js redan anropat callbacken innan denna timeout nås. Värdet bör vara väsentligt högre än auction timeouten.s2sConfig.timeout till ett värde som är lägre än auction timeouten. Hur mycket lägre beror på användarnas genomsnittliga nätverksfördröjning, men det bör förmodligen ligga i intervallet 50-75 % av auction timeouten. Värdet skickas i Prebid Servers OpenRTB som tmax.tmax-värdet har löpt ut. Se Prebid Servers timeout-referens för detaljer.
Alla dessa lager arbetar tillsammans, men varje lager tunas separat. Och det är precis det som är Prebids styrka: Du kan dra åt kontrollen så hårt eller löst som din stack kräver.
En Prebid-auktion kan i huvudsak köras på två sätt: direkt i användarens webbläsare (client-side) eller på ett externt infrastruktur-endpoint (server-side).
Client-side:
Server-side:
De flesta moderna publisher-setups använder en hybridmodell, där vissa bidders skickas genom Prebid.js (för att bevara cookie-baserad identitet) och andra genom Prebid Server (av performance-skäl, eller för att biddern inte stödjer client-side exekvering). Det ger det bästa av två världar: identitet och granulär kontroll från klientsidan och serversidans skala och effektivitet – allt utan att göra användarupplevelsen långsammare.
Auktionen och kontrollagret är exekveringslagret som avgör hur bid requesten blir till beslut i realtid. Från hur ad units konfigureras i GPT och Prebid.js, via hur bidders väljs ut och mappas till impressions, till hur timeouts, floors, valutor och secondary-inställningar definieras – allt löper genom denna kontrollogik.
Det avgör också var auktionen körs: i webbläsaren (client-side), på en extern server (server-side) eller båda delarna. Och det valet påverkar direkt latency, identity match rates och flexibilitet.
Att förstå det här lagret hjälper till att förklara:
I slutändan är header bidding inte bara en teknologi. Det är ett koordineringssystem. Och auktionen och kontrollagret är där alla rören möts.
Det var den första artikeln i den här serien i nio delar: Vad döljer sig egentligen i en bid request?
Låt oss hjälpa dig att få ut maximalt av dina displaykampanjer.
