Header bidding i Prebid.js: jak wydawca zwiększa przychody z reklam

Czym jest header bidding i dlaczego zastąpił waterfall

Header bidding to sposób na to, żeby wszyscy partnerzy sprzedażowi wydawcy licytowali odsłonę równocześnie. Przed jego upowszechnieniem wydawcy sprzedawali powierzchnię kaskadowo.

W modelu kaskadowym serwer reklam odpytywał partnerów po kolei, według historycznej średniej stawki. Jeśli pierwszy partner nie kupił odsłony za cenę minimalną, trafiała do drugiego, potem do trzeciego. Problem polegał na tym, że partner z niższą średnią mógł być gotów zapłacić więcej właśnie za tę odsłonę, ale nigdy nie dostawał szansy. Do tego Google AdX, dzięki integracji z serwerem reklam Google, przez lata miał przewagę informacyjną – część tych praktyk była przedmiotem procesu, który opisujemy w tekście o wyroku w sprawie ad techu Google.

Header bidding odwraca tę logikę. Kod w nagłówku strony wysyła zapytania do wszystkich skonfigurowanych SSP jednocześnie, czeka na odpowiedzi przez ustalony czas i przekazuje najlepsze oferty do serwera reklam. Tam konkurują z kampaniami bezpośrednimi i z AdX. Jeśli dopiero zaczynasz poznawać role SSP, DSP i giełd, zacznij od przewodnika po programmatic.

Jak działa Prebid.js: od zapytania do wyświetlenia reklamy

Prebid.js działa w przeglądarce użytkownika i spina aukcję header biddingu z serwerem reklam. Cały cykl trwa zwykle do jednej, półtorej sekundy.

1. Strona ładuje bibliotekę Prebid.js zbudowaną z wybranych adapterów i modułów.
2. Prebid odczytuje sygnał zgody z platformy CMP i definicje miejsc reklamowych (ad units).
3. Adaptery wysyłają równoległe zapytania do SSP, każde w formacie danego partnera.
4. Prebid czeka na odpowiedzi do upływu limitu czasu; spóźnione oferty są odrzucane.
5. Biblioteka wybiera najlepszą ofertę dla każdego miejsca i ustawia klucze targetowania w tagu Google Publisher Tag.
6. Serwer reklam porównuje ofertę Prebid z kampaniami bezpośrednimi i AdX, a wybrana kreacja się wyświetla.
7. Jeśli wygrał partner z Prebid, kreacja jest renderowana przez Prebid Universal Creative.

Client-side, server-side czy model mieszany

Prebid ma dwie główne odmiany: bibliotekę działającą w przeglądarce i Prebid Server, który prowadzi aukcję na serwerze. Wybór wpływa na szybkość strony i skuteczność dopasowania użytkowników.

Google ma też własne rozwiązanie serwerowe, Open Bidding, które działa wewnątrz Ad Managera. Dla wielu wydawców sensowna jest kombinacja: Prebid dla głównych SSP i Open Bidding jako dodatkowe źródło popytu.

Konfiguracja Prebid.js krok po kroku

Poniższy przykład pokazuje minimalną konfigurację dla jednego miejsca reklamowego z dwoma partnerami, zgodami TCF i walutą PLN w serwerze reklam. Identyfikatory partnerów są przykładowe – prawdziwe dostaniesz od SSP.

var PREBID_TIMEOUT = 1000;
var FAILSAFE_TIMEOUT = 3000;

var adUnits = [{
  code: 'div-baner-top',
  mediaTypes: { banner: { sizes: [[750, 200], [750, 100]] } },
  bids: [
    { bidder: 'appnexus', params: { placementId: 12345678 } },
    { bidder: 'rubicon', params: { accountId: 1001, siteId: 2002, zoneId: 3003 } }
  ]
}];

var googletag = googletag || {};
googletag.cmd = googletag.cmd || [];
googletag.cmd.push(function () { googletag.pubads().disableInitialLoad(); });

var pbjs = pbjs || {};
pbjs.que = pbjs.que || [];
pbjs.que.push(function () {
  pbjs.setConfig({
    consentManagement: {
      gdpr: { cmpApi: 'iab', timeout: 8000, defaultGdprScope: true }
    },
    currency: { adServerCurrency: 'PLN', granularityMultiplier: 4 },
    priceGranularity: 'dense'
  });
  pbjs.addAdUnits(adUnits);
  pbjs.requestBids({ bidsBackHandler: wyslijDoAdServera, timeout: PREBID_TIMEOUT });
});

function wyslijDoAdServera() {
  if (pbjs.adserverRequestSent) return;
  pbjs.adserverRequestSent = true;
  googletag.cmd.push(function () {
    pbjs.que.push(function () {
      pbjs.setTargetingForGPTAsync();
      googletag.pubads().refresh();
    });
  });
}

setTimeout(wyslijDoAdServera, FAILSAFE_TIMEOUT);

Najważniejsze elementy: disableInitialLoad() wstrzymuje wywołanie serwera reklam do czasu zakończenia aukcji, timeout w requestBids określa, jak długo Prebid czeka na oferty, a funkcja awaryjna z setTimeout gwarantuje, że reklamy wyświetlą się nawet wtedy, gdy Prebid się nie załaduje. Moduł currency przelicza oferty na złote, a granularityMultiplier dopasowuje przedziały cenowe do waluty.

Klucze targetowania i pozycje w Google Ad Manager

Prebid przekazuje wynik aukcji do serwera reklam jako klucze targetowania. Najważniejsze to hb_pb (zaokrąglona cena), hb_bidder (zwycięski partner), hb_adid (identyfikator oferty) i hb_size (rozmiar). Po stronie Ad Managera tradycyjnie tworzy się zamówienie z setkami pozycji, z których każda odpowiada jednemu przedziałowi ceny. Ad Manager oferuje też funkcję Header Bidding Trafficking, która upraszcza tę konfigurację; według projektu wyroku w sprawie ad techu Google ma ona trafić do wszystkich wydawców Ad Managera.

