Både købere og sælgere af digital annonceplads har længe beklaget de »vandfald«, som udgiverne har benyttet sig af for at udfylde de visninger, der ikke blev solgt af deres direkte salgsteams. I de senere år er header bidding kommet ind i økosystemet, og det er siden blevet almindeligt udbredt. I dag har omkring 20 % af Alexa 2000-webstederne implementeret header bidding.
GumGum har taget header bidding til sig, fordi det giver vores udgiverpartnere enorme fordele, og fordi det giver os mulighed for at konkurrere om visninger på vegne af vores kunder, som ellers ville være uden for rækkevidde i en vandfaldsmodel.
Hvis du har hørt en del om header bidding, men ikke helt ved, hvad det går ud på, så læs videre! Dette blogindlæg er en grundlæggende introduktion til denne yderst vigtige udvikling.
Hvad er header bidding?
Den nemmeste måde at forklare header bidding på er, at det er en metode, hvorudved udgivere kan oprette »superauktioner« i deres besøgendes browsere. Det giver alle udgiverens efterspørgselskilder – RTB-købere, annoncenetværk, direkte kampagner – mulighed for at konkurrere samtidigt om de tilgængelige visninger. Enhver efterspørgselspartner (f.eks. GumGum), der er kompatibel med udgiverens header bidding-wrapper, kan konkurrere om en visning.
Hvordan adskiller det sig fra vandfald, og – endnu vigtigere – hvorfor er det bedre end vandfald?
I et »waterfall« foregår alle beslutninger på udgiverens annonceservere: Så snart en visning bliver ledig, tjekker annonceserveren typisk, om den skal bruges til en direkte kampagne. Hvis ikke, søger den efter en anden køber, men de værktøjer, den har til rådighed til dette formål, er ret primitive. Generelt anmoder annonceserveren om et bud fra en realtids køber og sammenligner det med prisen fra det øverste annoncenetværk i dens vandfaldsmodel. Hvis RTB-buddet er højere, vinder den pågældende køber visningen. Hvis netværkets pris er højere, går buddet til netværket. På dette tidspunkt begynder mareridtet med annoncenetværksstandardindstillinger og vandfaldsmodellen.
Annoncenetværk kan frit afvise en visning og sende den tilbage til annonceserveren (dvs. »default«). Annonceserveren skal derefter finde en anden køber, som er det næste annoncenetværk i »waterfall«-strukturen, og hvis dette netværk afviser visningen, sender annonceserveren den videre til det næste, og så videre. Resultatet er stor forsinkelse og indtægtstab, hvis brugeren bliver træt af at vente på, at siden indlæses, og klikker væk. Værre endnu: Ved hvert skift fra et annoncenetværk til det næste går op til 10 % af visningerne tabt på grund af uoverensstemmelser. Det er et stort indtægtstab.
Generelt set (der er selvfølgelig undtagelser!) gælder det, at når en annonceserver først er røget ned ad annoncenetværkets »waterfall«, skal den af tekniske årsager typisk forblive der. Med andre ord: Når et netværk er blevet valgt som standard, kan det ikke vende tilbage til RTB og byde på annoncen igen.
Og her er grunden til, at indtægtstabet forværres endnu mere: Det kan meget vel være, at det indledende RTB-bud er højere end det, det første netværk rent faktisk er villigt til at betale – uden at annonceserveren er klar over det. Annonceservere kræver nemlig ofte, at udgivere indtaster en fast CPM for hvert annoncenetværk for at kunne vise annoncer fra dem. Denne pris er en pladsholder og repræsenterer typisk den gennemsnitlige CPM, som det pågældende netværk betaler. Men i virkeligheden betaler annoncenetværk forskellige priser for visninger, afhængigt af de kampagner, de har aktive på et givet tidspunkt. Lad os sige, at den gennemsnitlige CPM, som netværk A betaler, er 5,00 $, og at det er den pris, der er indtastet i annonceserveren. Lad os nu sige, at en visning bliver tilgængelig, og annonceserveren modtager et RTB-bud på 5,25 $. Annonceserveren vil tildele visningen til RTB-køberen, fordi den vurderer, at buddet er 0,25 $ højere end det, netværk A er villigt til at betale. Men hvad nu, hvis netværk A er i gang med at opkøbe annonceplads til en retargeting-kampagne for en førsteklasses bilproducent og er villigt til at betale en CPM på 15 $? Dette er ikke et usandsynligt scenarie – faktisk er det ret almindeligt.
Når man ser på de milliarder af visninger om måneden, er det let at forstå, hvorfor vandfaldsmodellen koster udgiverne en masse penge. Header bidding øger derimod effektiviteten i udgiverens indtægtsgenerering betydeligt, fordi det giver udgiveren mulighed for samtidig at vurdere den pris, hver køber er villig til at betale, og tildele annoncerne til den, der er villig til at betale mest.
Det reducerer også ventetiden ved indlæsning af sider og uoverensstemmelser betydeligt, så færre brugere forlader siden og dermed går glip af muligheden for at tjene penge.
Jeg kan godt se, hvordan Header Bidding gavner udgiverne, men hvordan gavner det køberne, når det kommer til at koste dem mere?
Header bidding giver købere en afgørende fordel, idet det giver dem mulighed for at konkurrere om visninger, som sandsynligvis ville være utilgængelige for dem i et vandfaldssystem. GumGum har for eksempel mulighed for at konkurrere om superpremium-visninger, som i et vandfaldssystem sandsynligvis ville være forbeholdt en direkte kampagne. Og selvom disse visninger er tilgængelige for tredjeparts-efterspørgselskilder, kan vi af de ovenfor nævnte årsager blive forhindret i at konkurrere om dem, selvom vi er villige til at betale mere.
Er der ulemper ved Header Bidding?
Hver gang der er tale om annoncering, vil der opstå forsinkelsesproblemer, og header bidding er ingen undtagelse. Det tager tid at afholde en auktion, udvælge en køber og vise annoncen. Når det er sagt, udgør forsinkelsen som følge af header bidding kun en brøkdel af den forsinkelse, der skyldes en »waterfall«-model.
Til sammenligning viser nogle undersøgelser, at 78 % af header bidding-transaktionerne tager under 200 millisekunder, mens det kun gælder for 12 % af waterfall-transaktionerne. 2. Hvorfor? Fordi alle byder samtidigt.
Du nævnte, at Header Bidding er muligt, så længe udgiveren har en wrapper. Hvad er det?
En wrapper er et stykke kode, der indeholder tags for alle en udgivers header bidding-efterspørgselspartnere. Wrapperen gør det nemt for udgivere løbende at tilføje partnere. Wrappers indeholder også vigtige tekniske og operationelle funktioner, som AdOpsInsider forklarer: »Typiske og forventede funktioner i en wrapper omfatter en asynkron container, der sikrer, at alle partnere får deres budanmodninger udløst på samme tid, en universel timeout-indstilling til at styre, hvor længe browseren venter på, at budgiverne svarer, samt partnerspecifikke »adaptere«, der gør det muligt for wrapperen at oversætte alle bud til en fælles nøgleværdi for annonceserveren.« 3
Købere skal overholde de wrappers, som udgiveren har implementeret, for at kunne deltage i auktionerne.
Hvem udvikler Header Bidding-wrappers?
Tidligere udviklede udgivere deres egne wrappers, men i dag findes der mange open source-systemer til header bidding-wrappers, der er udviklet af teknologivirksomheder som AppNexus og OpenX. Den løbende administration af en wrapper var en byrde for udgiverne, og derfor trådte teknologivirksomhederne til og udviklede wrappers, der strømliner processen.4 Som AppNexus forklarer: »Wrapperen er et enkelt stykke kode, der indeholder tags til alle en udgivers header bidding-efterspørgselspartnere, hvilket gør det nemt for udgivere at tilføje partnere efter behov og løbende administrere integrationerne.«5
Hvilken Header Bidding-løsning bruger GumGum?
GumGum har udviklet en pre-bid-wrapper, der er kompatibel med prebid.js, en gratis header bidding-wrapper, der er udviklet og inkuberet af AppNexus. Det betyder, at vi kan levere efterspørgsel til – dvs. konkurrere i superauktioner om – enhver udgiver, der bruger prebid.js. Klik her for mere information om prebid.js. Hvilke typer annoncer understøtter header bidding? Header bidding kan bruges til at konkurrere om alle annoncer, der findes på en webside, men indtil videre bruges det hovedsageligt til display-annoncer. Det er dog ved at ændre sig, i takt med at udgivere bliver mere fortrolige med header bidding. Nogle forudsiger, at digital video og endda in-app-annoncer vil se header bidding i 2018.6
-------------------------------------------------
1 https://dev.serverbid.com/v1.0/docs/hbix-sept-2017
3 http://www.adopsinsider.com/header-bidding/guide-header-bidding-wrappers/
4 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
5 https://blog.appnexus.com/2017/real-time-real-talk-prebid-js/
6 https://performancein.com/news/2017/10/17/header-bidding-next-evolution/
