Bieden via koptekst
Header bidding is een geavanceerde programmatische techniek waarmee uitgevers hun voorraad aan meerdere SSP's en advertentie-uitwisselingen kunnen aanbieden voordat ze advertentieservers (DFP) aanvragen.
Google Ad Manager (voorheen DFP) is al lange tijd de populairste advertentieserver . DFP stelde uitgevers in staat om externe vraagpartners aan hun advertentiestack toe te voegen. Google had echter nog een troef achter de hand: het kon impressies inkopen vóórdat externe vraagpartners dat deden, met behulp van dynamische toewijzing in AdX.
Dit was voor onafhankelijke verkopers van advertentietechnologie aanleiding om een techniek te ontwikkelen die het speelveld voor hen gelijk maakte. Deze techniek staat nu in de volksmond bekend als header bidding.
Ondanks de brede acceptatie en populariteit ervan blijven de technische aspecten van header bidding voor veel uitgevers nog steeds een mysterie. Om uitgevers inzicht te geven in header bidding, hoe het werkt en de voor- en nadelen ervan, hebben we deze uitgebreide handleiding gemaakt.
Header bidding is een vorm van programmatische veiling waarbij biedingsverzoeken gelijktijdig en in realtime naar meerdere vraagpartners worden verzonden. Dit betekent dat elke advertentie-impressie de kans heeft om tegen de maximale waarde te worden gekocht, afhankelijk van de beschikbare vraag.
Deze biedingen worden vervolgens door verschillende filters ( minimumprijs en targetingcriteria) gehaald die uitgevers in hun advertentieserver hebben geconfigureerd . Het hoogste bod wordt geselecteerd uit de gefilterde biedingen en ten slotte wordt de advertentie op het scherm van de gebruiker weergegeven. Dit hele proces duurt een fractie van een seconde.
Voor headerbieden moet een JavaScript-codefragment worden toegevoegd aan het gedeelte van de website. Met deze JS-code kunnen uitgevers biedingsverzoeken genereren met behulp van browserbronnen.
Geschiedenis van kopbieden
Header bidding deed zijn intrede in de ad tech-wereld rond 2014. En slechts een jaar later, in 2015, werd de techniek razendsnel populair. Aanvankelijk werd header bidding ook wel tagless, pre-bidding, full bidding, parallel auction en vele andere namen genoemd, zoals beschreven in dit artikel van Digiday. In juni 2018 publiceerde AdExchanger dit artikel over header bidding , waarna de term definitief ingeburgerd raakte. En de rest is geschiedenis.
Vergelijking met watervalmethode
Vóór de introductie van header bidding maakte het programmatische ecosysteem gebruik van een watervalmodel om advertentieruimte te verkopen. Een watervalmodel (of daisy-chaining) houdt in dat een reeks netwerken en/of exchanges van boven naar beneden is gerangschikt op basis van hun prestaties voor de uitgever. Dit is gebaseerd op de prestaties van de netwerken in het verleden op het gebied van opbrengst ( eCPM ), fill rate, latency en meer. De impressie(s) worden van netwerk naar netwerk doorgegeven, van boven naar beneden, totdat ze zijn verkocht.
Het is een kwestie van prioriteiten stellen. Naarmate je verder naar beneden in de waterval gaat, dalen de CPM- minimumprijzen, maar is er ook minder toegang tot de beste advertentieruimte voor adverteerders om op te bieden. Hoewel dit proces er theoretisch voor zorgde dat er geen advertentieruimte onverkocht bleef en een uitgever de best mogelijke prijs kreeg, gebeurde in de praktijk het tegenovergestelde.
De uitgeverswaterval was een inefficiënte manier om voorraad te verkopen:
- • Tijdrovend proces: Het kostte veel tijd om de inventaris te verkopen, omdat deze van bieder op bieder overging.
- • Minder waar voor je geld: Uitgevers kregen niet de werkelijke waarde van hun indrukken te zien. Er bestond bijvoorbeeld een kans dat de volgende bieders bereid waren meer te betalen, maar dat de premiumvoorraad al tegen lagere kosten aan eerdere bieders was verkocht. En er was geen manier om de prestaties te vergelijken en te optimaliseren.
- • Oneerlijke competitie: Adverteerders kregen geen eerlijke kans om het juiste publiek te bereiken, wat uiteindelijk de inkomstenmogelijkheden van de uitgevers belemmerde.
- • Moeilijk in te stellen targeting: Targeting verbetert de opbrengst, maar de watervalconfiguratie was niet uitgerust om adverteerders aan doelgroepen te koppelen.
Het is duidelijk dat de mogelijkheden voor het genereren van inkomsten met waterval niet zo geweldig waren voor uitgevers. En in plaats daarvan kozen ze voor advertentietechnologieoplossingen van Google (AdSense en DFP). Dit leidde ertoe dat Google de supply chain voor advertentietechnologie domineerde. Google was (en is tot op zekere hoogte nog steeds) gesloten voor het delen van zijn handelstactieken.
Kopbieden ingevoerd als oplossing:
Headerveiling in realtime geeft uitgevers de kans om de inkomsten uit elke afzonderlijke vertoning te maximaliseren.
Omdat header bidding biedingsverzoeken tegelijkertijd naar alle vraagpartners verzendt, geeft het hen gelijke kansen om hun biedingen uit te brengen.
Op basis van de ingediende biedingen kunnen uitgevers de prestaties van elke transactie vergelijken met behulp van gegevens op logniveau en aanpassingen doorvoeren voor een hogere opbrengst.
Het is ontworpen om te concurreren met Google-veilingen. Daarom gaan vertoningen tegelijkertijd naar headerbiedpartners en de advertentieserver van Google.
Gezien de voordelen ten opzichte van de traditionele advertentiestrategie van uitgevers, begon de branche te investeren in deze technologie. In 2020 verdienen de meeste uitgevers geld met hun advertentievoorraad (ondersteunende cijfers zijn te vinden in de volgende subkop) via header bidding, naast andere methoden zoals programmatic advertising en directe deals.
Effecten op de inkomsten van uitgevers
Header bidding heeft uitgevers geholpen hun inkomsten met 20-50% te verhogen . De nieuwswebsite The Telegraph zag een CPM-stijging van meer dan 70% slechts 9 maanden na de implementatie van header auction.
Via de oplossing voor koptekstbiedingen van AdPushup heeft CCNA7, een niche-onderwijswebsite, kopbieden met advertentievernieuwing geïmplementeerd, waardoor de omzet in zes maanden tijd met 500% is gestegen.
Volgens een eMarketer-rapport bedragen de huidige mondiale uitgaven aan header bidding ongeveer $70 miljard. En tegen 2021 zal dit aantal naar verwachting met 87% groeien en 81 miljard dollar bereiken.
80% van de 1 grootste Amerikaanse uitgevers (gebaseerd op Alexa-ranglijsten) gebruikt header bidding met gemiddeld 7 vraagpartners per pagina.
Maar dit is één kant van data. Volgens hetzelfde onderzoek van eMarketer lijkt het groeipercentage voor de adoptie van header bidding af te nemen. Op dit moment bedraagt het adoptiepercentage van biedingen via koptekst 20% en in 2021 zal dit 15% zijn. Dit gebeurt vanwege twee dingen:
Headerbieden bereikt zijn groeidrempel, aangezien de meeste doelgroepuitgevers de techniek al hebben toegepast.
Uitgevers investeren in andere concurrerende technologieën (zoals Google's Open Bidding ) om hun advertentieruimte te gelde te maken.
Wat de reden ook is, op individueel niveau kunnen uitgevers nog steeds het maximale uit headerbiedingen halen, omdat de vraagzijde de advertentie-uitgaven blijft verhogen.
Wrapper en adapter voor bieden via koptekst
Elke keer dat er een vertoning beschikbaar is, genereert de browser een individueel biedingsverzoek voor alle vraagpartners. Hiervoor moeten uitgevers het codefragment van elke vraagpartner op hun website invoegen. Het invoegen of verwijderen van deze codefragmenten telkens wanneer een vraagpartner wordt toegevoegd of verwijderd, kan erg snel vervelend worden. Bovendien kan het voortdurend wijzigen van de headercode van een website zonder speciale ondersteuning van ontwikkelaars leiden tot uitval van de site of verstoring van de lay-out.
Om deze problemen (ten minste gedeeltelijk) op te lossen, werden header bidding wrappers ontwikkeld.
Een header-biedingswrapper werkt als een container waarin de codefragmenten van alle vraagpartners op één plek worden bewaard. Sommige wrappers bieden zelfs een GUI (zoals AdPushup), zodat uitgevers helemaal niet met code hoeven te rommelen, maar in plaats daarvan vraagpartners aan en uit kunnen zetten via een controlepaneel. Daarnaast kan de wrapper ook worden gebruikt om een minimumprijs en de time-outs in te stellen.
Enkele bekende header bidding wrappers zijn Prebid.js, Pubfood.js en BiddR°360.
Hoe werkt headerbieden: aan de clientzijde versus aan de serverzijde
Headerbieden begint zodra een webpagina in de browser van de gebruiker wordt geladen. Tegelijkertijd initieert de wrapper de veiling door biedingsverzoeken naar de vraagpartners te sturen.
Kopveiling werkt volgens het eersteprijsveilingmodel, wat betekent dat de hoogste bieder zijn advertentiemateriaal mag weergeven en precies betaalt wat hij tijdens de veiling heeft geboden.
Voordat biedingen via de koptekstveiling naar de wrapper worden verzonden, voeren de vraagpartners hun eigen veilingen uit om te beslissen welke adverteerder of DSP aan de hoofdkopveiling zal deelnemen.
Als het bod van geen enkele vraagpartner voldoet aan de minimumprijs of als de time-outs zijn verstreken, wordt de voorraad aangeboden aan reservenetwerken zoals AdSense, op basis van de Ad Manager-instellingen.
Header bidding kan grofweg in twee typen worden ingedeeld: client-side en server-side.
In het geval van headerbieden aan de clientzijde wordt de veiling uitgevoerd in de browser van de gebruiker. Dit maakt het matchen van cookies mogelijk voor een betere targeting, omdat uitgevers adverteerders toegang kunnen geven tot gegevens op biedingsniveau. Het bieden van headers aan de clientzijde is echter berucht omdat het een hoge paginalatentie veroorzaakt als gevolg van een hoger browserbronnen- en netwerkverbruik.
In het geval van headerbieden aan de serverzijde wordt de veiling uitgevoerd op een speciale veilingserver, weg van de browser van de gebruiker. Deze techniek bespaart netwerkbandbreedte en browserbronnen, waardoor de paginalatentie afneemt. Als het echter om targeting gaat, levert de server-side methode echter niet de gewenste resultaten op vanwege de lagere cookie-matchpercentages.
Om het beste uit beide veilingtypen te halen, kunnen uitgevers ook kiezen voor hybride headerbiedingen. Dit is waar uitgevers zowel headerbiedingen aan de clientzijde als aan de serverzijde samen uitvoeren, meestal binnen een multivariate testomgeving (waarover later meer wordt uitgelegd).
Waarom is bieden via koptekst beter dan Adsense?
Header bidding en Google Adsense zijn geen directe concurrenten, omdat ze verschillende doeleinden dienen voor uitgevers van verschillende omvang.
Hoewel beide methoden voor het genereren van inkomsten zijn voor websites, werken ze anders. Google AdSense is bedoeld voor nieuwe en kleinschalige uitgevers. Het is gemakkelijk te gebruiken omdat het uitgevers in staat stelt automatische tekst-, beeld-, video- of interactieve media-advertenties weer te geven die zijn gericht op de inhoud van de site en het publiek. Het werkt volgens het CPC-model (Cost-Per-Click) en Google zorgt voor alle advertentieweergaveprocessen.
Aan de andere kant is header bidding, zoals eerder vermeld in onze gids, een programmatische advertentietechniek waarmee uitgevers hun advertentievoorraad tegelijkertijd aan meerdere advertentie-uitwisselingen kunnen aanbieden. Het is geavanceerder en bedoeld voor grootschalige uitgevers.
Met andere woorden: als u op zoek bent naar een grootschalige oplossing voor advertentieweergave, is het haalbaarder om over te stappen van Google Adsense naar header bidding.
Kopbieden versus realtime bieden (RTB)
Realtime bieden is eenvoudigweg een mechanisme dat het kopen en verkopen van advertenties mogelijk maakt via realtime veilingen. Het mechanisme is vergelijkbaar met de beurs waar handelaren in realtime aandelen kopen/verkopen.
Zowel header bidding als real-time bidding zijn technieken die worden gebruikt in programmatische advertenties en die in verschillende fasen van ad tech actief zijn.
Headerbieden vindt plaats vóór de oproep van de advertentieserver, waardoor uitgevers de concurrentie kunnen vergroten en mogelijk de advertentie-inkomsten kunnen verhogen, terwijl RTB plaatsvindt na de oproep van de advertentieserver, waarbij adverteerders in realtime op beschikbare advertentievertoningen bieden.
Voordelen van kopbieden
Dit zijn de voordelen van bieden via koptekst voor uitgevers:
- • Gemaximaliseerde vraag: Met een kopveiling kunnen uitgevers meerdere vraagpartners toevoegen. Deze vraagpartners zijn verder verbonden met DSP's en adverteerders. Deze toeleveringsketen helpt de biedconcurrentie voor de voorraad te vergroten en genereert meer inkomsten.
- • Transparante uitwisseling: Zelfs met een complexe supply chain is het bekend dat header bidding de zaken heel eenvoudig houdt. Uitgevers kunnen eenvoudig controleren welk deel van de voorraad aan welke vraagpartner wordt verkocht met gegevens op biedniveau. Bovendien bieden veel wrappers geavanceerde rapportage en analyses waarmee uitgevers hun inkomsten en prestaties kunnen monitoren.
- • Betere controle: Met headerbiedingen kunnen uitgevers de veiling configureren volgens hun behoeften. Dit omvat het aanpassen van de minimumprijs, het instellen van time-outs en het toevoegen of verwijderen van vraagpartners om de advertentie-inkomsten in evenwicht te brengen met de paginalatentie.
- • Minimale afwijking: Omdat de veiling via een wrapper op het uitgeversplatform wordt georganiseerd, kunnen uitgevers de transacties volgen. Bovendien helpt het uitvoeren van gelijktijdige veilingen om de discrepantie te verkleinen: minder bewegende delen betekent minder discrepantie.
- • Ook voordelen voor adverteerders: Headerbieden is succesvol omdat het zowel de verkoop- als de koopkant ten goede komt. Net als uitgevers kopen adverteerders gemakkelijk voorraad die wordt verkocht via headerbieden. De transparante omgeving met weinig discrepantie moedigt adverteerders aan om evenveel te investeren in headerbiedingen.
- • Concurreer met Google AdX: Google AdX Het is bekend dat het eerst indruk doorgeeft aan zijn partner en vervolgens aan andere door de uitgever toegevoegde netwerken. Hierdoor worden de concurrentiemogelijkheden kleiner. Bij kopbieden kunnen zowel AdX- als kopbalbiedingspartners echter samen bieden.
- • Verhoogde omzet: In tegenstelling tot de watervalweergave waarbij advertentievertoningen op een sequentiële manier aan de vraagbronnen werden geleverd op basis van vooraf bepaalde prioriteiten, geeft koptekstbieden voorrang aan de hoogste bieders. Met bieden via koptekst verzekert de hoogste bieder in de veiling de mogelijkheid om advertenties weer te geven in de advertentievoorraad van uitgevers, wat resulteert in hogere winsten voor uitgevers.
- • Verbeterde advertentiekwaliteit: Bieden via koptekst vergroot de concurrentie tussen adverteerders om de advertentievoorraad, vooral onder adverteerders die zich richten op het publiek van een uitgever en graag hun advertenties willen weergeven. Als gevolg hiervan hebben uitgevers meer mogelijkheden om advertenties weer te geven die zijn afgestemd op de interesses van hun publiek, en dit resulteert in een betere advertentiekwaliteit.
- • Snellere laadtijden: Het onder controle houden van de laadtijden is ongetwijfeld een van de cruciale factoren achter een betere gebruikerservaring. Gelukkig zorgt header bidding voor een kortere laadtijd. Een header-biedingswrapper neemt snel contact op met advertentie-uitwisselingen en vraagpartners om binnen milliseconden biedingen veilig te stellen.
Nadelen van kopbieden
Alles over headerbieden klinkt tot nu toe geweldig. Maar de techniek is niet zonder uitdagingen. Om te beginnen is het ingewikkeld om op te zetten en te implementeren. Vervolgens draagt de client-side methode bij aan een verhoogde paginalatentie.
Hier zijn enkele andere nadelen waar uitgevers rekening mee moeten houden:
- • Ingewikkelde installatie: Het implementatieproces is een beetje lastig. Van het kiezen van de juiste wrapper tot het integreren van codes van meerdere vraagpartners: uitgevers hebben technische expertise nodig om header bidding te begrijpen en te implementeren.
- • Verhoogde kosten: Voor kopveilingen is vaak een toegewijde persoon (of team) nodig om toezicht te houden en prestatie verbeteren. Dit omvat het beheren van de advertentieblokken, het toevoegen/verwijderen van vraagpartners en meer. Dit verhoogt de kosten voor het runnen van de veiling.
- • Verhoogde latentie: Bij headerbieden aan de clientzijde worden de veilingen uitgevoerd in de browser van de gebruiker, wat bijdraagt aan een hoge paginalatentie. Met server-side veilingen zoals Open Bidding van Google kan dit probleem echter worden opgelost ten koste van het matchen van cookies.
- • Gebrek aan transparantie aan de serverzijde: Bij server-side veilingen worden de zaken beheerd door de leverancier die de veilingserver beheert, waardoor het voor uitgevers moeilijk wordt om toegang te krijgen tot rapportages over de prestaties van biedingen en vraagpartners. Gebrek aan transparantie zorgt ervoor dat uitgevers de biedingen accepteren die ze krijgen, waardoor de reikwijdte van verbeteringen wordt geminimaliseerd.
Wrapper en adapter voor bieden via koptekst
Elke keer dat er een vertoning beschikbaar is, genereert de browser een individueel biedingsverzoek voor alle vraagpartners. Hiervoor moeten uitgevers het codefragment van elke vraagpartner op hun website invoegen. Het invoegen of verwijderen van deze codefragmenten telkens wanneer een vraagpartner wordt toegevoegd of verwijderd, kan snel vervelend worden. Bovendien kan het voortdurend wijzigen van de headercode van een website zonder speciale ondersteuning van ontwikkelaars leiden tot uitval van de site of verstoring van de lay-out.
Om deze problemen (althans tot op zekere hoogte) te elimineren, zijn er header-biedingswrappers ontwikkeld.
Een header-biedingswrapper werkt als een container waarin de codefragmenten van alle vraagpartners op één plek worden bewaard. Sommige wrappers bieden zelfs een GUI (Graphical User Interface) zoals AdPushup, zodat uitgevers helemaal niet met code hoeven te rommelen. In plaats daarvan kunnen ze vraagpartners in- en uitschakelen via een controlepaneel. Daarnaast kan de wrapper ook worden gebruikt om een minimumprijs en de time-outs in te stellen.
Enkele bekende header bidding wrappers zijn Prebid.js, Pubfood.js en BiddR°360.
Laten we nu dieper ingaan en het hebben over twee primaire en meest gebruikte wrappers voor biedingen via koptekst.
Soorten wrappers voor biedingen via koptekst
Open-Source
Zoals de naam al doet vermoeden, zijn open-source header bidding-wrappers gratis en open-source oplossingen die voor iedereen gratis toegankelijk zijn en aangepast kunnen worden. Deze wrappers zijn over het algemeen prebid.js, prebid server en pubfood. Het is een door de gemeenschap aangestuurd ontwikkelingsmodel, dat wordt onderhouden door ontwikkelaarsgemeenschappen en vervolgens wordt geïntegreerd in advertentieservers waar iedereen van kan profiteren.
Met deze oplossing zijn uitgevers vrij om de verpakking aan te passen aan hun specifieke behoeften. Dit omvat het optimaliseren van de advertentieprestaties, het integreren van extra functies en meer. Veel uitgevers betalen echter uiteindelijk voor leveranciersondersteuning voor verschillende configuraties, integraties en andere vormen van ondersteuning. Uitgevers die voor open-sourceoplossingen willen kiezen, moeten dus goed thuis zijn in de technische details van de software om de functionaliteiten ervan beter te kunnen beheren.
Eigen verpakking
Aan de andere kant is de eigen wrapper een closed-source oplossing die door één enkele entiteit wordt aangeboden. Het is een verpakking die eigendom is van advertentietechnologiebedrijven. Het wordt geleverd met een eigen reeks functies en functionaliteiten die de effectiviteit en efficiëntie van headerbidding vergemakkelijken. Vanwege het propriëtaire karakter ervan is het echter niet haalbaar om aanpassingen of aanpassingen aan de oplossing aan te brengen, zoals wel het geval is bij een open-source header bidding wrapper.
Hoewel uitgevers die afhankelijk zijn van een propriëtaire wrapper er mogelijk afhankelijk van zijn, ligt een voordeel ervan in het gemak van implementatie en de toegankelijkheid van ondersteuning wanneer dat nodig is. Bovendien worden deze wrappers of adapters geleverd met hun eigen analytische hulpmiddelen waarmee uitgevers hun advertentieactiviteiten beter kunnen beheren en optimaliseren. Maar uitgevers moeten er rekening mee houden dat de aanpassingsmogelijkheden beperkt zijn, omdat uitgevers afhankelijk zijn van de wrapper-eigenaar om nieuwe functies te implementeren of bepaalde problemen aan te pakken.
Introductie van Prebid: Open Source HB Wrapper
Prebid is een open-source header-biedingswrapper gemaakt door AppNexus. Om Prebid te kunnen gebruiken, plaatsen uitgevers hun JavaScript-fragmenten op hun websites. Hierdoor kunnen uitgevers regelitems instellen en asynchrone advertentieaanroepen doen, zonder dat ze een interne techniek hoeven te ontwikkelen.
Uitgevers kunnen externe vraagpartners toestaan om via de Prebid-adapter op hun advertentieruimte te bieden . Als AppNexus bijvoorbeeld een van de vraagpartners is waarmee u wilt samenwerken, moet u uw Prebid integreren met de adapter van AppNexus.
Omdat het een open-sourcetechniek is, dragen veel toonaangevende leveranciers van advertentietechnologie bij aan de ontwikkeling van Prebid, waarbij AppNexus en Rubicon Project de twee grootste bijdragers zijn.
Prebid is ontworpen om flexibel te zijn en kan worden gebruikt op desktop, mobiel, app en zelfs AMP-inventaris. Het ondersteunt ook client-side, server-side en hybride header-biedingen. Omdat het een van de meest populaire wrappers is, ondersteunen de meeste vraagpartners Prebid-integraties.
Prebid's server-side oplossing: Prebid Server
Gezien de groeiende interesse in server-side header bidding heeft Prebid een server-side oplossing ontwikkeld, genaamd Prebid Server. Dit is een uitbreiding op de prebid.js wrapper, waarmee Prebid code biedt om alle biedingen van de demand partners van de uitgever te integreren via zowel client- als server-side configuratie.
Een uitgever die prebid.js al gebruikt Prebid-server zou alleen maar een advertentieserver nodig hebben en partners vragen die geïnteresseerd zijn in server-side veilingen. In principe kunnen uitgevers hun bestaande prebid-configuratie gebruiken om deze in te schakelen met Prebid Server.
Er is nog steeds een leercurve, waarbij het interne technische team van uitgevers de prebid-documentatie moet doornemen om hun instellingen bij te werken.
Voor- en nadelen van Prebid Server
VOORDELEN
- • Prebid-server biedt verbeterde concurrentie tussen vraagpartners, wat mogelijk tot hogere advertentie-inkomsten leidt
- • Het biedt transparantie in het biedingsproces, waardoor uitgevers waardevolle inzichten krijgen
- • Omdat de veilingen op de server plaatsvinden, biedt dit snellere laadtijden en een soepelere advertentie-ervaring die bijdraagt aan een betere algehele gebruikerservaring.
- • De Prebid-server vereenvoudigt het beheer van advertentieblokken door platforms aan de server- en clientzijde te integreren en prestatierapporten voor alle bieders en vraagpartners te consolideren.
NADELEN
- • Het runnen van een Prebid Server kan kosten met zich meebrengen voor de serverinfrastructuur en mogelijk voor technische expertise om deze te beheren
- • Omdat de veiling op de server plaatsvindt, hebben uitgevers mogelijk minder zicht op individuele biedingen en winnende bieders in vergelijking met header-biedingen aan de clientzijde
- • Prebid Server kan moeite hebben met het doorgeven van cookies en gebruikersgegevens van browsers naar servers en heeft invloed op de advertentietargeting nu de sector afstapt van cookies van derden.
- • Hoewel het eenvoudiger is dan oplossingen op maat, vereist Prebid Server nog steeds dat de uitgevers enige technische kennis hebben voor installatie en beheer.
Prebid.js: Prebid-oplossing aan de clientzijde
De client in Prebid client-side oplossingen staat voor de eindgebruikers die de advertenties bekijken. Bij dit soort oplossingen vinden de veilingen (realtime bieden op advertentievertoningen) plaats in de browser van de gebruiker.
Hier is hoe het werkt:
Een veilingtag, prebid.js, wordt ingebed in de broncode van een website en vervolgens uitgevoerd in de webbrowser van de gebruiker wanneer deze de website opent. Zodra de prebid.js-tag wordt uitgevoerd, roept de browser van de gebruiker de bieders op om deel te nemen aan de veiling.
Omdat Prebid.js rechtstreeks in de browser werkt, verzamelt het veel cookies boordevol nuttige informatie over waarin gebruikers geïnteresseerd zijn. Dit helpt adverteerders gebruikers te targeten op basis van hun recente browse-activiteiten en de juiste doelgroep te bereiken.
Voor- en nadelen van Prebid.js
VOORDELEN
- • Prebid.js geeft uitgevers toegang tot een grotere groep vraagpartners, wat de concurrentie en inkomsten helpt vergroten
- • Vervolgens stelt prebid.js de uitgevers, net als de prebid-server, ook in staat de biedingen van verschillende vraagpartners te zien, wat tot meer transparantie leidt
- • Uitgevers hebben controle over hun advertentievoorraad en kunnen minimumprijzen instellen en prioriteit geven aan vraagpartners
- • Prebid.js is open-source en maakt communitybijdragen, maatwerk en continue verbetering mogelijk.
- • Uitgevers zijn niet gebonden aan één enkele aanbieder van advertentietechnologie, waardoor de afhankelijkheid wordt verminderd en de flexibiliteit wordt vergroot.
NADELEN
- • Ten eerste kan het integreren en beheren van Prebid.js complex zijn, vooral voor uitgevers met beperkte technische expertise.
- • Het client-side karakter van Prebid.js kan leiden tot een langere paginalatentie en langzamere laadtijden
- • Bovendien kan de ondersteuning, omdat het een open-sourceproject betreft, variëren, en kunnen uitgevers voor het oplossen van problemen vertrouwen op communityforums en documentatie.
- • Ten slotte kunnen er, omdat er meerdere vraagpartners deelnemen, zorgen ontstaan over de kwaliteit en relevantie van advertenties, wat van invloed kan zijn op de betrokkenheid van gebruikers.
Kopbieden en AMP
Gezien de toegenomen vraag naar AMP-sites is het bieden via koptekst geüpdatet zodat het ook op AMP-pagina's werkt.
Waarom werkte kopbieden niet op AMP?
Omdat AMP werkt door onnodige JS van webpagina's te verwijderen, zodat deze sneller in de mobiele browser van de gebruiker worden geladen. In hetzelfde proces werd ook de HB JS verwijderd.
Voor uitgevers die inkomsten willen genereren met hun AMP-verkeer, heeft advertentietechnologie twee oplossingen:
Realtime configuratie (RTC)
RTC is een functie van Fast Fetch, die in 2018 door het AMP-team is uitgebracht als alternatief voor traditioneel header-bieden voor AMP-compatibele pagina's.
Hiermee kunnen uitgevers maximaal vijf vraagpartners toevoegen met een maximale time-out van 5 seconde. Het instellen van RTC is relatief eenvoudig en uitgevers kunnen met behulp van een paar regels code definiëren met welke leveranciers ze willen werken:
RTC is een goede oplossing voor uitgevers die header bidding snel willen implementeren op AMP-pagina's en niet al te veel eisen of behoefte aan maatwerk hebben.
Hieronder volgen enkele leveranciers die het RTC-protocol ondersteunen.
- 1. AppNexus
- 2. APS
- 3. Kritiek
- 4. IndexExchange
- 5.Media.net
Wrapper-gebaseerde integratie
De tweede manier is om samen te werken met een leverancier die een header-biedingswrapper levert met AMP-ondersteuning (zoals AdPushup). Gezien de aard van AMP werken alleen wrappers met server-naar-server-integratie goed, en zullen implementaties aan de clientzijde een grotere kans hebben om tijdens runtime door AMP te worden geblokkeerd.
Met wrapper-gebaseerd bieden via koptekst wordt de beperking van vijf vraagpartners omzeild door biedingen via één RTC-slot te routeren. Dit betekent dat u zoveel vraagpartners kunt toevoegen als u wilt. Maar dat is niet het enige voordeel van het gebruik van een op wrapper gebaseerde oplossing.
Met RTC en de aanpak met één tag hebben uitgevers een ontwikkelaar nodig die updates doorvoert elke keer dat ze een vraagpartner willen toevoegen/verwijderen. Een goede wrapper daarentegen zorgt ervoor dat uitgevers deze wijzigingen kunnen doorvoeren vanuit een gebruiksvriendelijk paneel. Wrappers zal uitgevers ook voorzien van rapportage- en analysegegevens, iets waar RTC op dit moment geen ondersteuning voor heeft.
Bieden via videokopteksten en de werking ervan
Net als bij standaard displayadvertenties stelt video header bidding uitgevers in staat hun videoadvertentievoorraad te verkopen aan de hoogste bieder. Aanvankelijk vereiste video header bidding aparte web- en serverintegraties; nu kunnen veel bestaande wrappers (zoals Prebid.js) worden geconfigureerd om video-inventaris te verkopen, zowel via client-side als server-side veilingen.
In 2016 vreesden uitgevers dat er weinig kopers geïnteresseerd waren in videoadvertenties, waardoor ze mogelijk niet dezelfde concurrentie zouden ondervinden als bij displayadvertenties. De afgelopen jaren is videoadvertentieruimte echter waardevol geworden. Volgens Statista bedroegen de uitgaven aan videoadvertenties $26 miljoen in 2020 en wordt een jaarlijkse groei van 6.8% verwacht, tot $35 miljoen in 2024.
Terwijl de markt voor video groeit, bundelen veel adverteerders en vraagpartners hun krachten om uitgevers aan te moedigen te experimenteren met videovoorraad. OpenX, AppNexus en SpotX zijn enkele van de vraagpartners die zich bezighouden met videoadvertentieruimte.
Het antwoord van Google op headerbiedingen: Open bieden
Kort na het enorme succes van header bidding lanceerde Google zijn eigen server-side versie en noemde deze Exchange Bidding Dynamic Allocation (later hernoemd naar Open Bidding).
Google presenteerde Open Bidding door de nadruk te leggen op de voordelen aan de serverzijde. In feite bood het uitgevers een server-naar-server veiling aan. Met Open Bidding konden uitgevers hun eigen vraag inbrengen en tegelijkertijd gebruikmaken van de vraag van Google (AdX) om S2S-veilingen op het Google-platform te organiseren.
Zowel client-side header auction als Open Bidding hebben hun eigen voor- en nadelen, dus we kunnen niet zeggen dat de ene beter is dan de andere. Bij een vergelijking blijkt client-side wel transparanter te zijn en betere cookie-matchingpercentages te bieden. Open Bidding daarentegen bespaart uitgevers de moeite van een complexe configuratie, omdat Google alles regelt, van de installatie tot het doorlopende beheer van de veiling.
Uitgevers kunnen tegelijkertijd header bidding en open bidding gebruiken in Google Ad Manager . Met deze methode krijgen uitgevers toegang tot de vraag van Google en kunnen ze hun eigen vraagpartners toevoegen om de bieddruk verder te verhogen.
Hier is hoe het werkt:
Zodra er een vertoning beschikbaar is, worden advertentieverzoeken verzonden naar Google AdX en header bidding. Binnen het AdX-systeem plaatsen zowel AdX- als Open bieden-kopers hun biedingen om de vertoning te winnen. Ondertussen begint header bidding biedingsreacties te verzamelen van de vraagpartners. Na voltooiing geven AdX en Open bieden hun winnaar door. Op dezelfde manier wordt kopbieden doorgegeven aan een ander. Tenslotte vergelijkt GAM deze biedingen en kiest de winnaar (hoogste bod).
Kopbieden vs. Open bieden (EBDA): wat is het verschil?
Voordat we het verschil tussen header bidding en open bidding bespreken , laten we eerst kort uitleggen wat open bidding inhoudt.
Wat is Open bieden (EBDA)?
Open bidding, ook wel bekend als exchange bidding of exchange bidding in dynamic allocation (EBDA), is Google's oplossing voor header bidding. Omdat het een Google-product is, is open bidding direct geïntegreerd in Google Ad Manager en stelt het uitgevers in staat om vraag van verschillende advertentie-uitwisselingen te benutten zonder dat er extra wrappers of configuraties nodig zijn.
Wat is het verschil tussen bieden via koptekst en Open bieden?
Het grootste verschil tussen de twee ligt in het implementatie- en technologieplatform.
Traditioneel header bidding maakt gebruik van header bidding wrappers en is niet gebonden aan een specifieke ad tech-aanbieder . Open bidding daarentegen is direct geïntegreerd in Google Ad Manager en omvat voornamelijk biedingen via Google's advertentiebeurs, namelijk Google AdX , samen met andere deelnemende advertentiebeurzen.
Hoewel open bieden werkt volgens de principes van header bidding, is het een oplossing van Google. Het biedt uitgevers de mogelijkheid om rechtstreeks via het Google Ad Manager-platform toegang te krijgen tot de vraag van verschillende advertentie-uitwisselingen.
De Header Bidding-oplossing van Amazon: UAM en TAM
Amazon, na Google en Facebook de derde grootste speler in digitale reclame, is ook een belangrijke speler op het gebied van header bidding. Amazon Publisher Services biedt twee server-side header bidding-oplossingen: UAM en TAM.
UAM (Unified Ad Marketplace) is ontworpen voor kleine tot middelgrote uitgevers. Amazon biedt een dashboard om de veiling te beheren, waar uitgevers hun eigen vraag kunnen inbrengen en deze in hun website kunnen integreren.
TAM (Transparent Ad Marketplace) is bedoeld voor grote uitgevers. Uitgevers krijgen toegang tot meer dan 20 vraagpartners van Amazon Marketplace, waaronder AppNexus, OpenX, Rubicon Project en SpotX. Daarnaast kunnen uitgevers hun eigen partners toevoegen aan Amazon TAM.
Uitgevers kunnen hun advertentieservers (DFP) integreren met Amazon en de regelitems bijwerken met nieuwe wijzigingen om biedingen te ontvangen.
Omdat Amazon nieuw is in het spel, wordt het aanbevolen om UAM/TAM te gebruiken met Open Bidding en Prebid om betere resultaten te zien.
Klaar om headerbiedingen te proberen? Hier zijn 5 stappen om je voor te bereiden
We raden deze vijf stappen aan ter voorbereiding op headerbiedingen voor uitgevers die nog niet bekend zijn met deze technologie:
Stap 1: Vraag of headerbieden geschikt voor u is
Als u nog niet bekend bent met bieden via koptekst, is de kans groot dat u AdSense eerder heeft gebruikt om inkomsten te genereren met uw verkeer. Met AdSense worden de meeste technische handelingen beheerd door Google. Koptekstbiedingen zijn echter volledig afhankelijk van uw technische expertise.
Je kunt jezelf verdiepen in header bidding en basis JavaScript leren. Of investeer in een ad ops-team dat deze taken voor je uitvoert. Als geen van deze opties werkt, kun je altijd nog een extern ad ops-team inschakelen om header bidding voor je te beheren.
Stap 2: Leer en lees over bieden via koptekst
Zelfs als u de hulp van uw advertentietechnologieteam inschakelt, loont het goed om tijd te investeren in het leren over de technologie. Om te beginnen helpt het u partnerschappen op te bouwen met HB-vraagpartners.
Maak uzelf vertrouwd met hoe header bidding werkt, wat het wel en niet voor u kan doen, en verbeter vanaf daar.
Als u meer te weten komt over de verschillende typen header-biedingen, de grootste spelers op de markt en het acceptatiepercentage, kunt u weloverwogen beslissingen nemen voor uw bedrijf.
Stap 3: Wees voorbereid op uitdagingen
Kopbieden is vruchtbaar, maar er zijn ook voortdurende uitdagingen met de technologie. Ten eerste voegt u extra stukjes code toe die de latentie kunnen vergroten.
Je zult zelf de rapportage moeten bedenken. In tegenstelling tot Google moet u hier samenwerken met uw data-ingenieurs om een rapportage-API te maken en deze te integreren in Excel of soortgelijke services om de groei (of afname) te zien.
Als uw huidige team dit niet aankan, kunt u gebruikmaken van beheerde header bidding-oplossingen.
Stap 4: Kies de vraagpartner zorgvuldig
Vraagpartners (of rendementspartners) verbinden u met de adverteerders. U moet deze partners zorgvuldig kiezen. Enkele voorbeelden van vraagpartners zijn Appnexus, Criteo en Index Exchange.
Deze partners hanteren standaardcontroles en minimumvereisten om uitgevers in hun kring toe te laten. U kunt contact met hen opnemen voor een partnerschap, maar als u ze niet zelf kunt beheren, kan het helpen om hulp te krijgen van aanbieders van headerbiedoplossingen (zoals AdPushup).
Stap 5: Testen, testen, testen en nog eens testen
Header bidding zorgt ervoor dat uitgevers royaal worden beloond voor hun advertentieruimte, maar niet zonder eerst te testen. A/B-testen met verschillende bieders helpen de totale omzet te verhogen en stellen uitgevers in staat te begrijpen wat het beste werkt voor hun advertentieruimte.
U moet zich concentreren op het scannen op fouten, het toevoegen/verwijderen van vraagpartners aan verschillende regelitems en het verhogen van uw totale omzet.
Hoe stel ik headerbiedingen in?
Om header bidding te implementeren, moeten uitgevers een JavaScript-code op hun website plaatsen sectie. Deze code wordt gebruikt om de veiling te activeren wanneer er een vertoning verschijnt.
Als de uitgever de website kan integreren met een header bidding wrapper, dan is Prebid.js de meest geschikte optie. Als een uitgever echter niet over de technische expertise beschikt om dit te doen, kunt u wellicht kiezen voor een beheerde service die wordt aangeboden door een externe leverancier van advertentietechnologie.
Zodra de wrapper aan de website is toegevoegd, kunnen uitgevers contact opnemen met vraagpartners om toegang te krijgen tot hun respectievelijke adapters. Met de adapters kunnen uitgevers verbinding maken met de marktplaats van de vraagpartner en kopers vinden voor hun advertentievoorraad.
De installatie kan in drie eenvoudige stappen worden verdeeld:
Vind de juiste vraagpartner: Grote vraag betekent grote inkomsten. Als je goede contacten hebt met advertentie-uitwisselingen en SSP's, is het toevoegen van een vraagpartner geen probleem. Ga niet zomaar voor de populaire partners, maar onderzoek en vergelijk hun diensten en kies de partners die het beste aansluiten bij jouw doelgroep en niche.
Installeer een header bidding wrapper: Vervolgens moet u een header bidding wrapper op de website plaatsen. Deze werkt als een container waarin u de codes van al uw demand partners plaatst en de veilinginstellingen en -regels configureert. Hierna ontvangen uw demand partners, telkens wanneer er een impressie beschikbaar is, verzoeken om biedingen uit te brengen.
Stel time-outs en minimumprijzen in: Het toevoegen van te veel vraagpartners zonder de campagne te configureren kan leiden tot trage laadtijden van de pagina. Daarom moeten uitgevers sessietime-outs instellen, oftewel tijdslimieten voor het beëindigen van de veiling. Ook moeten uitgevers minimumprijzen instellen voor verschillende advertentie-eenheden en eventuele andere beperkingen toevoegen, indien nodig.
Als u klaar bent met de stappen, moet u de instellingen nog steeds voortdurend controleren en optimaliseren om er zeker van te zijn dat u de opbrengst op vertoningsniveau maximaliseert zonder bruikbaarheidsproblemen te veroorzaken.
Extensies voor bieden via koptekst
Hier volgen enkele extensies voor bieden via koptekst die u kunt installeren om uw concurrenten te besnuffelen en te zien welke vraagrelaties zij hebben:
Headerbid Expert : Deze Chrome-extensie, mogelijk gemaakt door Prebid, toont het aantal vraagpartners dat biedt op een bepaalde webpagina. Daarnaast geeft het aan hoe lang het duurt voordat elke partner een bod plaatst. Dankzij de snelle analyse van de extensie weten uitgevers of hun time-outperiode redelijk is, of ze hun advertentieruimte onderwaarderen en hoe ze deze problemen kunnen oplossen.
BidFilter : Deze extensie toont gedetailleerde resultaten, zoals de namen van de vraagpartners die aan de wrapper zijn toegevoegd, samen met de ontvangen biedingen op individuele advertentieformaten . De tabbladen in de extensie tonen een lijst van alle biedingen, winnende biedingen en lege biedingen (partners die niet opzettelijk hebben geboden of vanwege een time-out).
Ter afsluiting
Voor uitgevers is bieden via koptekst een enorme sprong voorwaarts ten opzichte van het monopolie van Google en de inefficiëntie van andere programmatische veilingen. Het opende een meer gecontroleerd platform met de vereiste transparantie voor beide partijen op het gebied van advertentietechnologie.
Hoewel er nog een aantal uitdagingen moeten worden overwonnen, is de toenemende acceptatiegraad een teken dat wij er als sector gebruik van zullen blijven maken. De eerste tekenen, zoals de introductie van server-side veilingen en de beschikbaarheid van HB voor video- en AMP-inventaris, zijn een teken dat de technologie zeer flexibel is.
Mocht u hierover vragen of opmerkingen hebben, neem dan gerust contact met ons op.
Kopbieden en AdPushup
Verbeter uw advertentie-ervaring en maximaliseer uw inkomsten met onze slimme+ Managed Header Bidding-oplossing.
Wij helpen onze uitgevers met meer dan alleen header bidding. Onze oplossing voor bieden via koptekst wordt geleverd met een reeks functies om het rendement te helpen verhogen. We hebben meerdere functies voor advertentieoptimalisatie gebouwd met behulp van machine learning voor onze header-biedengine. Bovendien beschikken we over doorgewinterde ad-ops-experts, die beheerde services leveren met 24/7 ondersteuning.
Klik hier voor meer informatie over onze Smart+ Header-biedingsoplossing.
Headerbieden is een realtime biedproces waarbij JavaScript-code wordt toegevoegd aan de code van een website. Met behulp van deze code kunnen uitgevers gelijktijdig biedingsverzoeken naar kopers sturen, hun biedingen binnen een bepaalde tijd ontvangen, een winnaar kiezen en hun advertentie weergeven.
Bij headerbieden worden wrappers en adapters gebruikt om voorraad aan kopers te koppelen. Om de technische complexiteit te verminderen, fungeert de header-biedingswrapper als een container voor de website die adapters van meerdere vraagpartners kan bevatten. Om een partner toe te voegen/verwijderen, een time-out in te stellen en andere aanpassingen te doen, kunnen uitgevers wijzigingen aanbrengen in de wrapper.
Bieden via videokoptekst werkt precies hetzelfde als bieden via displaykoptekst, waarbij gebruik wordt gemaakt van wrappers en adapters. Om videokoptekstbiedingen te implementeren, moeten uitgevers vraagpartners hebben met kopers van videovoorraad. Zoek op basis van het type kopers dat u heeft een VAST/VPAID-advertentieserver en/of update advertentieblokken met outstream-videoadvertenties.
DFP (of Google Ad Manager) is een advertentieserver die Open Bidding (Google's S2S header bidding) aanbiedt. Daarnaast kunnen uitgevers DFP ook gebruiken om de prestaties weer te geven (rapporten te genereren) van uw andere instellingen voor bieden via koptekst. Dit kunt u doen door de regelitems bij te werken met uw vraag- (rendements)partners.
80% van de top 1K topuitgevers in de VS maakt gebruik van header bidding, waaronder onder meer Forbes, The Guardian en Buzzfeed.
Prebid.js is een open-source header-biedingswrapper ontwikkeld door AppNexus. Het biedt client-side, server-side, video- en AMP-integraties. Met Prebid.js kunnen uitgevers regelitems instellen en asynchrone, meerdere advertentieoproepen met een advertentieserver afhandelen.
Hoewel AdSense een populair advertentienetwerk is, is bieden via koptekst in veel opzichten beter, zoals de optie om gewenste vraagpartners toe te voegen/verwijderen. Het is bekend dat bieden via koptekst een betere eCPM biedt dan AdSense, dankzij de toegenomen belangstelling van grote adverteerders voor voorraad voor bieden via koptekst. Het transparante biedproces en de eerlijke concurrentie zorgden ervoor dat adverteerders kozen voor headerbieden, waardoor de advertentie-uitgavenstroom via particuliere marktplaatsen toenam.
Dynamische toewijzing plaatst Ad Exchange tegenover andere vraagpartners die zijn opgezet in de DFP van een uitgever, waardoor het rendement op de investering wordt vergroot en uitgevers worden aangemoedigd om de prijzen in Ad Exchange te verhogen, waardoor de waarde van de voorraad toeneemt.
Ja, WordPress-uitgevers kunnen ook header-biedingen implementeren. Het enige wat ze hoeven te doen is de kopbiedcode of het headerbiedscript toe te voegen aan het hoofdgedeelte van hun website en dat is alles.
Amazon Transparent Ad Marketplace (TAM), ook bekend als Amazon TAM, is een exclusieve header-biedingswrapper aan de serverzijde die is afgestemd op grootschalige uitgevers. Het linkt rechtstreeks naar grote advertentie-uitwisselingen zoals Magnite en PubMatic. Toegang tot TAM is uitsluitend op uitnodiging. Uitgevers die TAM gebruiken, profiteren van het voordeel dat ze naast hun huidige SSP-partners ook kunnen profiteren van de vraag van Amazon. TAM werkt echter als een selfserviceplatform, waarbij uitgevers de technische aspecten van headerbidding zelf moeten beheren.
Amazon Unified Ad Marketplace (UAM), ook wel Amazon UAM genoemd, dient als een server-to-server header bidding-wrapper die is afgestemd op kleine en middelgrote uitgevers. Het richt zich op mensen zonder directe SSP-relaties en biedt toegang tot Amazon's eigen SSP's zoals Pubmatic en Rubicon Project. UAM biedt het gemak van integratie met de huidige instellingen voor headerbiedingen. Het werkt echter alleen op uitnodiging en is beperkt tot specifieke regio's zoals de VS, wat hindernissen voor de toegankelijkheid oplevert.