Gęstość przedziałów cenowych (priceGranularity) to kompromis: im drobniejsze przedziały, tym dokładniejsza konkurencja z AdX, ale też więcej pozycji do utrzymania. W praktyce wydawcy często stosują własne przedziały: drobne w zakresie stawek, w którym odbywa się większość aukcji, i grube powyżej.

Zgody, RODO i TCF w header biddingu

Każdy partner Prebid przetwarza dane użytkownika, dlatego aukcja musi respektować zgody zebrane przez CMP. W Europie standardem jest TCF, a Google wymagał migracji do wersji 2.3 do 28 lutego 2026 r.

Moduł zarządzania zgodą w Prebid odczytuje ciąg TC z CMP i przekazuje go partnerom. Ustawienie defaultGdprScope: true sprawia, że przy braku informacji z CMP Prebid traktuje ruch jako objęty RODO, co jest bezpieczniejszym założeniem dla polskiego serwisu. Jeśli CMP ładuje się wolno, limit timeout w konfiguracji zgód decyduje, jak długo Prebid czeka na sygnał. Zbyt krótki limit oznacza aukcje bez zgód i niższe stawki. Wymogi wobec samego banera opisujemy w przewodniku po banerze cookies zgodnym z TCF 2.3 i Prawem komunikacji elektronicznej.

Do konfiguracji warto dodać moduł identyfikatorów użytkownika (User ID), który obsługuje identyfikatory alternatywne. Ich działanie i zgodność z RODO omawiamy w artykule o UID2, ID5 i RampID. Obowiązki prawne wydawcy w konkretnej sytuacji najlepiej skonsultować z prawnikiem.

Ile może zyskać wydawca i jak to zmierzyć

Efekt header biddingu zależy od jakości ruchu, liczby partnerów i dotychczasowej konfiguracji. Jedyną wiarygodną metodą oceny jest test z podziałem ruchu.

Załóżmy hipotetycznie, że serwis ma 3 mln odsłon miesięcznie i średni przychód 4 zł za tysiąc odsłon, czyli 12 000 zł. Jeśli po wdrożeniu header biddingu przychód na tysiąc odsłon wzrośnie do 4,80 zł, miesięczny przychód wyniesie 14 400 zł. Jednocześnie wolniejsze ładowanie reklam może obniżyć liczbę odsłon na sesję, więc część zysku zniknie. Dlatego porównuj przychód na 1000 sesji, a nie tylko eCPM.

Test przeprowadź na losowo podzielonym ruchu, np. 50% sesji z nową konfiguracją i 50% ze starą, przez co najmniej dwa pełne tygodnie. Zasady planowania takiego testu opisujemy w artykule o wielkości próby w testach A/B. Na znaczeniu zyskuje też widoczność reklam, o czym piszemy w tekście o viewability i attention metrics.

Najczęstsze błędy w header biddingu i jak je wykryć

W praktyce większość problemów z header biddingiem da się wykryć w konsoli przeglądarki. Dodanie parametru ?pbjs_debug=true do adresu strony włącza szczegółowe logi Prebid, a polecenie pbjs.getBidResponses() w konsoli pokazuje otrzymane oferty.

Zbyt wielu partnerów. Każdy adapter to dodatkowe połączenie i kod. Powyżej kilku, kilkunastu partnerów przyrost stawek zwykle nie rekompensuje spowolnienia. Usuń tych, którzy rzadko wygrywają.

Zbyt długi limit czasu. Limit 3000 ms zbiera więcej ofert, ale reklamy pojawiają się z opóźnieniem, a użytkownik zdąży przewinąć stronę. Zacznij od ok. 1000 ms i testuj.

Brak wpisów w ads.txt. Jeśli SSP nie ma wpisu w pliku ads.txt, wielu kupujących nie złoży oferty. Po dodaniu partnera zawsze aktualizuj ads.txt i sprawdź jego plik sellers.json.

Wpływ na Core Web Vitals. Ciężka biblioteka i wiele skryptów partnerów pogarszają szybkość strony. Zbuduj Prebid tylko z potrzebnych modułów i zarezerwuj miejsce na reklamy, żeby uniknąć przesunięć układu. Więcej w poradniku o tagach a Core Web Vitals.

Odświeżanie reklam bez kontroli widoczności. Automatyczne odświeżanie miejsc, których nikt nie widzi, zawyża liczbę odsłon i obniża wartość powierzchni w oczach kupujących, a w skrajnych przypadkach może być traktowane jako nieważny ruch. Jak kupujący wykrywają takie praktyki, wyjaśniamy w artykule o ad fraud.

Header bidding po wyroku w sprawie ad techu Google

Rozstrzygnięcie sądu w USA z września 2026 r. nakłada na Google obowiązek integracji AdX z Prebid. Gdy wejdzie w życie, AdX ma konkurować w aukcji Prebid na równych zasadach, a serwer reklam Google połączy się z Prebid Server.

Dla wydawcy oznacza to, że dobrze utrzymana konfiguracja Prebid stanie się jeszcze ważniejsza. Jeśli korzystasz z przestarzałej wersji biblioteki, pliku zbudowanego lata temu albo konfiguracji, której nikt nie rozumie, to dobry moment, żeby ją uporządkować. Kupujący z kolei będą widzieć tę samą odsłonę różnymi ścieżkami, co zwiększa znaczenie Supply Path Optimization. Wszystkie teksty o aukcjach i sprzedaży powierzchni znajdziesz w podtemacie Programmatic i RTB.