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 AdManager (voorheen DFP) was het populairst advertentieserver voor een lange tijd. DFP heeft uitgevers in staat gesteld externe vraagpartners aan hun advertentiestack toe te voegen. Google had echter een trucje in petto: het kon vertoningen kopen vóór externe vraagpartners, 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.
Kopbieden is een soort programmatische veiling waarbij biedingsverzoeken worden tegelijkertijd in realtime naar meerdere vraagpartners verzonden, wat betekent dat elk afzonderlijk advertentie impressie heeft de kans om tegen de maximale waarde te worden gekocht, op basis van de beschikbare vraag.
Deze biedingen worden vervolgens door verschillende filters gevoerd (bodemprijs en targetingcriteria) geconfigureerd door uitgevers in hun advertentieserver. Uit de gefilterde biedingen wordt het hoogste bod geselecteerd en ten slotte wordt het advertentiemateriaal 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 bereikte ergens rond 2014 de advertentietechnologie. En pas na een jaar, in 2015, ging de techniek viraal. In het begin werd header-bieden afwisselend tagless, pre-bidding, full bidding, parallelle veiling en vele andere namen genoemd, zoals gerapporteerd in deze Digiday-functie. In juni 2018 publiceerde AdExchanger dit artikel over headerbieden, en de term werd bevestigd. En de rest is, zoals ze zeggen, geschiedenis.
Vergelijking met watervalmethode
Vóór het bieden via headers gebruikte het programmatische ecosysteem een watervalconfiguratie om voorraad te verkopen. Watervalopstelling (of serieschakeling) omvat een ladder van netwerken en/of uitwisselingen, gerangschikt van boven naar beneden in volgorde van prestatie voor de uitgever. Gebaseerd op de eerdere prestaties van de netwerken op het gebied van rendement (eCPM), opvullingspercentage, latentie en meer. De vertoning(en) wordt van netwerk naar netwerk doorgegeven, van boven naar beneden, totdat deze wordt (worden) verkocht.
Het is een kwestie van prioriteiten stellen. Terwijl je de waterval afdaalt, de CPM prijsminimums dalen, maar er is ook minder toegang tot de beste voorraad waarop adverteerders kunnen bieden. Hoewel dit proces er theoretisch voor zorgde dat geen enkele voorraad onverkocht bleef en een uitgever de best mogelijke prijs ophaalde, gebeurde in werkelijkheid 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 werk aan aanpassingen voor een grotere opbrengst.
Het is ontworpen om te concurreren met Google-veilingen. Daarom gaan vertoningen tegelijkertijd naar headerbiedpartners en de advertentieserver van Google.
De industrie zag de voordelen ten opzichte van de waterval van uitgevers en begon te investeren in de technologie. Als we vooruitspoelen naar 2020, genereren de meeste uitgevers inkomsten met hun advertentievoorraad (ondersteunende cijfers vindt u in de volgende subkop) via headerbieden en andere methoden:programmatische en directe deals.
Effecten op de inkomsten van uitgevers
Bieden via koptekst heeft uitgevers geholpen hun omzet met 20-50% laten groeien. The Telegraph, een nieuwswebsite, heeft een stijging van de CPM met meer dan 70% gezien, net na negen maanden implementatie van de kopveiling.
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 top 1K Amerikaanse uitgevers (gebaseerd op Alexa-ranglijst) gebruik header bieden 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 die van Google). Open bieden) voor het genereren van inkomsten met hun voorraad.
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 (althans tot op zekere hoogte) te elimineren, Er zijn 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 (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.
Bieden via koptekst 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 de technieken die worden gebruikt programmatische reclame en opereren in de verschillende stadia van advertentietechnologie.
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 op hun voorraad te bieden met behulp van de Prebid-adapter. Als AppNexus bijvoorbeeld een van de vraagpartners is waarmee u wilt samenwerken, moet u uw Prebid integreren met de AppNexus-adapter.
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
Kijkend naar de belangstelling van de industrie voor header-biedingen aan de serverzijdeheeft Prebid zijn server-side oplossing ontwikkeld, genaamd Prebid Server. Dit is een uitbreiding op prebid.js wrapper – waarbij prebid een code aanbiedt om alle biedingen van de vraagpartners van de uitgever te integreren via zowel client- als server-side setup.
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 standaard weer te geven advertentiesMet videoheaderbiedingen kunnen uitgevers hun videoadvertentievoorraad aan de hoogste bieder verkopen. Aanvankelijk, bieden op videokoptekst vereiste afzonderlijke web- en serverintegraties; nu kunnen veel bestaande wrappers (zoals Prebid.js) worden geconfigureerd om video-inventaris te verkopen, via zowel client- als server-side veilingen.
In 2016 vreesden uitgevers dat niet veel kopers geïnteresseerd waren in videovoorraad, waardoor ze mogelijk niet het soort concurrentie zouden krijgen dat je bij display-advertenties ziet. Maar de afgelopen jaren is video-inventarisatie waardevol geworden. Volgens StatistaDe uitgaven voor videoadvertenties bedroegen in 26 $2020 miljoen en zullen naar verwachting een jaarlijkse groei van 6.8% kennen, 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 gaf deze een naam Dynamische toewijzing van exchange-biedingen (later hernoemd naar Open bieden).
Google gooide Open bieden door zich te concentreren op de voordelen aan de serverzijde. Kortom, het bood uitgevers een server-naar-server-veiling aan. Met Open bieden stond Google uitgevers toe hun eigen vraag in te brengen en ook de vraag van Google (AdX) te gebruiken om S2S-veilingen uit te voeren op het Google-platform.
Beiden Koptekstveiling aan de clientzijde en Open bieden hebben hun eigen voor- en nadelen, dus we kunnen niet zeggen dat de een beter is dan de ander. In vergelijking blijkt de clientzijde echter transparanter te zijn en betere cookie-matchpercentages te bieden. Terwijl Open bieden uitgevers verlost van complexe configuraties, omdat Google alles regelt, van de configuratie tot het lopende veilingbeheer.
Uitgevers kunnen tegelijkertijd bieden via koptekst en Open bieden uitvoeren Google AdManager. Met deze methode kunnen uitgevers toegang krijgen tot de vraag van Google en hun interne vraagpartners toevoegen om de bieddruk verder te verbeteren.
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 bij headerbieden vs Open biedenLaten we eerst snel begrijpen wat open bieden is.
Wat is Open bieden (EBDA)?
Open bieden, ook wel exchange-biedingen of exchange-biedingen in dynamische toewijzing (EBDA) genoemd, is de oplossing van Google voor header-biedingen. Omdat het een Google-product is, is Open bieden rechtstreeks geïntegreerd Google AdManager en stelt uitgevers in staat toegang te krijgen tot de vraag van verschillende advertentie-uitwisselingen zonder dat er extra wrappers of instellingen 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 bieden via koptekst omvat het gebruik van wrappers voor bieden via koptekst en is niet aan een specifiek onderwerp gebonden aanbieder van advertentietechnologie. Aan de andere kant is open bieden rechtstreeks geïntegreerd in Google Ad Manager en omvat het voornamelijk bieden via de advertentie-uitwisseling van Google, namelijk: Google Adx, samen met andere deelnemende advertentie-uitwisselingen.
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, de derde grootste naam op het gebied van digitaal adverteren, na Google en Facebook, is ook een belangrijke speler op het gebied van headerbiedingen. Zijn Amazon Publisher-services heeft twee server-side header bidding-oplossingen: UAM en TAM.
UAM (uniforme advertentiemarktplaats) is ontworpen voor kleine tot middelgrote uitgevers. Amazon biedt een dashboard om de veiling te beheren, waarbij uitgevers hun eigen vraag mogen inbrengen en deze in hun website kunnen integreren.
TAM (transparante advertentiemarktplaats) is bedoeld voor grote uitgevers. Uitgevers krijgen toegang tot meer dan 20 vraagpartners van Amazon Marketplace, waaronder AppNexus, OpenX, Rubicon Project en SpotX. Bovendien kunnen uitgevers hun eigen partners meenemen en deze 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.
U kunt uzelf informeren over headerbieden en basis-Javascript leren. U kunt ook investeren in het opzetten van een ad-ops-team dat deze taken voor u afhandelt. Als geen van deze werkt, kun je altijd kiezen uitbestede advertentieactiviteiten om kopbiedingen voor u 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 de hulp inroepen van beheerde header-biedingsoplossingen.
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
Headerbieden zorgt ervoor dat uitgevers rijkelijk worden beloond voor hun voorraad, maar niet zonder eerst tests uit te voeren. A / B-testen met bieders helpt de totale opbrengst te verhogen en stelt uitgevers in staat te begrijpen wat het beste werkt voor hun voorraad.
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: Een grote vraag betekent een grote omzet. Als je goede contacten hebt met advertentiebeurzen en SSP's, dan een vraagpartner toevoegen zal voor jou geen probleem zijn. Ga niet alleen voor de populaire partners, onderzoek en vergelijk hun diensten, en kies de diensten die passen bij uw doelgroepprofiel op basis van de niche waarin u actief bent.
Installeer een header-biedingswrapper: Vervolgens moet u een header-biedingswrapper op de website plaatsen. Dit werkt als een container, waarin u codes van al uw vraagpartners plaatst en veilinginstellingen en -regels instelt. Hierna ontvangen uw vraagpartners, elke keer dat er een vertoning beschikbaar is, verzoeken om biedingen te plaatsen.
Time-outs en minimumprijs instellen: Als u te veel vraagpartners toevoegt zonder de campagne te configureren, kan dit ertoe leiden dat de pagina langzaam wordt geladen. Daarom moeten uitgevers sessietime-outs instellen, dat wil zeggen tijdslimieten voor het beëindigen van de veiling. Op dezelfde manier moeten uitgevers minimumprijzen instellen voor verschillende advertentieblokken en indien nodig andere beperkingen toevoegen.
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:
Kopbod-expert: Een Chrome-extensie, mogelijk gemaakt door Prebid, die het aantal vraagpartners vertelt dat op een bepaalde webpagina biedt. Verder vertelt het de tijd die elke partner nodig heeft om zijn bod uit te brengen. Op basis van de snelle analyse die door de extensie wordt geboden, komen uitgevers te weten of hun time-outperiode voldoende is of dat ze hun inventarissen en methoden om deze problemen op te lossen te laag inschatten.
BiedFilter: Deze extensie toont gedetailleerde resultaten, zoals de namen van de vraagpartners die in de wrapper zijn toegevoegd, samen met de biedingen die op individuele biedingen zijn ontvangen advertentieformaten. De tabbladen bij extensie tonen een lijst met alle biedingen, winnende biedingen en lege biedingen (partners die niet opzettelijk of vanwege een time-out hebben geboden).
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 contact.
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.
Wilt u meer weten over onze Smart+ Header-biedoplossing, Klik hier..
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.
