Zrozumienie tego, jak działa header bidding jest kluczowe dla zrozumienia jak działają reklamy automatyczne. Pierwotnie header bidding miał rozwiązać problemy wiążące się z modelem kaskadowym (waterfall), tj. faworyzowaniem przez Google własnej giełdy reklam (AdX).
Ostatecznie header bidding całkowicie zastąpił model waterfall i stał się nowym standardem w branży. Przyjmuje się, że ponad połowa amerykańskich wydawców korzysta z tego rodzaju mechanizmów do licytacji stawki podczas sprzedaży swoich powierzchni reklamowych.
Co to jest header bidding?
Header bidding (pre-bidding, advance bidding, oraz holistic yield management) to automatyczny proces, który umożliwia wydawcom urządzić licytację przestrzeni reklamowej dla wielu chętnych (DSP, sieci reklamowych połączonych z giełdami reklam i SSP) jednocześnie na moment przed wysłaniem żądania reklamy do serwera reklamy.
Ten proces pozwala wydawcy “podejrzeć”, kto i za ile licytuje oraz wybrać najkorzystniejszą dla siebie stawkę CMP (Cost Per Mile – koszt za tysiąc wyświetleń).
Stawki w licytacji są ujawniane na moment przed wysłaniem żądania do serwera reklamowego; dlatego licytujący mogą konkurować o asortyment premium. Licytujący reklamodawcy mają większą szansę wygrać wyświetlenie. A wydawcy więcej zarobić za sprzedany asortyment.
W teorii wygrywają obie strony umowy. Ale wielkość “wygranej” zależy tak naprawdę od sposobu implementacji mechanizmu header bidding.
W tym poście opowiemy o implementacjach client-side header bidding (CSHB) i server-side header bidding (CSHB).
Co to jest header bidding po stronie klienta (CSHB, Client-Side Header Bidding)?
Implementacja client-side header bidding (aka browser-side header bidding) polega na dodaniu fragmentu kodu JavaScript do witryny wydawcy. Kod jest wykonywany przy każdym załadowaniu strony www przez użytkownika strony (internautę, który ją odwiedza) i wysyła zapytania o oferty do partnerów biznesowych, czyli potencjalnych reklamodawców. Zapytania o oferty to zaproszenie do licytacji przestrzeni reklamowej. Oferty od partnerów zaczynają spływać do DSP – dzieje się to za pośrednictwem platform SSP i giełd reklam, przy czym licytację wygrywa ten licytujący, który zaoferuje najwyższą cenę.
Jak to działa?
Aby zrozumieć jak działa client-side header bidding, spójrz na poniższą ilustrację. Przedstawia ona moment samej licytacji, czyli od chwili, gdy strona wydawcy jest już załadowana do milisekund przed wysłaniem żądania na serwer reklamy.
Krok po kroku:
- Użytkownik otwiera przeglądarkę internetową i wchodzi na stronę wydawcy, np. wydawca-abc.pl.
- Przeglądarka ładuje treść tej strony www.
- Kod JavaScript odpowiedzialny za procesy header bidding wysyła żądanie do platformy zewnętrznej, na której jest prowadzona licytacja pomiędzy reklamodawcami.
- Licytacja odbywa się.
- Licytację wygrywa ten, kto zaoferował najwyższą stawkę. Reklama wyświetla się na stronie www użytkownikowi.
Tak jak widzisz na grafice, są różne czasy pomiędzy pojawieniem się kolejnej oferty (kolejnej stawki licytacji). Te różnice oznaczają nie tylko to, że niektórzy licytujące nie zdążą złożyć swojej oferty, ale także to, że reklama na stronie zostanie wyświetlona z lekkim opóźnieniem. Przekroczenie limitu czasowego różni się też w zależności od urządzania: dla desktopów jest to 400–800 milliseconds, a dla urządzeń mobilnych 800–1,200 milliseconds.
Zalety client-side header biddingu dla wydawców
1. Synchronizacja ciasteczek
Ponieważ cały proces licytacji odbywa się w przeglądarce, dostawcy AdTech reprezentujący wydawców i reklamodawców mogą synchronizować swoje pliki cookie, co pozwala reklamodawcom zidentyfikować użytkownika w witrynie wydawcy.
To umożliwia reklamodawcom prowadzenie targetowanych i retargetowanych kampanii reklamowych i przekłada się na większe przychody wydawców.
2. Kontrola nad wrapperami i transparentnością
Wrappery to kod JavaScript, który zachowuje się jak system zarządzania na stronie wydawcy – mają podobną funkcję co tagi.
Używając wrapperów, wydawca może łatwo dodawać i usuwać wspomnianych wcześniej uczestników licytacji (tzw. demand sources) i ustalać limity czasowe dla składania ofert. Warto jednak wiedzieć, że konfiguracja wrapperów jest skomplikowana i ich zmiana (np. Z Index Exchange’s Header Tag na Prebid) jest wymagającym zadaniem.
Wydawcy, którzy używają wrapperów (lub pojedynczych tagów nagłówka do określania stawek) na swojej stronie internetowej otrzymują więcej informacji o tym kto i za ile licytuje.
3. Client-side header bidding branżowym standardem
Porównując server-side header bidding i client-side, ta ostatnia implementacja jest bardziej dopracowana, co sprawia, że branża najczęściej ją właśnie wybiera.
Wady client-side header biddingu
1. Opóźnienia
Header bidding powstało po to, aby zwiększyć efektywność licytacji (zastąpiło model waterfall). Jednak ta implementacja jest daleka od ideału.
CSHB wymaga dodania wielu skryptów do nagłówka strony, przez co spowalnia proces ładowania się kolejnych elementów strony, wpływając negatywnie na UX. Skutkuje to mniejszą ilością wyświetleń reklam.
CSHB potrzebuje także połączyć się z wieloma platformami AdTech za każdym razem, gdy użytkownik wczytuje stronę, a to może wpływać na prędkość połączenia użytkownika.
2. Kompatybilność
CSBH działa w przeglądarce, więc musi być wstecznie kompatybilny z różnymi przeglądarkami (także z ich starymi wersjami), a to może powodować problemy.
Ponadto niektóre przeglądarki mogą grupować połączenia nawiązywane przez mechanizm CSHB z innymi pikselami lub całkowicie je zablokować, a to oznacza, że niektóre aukcje się nie odbywają.
3. Ryzyko duplikowania stawek
Jeśli wydawca łączy się z wieloma partnerami licytacji jednocześnie, istnieje ryzyko, że będą oni licytować tę samą jednostkę wyświetlenia reklamy kilka razy, czyli duplikować stawki na aukcjach.
4. Wydajność
Dodanie kolejnych elementów CSHB (rozbudowanie logiki CSHB) może spowodować spowolnienie działania przeglądarki istrony www. Dla nowszych komputerów i urządzeń mobilnych to nie będzie wielki problem, ale wydajność starszych sprzętów może znacząco spaść.
5. Podatność na złe praktyki licytowania
Ponieważ mechanizm jest kontrolowany przez użytkownika, a nie renomowanego dostawcę, implementacja header biddingu po stronie klienta pozostawia sporo miejsca na stosowanie złych praktyk podczas licytacji, a zatem nigdy nie może być w pełni przejrzysta dla wszystkich zaangażowanych stron.
Procesy walidacji danych nigdy nie powinny przebiegać po klienta (client-side), ponieważ taka walidacja byłaby podatna na fałszowanie.
6. Ograniczona ilość licytujących
Przeglądarka ma ograniczone możliwości nawiązywania połączeń, a ponieważ CSHB ściśle współpracuje z przeglądarką, także wysyła żądania stawek licytacji (prośby o podanie stawki dla aukcji) do ograniczonej ilości uczestników licytacji.
Co to server-side header bidding (SSHB)?
Server-side header bidding to nowszy proces, ale wciąż podobny do CSHB. Różnica polega na tym, że licytacje odbywają się nie w przeglądarce, ale na dedykowanym serwerze. SSHB posiada te same zalety co CSHB, a jednocześnie eliminuje problemy np. Opóźnień działania strony www.
Jak to działa?
Zasadę działania SSHB zilustrowaliśmy poniżej.
Krok po kroku:
- Użytkownik otwiera przeglądarkę internetową i wchodzi na stronę wydawcy, np. wydawca-abc.pl.
- Przeglądarka ładuje treść tej strony www.
- Kod JavaScript odpowiedzialny za procesy licytacji wykonuje się, co znaczy, że wysyła żądanie do serwera SSHB.
- Serwer przekazuje informację o licytacji do partnerów biznesowych (czyli licytujących).
- Najwyższa stawka na licytacji wygrywa, a żądanie wyświetlenia reklamy jest przekazywane do serwera reklamowego wydawcy.
- Zwycięzka stawka z licytacji konkuruje teraz z direct deals. Direct deal to transakcja bezpośrednio zawarta przez wydawcę z reklamodawcą; towarem sprzedawanym są oczywiście wyświetlenia reklam.
- Serwer reklamowy porównuje, czyje stawka jest wyższa – licytującego, czy reklamodawcy, który kupił wyświetlania w direct deals. Serwer wybiera wyższą stawkę i reklama zwycięzcy jest wyświetlana.
Na ilustracji poniżej możesz jeszcze raz prześledzić obydwie implementacje.
Przypomnijmy, że główną różnicą jest to, że CSHB wykonuje się w przeglądarce, a SSHB na dedykowanym serwerze.
Zalety server-side header biddingu
1. Rozwiązuje problemy opóźnień
Kwestię opóźnień można rozwiązać poprzez użycie open source’owych rozwiązań jak Prebid.js czy poprzez ustawienie dłuższego czasu dla timeout’u, ale rozwiązania, które całkowicie eliminują potrzebę licytacji po stronie klienta, są oczywiste: wystaczy przenieść licytacje z przeglądarki na serwer.
To zniweluje zaledwie kilka milisekund opóźnienia, ale warto podjąć takie działanie, ponieważ te kilka milisekund ma ogromne znaczenie dla generalnego UX. Dla przykładu, CafeMedia uzyskała 40% szybsze ładowanie swojej strony www.
2. Lepiej działa przy licytacjach reklam wideo i rich media
Wideo generalnie są cięższymi plikami i wolniej się łądują, dlatego przejście z CSHB na SSHB znacznie przyspiesza wyświetlanie (i licytowanie) takiech reklam. Server-side to także jedyna możliwa implementacja, gdy mówimy o aukcjach dla urządzeń over-the-top (OTT), które są częścią bardzo kompleksowego ekosystemu reklamy telewizyjnej.
3. Większa ilość licytujących
W przeciwieństwie do przeglądarek internetowych, które mają ograniczone możliwości nawiązywania połączeń, server-side header bidding daje wydawcy możliwość zapraszania do licytacji tylu uczestników aukcji, ile ten tylko chce. Dla wydawców to szansa na większe zarobków i większą ilość sprzedanej powierzchni reklamowej (fill rate),a dla reklamodawców to szansa na uzyskanie większej skali swoich kampanii reklamowych.
Wady server-side header biddingu
1. Brak kontroli i transparentności
Stawka wyjściowa na licytacji jest ustalana przez wydawcę, ale nie może on wybrać dowolnie kupujących / licytujących. Proces aukcji pozostaje “ukryty” na serwerze, aby zapobiegać faworyzowaniu licytujących.
Takie możliwości dają wrappery w implementacji client-side.
2. Trudności w identyfikacji użytkowników
Server-side header bidding nie umożliwia synchronizacji ciasteczek, a większość danych o użytkownikach jest filtrowana podczas przenoszenia na serwer. Ranker, strona z ankietami, zanotowała 25% spadek przychodów z reklam ze względu na konfigurację SSHB.
3. Wdrażanie i zaufanie do rozwiązania
Niewielu wydawców i reklamodawców w pełni ufa implementacji server-side header biddingu, ponieważ jest to stosunkowo nowa metoda.
Odpowiedź Google na header bidding
Google nie przeszło obojętnie obok możliwości zbudowania własnego rozwiązania jako odpowiedzi dla header biddingu. Exchange Bidding Dynamic Allocation (EBDA) rozwiązuje problemy z opóźnieniem ładowania się strony internetowej i jest wspierane przez Google. Google podkreśla zaletę swojego rozwiązania: exchange bidding umożliwia wydawcom konsolidowanie rachunków i płatności.
EBDA jest dostępna wyłącznie dla certyfikowanych partnerów Google.
Google rozwiązuje też problem transparentności na aukcjach i ułatwia zarządzanie całym procesem, włączając w to płatności.
Server-Side czy Client-Side Header Bidding – który jest lepszy?
Wybór pomiędzy client-side i server-side header biddingiem jest decyzją wydawcy, która powinna opierać się o analizę dostępnej na sprzedaż przestrzeni reklamowej, ilości chętnych reklamodawców i aktualnych trendów.
Zarówno CSHB, jak i SSHB mają swoje wady i zalety, dlatego najlepszym wyjściem dla wydawcy jest przetestowanie obydwu implementacji i sprawdzenie, która generuje większe przychody w dłuższym horyzoncie czasowym.
