W ciągu ostatnich kilku lat Clearcode pracował dla naszych klientów nad wieloma projektami związanymi z Prebid. W ramach tych projektów, opracowaliśmy wrappery, adaptery oraz interfejsy użytkownika do zarządzania procesem header bidding i różnymi źródłami popytu.
Dodatkowo, stworzyliśmy własne rozwiązanie do header bidding, o nazwie Header Bidding Control Center. Dzięki niemu, firmy mogą łatwo zarządzać konfiguracją Prebid za pomocą przyjaznego interfejsu użytkownika.
Michael Sweeney, szef marketingu Clearcode, przeprowadził rozmowę z Jackiem Jagiełło, architektem systemów w dziale badań i rozwoju Clearcode. Tematem rozmowy było budowanie, konfigurowanie i wdrażanie serwera Prebid przez firmy.
O Prebid
Co to jest Prebid?
Prebid to rozwiązanie open source, które umożliwia wydawcom przeprowadzanie aukcji w ramach header bidding na ich stronach internetowych i w aplikacjach mobilnych. Prebid.org jest organizacją, która zarządza i utrzymuje standardy, biblioteki JavaScript oraz zestawy SDK, które firmy mogą wykorzystać do dodawania funkcji header bidding do swoich cyfrowych zasobów, takich jak strony internetowe i aplikacje mobilne.
Header bidding to proces techniczny, dzięki któremu wydawcy mogą sprzedawać wyświetlenia reklam poprzez różne platformy po stronie dostawcy (SSP), zanim ich ad server zostanie uruchomiony w celu znalezienia reklamy, która jest dostępna dla danej przestrzeni reklamowej.
Jaka jest różnica między Prebid.js a Prebid serwerem?
Jeśli chodzi o wdrażanie header bidding za pomocą Prebid, wydawcy mają dwie główne opcje – Prebid.js i Prebid serwer. W prostych słowach, Prebid.js to biblioteka JavaScript, którą wydawcy mogą używać do przeprowadzania procesu header bidding po stronie klienta, natomiast Prebid serwer to dedykowany serwer, którego wydawcy mogą używać do przeprowadzania licytacji po stronie serwera, a nie w przeglądarce internetowej.
Zarówno implementacja po stronie klienta (Prebid.js), jak i po stronie serwera (Prebid serwer) mają swoje wady i zalety.
Główną zaletą przeprowadzania header bidding w przeglądarkach internetowych jest łatwiejsze identyfikowanie użytkowników, na przykład za pomocą plików cookie. Jednak głównym minusem jest opóźnienie ładowania strony. Im więcej partnerów w zakresie popytu współpracuje z wydawcą, tym dłużej może trwać proces wyświetlania reklam, co może negatywnie wpływać na doświadczenia użytkowników.
Główną zaletą przeprowadzania header bidding na serwerze jest przeniesienie wszystkich żądań po stronie klienta poza przeglądarkę internetową, co skraca czas oczekiwania dla uczestników licytacji. Jednak główną wadą jest trudność w identyfikacji użytkowników, ponieważ przekazywanie plików cookie z przeglądarki internetowej do serwera Prebid jest bardziej skomplikowane.
Twórcy aplikacji, którzy chcą zarabiać na swoich zasobach reklamowych na urządzeniach mobilnych, muszą korzystać z serwera Prebid, ponieważ wymaga tego Prebid Mobile SDK.
Jedną z zalet header bidding jest to, że wydawcy często znajdują reklamodawców oferujących wyższe stawki, gdy stawki są określane w nagłówku, niż w przypadku umów zawieranych na serwerze reklamowym, takich jak umowy bezpośrednie i oferty OpenRTB.
Prebid.js vs Prebid Server: Która opcja zapewnia największe przychody z reklam?
Określenie, która metoda implementacji zapewnia największe przychody z reklam, może być trudne, ponieważ zależy to od wielu czynników, takich jak rodzaj zasobów reklamowych wydawcy, odbiorcy oraz partnerzy w zakresie popytu, z którymi współpracuje.
Generalnie, jeśli wydawca polega na dopasowywaniu plików cookie, czyli identyfikowaniu użytkowników za pomocą identyfikatorów znajdujących się w plikach cookie, w celu sprzedaży swoich zasobów reklamowych, może doświadczyć spadku przychodów z reklam, jeśli przejdzie z Prebid.js (header bidding po stronie klienta) na Prebid Server (header bidding po stronie serwera).
Jest to spowodowane tym, że reklamodawcy mogą zapłacić mniej za wyświetlenie reklamy, jeśli nie mogą zidentyfikować użytkownika i określić, czy jest on częścią grupy docelowej.
W celu połączenia najlepszych cech obu rozwiązań, niektórzy wydawcy decydują się na hybrydowy model, w którym korzystają z Prebid.js do zarządzania wybranymi partnerami w zakresie popytu, a Prebid Server stosują dla pozostałych partnerów w zakresie popytu.
Q&A: Jak wykorzystać Prebid serwer do zbudowania giełdy reklam?
Co to jest Prebid serwer i jak jest na ogół wdrażany?
Michael Sweeney: Zanim przejdziemy do szczegółów dotyczących korzystania z Prebid Server do tworzenia giełdy reklam, porozmawiajmy o typowych przypadkach użycia Prebid Server oraz o różnicach w sposobie użycia w tych dwóch różnych sytuacjach.
Jacek Jagiełło: Zaczniemy od omówienia typowego przypadku użycia Prebid Server przez wydawcę.
Zazwyczaj wydawca ma skonfigurowaną własną instalację Prebid.js na swojej stronie internetowej, aby móc sprzedawać swoje zasoby reklamowe za pośrednictwem różnych platform po stronie dostawcy (SSP).
Ze względu na wydajność mogą zdecydować się na korzystanie z header bidding po stronie serwera (SSHB), więc wdrażają Prebid Server, konfigurują adaptery po stronie serwera i dostosowują konfigurację Prebid.js, aby połączyć się z serwerem Prebid Server i przeprowadzać header bidding po stronie serwera.
Natomiast agencja reklamowa, która posiada już ustaloną sieć reklamową, potrzebuje sposobu na integrację nowych wydawców z ich siecią, co jest niezbędne do skalowania działalności.
Aby umożliwić wprowadzenie nowych wydawców do swojej sieci popytu, agencja może stworzyć adapter, który łączy się z ich serwerem Prebid i udostępnić go wydawcom. W takim przypadku adapter agencji działa praktycznie jako kolejny adapter Prebid.js dla wydawcy.
Michael Sweeney: Więc w niektórych przypadkach wydawca może sam korzystać z Prebid Server, a agencja może do niego zwrócić się, mówiąc: “Możemy zapewnić Ci dostęp do większej liczby ofert poprzez nasz Prebid serwer”. Czy taka sytuacja jest możliwa? Czy wydawcy mogą wdrażać i wywoływać wiele różnych serwerów Prebid?
Jacek Jagiełło: Adapter agencji, który wydawca konfiguruje na swojej stronie w celu uzyskania dostępu do ofert agencji, może wywoływać dowolny punkt końcowy, który zwraca oferty. Takim punktem końcowym może być Prebid serwer.
Jest to korzystne dla agencji, ponieważ nie muszą tworzyć własnego oprogramowania, które integruje się z każdym źródłem popytu; mogą zamiast tego skorzystać z Prebid Server.
Jednak jeśli wydawca korzysta z tego samego adaptera ofert co agencja w swojej sieci ofert reklamowych, wydawca może otrzymać dwie lub więcej stawek z tego samego źródła ofert reklamowych. Powielanie stawek jest w rzeczywistości dość powszechne zarówno w implementacji header bidding po stronie serwera (SSHB) jak i po stronie klienta (CSHB).
Michael Sweeney: Tak, powielanie ofert jest problemem w header bidding, zwłaszcza jeśli masz wielu partnerów, takich jak SSP czy nawet serwery Prebid. Jak już wspomniałeś, wydawca i agencja mogą mieć te same źródła ofert reklamowych w swoich adapterach, co oznacza, że obaj otrzymują oferty z tego samego źródła.
Jacek Jagiełło: Dokładnie, mogą mieć różne identyfikatory użytkowników, ale ostatecznie oferty pochodzą z jednej witryny, która może być zidentyfikowana poprzez przekazanie domeny w żądaniu OpenRTB.
Michael Sweeney: Zgadza się. W jaki sposób reklamodawcy mogą więc określić, czy odsyłają odpowiedzi na stawkę za to samo wyświetlenie?
Jacek Jagiełło: Reklamodawca może wykryć takie powielenie, porównując czas otrzymania dwóch zapytań o stawkę. Istnieje kilka sposobów, na podstawie których reklamodawca może wykryć zduplikowane stawki.
Michael Sweeney: A jak wydawca może stwierdzić, czy otrzymuje te same oferty, gdy korzysta z dwóch różnych konfiguracji Prebid Server? Czy wydawcy mogą sprawdzić, z jakich źródeł ofert reklamowych korzysta agencja?
Jacek Jagiełło: To zależy od sposobu, w jaki agencja wdraża adapter. Agencja może działać jako pośrednik, współpracując z różnymi partnerami popytu, ale przekazując oferty wydawcy za pośrednictwem własnego adaptera.
Agencja może powiedzieć: “Używamy tych adapterów, a to źródło ofert reklamowych zwróciło tę ofertę”.
Ale mogą też powiedzieć: “Oto nasza oferta” (choć tak naprawdę otrzymali ją od AppNexus), ale podają ją jako swoją, ponieważ pochodzi z ich sieci, z ich adaptera.
Jednak pod maską agencja może używać różnych adapterów. W końcu zależy to od polityki agencji.
Jeśli wydawca skontaktuje się z agencją i poprosi o listę partnerów, z którymi współpracują, powinien być w stanie wykryć pokrywających się oferentów.
W jaki sposób agencje mogą zbudować giełdę reklam przy użyciu Prebid serwera?
Michael Sweeney: W jaki sposób proces header bidding działa z serwerem Prebid?
Jacek Jagiełło: Proces wygląda tak:
- Użytkownik odwiedza stronę internetową, a strona rozpoczyna proces ładowania.
- W nagłówku strony internetowej (między tagami <head> </head>) ładowany jest skrypt Prebid.js, który inicjuje żądanie do serwera Prebid.
- Prebid serwer przekazuje informacje o stronie internetowej, zasobach reklamowych i użytkowniku (np. identyfikator użytkownika, jeśli jest dostępny) do różnych platform po stronie dostawcy i giełd reklam, skonfigurowanych w adapterze Prebid Server.
- Platformy SSP (Supply Side Platform) następnie wysyłają zapytanie o oferty do różnych źródeł popytu, takich jak platformy DSP (Demand Side Platform) i giełdy reklam. Źródła popytu mają dostęp do setek, a nawet tysięcy kampanii reklamowych, reprezentujących reklamodawców.
- Platformy SSP analizują odpowiedzi z różnych źródeł popytu i zwracają oferty do serwera Prebid.
- Prebid serwer przekazuje oferty do pliku Prebid.js skonfigurowanego na stronie wydawcy.
- W zależności od konfiguracji Prebid.js, wszystkie oferty lub tylko najwyższa oferta są przekazywane do serwera reklamowego wydawcy. Ta oferta może teraz konkurować z innymi źródłami generowania przychodu z reklam na serwerze reklam, np. z ofertami bezpośrednimi.
- Jeśli ad server wydawcy uzna, że oferta z header bidding wygrywa aukcję, zostaje zwrócona specjalna kreatywna jednostka reklamowa, która jest renderowana na stronie i wyświetlana użytkownikowi.
Michael Sweeney: W tym przykładzie mówimy o agencji, która implementuje Prebid Server, ale czy SSP lub nawet wydawca mogliby również używać Prebid Server?
Jacek Jagiełło: Tak, Prebid Server może być wdrożony przez wydawcę, dostarczony przez SSP lub, jak w tym przypadku, przez agencję.
Prebid Server zawiera różne adaptery SSP i giełd reklam, które są wywoływane, gdy Prebid Server otrzymuje żądanie ze strony internetowej lub aplikacji mobilnej.
Michael Sweeney: Opowiedz nam o roli agencji i jej adaptera w tym kontekście.
Jacek Jagiełło: W tym przypadku agencja zarządza serwerem Prebid Server i oferuje go wydawcom, aby mogli go zaimplementować na swoich stronach internetowych i uzyskać dostęp do źródeł popytu dostarczanych przez agencję.
Agencja ma identyfikatory, parametry stawek itp., które są używane przez wielu wydawców. W razie potrzeby mogą również dostarczać określone parametry dla konkretnych wydawców. Te informacje wraz z konfiguracjami są hostowane na serwerze Prebid Server.
Aby umożliwić wydawcom korzystanie z ich wersji Prebid Server, agencja musi po prostu dostarczyć im swój adapter, który jest dodawany do stron wydawców.
Michael Sweeney: Aby odnieść korzyści z budowy serwera Prebid, trzeba mieć dostęp do wielu żądań, takich jak różne DSP, i nawiązać relacje z wieloma wydawcami, czyż nie?
Jacek Jagiełło: Tak. Prebid serwer działa podobnie jak giełda, ale bez faktycznych aukcji. Ostateczna decyzja, która oferta zostanie zwrócona, jest podejmowana przez SSP lub giełdę reklam, podobnie jak w typowej aukcji czasu rzeczywistego (RTB). Prebid serwer służy do hostowania i zarządzania różnymi połączeniami z źródłami popytu.
Niektórzy mogą używać terminu “aukcja przedlicytacyjna”, ale chodzi o to, że oferty są wysyłane do różnych SSP. Aukcje nie odbywają się na serwerze Prebid.
Warto również zaznaczyć, że Prebid Server nie jest serwerem reklamowym.
Nie zawiera skomplikowanej logiki, jaką można znaleźć w serwerze reklam. To jedna z różnic między Prebid Server a serwerem reklam – Prebid Server nie używa złożonej logiki do określania zwycięskich ofert; albo zwraca wszystkie oferty, albo tylko najwyższą ofertę ze źródeł popytu.
Warto również wspomnieć, że wydawcy często korzystają z serwera reklamowego, takiego jak Google Ad Manager lub innego, który podejmuje ostateczną decyzję, która reklama powinna zostać wyświetlona.
Ad server otrzymuje zwycięską stawkę z header bidding, a następnie porównuje ją z innymi elementami zamówienia, takimi jak bezpośrednie oferty, aby wybrać najlepiej płatną opcję.
W jaki sposób Prebid serwer przekazuje zwycięską ofertę do ad servera?
Michael Sweeney: Wspomniałeś, że Prebid Server jest odpowiedzialny za przekazywanie zapytań ofertowych do SSP i giełd reklam, a następnie za zbieranie odpowiedzi na oferty. Czy po zebraniu odpowiedzi na oferty od SSP i giełd reklam Prebid Server łączy się bezpośrednio z serwerem reklam i przekazuje najwyższą stawkę lub wszystkie oferty, jeśli tak zostało skonfigurowane, do serwera reklam?
Jacek Jagiełło: Prebid Server nie nawiązuje bezpośredniej interakcji z ad serverem — zwraca oferty do przeglądarki. Następnie przeglądarka internetowa przekazuje je do serwera reklam za pośrednictwem Prebid.js, który jest skonfigurowany tak, aby przekazać wszystkie oferty lub tylko najwyższą płatną ofertę do serwera reklam.
Michael Sweeney: Jakie informacje są przekazywane z przeglądarki do ad servera w celu wyświetlenia reklamy?
Jacek Jagiełło: Na serwerze reklamowym wydawcy należy skonfigurować kreatywy o nazwie “Prebid Universal Creative”. Jest to fragment kodu HTML, który jest umieszczany na serwerze reklam. Następnie należy skonfigurować element zamówienia z tymi kreatywami.
Kreatywy te są następnie przesyłane do przeglądarki, a fragment kodu wywołuje funkcję Prebid, aby wyświetlić zwycięski kreatyw. To jest w pewnym sensie jak przekazywanie informacji — serwer reklam mówi Prebidowi “wygrałeś aukcję, wyświetl tę kreację”.
Jest to trochę jak “piggybacking”, ponieważ kod używany do wyświetlenia reklamy Prebid jest dostarczany jako fragment kodu HTML z serwera reklam.
W związku z tym ad server jedynie wie, że ten element zamówienia wygrał aukcję i musi przekazać fragment kodu. Następnie fragment kodu wywołuje funkcję Prebid, aby wyświetlić reklamę.
Michael Sweeney: To niesamowite, jak wszystko toczy się w czasie, w którym musi się wydarzyć. Mówimy o wysyłaniu żądania z przeglądarki do serwera Prebid, a następnie do innych platform AdTech i z powrotem. Następnie jest ono ponownie wysyłane do przeglądarki i serwera reklam. Serwer reklam musi wtedy zdecydować, która reklama ma być wyświetlana spośród wielu różnych ofert, a następnie przeprowadzić cały proces wyświetlania reklam. A to wszystko dzieje się podczas ładowania strony internetowej!
Jacek Jagiełło: Tak, wiele procesów ma miejsce za kulisami podczas ładowania strony i wszystko dzieje się bardzo szybko.
Z tego powodu istnieje ryzyko błędów ludzkich i błędnych konfiguracji na różnych poziomach, dlatego ważne jest, aby firmy współpracowały z zespołem, który wie, jak prawidłowo zbudować, skonfigurować i wdrożyć Prebid.js lub Prebid Server.
Niewielki błąd lub nieprawidłowa konfiguracja może uniemożliwić poprawne działanie całego procesu header bidding.
Jak długo trwa zbudowanie giełdy przy użyciu Prebid serwera?
Michael Sweeney: Clearcode ostatnio pracowało nad kilkoma projektami, w których praktycznie budowaliśmy giełdę przy użyciu adapterów Prebid Server dla naszych klientów. Ile czasu ogólnie zajmuje budowa takiego rozwiązania?
Jacek Jagiełło: To zależy od kilku czynników, takich jak źródła popytu, z którymi wydawcy lub agencje chcą się zintegrować.
Samo wdrożenie jest dość proste – wystarczy zaimplementować Prebid serwera i napisać adapter. Ogólnie rzecz biorąc, ta część zajęłaby około miesiąca. Jednak może być również konieczne spędzenie dodatkowych 4 do 6 tygodni na konfiguracji adaptera, testowaniu, rozwiązywaniu problemów i wdrażaniu niestandardowych funkcji, jeśli to konieczne.
