Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Interakcja z określaniem stawek w czasie rzeczywistym rozpoczyna się, gdy Google wyśle do Twojej aplikacji pytanie o stawkę. Z tego przewodnika dowiesz się, jak zakodować aplikację, aby przetwarzała pytanie o stawkę.
Żądanie analizy
Google wysyła pytanie o stawkę jako zserializowany bufor protokołu dołączony jako ładunek binarny żądania POST HTTP. Pole Content-Type jest ustawione na application/octet-stream. Przykład znajdziesz w sekcji Przykładowe pytanie o stawkę.
Musisz przeanalizować to żądanie w instancji wiadomości BidRequest. Wartość BidRequest jest definiowana w elemencie realtime-bidding.proto, który można uzyskać ze strony danych referencyjnych. Wiadomość możesz przeanalizować za pomocą metody ParseFromString() w wygenerowanej klasie BidRequest. Na przykład ten kod C++ analizuje żądanie z ładunkiem POST w ciągu znaków:
string post_payload = /* the payload from the POST request */;
BidRequest bid_request;
if (bid_request.ParseFromString(post_payload)) {
// Process the request.
}
Gdy już będziesz mieć BidRequest, możesz używać go jako obiektu, wyodrębniając i interpretując potrzebne pola. Na przykład w C++:
for (int i = 0; i < bid_request.adslot_size(); ++i) {
const BidRequest_AdSlot& adslot = bid_request.adslot(i);
// Decide what to bid on adslot.
}
Niektóre informacje wysyłane w funkcji BidRequest, takie jak identyfikator użytkownika Google, język czy lokalizacja geograficzna, nie zawsze są dostępne. Jeśli masz
grupy reklam z kierowaniem wstępnym, które korzystają z nieznanych informacji w przypadku danego wyświetlenia, nie będą się one zgadzać. Jeśli brakujące informacje nie mają znaczenia w warunkach kierowania wstępnego, pytania o stawkę są wysyłane z pominiętymi informacjami.
Informacje o grupie reklam z kierowaniem wstępnym są dostępne w grupie MatchingAdData dla każdego elementu AdSlot. Zawiera on pierwszy pasujący identyfikator grupy reklam z kierowaniem wstępnym, która skłoniła Google do wysłania pytania o stawkę, czyli grupy reklam i kampanii, za które płacisz, gdy Twoja odpowiedź wygra aukcję dla wyświetlenia. W pewnych okolicznościach musisz wyraźnie wskazać w elemencie BidResponse.AdSlot atrybut billing_id, np. gdy BidRequest.AdSlot zawiera więcej niż 1 parametr matching_ad_data.
Więcej informacji na temat ograniczeń dotyczących treści stawki znajdziesz w realtime-bidding.proto.
Pliki słownika
Pytanie o stawkę korzysta z identyfikatorów zdefiniowanych w plikach słownika, które są dostępne na stronie danych referencyjnych.
Makra adresu URL stawki
Opcjonalnie niektóre pola BidRequest można wstawić do adresu URL używanego w żądaniu POST HTTP. Jest to przydatne np. wtedy, gdy używasz prostego frontendu, który równoważy obciążenie względem wielu backendów przy użyciu wartości z żądania. Skontaktuj się z technicznym menedżerem konta, by poprosić o pomoc w zakresie nowych makr.
Makro
Opis
%%GOOGLE_USER_ID%%
Zastąpione wartością google_user_id z tabeli BidRequest. Na przykład adres URL
Pytania o stawkę wysyłane do licytujących na giełdach i w sieci, którzy uczestniczą w Otwartym ustalaniu stawek, są podobne do pytań z usługi Authorized Buyers, które uczestniczą w standardowym określaniu stawek w czasie rzeczywistym. Klienci korzystający z Otwartego ustalania stawek otrzymają niewielką liczbę dodatkowych pól, a kilka dotychczasowych pól może mieć alternatywne zastosowania. Obejmują one:
OpenRTB
Authorized Buyers;
Szczegóły
BidRequest.imp[].ext.dfp_ad_unit_code
BidRequest.adslot[].dfp_ad_unit_code
Zawiera kod sieci Ad Managera wydawcy, po którym następuje hierarchia jednostek reklamowych, rozdzielone ukośnikami.
Przykładowy format: /1234/cruises/mars.
BidRequest.user.data[].segment[]
BidRequest.adslot[].exchange_bidding.key_value[]
Powtórzone pary klucz-wartość wysyłane od wydawcy do licytującego na giełdzie.
Możesz ustalić, że wartości są parami klucz-wartość wysyłanymi przez wydawcę, gdy BidRequest.user.data[].name ma wartość “Publisher Passed”.
Deklarowanie dozwolonych dostawców
Dostawcy technologii, którzy świadczą usługi takie jak badania, remarketing i wyświetlanie reklam, mogą odgrywać rolę w interakcji między kupującymi a sprzedawcami. Dozwolone są tylko dostawcy, którzy zostali zweryfikowani przez Google pod kątem udziału w interakcjach z Authorized Buyers.
Aby zrozumieć zasady BidRequest i utworzyć BidResponse, musisz wiedzieć, że deklarowanie dostawców technologii jest możliwe na 2 sposoby:
Inni dostawcy mogą uczestniczyć w programie tylko wtedy, gdy są zadeklarowani zarówno w BidRequest, jak i w BidResponse:
W BidRequest pole allowed_vendor_type określa dostawców, na których zezwala sprzedawca. Dostawcy wymienieni w polu allowed_vendor_type w BidRequest są wymienieni w pliku słownika Vendors.txt.
W BidResponse pole vendor_type określa, z których z dozwolonych dostawców kupujący chce korzystać.
Przykładowe pytanie o stawkę
Poniższe przykłady przedstawiają czytelne dla człowieka próbki żądań Protobuf i JSON.
Aby przekonwertować pytanie o stawkę na postać binarną (tak jak w przypadku ładunku POST w rzeczywistym żądaniu), wykonaj te czynności (w języku C++). Pamiętaj, że nie dotyczy to formatu JSON OpenRTB.
string text_format_example = /* example from above */;
BidRequest bid_request;
if (TextFormat::ParseFromString(text_format_example, &bid_request)) {
string post_payload;
if (bid_request.SerializeToString(&post_payload)) {
// post_payload is a binary serialization of the protocol buffer
}
}
Remarketing
Authorized Buyers przekazuje z aplikacji mobilnej identyfikator wyświetlania reklam mobilnych w pytaniach o stawkę. Identyfikatorem wyświetlania reklam mobilnych może być IDFA na iOS lub
identyfikator wyświetlania reklam w Androidzie. Wysyłany jest on za pomocą makra %%EXTRA_TAG_DATA%% w tagu JavaScript zarządzanym przez usługę Authorized Buyers.
Makro %%ADVERTISING_IDENTIFIER%% umożliwia kupującym otrzymywanie identyfikatora IDFA na iOS lub identyfikatora wyświetlania reklam na urządzeniu z Androidem podczas renderowania wyświetleń. Zwraca zaszyfrowany bufor proto MobileAdvertisingId taki jak %%EXTRA_TAG_DATA%%:
Listy użytkowników możesz tworzyć na podstawie identyfikatorów wyświetlania reklam mobilnych, korzystając z identyfikatorów wyświetlania reklam zebranych podczas renderowania wyświetleń. Listy użytkowników mogą być przechowywane
na Twoim serwerze albo na naszym serwerze. Aby utworzyć listy użytkowników na serwerach Google,
możesz skorzystać z naszej usługi przesyłania zbiorczego.
Gdy identyfikator wyświetlania reklam mobilnych pasuje do listy użytkowników, możesz go używać do remarketingu.
Opinie w czasie rzeczywistym
Opinie w czasie rzeczywistym są dostępne dla Authorized Buyers, a także giełd i sieci korzystających z Otwartego ustalania stawek.
Odpowiedzi na pytania o stawkę są obsługiwane w kolejnych pytaniach o stawkę zarówno w przypadku protokołów AdX, jak i OpenRTB. W przypadku OpenRTB jest on wysyłany w obrębie BidRequestExt.
Oprócz domyślnych pól wysyłanych w odpowiedzi na pytanie o stawkę możesz też wysyłać dane niestandardowe w odpowiedzi na stawkę (w AdX Proto lub OpenRTB) za pomocą metody event_notification_token zwracanej w BidResponse. event_notification_token to dowolne dane znane tylko licytującemu, które mogą pomóc w debugowaniu, np. nowy identyfikator kierowania lub identyfikator ustalania stawek reprezentujący nową taktykę albo metadane powiązane z kreacją, które są znane tylko licytującemu. Więcej informacji znajdziesz w artykule OpenRTB Protocol Buffer (Bufor protokołu OpenRTB) do RTB i AdX Proto dla AdX.
Gdy Authorized Buyers wysyła do licytującego pytanie o stawkę, licytujący odpowiada BidResponse. Jeśli licytujący ma włączone przesyłanie opinii w czasie rzeczywistym, w kolejnym pytaniu o stawkę wysyła opinię o odpowiedzi w komunikacie BidResponseFeedback, jak pokazano poniżej:
message BidResponseFeedback {
// The unique id from BidRequest.id
optional bytes request_id = 1;
// The index of the BidResponse_Ad if there was more than one. The index
// starts at zero for the first creative.
optional int32 creative_index = 2;
// The status code for the ad. See creative-status-codes.txt in the
// technical documentation for a list of ids.
optional int32 creative_status_code = 3;
// If the bid won the auction, this is the price paid in your account
// currency. If the bid participated in the auction but was out-bid, this
// is the CPM that should have been exceeded in order to win. This is not
// set if the bid was filtered prior to the auction, if the publisher or
// winning bidder has opted out of price feedback or if your account has
// opted out of sharing winning prices with other bidders. For first-price
// auctions, minimum_bid_to_win is populated instead of this field.
optional int64 cpm_micros = 4;
// The minimum bid value necessary to have won the auction, in micros of
// your account currency. If your bid won the auction, this is the second
// highest bid that was not filtered (including the floor price). If your
// bid did not win the auction, this is the winning candidate's bid. This
// field will only be populated if your bid participated in a first-price
// auction, and will not be populated if your bid was filtered prior to the
// auction.
optional int64 minimum_bid_to_win = 7;
// The minimum bid value necessary to have won the server-side component of
// the overall auction given that there was also an interest group bidding
// component to the overall auction which ran using the Protected Audience
// API. The value is expressed in CPM micros of the buyer account currency.
// The minimum bid to win for the overall auction, including bids from the
// server-side and the on-device interest group components, is populated in
// the minimum_bid_to_win field of the same BidResponseFeedback object.
optional int64 server_side_component_minimum_bid_to_win = 16;
// Billable event rate multiplier that was applied to this bid during
// ranking. The adjustment reflects the likelihood that your bid would
// generate a billable event (namely, the ad renders successfully) if it won
// the auction, relative to the probability that other bids generate a
// billable event if they won the auction. This adjustment can be larger or
// smaller than 1. This affects the final ranking in the auction only; in
// particular, this multiplier does not affect the payment or whether the
// bid clears any floor price.
optional float billable_event_rate_bid_adjustment = 15 [default = 1];
// When a publisher uses an RTB auction and waterfall-based SDK mediation on
// the same query, the winner of the real-time auction must also compete in
// a mediation waterfall (which is ordered by price) to win the impression.
// If the bid participated in the auction and there was no waterfall, the
// value of this field is 0. If the bid participated in the auction and
// there was a waterfall, the value of this field is a price representing a
// sample bid from the eligible mediation networks that were higher than the
// auction winner, weighted by expected fill rate. This field can be used
// in conjunction with minimum_bid_to_win to train bidding models. The CPM
// is in micros of your account currency.
optional int64 sampled_mediation_cpm_ahead_of_auction_winner = 10;
// Event notification token that was included in the bid response.
optional bytes event_notification_token = 5;
// Buyer creative ID that was included in the bid response.
optional string buyer_creative_id = 6;
// Possible types of bid response feedback objects.
enum FeedbackType {
FEEDBACK_TYPE_UNSPECIFIED = 0;
// Feedback for a bid that was submitted on a bid response.
BID_FEEDBACK = 1;
// Feedback for an interest group buyer submitted on a bid response to
// particpate in an interest group bidding component of the auction run
// using the Protected Audience API.
INTEREST_GROUP_BUYER_FEEDBACK = 2;
}
// The type of the BidResponseFeedback message. Google will send separate
// BidResponseFeedback objects for:
// a) Each bid submitted on a bid response
// b) Each buyer submitted on a bid response to particpate in an interest
// group bidding component of the auction run using the Protected Audience
// API.
optional FeedbackType feedback_type = 17;
// Origin of an interest group buyer that was included in the bid response.
// This field is populated only for feedback where a bidder opted in an
// interest group buyer to participate in the interest group bidding
// component of the overall auction run using the Protected Audience API.
// To learn more about origins, see https://www.rfc-editor.org/rfc/rfc6454.
// To learn more about interest group bidding and the Protected Audience
// API, see
// https://developers.google.com/authorized-buyers/rtb/fledge-origin-trial.
optional string buyer_origin = 18;
// The status code for the submitted interest group buyer. This field is
// only populated in the feedback for an interest group buyer that a bidder
// requested to enter into the interest group auction through the bid
// response. Individual creative status codes of bids submitted by the buyer
// in the on-device interest group auction are not available. See
// https://storage.googleapis.com/adx-rtb-dictionaries/interest-group-buyer-status-codes.txt
// for a list of interest group buyer status codes.
optional int32 interest_group_buyer_status_code = 19;
}
Pierwsze pole, które należy sprawdzić w tej wiadomości, to bid_response_feedback.creative_status_code. Znaczenie kodu znajdziesz w pliku
creative-status-codes.txt. Pamiętaj, że jeśli wygrasz stawkę, możesz zrezygnować z opinii o cenach. Więcej informacji znajdziesz w artykule Jak zrezygnować.
Informacje zwrotne w czasie rzeczywistym zawierają identyfikator pytania o stawkę i jeden z tych elementów:
Wynik aukcji
Opinie w czasie rzeczywistym
Kupujący nie przesłał stawki.
Nic.
Kupujący przesłał stawkę, która została odfiltrowana, zanim trafiła na aukcję.
Tworzenie modelu ustalania stawek na potrzeby aukcji pierwszej ceny
Po ustaleniu stawki w aukcji pierwszej ceny otrzymasz informacje zwrotne w czasie rzeczywistym, w tym pola minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, jeśli stawka nie została odfiltrowana z aukcji. Sygnały te można wykorzystać do ustalania, o ile wyższa lub niższa byłaby stawka, aby wygrać wyświetlenie.
minimum_bid_to_win: minimalna stawka, jaką można było ustawić, aby wygrać aukcję z określaniem stawek w czasie rzeczywistym. Jeśli wygrasz aukcję, będzie to
najniższa stawka, jaką można było zaoferować, a jednocześnie nadal wygrywać. Jeśli przegrasz aukcję, będzie to zwycięska stawka.
sampled_mediation_cpm_ahead_of_auction_winner: jeśli w łańcuchu zapośredniczenia są też inne sieci, wartość w tym polu to cena reprezentująca przykładową stawkę z jednej z odpowiednich sieci zapośredniczenia, która była wyższa niż zwycięzca aukcji i ważona według oczekiwanego współczynnika wypełnienia. Jeśli żadna z sieci w łańcuchu zapośredniczenia nie powinna wypełniać żadnej sieci lub jeśli wydawca nie korzysta z zapośredniczenia SDK, ma wartość 0.
Jak to działa
Aby opisać obliczenia użyte do określenia możliwych wartości dla funkcji minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner, musimy najpierw zdefiniować:
Poniżej podajemy wartości CPM w łańcuchu zapośredniczenia w kolejności malejącej:
\[C_1, C_2, …, C_n\]
Poniżej przedstawiono odpowiadające współczynniki wypełnienia dla CPM w łańcuchu zapośredniczenia:
\[f_1, f_2, …, f_n\]
Ta funkcja służy do określania oczekiwanego CPM i prawdopodobieństwa z elementu łańcucha zapośredniczenia \(i\)na podstawie podanego współczynnika wypełnienia:
\(X_i = \{C_i\) z prawdopodobieństwem \(f_i\); \(0\) z prawdopodobieństwem \(1 - f_i\}\)
Ostatni zwycięski łańcuch zapośredniczenia to:
\[\{C_1, C_2, …, C_K, W\}\]
gdzie \(W\) jest zwycięska stawka oraz \(C_K > W >= C_{K+1}\)
Cena minimalna jest oznaczona jako \(F\).
Stawka za drugie miejsce jest oznaczona jako \(R\).
Obliczenia dotyczące zwycięzcy aukcji
Pole
Obliczenie
minimum_bid_to_win
\(max\{F, R, X_{K+1}, …, X_n\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
\(\{C_i\) z prawdopodobieństwem \(\prod_{j=1}^{i-1}(1-f_j) \cdot f_i \div \prod_{j=1}^{K}(1-f_j)\}\)
Dotyczy \(1 <= i <= K\).
Obliczenia dotyczące przegranych aukcji
Pole
Obliczenie
minimum_bid_to_win
\(max\{F, W\}\)
sampled_mediation_cpm_ahead_ of_auction_winner
\(max\{X_1, …, X_K\}\)
Przykład z prostym łańcuchem zapośredniczenia
Załóżmy, że wydawca używa zarówno określania stawek w czasie rzeczywistym, jak i łańcucha zapośredniczenia SDK w taki sposób:
Łańcuch zapośredniczenia SDK
Oczekiwany CPM
Współczynnik wypełnienia
Sieć 1
\(C_1 = $3.00\)
\(f_1 = 5\%\)
Sieć 2
\(C_2 = $2.00\)
\(f_2 = 45\%\)
Sieć 3
\(C_3 = $0.50\)
\(f_3 = 80\%\)
Sieć 4
\(C_4 = $0.10\)
\(f_4 = 85\%\)
Zakładamy, że po przeprowadzeniu aukcji RTB:
Aukcja RTB
CPM
Zwycięzca aukcji (Z)
4 PLN
Z drugiej ręki (R)
0,05 USD
Cena minimalna / cena minimalna (F)
0 zł
Stawka, która wygrała aukcję
Poniżej znajdziesz przykład obliczania prawdopodobieństwa w przypadku stawki, która wygrała
minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner.
Poniżej znajduje się przykład obliczania prawdopodobieństwa w przypadku przegranych stawek
minimum_bid_to_win i sampled_mediation_cpm_ahead_of_auction_winner.
minimum_bid_to_win
Probability,
\(max(F, W) = $1.00\)
\(100\%\)
sampled_mediation_cpm_ ahead_of_auction_winner
Probability,
\(C_1 = $3.00\)
\(f_1 = 5\%\)
\(C_2 = $2.00\)
\((1-f_1) \cdot f_2 =~ 42.8\%\)
\(0\)
\((1-f_1) \cdot (1-f_2) =~ 52.2\%\)
Rozdzielanie stawek
Rozdzielanie stawek opisuje przetwarzanie pojedynczego złożonego elementu BidRequest na wiele pytań o stawkę, które są wysyłane do Twojej aplikacji. Ponieważ zachowują one identyczne identyfikatory (BidRequest.google_query_id w protokole RTB Authorized Buyers lub BidRequestExt.google_query_id w protokole OpenRTB), możesz ustalić, które pytania o stawkę są skorelowane po scaleniu.
Formaty reklam
Niektóre możliwości wyświetlania reklam mogą obejmować wiele formatów. W przypadku rozdzielania stawek każdy format jest wysyłany w osobnym pytaniu o stawkę, a takie atrybuty jak odpowiednie identyfikatory płatności mają związek z formatem określonym w pytaniu.
Pytania o stawkę zawierające te formaty zostaną scalone w odrębne pytania o stawkę:
Baner
Wideo
Audio
Natywna
Przykład spłaszczenia formatu reklamy
Poniżej znajduje się przykład przedstawiający uproszczone pytanie o stawkę w formacie JSON OpenRTB bez rozdzielania formatu reklamy w porównaniu z odpowiednim zestawem płaskich żądań:
Możliwość wyświetlania reklam w przypadku danego licytującego może się odnosić nie tylko do aukcji otwartej, ale też w różnych typach umów. W przypadku umów o rozdzielaniu stawek po jednym pytaniu o stawkę w przypadku aukcji otwartej zostanie wysłane 1 pytanie o stawkę dla każdego typu umowy o stałej cenie. W praktyce ograniczenia dotyczące reklam mogą się różnić w zależności od aukcji i umów o stałej cenie. Na przykład w przypadku możliwości związanych z reklamami wideo dostępnych zarówno dla aukcji otwartej, jak i umowy o stałej cenie system licytujący będzie otrzymywać osobne pytania o stawkę w przypadku każdego z nich, gdy takie ograniczenia jak maksymalny czas trwania reklamy i dopuszczanie reklam możliwych do pominięcia mogą się różnić. W efekcie zastosowanie tej opcji do możliwości reklamowej ułatwia rozróżnianie ograniczeń dotyczących reklam w aukcjach otwartych i umowach o stałej cenie.
Maksymalny czas trwania reklamy wideo możliwej do pominięcia
Protokół Google i implementacja OpenRTB obsługują te pola dotyczące czasu trwania filmu i możliwości pominięcia:
Czas działania
Czas trwania reklamy możliwej do pominięcia
Możliwość pominięcia
Protokół Google
max_ad_duration
skippable_max_ad_duration
video_ad_skippable
OpenRTB
maxduration
nie dotyczy
skip
Oznacza to, że chociaż protokół Google może mieć szczegółowy czas trwania reklam możliwych i niemożliwych do pominięcia, implementacja OpenRTB ma tylko jedną wartość maksymalnego czasu trwania.
Przed rozdzielaniem stawek wartość maxduration OpenRTB była ustawiona na niższą wartość z pól max_ad_duration i skippable_max_ad_duration protokołu Google. Zamiast tego wysyłanie 2 osobnych pytań o stawkę w przypadku różnic między tymi wartościami: jedno oznacza atrybut maxduration w przypadku reklam możliwych do pominięcia, a drugie niemożliwe do pominięcia.
W przykładach poniżej widać, jak żądanie protokołu Google przekłada się na OpenRTB przed rozdzielaniem stawek i po nim. Odpowiednik żądania protokołu Google ma wartość max_ad_duration równą 15, a skippable_max_ad_duration o wartości 60.
Przykład
max_ad_duration
skip (prawda LUB fałsz)
Pierwotne żądanie bez rozdzielania
15
true
Żądanie spłaszczone 1: niemożliwe do pominięcia
15
false
Żądanie spłaszczone nr 2: reklama możliwa do pominięcia
60
true
Rozdzielanie pytań o stawkę za czas trwania reklam wideo możliwych do pominięcia odbywa się tylko wtedy, gdy są spełnione te warunki:
Żądanie zezwala na wideo.
Dozwolone są zarówno filmy z możliwością pominięcia, jak i bez pominięcia, a 2 maksymalne czasy trwania różnią się wartością.
To żądanie kwalifikuje się do aukcji prywatnej lub aukcji otwartej.
Konto licytującego ma aktywne punkty końcowe OpenRTB.
Możesz zrezygnować z tego typu rozdzielania, kontaktując się z technicznym menedżerem konta.
Bloki reklamowe wideo
Pytania o stawkę w bloku reklamowym wideo z wieloma możliwościami reklamowymi są rozdzielane tak, że każde pytanie o stawkę dotyczy pojedynczej możliwości reklamy z tego bloku reklamowego.
Dzięki temu możesz ustalać stawki za wiele możliwości reklamowych w danym bloku reklamowym.
Open Measurement
Open Measurement pozwala określić dostawców zewnętrznych, którzy świadczą niezależne usługi pomiarowe i weryfikacyjne na potrzeby reklam wyświetlanych w środowiskach aplikacji mobilnych.
Aby dowiedzieć się, czy wydawca obsługuje Open Measurement w pytaniu o stawkę, sprawdź, czy możliwość wyświetlania reklamy wyklucza atrybut OmsdkType:
OMSDK 1.0, który znajduje się w atrybutach kreacji możliwych do wykluczenia przez wydawcę. W przypadku protokołu Authorized Buyers znajdziesz go w sekcji BidRequest.adslot[].excluded_attribute. W przypadku protokołu OpenRTB znajduje się on w atrybucie battrBaner lub Wideo, w zależności od formatu.
Więcej informacji o interpretowaniu pytań o stawkę zawierających sygnały Open Measurement znajdziesz w artykule Pakiet SDK Open Measurement w Centrum pomocy.
Przykładowe pytania o stawkę
W sekcjach poniżej znajdziesz przykładowe pytania o stawkę w przypadku różnych typów reklam.
