Header bidding on ohjelmallisen mainonnan tekniikka, jota hyödyntää yli 70 % julkaisijoista eCPM-hintojen kasvattamiseksi, täyttöasteiden parantamiseksi ja mainostulojen maksimoimiseksi. Header bidding voidaan toteuttaa kahdella tavalla: client-side- tai server-side-toteutuksena.
Viime aikoina kiinnostus server-side header bidding -ratkaisuihin on kasvanut. Server-side-toteutus on erinomainen valinta käyttäjäkokemuksen parantamiseen sekä teknisen hallittavuuden ja tehokkuuden lisäämiseen. Client-side-mallissa liitettyjen SSP-yhteyksien määrällä on rajoituksensa, jotta sivun latausaika ei häiriinny, kun taas server-side-malli tarjoaa enemmän liikkumavaraa. Tämä joustavuus tuo kuitenkin mukanaan myös lisää vastuuta ja korkeammat kustannukset.
Prebid Serverin käyttöönotto
Ensimmäinen askel on valita teknologiakumppani, joka toteuttaa ja ylläpitää Prebidin palvelinpuolella, tai vaihtoehtoisesti rakentaa palvelininfrastruktuuri itse hyödyntämällä Prebid Frameworkia. Selvitä, kumpi näistä vaihtoehdoista sopii tarpeisiisi parhaiten.
Kehittäjien tulee asentaa Prebid Server, jotta on mahdollista osallistua kysyntälähteiden kilpailutukseen palvelimella. Lisäksi on tärkeää löytää helppo tapa päivittää server-side-koodia tarpeen mukaan sekä valvoa toteutuksen suorituskykyä. Koska Prebid Framework kehittyy jatkuvasti, toteutusta on päivitettävä säännöllisesti parhaan mahdollisen suorituskyvyn varmistamiseksi.
Oman ratkaisun kehittäminen vaatii usein huomattavasti teknisiä resursseja, sillä kyseessä on monimutkainen projekti. Usein onkin järkevämpää hyödyntää teknisiä alustoja (kuten Relevant Yield) server-side-toteutuksen ja ylläpidon teknisen taakan vähentämiseksi, samalla säilyttäen hallinnan omassa ympäristössä. Tämä mahdollistaa pienemmän riippuvuuden kehittäjistä ja enemmän teknistä autonomiaa adops- ja yield-asiantuntijoille.
Prebid Serverin rakentaminen itse saattaa aluksi vaikuttaa kustannustehokkaalta ja omavaraiselta ratkaisulta, mutta siihen voi liittyä piileviä haasteita. Prebid Server -osaaminen on erikoisala, joka vaatii vuosien kokemusta header bidding -teknologioista, ja osaavien kehittäjien löytäminen voi olla vaikeaa. Tämä kaventaa osaajien joukkoa ja tekee rekrytoinnista kalliin ja aikaa vievän prosessin. Vaikka sopiva kehittäjä löytyisikin, riippuvuus yhdestä henkilöstä voi vaarantaa mainosmonetisoinnin vakauden.
Mihin Prebid Serveriä käytetään?
Prebid Serverin käyttöönotto ja ylläpito on tunnetusti haastavaa, mutta miksi monet premium-julkaisijat ja verkostot silti valitsevat tämän ratkaisun? Tässä muutamia keskeisiä etuja, jotka tekevät sen teknisistä vaatimuksista perusteltuja.
Parempi tuotto parannetun käyttäjäkokemuksen kautta: Server-side-toteutuksessa verkkosivulta tai mobiilisovelluksesta tehdään yksi kutsu palvelimelle, joka jatkaa kutsuja serverin kautta kaikille kysyntälähteille. "Wrapper" palauttaa kaikki tarjoukset ja hinnat myyjille, joten hinnoittelu on läpinäkyvää. Tämä eroaa client-side-toteutuksesta, jossa kaikki kutsut tehdään käyttäjän selaimesta ja jonka hitaampi latausaika voi johtaa korkeampiin poistumisprosentteihin, negatiiviseen käyttäjäkokemukseen, alhaisiin täyttöasteisiin ja siten matalampiin mainostuloihin.
In-App-mainosmonetisointi Prebid Mobilen avulla: Prebid on Amazonin ja Googlen ohella yleinen header bidding -ratkaisu mobiilisovellusten mainosmonetisointiin. Koska Prebid Mobilea ei voi integroida client-side-puolella, tarvitaan server-side-tuki. Relevant Yield on auttanut useita sovellusjulkaisijoita saavuttamaan merkittäviä tuloksia Prebid Mobilen avulla, esimerkkinä WetterOnlinen yli 10 % kasvu.
Nopeutetut mobiilisivut (Accelerated Mobile Pages, AMP): AMP oli alun perin Googlen aloite hakutulosten parantamiseksi, mutta sen vaikutus hakusijoituksiin on kuitenkin vähentymässä. Jos et vielä käytä AMP:ia, harkitse, voisiko se olla hyödyllinen osa Prebid-toteutustasi. Monet julkaisijat pitävät sitä suoraviivaisena tapana parantaa mobiilisivujen suorituskykyä ja käyttäjäkokemusta. AMP:n käyttö edellyttää server-side-toteutusta.
Prebid DOOH: Prebid julkaisi tämän tuotteensa syyskuussa 2024, joten se on melko uusi. Prebid on päättänyt hyödyntää toteutuksessa Prebid Serveriä luodakseen yhtenäisen huutokauppaprosessin ja parantaakseen tarjousprosessin läpinäkyvyyttä.
Prebid Server tarjoaa samat optimointiominaisuudet kuin Prebid.js (client-side), joten siirtyminen ei vaadi kompromisseja. Myyjät voivat myös valita, että osa SSP:stä (Supply side platform) toimii client-side- ja osa server-side-ympäristössä parhaan suorituskyvyn saavuttamiseksi. Erilaiset SSP:t eri maantieteellisillä alueilla ja erilaisilla kokoonpanoilla voivat tuottaa vaihtelevia tuloksia server-side-ympäristössä, joten testaaminen on suositeltavaa parhaiden tulosten saavuttamiseksi.
Tehoa ja joustavuutta Header Bidding -toteutuksiin
Server-side-toteutukseen ei ole yksiselitteistä kyllä tai ei -vastausta. Siksi uskomme, että paras ratkaisu on, jos sinulla on mahdollisuus joustavasti siirtyä client- ja server-side-toteutusten välillä tarpeen mukaan, sillä yhden vaihtoehdon varaan jättäytyminen harvoin tukee kestävää kasvua ja kehitystä.
Relevant Yieldin filosofia on, että myyjillä tulee olla mahdollisuus käyttää molempia vaihtoehtoja joustavasti. Prebid-wrapper-ratkaisumme, HB Manager, tukee kaikkia Prebid-tuotteita, kuten Prebid.js:ää ja Prebid Serveriä, ja tarjoaa mahdollisuuden käyttää niitä rinnakkain. Vaikka client- ja server-side-kutsujen samanaikainen käyttö saattaa kuulostaa ristiriitaiselta, eri SSP:t kohdentavat tarjousstrategiansa eri kutsutyypeille, ja toisinaan toinen vaihtoehto voi olla tehokkaampi. Tästä syystä suosittelemme suorituskyvyn testaamista huolellisesti.
HB Managerin käyttöliittymä mahdollistaa erilaisten vaihtoehtojen joustavan testauksen ilman koodaustarvetta. Testien tuloksia voi seurata reaaliaikaisesti HB Analytics -moduulin avulla. Useimmat asetukset ja mukautukset voidaan tehdä suoraan käyttöliittymässä – esimerkiksi server-side-huutokauppojen aktivoiminen, SSP-liikenteen ohjaaminen ja maantieteellinen hinnoittelu. Näin löydät juuri sinulle parhaan toteutuksen: kuinka monta SSP:tä kannattaa olla client-side- ja server-side-puolella? Miten sivun latausnopeus muuttuu, kun client-side-tarjoajien määrää vähennetään, ja saavutetaanko näin halutut tulokset KPI-mittareihin?