Zarchiwizowane informacje o wersjach

17 grudnia 2019
03
20 lip 2019 r., 2019 r., 2
10.09.2019., 9.01., 9.01., 9.02, 2019., 9.02
19.01., 9.01., 9.02., 9.02
19.00.{/19.01.{/19

21 lip. 2019 r.{/19
14.11.2019.











29 października 2018 r.
3
20 lip 2018 r. 40 lip 8 lip 2018 r. 40 lipca 2018 r. 18 lipca 2018 r. 18 lipca 2018 r. 18 lipca 2018 r. 18 lipca 2018 r. 18 lipca 2018 r. 18 lip 2018 2018 r. 28 lip 2018 r.
18 lip 2018 r.{/18























17 maja 2018 r. 80 marca 2018 r. 08 marca 2018 r. 04
20 marca 2018 r. 2007
2018 r. 2018 marca 2018 r. 80 marca 2018 r. 2018 maja 2018 r. 2018 maja 2018 r. 2018 maja 2018 r. 2018 maja 2018 r.

2018}2018 r.201815 r.






















17 grudnia 2019 r.

Nowości w protokole RTB w wersji 170

Dodano: BidRequest.AdSlot.MatchingAdData.DirectDeal.must_bid.
W przypadku umów automatyzacji gwarantowanej to nowe pole zostanie ustawione na „prawda”, gdy kupujący będzie zobowiązany do ustalania stawek. Licytujący mogą pominąć określanie stawek w ramach umowy automatyzacji gwarantowanej w przypadku tego wyświetlenia tylko wtedy, gdy ta wartość jest ustawiona na fałsz. Informacje o ustalaniu stawek w ramach umów automatyzacji gwarantowanej znajdziesz w tym artykule w Centrum pomocy.
Wycofano: BidRequest.AdSlot.MatchingAdData.DirectDeal.must_bid_level.
To pole zostało oznaczone jako wycofane, a w tej wersji dodano pole must_bid. Będziemy je wypełniać do końca I kwartału 2020 r., kiedy to pole zostanie całkowicie usunięte z protokołu.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 44
Dodano: DealExt.must_bid.
W przypadku umów automatyzacji gwarantowanej to nowe pole zostanie ustawione na „prawda”, gdy kupujący będzie zobowiązany do ustalania stawek. Licytujący mogą pominąć określanie stawek w ramach umowy automatyzacji gwarantowanej w przypadku tego wyświetlenia tylko wtedy, gdy ta wartość jest ustawiona na fałsz. Informacje o ustalaniu stawek w ramach umów automatyzacji gwarantowanej znajdziesz w tym artykule w Centrum pomocy.

5 grudnia 2019 r.

Nowości w protokole RTB w wersji 169

Dodano: BidRequest.AdSlot.OpenBidding.is_open_bidding.
To nowe pole zostanie ustawione na „prawda” w przypadku pytań o stawkę, jeśli wydawca skonfiguruje grupę zysku lub grupę zapośredniczenia, która jest kierowana na boks reklamowy w żądaniu i licytującym, który je otrzymuje. Informacje o Otwartym ustalaniu stawek i jego wpływie na proces ustalania stawek znajdziesz w tym artykule w Centrum pomocy.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 43
Dodano: ImpExt.OpenBidding.is_open_bidding.
To nowe pole zostanie ustawione na „prawda” w przypadku pytań o stawkę, jeśli wydawca skonfiguruje grupę zysku lub grupę zapośredniczenia, która jest kierowana na boks reklamowy w żądaniu i licytującym, który je otrzymuje. Informacje o Otwartym ustalaniu stawek i jego wpływie na proces ustalania stawek znajdziesz w tym artykule w Centrum pomocy.
Dodano: DealExt.publisher_blocks_overridden.
To pole wskazuje, czy wydawca wyłączył odpowiednią umowę ze skonfigurowanych blokad. To ustawienie nie zastępuje zasad AdX ani decyzji Centrum oceny reklam. Więcej informacji znajdziesz w tym artykule w Centrum pomocy.

21 listopada 2019 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.

14 listopada 2019 r.

Nowości w protokole RTB w wersji 168

Dodano: BidRequest.bid_response_feedback.sampled_mediation_cpm_ahead_of_auction_winner.
Jeśli łańcuch zapośredniczenia obejmuje też inne sieci, wartością w tym polu jest cena reprezentująca przykładową stawkę z jednej z odpowiednich sieci zapośredniczenia, która była wyższa niż zwycięzca aukcji, ważona według przewidywanego współczynnika wypełnienia. Jeśli żadna z sieci w łańcuchu zapośredniczenia nie jest wypełniona lub wydawca nie korzysta z zapośredniczenia SDK, wartość ta będzie ustawiona na 0. Więcej informacji znajdziesz w artykule Tworzenie modelu ustalania stawek na potrzeby aukcji pierwszej ceny.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 42
Dodano: BidRequestExt.bid_feedback.sampled_mediation_cpm_ahead_of_auction_winner.
Jeśli łańcuch zapośredniczenia obejmuje też inne sieci, wartością w tym polu jest cena reprezentująca przykładową stawkę z jednej z odpowiednich sieci zapośredniczenia, która była wyższa niż zwycięzca aukcji, ważona według przewidywanego współczynnika wypełnienia. Jeśli żadna z sieci w łańcuchu zapośredniczenia nie jest wypełniona lub wydawca nie korzysta z zapośredniczenia SDK, wartość ta będzie ustawiona na 0. Więcej informacji znajdziesz w artykule Tworzenie modelu ustalania stawek na potrzeby aukcji pierwszej ceny.

13 listopada 2019 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.

12 listopada 2019 r.

Co nowego w słownikach RTB

Plik słownika callout-status-codes.txt uległ zmianie.
Usunięto grupę 22 Dropped due to pretargeting sampling.

5 listopada 2019 r.

Co nowego w słownikach RTB

Plik słownika cookie-matcher-status-codes.txt uległ zmianie.
Dodano 13 COOKIE_MATCHER_UIS_RPC_ERROR.

17 października 2019 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 41
Dodano: BidExt.buyer_reporting_id.
Zadeklarowany przez kupującego identyfikator, który zostanie użyty do podziału danych o wydatkach i nieprawidłowym ruchu w raportach przejrzystości dotyczących nieprawidłowego ruchu w Narzędziu do wysyłania zapytań. Obecnie dzielimy też dane w raportach przejrzystości dotyczących nieprawidłowego ruchu na podstawie wartości zadeklarowanej w polu Seatbid.seat (tylko wtedy, gdy pole BidExt.buyer_reporting_id nie jest wypełnione), ale z końcem I kwartału 2020 r. przestaniemy to robić, aby licytujący mogli przejść do tego nowego pola.

1 października 2019 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 40
Dodano: DealExt.deal_type.
Teraz w rozszerzeniu Umowa OpenRTB przesyłamy typ umowy Google.

23 września 2019 r.

Nowości w protokole RTB w wersji 167

Do wszystkich pól CPM dodaliśmy komentarze wyjaśniające w sprawie waluty.

16 września 2019 r.

Nowości w protokole RTB w wersji 166

Wartość OMID w wyliczeniu BidResponse.Ad.ImpressionTrackingResource.Context nie jest obecnie obsługiwana.
Obecnie nie przetwarzamy skryptów OMID przesłanych za pomocą pola impression_tracking_resource.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 39
Wartość OMID w wyliczeniu EventTrackerExt.Context nie jest obecnie obsługiwana.
Obecnie nie przetwarzamy skryptów OMID przesłanych za pomocą natywnego pola eventtrackers.

13 września 2019 r.

Nowości w protokole RTB w wersji 165

Dodano: BidResponse.ad.adslot.third_party_buyer_token.
Ten token jest używany do identyfikowania informacji o kupującym zewnętrznym, jeśli pośrednikiem jest giełda, która jako licytujący otwarty. Są one uzyskiwane od zewnętrznego kupującego i muszą zostać przekazane do Google bez wprowadzania zmian w odpowiedzi na stawkę.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 38
Dodano: BidExt.third_party_buyer_token.
Ten token jest używany do identyfikowania informacji o kupującym zewnętrznym, jeśli pośrednikiem jest giełda, która jako licytujący otwarty. Są one uzyskiwane od zewnętrznego kupującego i muszą zostać przekazane do Google bez wprowadzania zmian w odpowiedzi na stawkę.

21 sierpnia 2019 r.

Dodano nową wartość wyliczenia RIDA, AFAI i MSAI do UserIdType.

29 lipca 2019 r.

Nowości w protokole RTB w wersji 164

Dodano: BidRequest.AdSlot.flexible_adslot_settings.
Ten komunikat podrzędny służy do określania ustawień związanych z możliwością zmiany rozmiaru boksu reklamowego. Jeśli np. licytujący może zwrócić zakres rozmiarów, podaj w tym miejscu wartość maksymalną i minimalną wysokość i szerokość. W przypadku OpenRTB automatyczna wysokość i szerokość są też określane za pomocą atrybutów wmax, hmax, wmin i hmin w wiadomości BidRequest.Imp.Banner.

10 lipca 2019 r.

Nowości w protokole RTB w wersji 163

Wycofano i usunięto: BidRequest.AdSlot.is_intersitial_slot.
To pole jest nieaktualne i nie jest już wypełniane. Aby określić, czy boks reklamowy jest pełnoekranowy, użyj BidRequest.Mobile.is_interstitial_request i wartości wyliczeniowej BidRequest.Video.Placement INTERSTITIAL.

9 lipca 2019 r.

Co nowego w raporcie o stanie fragmentu kodu (Proto) w wersji 29

Usunięto wycofaną wartość SSL_REQUEST z wyliczenia ContextType.

13 marca 2019 r.

Co nowego w Google RTB Proto w wersji 162 i protosach OpenRTB

Niedawno ogłosiliśmy nadchodzącą zmianę w naszym modelu cenowym. Z tą zmianą są powiązane te nowe pola:
Dodano tabelę BidRequest.bid_response_feedback.minimum_bid_to_win do tabeli realtime-bidding.proto, a BidRequestExt.bid_feedback.minimum_bid_to_win do openrtb-adx.proto.
To pole jest wypełniane tylko w przypadku aukcji pierwszej ceny i wskazuje minimalną stawkę potrzebną do przebicia cen minimalnych i przelicytowania wszystkich konkurentów. Jest to wykluczone w przypadku wszystkich licytujących, którzy biorą udział w aukcjach wygranych w ramach umowy. Nowy stan kreacji „LOST_TO_PMP_DEAL” wskazuje, czy przegrana z tego powodu jest przegrana.
Dodano typ BidResponse.ad.adslot.use_bid_translation_service do pliku realtime-bidding.proto i BidExt.use_bid_translation_service do pliku openrtb-adx.proto.
Opcjonalna wartość logiczna umożliwiająca określanie stawek z aukcji pierwszej ceny na potrzeby usługi tłumaczenia stawek. Jeśli ma wartość prawda, podana stawka drugiej ceny zostanie przekonwertowana na stawkę pierwszej ceny. W praktyce włączenie tej opcji nie spowoduje podniesienia stawki. Ta usługa jest tymczasowo oferowana jako pomoc w migracji. Zamierzamy usunąć ją w 2020 roku.
Zachęcamy licytujących do aktualizacji implementacji określania stawek w ramach przygotowań do tej zmiany.
Dodaliśmy obsługę tych makr w adm, impression_tracking_url i burl:
  • ${AUCTION_ID} – identyfikator pytania o stawkę; z atrybutu BidRequest.id.
  • ${AUCTION_BID_ID} – identyfikator stawki; z atrybutu BidResponse.bidid.
  • ${AUCTION_IMP_ID} – identyfikator wyświetlenia wygranego; z atrybutu BidRequest.imp[].id.
  • ${AUCTION_SEAT_ID} – identyfikator stanowiska licytującego, dla którego ustalono stawkę; pochodzący z atrybutu BidResponse.seatbid[].seat.
  • ${AUCTION_AD_ID} – identyfikator znaczników reklamy, który licytujący chce wyświetlać; z atrybutu BidResponse.seatbid[].bid[].adid.
  • ${AUCTION_PRICE} – cena rozliczenia z tą samą walutą i jednostkami co stawka.
Usunięto plik słownika gdn-vendors.txt.
Zamiast tego użyj elementu vendors.txt. Pobierz plik.

10 grudnia 2018 r.

Usunięto wartość wyliczenia od BUYER_PROVIDED_ID do UserIdType.

10 grudnia 2018 r.

Nowości w protokole RTB w wersji 161

Zaktualizowano komentarze do: BidRequest.Adslot.width i BidRequest.Adslot.height.
Zaktualizowaliśmy komentarze, aby uwzględnić, że pierwszy boks na szerokość/wysokość reklamy pełnoekranowej nie musi już być taki sam jak rozmiar ekranu, ponieważ niektóre reklamy pełnoekranowe mogą być nieco mniejsze od rozmiaru ekranu.
Wycofano NativeAdTemplate.Fields.STORE i NativeAdTemplate.store_max_safe_length.

16 listopada 2018 r.

Nowości w protokole RTB w wersji 160

Dodano: BidResponse.Ad.AdSlot.buyer_reporting_id.
Licytujący mogą użyć tego pola, aby określić wybrany przez siebie identyfikator, który będzie służyć do podziału danych o wydatkach i nieprawidłowym ruchu w raportach przejrzystości dotyczących nieprawidłowego ruchu. Identyfikatory dłuższe niż 64 bajty będą ignorowane.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Licytujący mogą teraz użyć parametru SeatBid.seat, aby określić wybrany identyfikator, który będzie służyć do podziału danych o wydatkach i nieprawidłowym ruchu w raportach przejrzystości dotyczących nieprawidłowego ruchu. Identyfikatory dłuższe niż 64 bajty będą ignorowane.

29 października 2018 r.

Nowości w protokole RTB w wersji 159

Dodano: BidRequest.auction_type.
To pole odpowiada polu BidRequest.at, które zostało już wysłane w OpenRTB.

22 października 2018 r.

Nowości w protokole RTB w wersji 158

Dodano: BidRequest.AdSlot.excluded_creatives.
Pole zawiera listę kreacji, których nie można wyświetlać w tym wyświetleniu. Jeśli chcesz włączyć tę funkcję, skontaktuj się ze swoim menedżerem konta.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 36
Dodano: ImpExt.excluded_creatives.
Pole zawiera listę kreacji, których nie można wyświetlać w tym wyświetleniu. Jeśli chcesz włączyć tę funkcję, skontaktuj się ze swoim menedżerem konta.

17 października 2018 r.

Nowości w protokole RTB w wersji 157

Dodano obsługę dekodera w BidRequest.Device.device_type.
BidRequest.Device.device_type może zawierać nowy typ dekodera.

19 października 2018 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 35
Dodano: BidExt.billing_id.
Wycofujemy funkcję Bid.cid do określania w odpowiedzi na stawkę identyfikatora płatności, do którego ma być przypisywane wyświetlenie. Przenosimy ją do nowego pola BidExt.billing_id. Do czasu przejścia licytujących będziemy nadal korzystać z Bid.cid na potrzeby zgodności wstecznej.

17 października 2018 r.

Nowości w protokole RTB w wersji 157

Dodano obsługę dekodera w BidRequest.Device.device_type.
BidRequest.Device.device_type może zawierać nowy typ dekodera.

8 października 2018 r.

Nowości w protokole RTB w wersji 155

W BidRequest.Mobile.advertising_id dodano obsługę identyfikatora urządzenia Samsung.
Identyfikator Samsunga można wysłać za pomocą BidRequest.Mobile.advertising_id.

1 października 2018 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 33
Dodano: BidExt.restricted_categories.
W tym polu należy używać tego pola do określania kategorii z ograniczeniami, które mogą być wyświetlane w przypadku reklam z danego fragmentu. Listę identyfikatorów kategorii z ograniczeniami znajdziesz w pliku ad-restricted-category.txt. W szczególności w przypadku reklam alkoholu wymagana jest deklaracja atrybutu 33, która pozwala uniknąć odrzucenia kreacji.
Protokół Google OpenRTB 2.5.0
Pole
App.storeurl jest teraz wypełniane w przypadku odpowiednich żądań.

Co nowego w sekcji Raportowanie

Wycofany raport skuteczności pliku CSV.
Wycofaliśmy możliwość pobierania danych z raportu skuteczności co godzinę w formacie CSV. Dane z raportu skuteczności są nadal dostępne za pomocą interfejsu Performance Report API.

20 września 2018 r.

Nowości w protokole RTB w wersji 153

Dodano: BidRequest.google_query_id.
Jest to unikalny identyfikator ogólnego zapytania. Jeśli do zapytania jest wiele objaśnień, wszystkie ich żądania będą zawierać tę samą właściwość google_query_id.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 32
Dodano: BidRequestExt.google_query_id.
Jest to unikalny identyfikator ogólnego zapytania. Jeśli do zapytania jest wiele objaśnień, wszystkie ich żądania będą zawierać tę samą właściwość google_query_id.

18 września 2018 r.

Co nowego w raporcie o stanie fragmentu kodu (Proto) w wersji 28

Dodano nowy powód odrzucenia.
100 Promowanie usług związanych z poręczeniem majątkowym.

27 sierpnia 2018 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 27

Dodano nowy powód odrzucenia.
99 Tymczasowe wstrzymanie kreacji.

23 sierpnia 2018 r.

Nowości w protokole RTB w wersji 153

Dodano: BidRequest.adslot.native_placement_type.
Ten komunikat opisuje umiejscowienie boksu reklamowego natywnego w kontekście otoczenia.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
NativeRequest.plcmttype zawiera teraz te same dane co pole BidRequest.adslot.native_placement_type w protokole AdX.

1 sierpnia 2018 r.

Nowości w protokole RTB w wersji 152

Dodano: BidRequest.Mobile.installed_sdk.
Ten komunikat informuje systemu o pakiecie SDK zainstalowanym w aplikacji, w której może licytować.

30 lipca 2018 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 26

Dodano nowe pole creative_status_identity_type przeznaczone do migracji do weryfikacji kreacji bez określonego rozmiaru.

23 lipca 2018 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.
Zaktualizowaliśmy wpisy „Integral Ad Science”, „Google”, „EMX Digital”, „KeyCDN”, „Better Banners”, „zeotap” i „Tramplin Media”.
Usunięto wpis „Clearstream.TV, Inc.”

19 lipca 2018 r.

Nowości w protokole RTB w wersji 150

Do kampanii BidResponse.Ad.AdSlot.exchange_deal_type dodano nowy typ umowy dotyczącej giełdy.
Nowy typ umowy EXCHANGE_AUCTION_PACKAGE dla licytujących na giełdzie zapewnia pakiet zasobów reklamowych, który nie jest traktowany jako specjalny w aukcji.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 31
Do kampanii BidExt.exchange_deal_type dodano nowy typ umowy dotyczącej giełdy.
Nowy typ umowy EXCHANGE_AUCTION_PACKAGE dla licytujących na giełdzie zapewnia pakiet zasobów reklamowych, który nie jest traktowany jako specjalny w aukcji.

17 lipca 2018 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Dodano 3 miasta w Argentynie.
Dodano 3 miasta w Kanadzie.
Dodano 2 miasta w Kolumbii.
Dodano 2 miasta w Grecji.
Dodano 26 miast we Włoszech.
Dodano 333 miasta w Japonii.
Dodano 78 miast w Szwajcarii.

16 lipca 2018 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.
Zaktualizowane informacje dla dotychczasowych dostawców: Adriver, MediaMath, The Reach Group, GetIntent, DYNADMIC, AdClear, Sharethrough Inc., media.ventive GmbH, Ingenious Technologies, StreamRail, Adways SAS, BDSK Handels GmbH & KG, Adserve, INFINIA, Dochase.
Dodano nowych dostawców: AT Internet, Media.net, Vidazoo, Madington, IgnitionAI, All In Movies LTD, Captify, Seedtag, Affiliate Future, Grabit Interactive, FXCM.com, Rambla, Tramplin Media.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

2 lipca 2018 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 4513 Rippll.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 4513 Rippll.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

27 czerwca 2018 r.

Nowości w protokole RTB w wersji 149

Oznaczono zasób BidRequest.adslot.matching_ad_data.direct_deal.remaining_impressions_to_buy jako wycofany.
Nie będziemy już udostępniać tych informacji, aby uprościć nasz interfejs API.

26 czerwca 2018 r.

Nowości w protokole RTB w wersji 148

Dodano: BidRequest.AdSlot.buyer_generated_request_data.
Ta opcja zostanie ustawiona w żądaniach aplikacji mobilnej dla kupujących, którzy mają zainstalowany w aplikacji swój pakiet SDK, co umożliwi przekazywanie dodatkowych informacji.
Dodano: BidResponse.Ad.AdSlot.sdk_rendered_ad.
To pole umożliwia licytującemu zwrócenie reklamy, która ma zostać wyrenderowana przez znany mu pakiet SDK. Tej opcji można użyć tylko wtedy, gdy BidRequest zawiera podwiadomość mobile.installed_sdk.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 30
Dodano: AppExt.InstalledSdk.
Ten komunikat informuje systemu o pakiecie SDK zainstalowanym w aplikacji, w której może licytować.
Dodano: ImpExt.BuyerGeneratedRequestData.
Ta opcja zostanie ustawiona w żądaniach aplikacji mobilnej dla kupujących, którzy mają zainstalowany w aplikacji swój pakiet SDK, co umożliwi przekazywanie dodatkowych informacji.
Dodano: BidExt.SdkRenderedAd.
To pole umożliwia licytującemu zwrócenie reklamy, która ma zostać wyrenderowana przez znany mu pakiet SDK. Tej opcji można użyć tylko wtedy, gdy żądanie BidRequest zawiera wiadomość podrzędną AppExt.InstalledSdk.
Dodano obsługę języka NativeRequest.eventtrackers.
Określa typ obsługiwanego śledzenia zdarzeń. Mapuje na wiadomość podrzędną w polu BidRequest.adslot[].excluded_attribute protokołu Authorized Buyers.
Dodano obsługę języka NativeResponse.eventtrackers.
Tablica modułów do śledzenia zdarzeń odpowiedzi, które mają być uruchamiane z reklamą w odpowiedzi na zadeklarowane obsługiwane metody w NativeRequest. Zastępuje imptrackery i jstrackers. Mapuje na protokół BidResponse.ad[].impression_tracking_resource protokołu Authorized Buyers.

26 czerwca 2018 r.

Co nowego w słownikach RTB

Plik słownika publisher-excludable-creative-attributes.txt uległ zmianie.
Dodano atrybut 114 OmsdkType: OMSDK 1.0, który służy do wskazywania, czy pakiet Open Measurement SDK jest obsługiwany.

13 czerwca 2018 r.

Nowości w protokole RTB w wersji 147

Dodano wartość wyliczenia AUCTION_PACKAGE do BidRequest.adslot.matching_ad_data.direct_deal.deal_type.
Do wskazywania, że w pliku direct_deal występuje pakiet aukcji direct_deal_id, używamy teraz wyliczenia AUCTION_PACKAGE (w przeciwieństwie do poprzednio używanych PRIVATE_AUCTION).

11 czerwca 2018 r.

Nowości w protokole RTB w wersji 146

Dodano BidRequest.AdSlot.ImpressionTrackingResource.verification_parameters i BidRequest.AdSlot.ImpressionTrackingResource.vendor_key.
Parametr verification_parameters może zawierać dodatkowe parametry, które należy przekazać do skryptu weryfikacji OMID w polu ImpressionTrackingResource.script_url. Pole vendor_key powinno zawierać unikalny identyfikator dostawcy skryptu OMID. Gdy ImpressionTrackingResource.context ma wartość OMID, zawartość tych nowych pól będzie przekazywana do pakietu Open Measurement SDK.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 29
Dodano EventTrackerExt.verification_parameters i EventTrackerExt.vendor_key. Pole verification_parameters może zawierać dodatkowe parametry, które należy przekazać do skryptu weryfikacji OMID ustawionego w parametrze EventTracker.url. Pole vendor_key powinno zawierać unikalny identyfikator dostawcy skryptu OMID. Gdy EventTrackerExt.context ma wartość OMID, zawartość tych nowych pól będzie przekazywana do pakietu Open Measurement SDK.
Protokół Google OpenRTB 2.5.0
Pole User.buyeruid zawiera teraz te same treści co User.customdata. Za jakiś czas całkowicie wycofamy funkcję User.customdata.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 263 AddThis, Inc.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

7 czerwca 2018 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Usunięto grupę 10 Tumri.
Usunięto 56 Adobe Media Optimizer.
Usunięto 132 Adobe Media Optimizer.
Usunięto 225 ZANOX AG.
Usunięto 233 Xaxis, Inc.
Usunięto 260 Alenty S.A.S.
Usunięto 432 Hi-Media.
Usunięto 497 Exactag.
Usunięto 815 Resonate Networks, Inc.
Usunięto 874 Cint AB.
Usunięto 886 Research and Analysis of Media in Sweden AB.
Usunięto 888 ViewersLogic LTD.
Usunięto 4362 Adnami ApS.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Usunięto grupę 10 Tumri.
Usunięto 56 Adobe Media Optimizer.
Usunięto 132 Adobe Media Optimizer.
Usunięto 225 ZANOX AG.
Usunięto 233 Xaxis, Inc.
Usunięto 260 Alenty S.A.S.
Usunięto 432 Hi-Media.
Usunięto 497 Exactag.
Usunięto 616 Tealium, Inc.
Usunięto 814 Media Detect GmbH.
Usunięto 815 Resonate Networks, Inc.
Usunięto 864 INCUBIQ Solutions Ltd.
Usunięto 874 Cint AB.
Usunięto 886 Research and Analysis of Media in Sweden AB.
Usunięto 888 ViewersLogic LTD.
Usunięto 4362 Adnami ApS.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

4 czerwca 2018 r.

Co nowego w słownikach RTB

Plik słownika publisher-verticals.txt uległ zmianie.
Zmieniono wiersz 5227 /World Localities/Latin America/South America/Brazil/Southeast Brazil/São Paulo (State).
Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 193 Filtered due to missing SDK identifier.
Dodano 194 Filtered due to missing SDK rendering data.

31 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 4483 ComScore vCE (YouTube).
Dodano 4484 Campaign Monitor (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 4483 ComScore vCE (YouTube).
Dodano 4484 Campaign Monitor (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

21 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.
Zaktualizowaliśmy o aktualne informacje o domenie dla wszystkich dostawców.

May 18, 2018

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Usunięto grupę 284 Research Now Limited.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Usunięto grupę 284 Research Now Limited.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

17 maja 2018 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 25

Dodano nowe przyczyny odrzucenia.
97 Nieobsługiwany język.
98 Brak zgodności z protokołem SSL.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 4374 TailTarget.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Dodano 4374 TailTarget.
Dodano 4458 Yieldlab.
Dodano 4461 Sharethrough.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

16 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Usunięto grupę 4452 Research Now (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Usunięto grupę 4452 Research Now (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

15 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 4452 Research Now (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 4452 Research Now (YouTube).
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

11 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Usunięto grupę 43 BrightRoll Inc..
Usunięto 94 Nielsen OBE (Vizu).
Usunięto 145 DoubleVerify Inc..
Usunięto 204 Pulpo Media Inc.
Usunięto 303 Dynamic Logic / Safecount (AdIndex).
Usunięto 316 Flashtalking.
Usunięto 334 Adloox Research Verification.
Usunięto 395 Adnologies GmbH.
Usunięto 441 Hubrus LLC.
Usunięto 472 Neustar AdAdvisor.
Usunięto 476 ComScore Validated Campaign Essentials:Ad Swapping.
Usunięto 539 Adform DSP.
Usunięto 551 Nielsen Digital Ad Ratings.
Usunięto 553 Kpsule.
Usunięto 554 Content Directions, Inc. dba Linkstorm.
Usunięto 569 Contobox.
Usunięto 606 Gruvi Ltd..
Usunięto 608 Rockabox Media Ltd.
Usunięto 615 Nielsen Digital Ad Ratings (JS).
Usunięto 618 Demand Side Science, Inc..
Usunięto 633 Knorex Pte. Ltd..
Usunięto 713 MezzoMedia.
Usunięto 724 Extreme Reach, Inc..
Usunięto 791 VideoHub DSP.
Usunięto 813 Protected Media LTD.
Usunięto 820 Beijing PinYou Interactive Information Technology.
Usunięto 834 Jivox Corporation.
Usunięto 838 RevJet LLC..
Usunięto 863 Bonzai Digital Pvt. Ltd.
Usunięto 876 Exponential Interactive, Inc.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Usunięto grupę 43 BrightRoll Inc..
Usunięto 94 Nielsen OBE (Vizu).
Usunięto 145 DoubleVerify Inc..
Usunięto 204 Pulpo Media Inc.
Usunięto 303 Dynamic Logic / Safecount (AdIndex).
Usunięto 334 Adloox Research Verification.
Usunięto 395 Adnologies GmbH.
Usunięto 441 Hubrus LLC.
Usunięto 551 Nielsen Digital Ad Ratings.
Usunięto 553 Kpsule.
Usunięto 554 Content Directions, Inc. dba Linkstorm.
Usunięto 569 Contobox.
Usunięto 606 Gruvi Ltd..
Usunięto 618 Demand Side Science, Inc..
Usunięto 713 MezzoMedia.
Usunięto 724 Extreme Reach, Inc..
Usunięto 813 Protected Media LTD.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

9 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika providers.csv uległ zmianie.
Usunięto wiersz 184,"eBay","https://www.ebay.com/help/policies/member-behaviour-policies/user-privacy-notice-privacy-policy?id=4260#section12","rover.ebay.com ebay.cachetastic.com *.ebaystatic.com dap.ebay.gslb.com *.ebay.de *.ebay.co.uk *.ebay.fr *.ebay.it *.ebay.es *.ebayrtm.com *.ebay.at *.ebay.ch *.ebay.be *.ebay.dk *.ebay.gr *.ebay.ie *.ebay.nl *.ebay.no *.ebay.pl *.ebay.cz *.ebay.ru *.ebayimg.com anywhere.ebay.com i.ebayimg.com *.edpn.ebay.com mstconsole.ebay.com rpsx.ebay.com *.ebay.com ads.ebay.com sc.dealtime.com mktg.kijiji.ca *.fetchback.com".

7 maja 2018 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 24

Dodano nowe przyczyny odrzucenia.
96 Niedopuszczalna jakość miejsca docelowego.

3 maja 2018 r.

Co nowego w słownikach RTB

Plik providers.csv został dodany.
Ten plik zawiera informacje o dostawcach przekazywanych w pytaniu o stawkę. Pełny opis znajdziesz w słownikach RTB.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 303 Insight Express (Mobile).
Usunięto 303 Dynamic Logic / Safecount (AdIndex).
Usunięto 523 Spongecell - Expandable.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Dodano 303 Insight Express (Mobile).
Usunięto 303 Dynamic Logic / Safecount (AdIndex).
Usunięto 486 Adloox: Ad Swapping.
Usunięto 523 Spongecell - Expandable.
Usunięto 537 Public Eye.
Usunięto 623 Human Demand.
Usunięto 798 Nielsen Catalina Solutions.
Usunięto 806 Sociomantic Expandable.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

1 maja 2018 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Zmieniono 43 BrightRoll na: 43 BrightRoll Inc..
Zmieniono 56 Efficient Frontier na 56 Adobe Media Optimizer.
Zmieniono 79 Revenue Science na 79 revenue cloud.
Zmieniono 94 Nielsen OBE (Vizu) - Survey na 94 Nielsen OBE (Vizu).
Zmieniono 132 Adlens na 132 Adobe Media Optimizer.
Zmieniono 144 Campaign Monitor (Integral Ad Science) na 144 Campaign Monitor.
Zmieniono 145 DoubleVerify na 145 DoubleVerify Inc..
Zmieniono 204 Pulpo Media na 204 Pulpo Media Inc.
Zmieniono 225 Zanox na 225 ZANOX AG.
Zmieniono 233 Media Innovation Group (Xaxis) na 233 Xaxis, Inc.
Zmieniono 238 Aggregate Knowledge na 238 Media Intelligence Platform (Aggregate Knowledge).
Zmieniono 260 Alenty na 260 Alenty S.A.S.
Zmieniono 284 Research Now na 284 Research Now Limited.
Zmieniono 303 Millward Brown Digital - Survey na 303 Dynamic Logic / Safecount (AdIndex).
Zmieniono 334 Adloox na 334 Adloox Research Verification.
Zmieniono 395 Adnologies na 395 Adnologies GmbH.
Zmieniono 414 Batch Media na 414 Batch Media Gmbh.
Zmieniono 441 Hubrus na 441 Hubrus LLC.
Zmieniono 474 Integral Ad Science Firewall - Ad Swapping na 474 Integral Ad Science Firewall.
Zmieniono 485 comScore - VoiceFive na 485 VoiceFive (ComScore).
Zmieniono 489 Revenue Cloud na 489 revenue cloud.
Zmieniono 550 AdYapper na 550 AdYapper, Inc..
Zmieniono 551 Nielsen Digital Ad Ratings (formerly OCR) na 551 Nielsen Digital Ad Ratings.
Zmieniono 553 Kpsule - Expandable na 553 Kpsule.
Zmieniono 554 Linkstorm - Expandable na 554 Content Directions, Inc. dba Linkstorm.
Zmieniono 566 Spark Flow Expandable na 566 Spark Flow S.A..
Zmieniono 569 Contobox Expandable na 569 Contobox.
Zmieniono 606 Gruvi TV na 606 Gruvi Ltd..
Zmieniono 618 Demand Side Science na 618 Demand Side Science, Inc..
Zmieniono 698 GET IT Mobile na 698 GET IT Mobile, Inc.
Zmieniono 724 Extreme Reach ad server na 724 Extreme Reach, Inc..
Zmieniono 743 White Ops na 743 White Ops, Inc..
Zmieniono 767 SFR na 767 SOCIETE FRANCAISE DU RADIOTELEPHONE.
Zmieniono 776 Spark Flow na 776 Spark Flow S.A..
Zmieniono 780 Where 2 Get It na 780 Where 2 Get It, Inc..
Zmieniono 785 Scrutineer Survey na 785 Scrutineer.
Zmieniono 797 ADmantX na 797 ADmantX, SPA.
Zmieniono 813 Protected Media na 813 Protected Media LTD.
Zmieniono 815 Resonate Networks na 815 Resonate Networks, Inc.
Zmieniono 828 Crutchfield New Media na 828 Crutchfield New Media, LLC.
Zmieniono 874 Cint na 874 Cint AB.
Zmieniono 886 Research and Analysis of Media na 886 Research and Analysis of Media in Sweden AB.
Zmieniono 888 ViewersLogic na 888 ViewersLogic LTD.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Zmieniono 43 BrightRoll na: 43 BrightRoll Inc..
Zmieniono 56 Efficient Frontier na 56 Adobe Media Optimizer.
Zmieniono 79 Revenue Science na 79 revenue cloud.
Zmieniono 94 Nielsen OBE (Vizu) - Survey na 94 Nielsen OBE (Vizu).
Zmieniono 132 Adlens na 132 Adobe Media Optimizer.
Zmieniono 144 Campaign Monitor (Integral Ad Science) na 144 Campaign Monitor.
Zmieniono 145 DoubleVerify na 145 DoubleVerify Inc..
Zmieniono 204 Pulpo Media na 204 Pulpo Media Inc.
Zmieniono 225 Zanox na 225 ZANOX AG.
Zmieniono 233 Media Innovation Group (Xaxis) na 233 Xaxis, Inc.
Zmieniono 238 Aggregate Knowledge na 238 Media Intelligence Platform (Aggregate Knowledge).
Zmieniono 242 Lotame na 242 Lotame Solutions Inc..
Zmieniono 260 Alenty na 260 Alenty S.A.S.
Zmieniono 267 DataLogix na 267 DataLogix, Inc..
Zmieniono 284 Research Now na 284 Research Now Limited.
Zmieniono 303 Millward Brown Digital - Survey na 303 Dynamic Logic / Safecount (AdIndex).
Zmieniono 316 Flashtalking Expandable na 316 Flashtalking.
Zmieniono 332 Audience Manager(DemDex) na 332 Audience Manager.
Zmieniono 334 Adloox na 334 Adloox Research Verification.
Zmieniono 395 Adnologies na 395 Adnologies GmbH.
Zmieniono 414 Batch Media na 414 Batch Media Gmbh.
Zmieniono 441 Hubrus na 441 Hubrus LLC.
Zmieniono 474 Integral Ad Science Firewall - Ad Swapping na 474 Integral Ad Science Firewall.
Zmieniono 475 zzzz [ARCHIVED] comScore AdXpose - Ad Blocking na 475 ComScore (AdXpose): Ad Swapping.
Zmieniono 476 comScore vCE - Ad Swapping na 476 ComScore Validated Campaign Essentials:Ad Swapping.
Zmieniono 477 DoubleVerify BrandShield - Ad Swapping na 477 ComScore (AdXpose): Ad Swapping.
Zmieniono 481 eXelate na 481 eXelate Inc..
Zmieniono 485 comScore - VoiceFive na 485 VoiceFive (ComScore).
Zmieniono 486 AdLoox - Ad Swapping na 486 Adloox: Ad Swapping.
Zmieniono 489 Revenue Cloud na 489 revenue cloud.
Zmieniono 490 AdLedge - Ad Blocking na 490 Adledge: Ad Swapping.
Zmieniono 501 Rutarget na 501 Rutarget / Segmento.
Zmieniono 529 Eyeota na 529 Eyeota Limited.
Zmieniono 539 Adform - Expandable na 539 Adform DSP.
Zmieniono 542 Bizo na 542 Bizo Inc.
Zmieniono 543 VisualDNA na 543 VisualDNA (Imagini).
Zmieniono 550 AdYapper na 550 AdYapper, Inc..
Zmieniono 551 Nielsen Digital Ad Ratings (formerly OCR) na 551 Nielsen Digital Ad Ratings.
Zmieniono 553 Kpsule - Expandable na 553 Kpsule.
Zmieniono 554 Linkstorm - Expandable na 554 Content Directions, Inc. dba Linkstorm.
Zmieniono 564 Noddington Technologies Limited (Aidata) na 564 NODDINGTON TECHNOLOGIES LIMITED.
Zmieniono 566 Spark Flow Expandable na 566 Spark Flow S.A..
Zmieniono 569 Contobox Expandable na 569 Contobox.
Zmieniono 572 Webtrekk na 572 Webtrekk GmbH.
Zmieniono 573 Fabric Worldwide na 573 Fabric Worldwide Inc.
Zmieniono 574 Liveramp na 574 LiveRamp, Inc..
Zmieniono 575 Krux na 575 Krux Digital, Inc..
Zmieniono 577 Ru Target LLC na 577 Rutarget / Segmento.
Zmieniono 606 Gruvi TV na 606 Gruvi Ltd..
Zmieniono 608 Rockabox Media - Expandable na 608 Rockabox Media Ltd.
Zmieniono 615 Nielsen Digital Ad Ratings (formerly OCR) JS na 615 Nielsen Digital Ad Ratings (JS).
Zmieniono 616 Tealium na 616 Tealium, Inc.
Zmieniono 618 Demand Side Science na 618 Demand Side Science, Inc..
Zmieniono 633 Knorex - Expandable na 633 Knorex Pte. Ltd..
Zmieniono 698 GET IT Mobile na 698 GET IT Mobile, Inc.
Zmieniono 724 Extreme Reach ad server na 724 Extreme Reach, Inc..
Zmieniono 743 White Ops na 743 White Ops, Inc..
Zmieniono 767 SFR na 767 SOCIETE FRANCAISE DU RADIOTELEPHONE.
Zmieniono 776 Spark Flow na 776 Spark Flow S.A..
Zmieniono 780 Where 2 Get It na 780 Where 2 Get It, Inc..
Zmieniono 785 Scrutineer Survey na 785 Scrutineer.
Zmieniono 793 Semasio na 793 Semasio GmbH.
Zmieniono 797 ADmantX na 797 ADmantX, SPA.
Zmieniono 808 Hatena na 808 Hatena Co., Ltd.
Zmieniono 813 Protected Media na 813 Protected Media LTD.
Zmieniono 814 Media Detect na 814 Media Detect GmbH.
Zmieniono 815 Resonate Networks na 815 Resonate Networks, Inc.
Zmieniono 818 Redbranch na 818 Redbranch, Inc. (dba Fraudlogix).
Zmieniono 820 iPinyou - Expandable na 820 Beijing PinYou Interactive Information Technology.
Zmieniono 826 AmberData na 826 AmberData LLC.
Zmieniono 828 Crutchfield New Media na 828 Crutchfield New Media, LLC.
Zmieniono 834 Jivox - Expandable na 834 Jivox Corporation.
Zmieniono 838 Revjet Expandable na 838 RevJet LLC..
Zmieniono 863 Bonzai Expandable na 863 Bonzai Digital Pvt. Ltd.
Zmieniono 864 INCUBIQ Solutions na 864 INCUBIQ Solutions Ltd.
Zmieniono 874 Cint na 874 Cint AB.
Zmieniono 876 Exponential Expandable na 876 Exponential Interactive, Inc.
Zmieniono 884 Nugg.ad na 884 nugg.ad AG.
Zmieniono 885 Cloud Technologies na 885 OnAudience.com.
Zmieniono 886 Research and Analysis of Media na 886 Research and Analysis of Media in Sweden AB.
Zmieniono 888 ViewersLogic na 888 ViewersLogic LTD.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

30 kwietnia 2018 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 79 Revenue Science.
Dodano 138 Reddion.
Dodano 475 zzzz [ARCHIVED] comScore AdXpose - Ad Blocking.
Dodano 501 Rutarget.
Dodano 566 Spark Flow Expandable.
Usunięto 130 Broadband Enterprises.
Usunięto 182 comScore - vCE.
Usunięto 226 DoubleClick Rich Media Expandable.
Usunięto 228 Sizmek Expandable.
Usunięto 229 PointRoll Expandable.
Usunięto 428 Conversant (Mediaplex) Expandable.
Usunięto 520 Flite - Expandable.
Usunięto 538 Weborama Expandable.
Usunięto 549 Predicta - Expandable.
Usunięto 568 Admotion - Expandable.
Usunięto 617 Mixpo - Expandable.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 79 Revenue Science.
Dodano 138 Reddion.
Dodano 566 Spark Flow Expandable.
Usunięto 130 Broadband Enterprises.
Usunięto 182 comScore - vCE.
Usunięto 226 DoubleClick Rich Media Expandable.
Usunięto 617 Mixpo - Expandable.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

26 kwietnia 2018 r.

Nowości w protokole RTB w wersji 145

Dodano miejsce: BidRequest.AdSlot.session_depth
To pole zawiera łączną liczbę wyświetleń zrealizowanych u tego użytkownika (w tej konkretnej witrynie lub aplikacji) w tej sesji przeglądania plus 1. Sesja kończy się po 30 minutach braku aktywności. Domyślna wartość –1 oznacza, że nie można oszacować głębokości sesji.

25 kwietnia 2018 r.

Nowości w raporcie o stanie fragmentu kodu (proto) w wersji 23

Dodano nowe przyczyny odrzucenia.
94 Niewłaściwe użycie skryptu OMID
95 Dostawca OMID nieumieszczony na białej liście

18 kwietnia 2018 r.

Nowości w protokole RTB w wersji 144

BidRequest.AdSlot.ConsentedProvidersSettings.consented_providers to teraz packed.
Dzięki temu pole na przewodzie będzie bardziej gęste. Pamiętaj, aby zaktualizować go do tej wersji, ponieważ dodawanie atrybutów packed nie jest zgodne wstecznie.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 28
UserExt.ConsentedProvidersSettings.consented_providers to teraz packed. Dzięki temu pole na przewodzie będzie bardziej gęste. Pamiętaj, aby zaktualizować go do tej wersji, ponieważ dodawanie atrybutów packed nie jest zgodne wstecznie.

17 kwietnia 2018 r.

Co nowego w słownikach RTB

Plik słownika mobile-os.csv uległ zmianie.
Dodano wiersz 630359,"iOS",11,4,-1.
Plik słownika hosted-match-status-codes.txt uległ zmianie.
Dodano 10 HOSTED_MATCH_INTERNAL_ERROR.

16 kwietnia 2018 r.

Nowości w protokołu RTB w wersji 143

Dodaję BidRequest.AdSlot.consented_providers_settings i BidRequest.AdSlot.regs_gdpr
Dodanie nowych pól w celu wskazywania zgody użytkownika na korzystanie z personalizacji reklam, która jest przekazywana przez wydawców w przypadku użytkowników z krajów Europejskiego Obszaru Gospodarczego. Dostawcy.csv zostaną opublikowane w późniejszym czasie.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 27
Dodanie właściwości UserExt.consented_providers_settings i RegsExt.gdpr w celu wskazania zgody użytkownika na korzystanie z dostawców personalizacji reklam (przekazywanej przez wydawców w przypadku użytkowników z krajów Europejskiego Obszaru Gospodarczego).csv zostanie opublikowany później.

9 kwietnia 2018 r.

Nowości w protokole RTB w wersji 142

Dodano miejsce: BidResponse.Ad.impression_tracking_resource
W tym polu możesz określić zasoby JavaScript, które będą wywoływane podczas renderowania. Obecnie jedynym przypadkiem użycia jest określenie zasobów, które mają być wywoływane przez pakiet Open Measurement SDK.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 26
Dodano atrybut EventTrackerExt.context, który służy do określania, że zasób JavaScript uwzględniony w komunikacie EventTracker ma być wywoływany przez pakiet Open Measurement SDK.

28 marca 2018 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Wprowadziliśmy nową wersję kierowania geograficznego.
Dodano ponad 5000 lokalizacji.

9 marca 2018 r.

Nowości w protokole RTB w wersji 141

W sekcji BidRequest.adslot.matching_ad_data.direct_deal dodano nowe pole: must_bid_level
Więcej informacji znajdziesz w artykule Dodatkowe pola określania stawek w czasie rzeczywistym w przypadku automatyzacji gwarantowanej.

8 marca 2018 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Zmieniono 15 Creative filtered because one or more detected product categories were excluded in the bid request.

7 marca 2018 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 25
DodanoBidExt.amp_ad_url
To pole umożliwia licytującemu wysłanie adresu URL reklamy AMP HTML.

Nowości w protokole RTB w wersji 140

Dodano miejsce: BidResponse.Ad.amp_ad_url
To pole umożliwia licytującemu przesłanie adresu URL reklamy AMP HTML.

1 marca 2018 r.

Nowości w protokole RTB w wersji 139

Do tabeli VideoPlaybackMethod dodano nowe wartości wyliczeniowe INITIATE_ON_ENTERING_VIEWPORT_SOUND_ON i INITIATE_ON_ENTERING_VIEWPORT_SOUND_OFF.

27 lutego 2018 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Dodano nową wartość wyliczenia OMID_1 do zakresu APIFramework. Ta wartość wskazuje, że dla żądania włączony jest pakiet Open Measurement SDK. Chociaż tej wartości nie ma jeszcze w specyfikacji IAB OpenRTB, jest ona zapisana w obecnej spec IAB AdCom.

22 lutego 2018 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 192 Rejected due to Coppa/KFA being filtered for demand syndication.

14 lutego 2018 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 191 Creative filtered because it contains an invalid OMSDK script URL.

13 lutego 2018 r.

Nowości w protokole RTB w wersji 138

Oznaczono funkcję BidRequest.adslot.matching_ad_data.pricing_rule jako wycofaną.
Nie będziemy już udostępniać tych informacji, aby uprościć nasz interfejs API.

6 lutego 2018 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 24
Dodano BidRequestExt.bid_feedback. To rozszerzenie obsługuje teraz przesyłanie opinii w czasie rzeczywistym w OpenRTB.
Dodano BidExt.event_notification_token. To pole można ustawić na dowolny token wybrany przez licytującego i będzie ono widoczne w czasie rzeczywistym informacji zwrotnych o stawce, na którą zostało wysłane.

5 lutego 2018 r.

Nowości w protokole RTB w wersji 137

Dodano: BidRequest.BidResponseFeedback.buyer_creative_id.
Informacje zwrotne dotyczące RTB w czasie rzeczywistym zawierają teraz identyfikator kreacji kupującego z odpowiedniej odpowiedzi na stawkę.

Zarchiwizowane informacje o wersji z 2017 r. i wcześniejszych

18-15-15-19-19-17 <br-> <br-> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> 2017 2017 2017 2017 2013 <br-> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br->2013 - 2017 2017 2017 2017 2013 - <br">















































17 grudnia 2017 r. 6.02
10.00 20.00 20.00
w. 6.02
1.00 20.00. 20.
ep 6 r. 2017 r. 6.02
10 r. 6.02
10 r. 6.02
10 r. 6.02
10 r. 2000 b.
19.10 b.
b. 6.00. 7. r.

20 r. 6
2019 r.6 grudnia 6 grudnia 2017 r.
19 lip 6 grudnia 2017 r.{/10 6 grudnia 2017 r. 5
20 b.
16 r. 7.01. {/17 2017 r.
































18-15-15-19-10-1/8-18/13/18/18-18/2018-18-go-8-8-8-8/8-17 / <br-> <br-> <br/> <br/> <br-> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/> <br/>2















































19 grudnia 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Zmieniono kodowanie interfejsów API BidRequest.id i BidRequest.[constrained_usage_]hosted_match_data z base64 na bezpieczne w internecie w standardzie base64. Nadal nie będzie dopełnienia.

1 listopada 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Poprawiono pola NativeRequest.EventTrackers.methods i NativeResponse.EventTracker.method; moc zbioru została pomieszana, pole żądania powtarza się, a nie pole odpowiedzi.
Poprawiliśmy uwzględnianie liczby mnogiej niektórych nowych wiadomości i nazw wyliczeniowych, aby lepiej dostosować je do standardu OpenRTB i uniknąć nieporozumień.

26 października 2017 r.

Nowości w protokole RTB w wersji 136

Dodano: BidResponse.Ad.NativeAd.click_tracking_urls.
AdX obsługuje teraz wiele natywnych linków monitorujących kliknięcia.
Pole click_tracking_url planujemy wycofać.

25 października 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Protokół reklam natywnych został zaktualizowany do wersji 1.2 specyfikacji.
Usunięto komentarze związane z mapowaniem w formie „[AdX: ...]”. Więcej informacji o mapowaniu i zachowaniu kupujących w Authorized Buyers znajdziesz teraz w przewodniku po OpenRTB.
Protokół rozszerzeń Google OpenRTB w wersji 22
Dodano rozszerzenia ImpExt.ampad i SiteExt.amp, by obsługiwać przyspieszone strony mobilne.

18 października 2017 r.

Co nowego w słownikach RTB

Plik słownika mobile-os.csv uległ zmianie.
Dodano wiersz 630343,"iOS",11,1,-1.
Dodano wiersz 630345,"Android",8,1,-1.
Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 184 Creative filtered because the field amp_ad_url is too short, must be at least 11 characters.
Dodano 185 Creative filtered because the field amp_ad_url could not be parsed.
Dodano 186 Creative filtered because the field amp_ad_url has a domain consisting of all digits.
Plik słownika callout-status-codes.txt uległ zmianie.
Dodano 22 Dropped due to pretargeting sampling.

16 października 2017 r.

Nowości w protokole RTB w wersji 135

Dodano: BidResponse.Ad.event_notification_token.
Dodano: BidRequest.BidResponseFeedback.event_notification_token.
Licytujący w odpowiedziach na stawki wysyłają do AdX parametr event_notification_token, aby rozwiązać problemy. AdX będzie uwzględniać zdarzenie_notification_token w czasie rzeczywistym na potrzeby stawki. Zawartość tokena nie będzie rejestrowana przez AdX. AdX zignoruje tokeny dłuższe niż 64 bajty.
Zaktualizowano komentarze do: BidRequest.Adslot.allowed_vendor_type.
Dodano 2 sygnały z pytań o stawkę: AmpPage i AmpAdRequirementType.
AmpPage wskazuje, czy żądanie pochodzi ze strony utworzonej w języku HTML AMP (Accelerated Mobile Pages). Parametr AmpAd requirementsmentType zawiera więcej informacji o tym, czy reklamy wbudowane w AMP są dozwolone lub wymagane, a także o sposobie renderowania reklam AMP. Aby zwiększyć przejrzystość, sygnały te zastępują AmpAdRequestType wyliczeniowego.
Dodano nową wartość wyliczenia BUYER_PROVIDED_ID do UserIdType.
BUYER_PROVIDED_ID to plik cookie w domenie kupującego. Gdy kupujący prześle identyfikatory w domenie kupującego, użyjemy naszej tabeli mapowania, aby zmapować identyfikator na domenę Google.

6 października 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Dodaliśmy i usunęliśmy linie dla lokalizacji w Kanadzie, Wielkiej Brytanii, Włoszech, Norwegii, Republice Południowej Afryki, Kolumbii, Nigerii, Ukrainie i Stanach Zjednoczonych. Więcej informacji znajdziesz na liście różnic.

22 września 2017 r.

Co nowego w słownikach RTB

Plik słownika ad-sensitive-categories.txt uległ zmianie.
Usunięto grupę 28 Free Gifts, Quizzes, & Surveys.
Usunięto 29 Misleading Claims.
Plik słownika hosted-match-status-codes.txt uległ zmianie.
Dodano 1 DEPRECATED_HOSTED_MATCH_FORBIDDEN.
Usunięto 1 HOSTED_MATCH_FORBIDDEN.

19 września 2017 r.

Nowości w protokole RTB w wersji 134

Dodano miejsce: BidRequest.response_deadline_ms
To pole określa, jak długo Google będzie czekać na odpowiedź na to pytanie o stawkę. Licytujący, którzy stosują logikę zależną od terminu, powinni odczytywać to pole po każdym pytaniu o stawkę, zamiast np. wpisywać na stałe terminy 100 ms. Jeśli to pole jest nieskonfigurowane, systemy licytujące powinny przyjąć domyślny termin (tak jak obecnie). Jednostka jest wyrażona w milisekundach.

18 września 2017 r.

Nowości w protokołach RTB

Protokół RTB w wersji 133 i protokołu przesyłania zbiorczego plików cookie w wersji 6.
Zaktualizowaliśmy komentarze do wyliczenia BidRequest.Video.Placement.IN_FEED.
Wprowadzono wyliczenie BidRequest.Video.Placement.IN_ARTICLE dla kreacji wideo, które jako samodzielne odtwarzacze wczytują i odtwarzają między akapitami treści redakcyjnych.
Dodano wyliczenie ErrorCode.BAD_DATA_SOURCE_ID do protokołu przesyłania zbiorczego plików cookie, aby wskazać, że identyfikator źródła danych (data_source_id) był poza dozwolonym zakresem [1, 1000]. Google nie interpretuje tego identyfikatora i jest używany wyłącznie na potrzeby raportowania.

15 września 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Teraz wypełniamy pole displaymanager obiektu Imp wartością BidRequest.AdSlot.renderer. Więcej informacji znajdziesz w opisie obiektu Imp w przewodniku po OpenRTB.
Do określenia pola Banner.pos używamy teraz nie tylko BidRequest.AdSlot.slot_visibility, ale też BidRequest.StickySettings. Szczegółowe informacje znajdziesz w opisie obiektu Banner w przewodniku po OpenRTB.

14 września 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Dodano nowe lokalizacje i kody pocztowe w Holandii, Indiach, Japonii, Kanadzie, Korei, Libanie, Panamie, Stanach Zjednoczonych i we Włoszech. Więcej informacji znajdziesz na liście różnic.

11 września 2017 r.

Nowości w protokole RTB w wersji 132

Zaktualizowaliśmy komentarze do BidRequest.Mobile.is_app i BidRequest.Mobile.app_id, aby odzwierciedlały zachowanie żądań ze stron mobilnych zawartych w aplikacjach mobilnych.

24 sierpnia 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Dodano lokalizacje w Hiszpanii, Holandii, Indiach, Japonii, Kanadzie, Libanie, Niemczech, Stanach Zjednoczonych i Wielkiej Brytanii. Więcej informacji znajdziesz na liście różnic.

10 sierpnia 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 181 Creative filtered because the VAST XML document is larger than the set maximum size.
Dodano 182 Creative filtered because the publisher disallowed the deal ID it targeted.
Dodano 183 Creative filtered beacuse the publisher enabled the deal ID it targeted for a different deal type.

9 sierpnia 2017 r.

Nowości w protokole RTB w wersji 131

Do interfejsu BidRequest.Video.VideoFormat dodano nowe obsługiwane wartości typu MIME audio:
Dodano AUDIO_MP3
Dodano AUDIO_OGG
Dodano AUDIO_MP4A
Dodano AUDIO_MP3_OGG, gdy wymagane są zarówno pliki MP3, jak i OGG.
Dodano ALLOWED_AD_TYPE_AUDIO do listy BidRequest.AdSlot.AllowedAdType
Widoczna, gdy występuje dowolny z typów MIME audio
Do elementu BidRequest.Video.Placement dodano tryb AUDIO, aby sygnalizować, kiedy żądanie pochodzi ze strumienia audio.
WAŻNE: niektóre odtwarzacze audio żądają reklam wideo, gdy użytkownik wchodzi w interakcję z ekranem. To pole nie akceptuje reklam audio miodu lub reklam wideo, które nie są akceptowane.

7 sierpnia 2017 r.

Nowości w protokole RTB w wersji 130

Do tabeli BidRequest.Video.VideoFormat dodano nowe obsługiwane wartości typu MIME:
Dodano VIDEO_WEBM dla „video/webm”
Dodano VIDEO_MOV dla „video/quicktime”
Dodano VIDEO_3GPP dla „video/3gpp”
Dodano VIDEO_HLS dla „application/x-mpegURL”
Dodano VIDEO_DASH dla „application/dash+xml”

2 sierpnia 2017 r.

Nowości w protokole RTB w wersji 129

Dodano: BidRequest.AdSlot.exchange_bidding.key_value.
Wartość ta zostanie ustawiona, gdy wydawca biorący udział w Otwartym ustalaniu stawek zdecyduje się na przekazanie kluczy i wartości w żądaniu na giełdę zewnętrzną.
Dodano: BidResponse.Ad.AdSlot.video_vast_xml.
To pole umożliwia licytującemu odpowiadanie na żądanie reklamy wideo przez zwrócenie pełnego dokumentu XML VAST 2.0 lub 3.0.

28 lipca 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 181 Creative filtered because the VAST XML document is larger than the set maximum size.
Dodano 182 Creative filtered because the publisher disallowed the deal ID it targeted.
Dodano 183 Creative filtered because the publisher enabled the deal ID it targeted for a different deal type.

20 lipca 2017 r.

Co nowego w słownikach RTB

Plik słownika publisher-verticals.txt uległ zmianie.
Dodano nowe branże i lokalizacje na świecie. Więcej informacji znajdziesz na liście różnic.
Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 179 Creative filtered because the required field amp_ad_url was missing or empty.
Dodano 180 Video ad VAST version is not one of the supported versions in the video ad request.

13 lipca 2017 r.

Co nowego w słownikach RTB

Plik słownika publisher-verticals.txt uległ zmianie.
Dodano wiersz 1347 /Business & Industrial/Transportation & Logistics/Self Storage.
Usunięto wiersz 1347 /Business & Industrial/Transportation & Logistics/Public Storage.
Plik słownika buyer-declarable-creative-attributes.txt uległ zmianie.
Dodano 30 InstreamVastVideoType: Vpaid.
Usunięto 30 InstreamVastVideoType: Vpaid Flash.
Plik słownika publisher-excludable-creative-attributes.txt uległ zmianie.
Dodano 30 InstreamVastVideoType: Vpaid.
Usunięto 30 InstreamVastVideoType: Vpaid Flash.
Plik słownika pretargetable-creative-attributes.txt uległ zmianie.
Dodano 30 InstreamVastVideoType: Vpaid.
Usunięto 30 InstreamVastVideoType: Vpaid Flash.
Plik geo-table.csv został zmieniony.
Dodano nowe lokalizacje. Więcej informacji znajdziesz na liście różnic.

30 czerwca 2017 r.

Nowości w protokołach RTB

Protokół RTB w wersji 128 i protokół przesyłania zbiorczego plików cookie w wersji 5
Do protokołu RTB dodano pole BidRequest.publisher_id, aby wskazać wydawcę, od którego pochodzi wyświetlenie.
Dodano atrybut data_source_id do protokołu przesyłania zbiorczego plików cookie, aby wskazać źródło danych, które przyczyniło się do subskrypcji.

28 czerwca 2017 r.

Co nowego w słownikach RTB

Plik słownika pretargetable-creative-attributes.txt uległ zmianie.
Dodano 71 InstreamVastVideoType: Non Vpaid.
Usunięto 71 InstreamVastVideoType: Non Vpaid Flash.

16 czerwca 2017 r.

Co nowego w słownikach RTB

Plik słownika mobile-os.csv uległ zmianie.
Dodano wiersz 630335,"iOS",10,4,-1.
Dodano wiersz 630337,"iOS",11,0,-1.
Dodano wiersz 630339,"Android",8,0,-1.
Dodano wiersz 630341,"WindowsPhone",10,0,-1.
Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 175 Creative filtered because it has an empty VAST XML document.
Dodano 176 Creative filtered because the VAST document can't be parsed.

15 czerwca 2017 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 21
Dodano pole is_rewarded_inventory. To pole zawiera te same dane co pole BidRequest.AdSlot.is_rewarded protokołu AdX.

8 czerwca 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 174 Creative filtered because it lacks an MP4A file in the VAST.

7 czerwca 2017 r.

Nowości w protokole RTB w wersji 127

Do wyliczeń, które nie miały wartości domyślnej, dodano nieokreślone wartości.
Jest to pułapka, gdy w interfejsie BidRequest uwzględniane są nowe wartości wyliczeniowe, ale licytujący nadal używa starszej wersji protokołu RTB, która nie zawiera tych definicji wartości wyliczeniowych. W takim przypadku biblioteka proto powoduje, że metoda pobierająca zwraca pierwszą zadeklarowaną wartość (jeśli nie jest ustawiona jako domyślna). Jeśli pierwsza wartość jest nieokreślona, klienci wiedzą, że mają ignorować takie wartości.

6 czerwca 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 170 Creative filtered because it lacks a MOV file in the VAST.
Dodano 171 Creative filtered because it lacks a 3GPP file in the VAST.
Dodano 172 Creative filtered because it lacks a DASH file in the VAST.
Dodano 173 Creative filtered because it lacks an HLS file in the VAST.

5 czerwca 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Dodano obsługę vcm w planszach końcowych wideo. OpenRTB 2.5 pozwala giełdy na ustawienie vcm=1, gdy po filmie obsługiwana jest plansza końcowa. Więcej informacji znajdziesz w dokumentacji obiektów Banner w przewodniku po OpenRTB.
Teraz wypełniamy cat w obiekcie App dla aplikacji mobilnych, mapując kategorie aplikacji mobilnych na odpowiednie wartości IAB. Więcej informacji znajdziesz w dokumentacji obiektu App w przewodniku po OpenRTB.
Teraz wypełniamy 3 rodzaje danych w polu metric w obiekcie imp: click_through_rate, viewability i completion_rate. Więcej informacji znajdziesz w opisie obiektu Imp w przewodniku po OpenRTB.

4 czerwca 2017 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 20
Dodano pole attribute. To pole zawiera te same dane co pole attribute obiektu reklamy w protokole AdX, w tym atrybut AdX sizeless.
Dodano obiekt PublisherExt, aby umożliwić wysyłanie kraju wydawcy z protokołu AdX.

25 maja 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 166 Creative filtered beacuse the publisher didn't whitelist the deal ID it targeted, and didn't enable unknown deal IDs from the exchange.
Dodano 167 Publisher requires premium (high-quality) snippets only, but this snippet does not match.
Dodano 168 Creative filtered because it lacks a MP3 (audio) file in the VAST.
Dodano 169 Creative filtered because it lacks a AUDIO (audio) file in the VAST.

11 maja 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Uwzględniamy teraz pole BidResponse.burl.

10 maja 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Ustawiamy teraz pole BidRequest.wlang.
W przypadku reklam wideo ustawiamy teraz pole BidRequest.imp.video.placement.

4 maja 2017 roku

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
W przypadku reklam wideo ustawiamy teraz pole BidRequest.{site|app}.content.producer.domain.

2 maja 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Dodano nowe lokalizacje, głównie w Stanach Zjednoczonych. Szczegóły znajdziesz w pełnej różnicy.

21 kwietnia 2017 roku

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.5.0
Zaktualizowaliśmy specyfikację OpenRTB 2.5. Rzeczywista obsługa nowych pól w OpenRTB 2.5 pojawi się w kolejnych wersjach.

12 kwietnia 2017 r.

Co nowego w słownikach RTB

Plik słownika publisher-verticals.txt uległ zmianie.
Do aktualizacji pliku dodano i usunięto wiersze.
Plik słownika mobile-carriers.csv uległ zmianie.
Do aktualizacji pliku dodano i usunięto wiersze.

27 marca 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Dodano komentarz informujący, że makro ${AUCTION_PRICE} jest teraz obsługiwane przez impression_tracking_url.

22 marca 2017 r.

Nowości w protokole RTB w wersji 126

Zmieniliśmy komentarze do pola click_through_url, aby ułatwić jego zrozumienie.
Dodano komentarze wskazujące, że pole działa jako deklaracja docelowego adresu URL, której nie można używać w środowisku aktywnym.

17 marca 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Zaktualizowaliśmy komentarz nad polem protocols, aby odzwierciedlić, że to pole jest teraz ustawiane dynamicznie dla każdego żądania i nie jest już zakodowane na stałe według określonego zestawu wartości.

10 marca 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Dodano komentarze wyjaśniające, że ciągi tekstowe przekraczające max_safe_length mogą zostać obcięte przez Authorized Buyers lub wydawcę podczas renderowania.

9 marca 2016 r.

Nowości w protokole RTB w wersji 125

Zaktualizowano opis max_safe_length pól.
Dodano komentarze wyjaśniające, że ciągi tekstowe przekraczające max_safe_length mogą zostać obcięte przez Authorized Buyers lub wydawcę podczas renderowania.

3 marca 2017 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 889 Netscore.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

1 marca 2017 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 9
Usunięto dfp_network_code. Wartość tego pola jest zawsze taka sama jak pierwsza część pola dfp_ad_unit_code, więc pole dfp_network_code nie jest już potrzebne.

28 lutego 2017 r.

Nowości w protokole RTB w wersji 124

W sekcji BidRequest.adslot.matching_ad_data.direct_deal dodano nowe pole: remaining_impressions_to_buy
Więcej informacji znajdziesz w dokumentacji RTB w przypadku umów automatyzacji gwarantowanej.

24 lutego 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Dodano komentarze, aby ułatwić korzystanie z pól adm i adm_native.

23 lutego 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Kody stanu kreacji 147,148,149,150, 151 zostały wycofane i nie są już używane.

22 lutego 2017 r.

Nowości w protokole RTB w wersji 123

Komentarze do wyliczeni EndCapSupport zostały zmienione, aby było jasne, że niektóre wartości są nieużywane.
Wartości END_CAP_FORBIDDEN i END_CAP_REQUIRED nigdy nie zostały ustawione w odpowiedzi na pytanie o stawkę.
Komentarze do pola click_through_url zostały zmienione, aby ułatwić zrozumienie jego użycia.
Dodano komentarze wskazujące, że pole działa jako deklaracja docelowego adresu URL, której nie można używać w środowisku aktywnym.

17 lutego 2017 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Usunięto komentarze, aby podkreślić, że pola demograficzne nie są już mapowane na wycofane pola demograficzne użytkowników AdX.
Dodano komentarz opisujący mapowanie z powrotem do protokołu AdX dla pola BidRequest.Imp.secure.

16 lutego 2017 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 888 ViewersLogic.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Dodano 888 ViewersLogic.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

9 lutego 2017 r.

Nowości w protokole RTB w wersji 122

Plik słownika realtime-bidding.proto.txt uległ zmianie.
Zmieniono opis karty IN_FEED.

8 lutego 2017 r.

Nowości w protokole RTB w wersji 121

Dodano nową wartość do pola BidRequest.adslot.matching_ad_data.direct_deal.deal_type: PROGRAMMATIC_GUARANTEED.
Więcej informacji znajdziesz w dokumentacji RTB w przypadku umów automatyzacji gwarantowanej.

3 lutego 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Drobne poprawki w hierarchii administracyjnych, głównie we Francji. Szczegółowe informacje znajdziesz w pełnej różnicy.

26 stycznia 2017 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Dodano 165 Creative filtered by publisher's restrictions on which brands can be shown together. Ten kod jest używany, jeśli kreacja została odfiltrowana za pomocą skonfigurowanych przez wydawcę wykluczeń konkurujących reklamodawców.

25 stycznia 2017 r.

Nowości w protokole RTB w wersji 120

Dodano: BidRequest.AdSlot.is_rewarded.
To pole wskazuje, czy użytkownik otrzymuje nagrodę za obejrzenie reklamy.

18 stycznia 2017 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Drobne poprawki hierarchii w usłudze geo-table.csv. Więcej informacji znajdziesz na liście różnic.
Plik słownika publisher-verticals.txt uległ zmianie.
W wersji publisher-verticals.txt dodano drobne poprawki nazw. Więcej informacji znajdziesz na liście różnic.
Plik słownika creative-status-codes.txt uległ zmianie.
Dodano nowe kody stanu 163 Native ad image asset width not in permitted range i 164 Native ad image asset aspect ratio not in permitted range do: creative-status-codes.txt.

13 stycznia 2017 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 885 Cloud Technologies.
Dodano 886 Research and Analysis of Media.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 886 Research and Analysis of Media.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

12 stycznia 2016 r.

Nowości w protokole RTB w wersji 119

Zaktualizowano opis: app_id.
W protokole RTB zaktualizowaliśmy komentarz dotyczący elementu app_id, aby uwzględnić przykład dotyczący urządzeń z systemem Windows.

Styczeń 9, 2017

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Dodano komentarze w celu opisania nowego zachowania: w przypadku ciągu znaków klienta użytkownika przeglądarki niektóre dane mogą zostać usunięte lub zastąpione.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 884 Nugg.ad.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

6 stycznia 2017 r.

Nowości w protokole RTB w wersji 118

Dodaj miejsce docelowe wideo IN_FEED.
Dodanie nowego miejsca docelowego wideo IN_FEED w wiadomości wideo usługi BidRequest. Miejsce docelowe IN_FEED odpowiada formatowi wideo In-Feed, w którym kreacja wideo wyświetla się, gdy użytkownik przewija kanał z treściami, zwykle kanał aplikacji społecznościowej, artykuł z wiadomościami itp. Film wyświetla się w głównym kanale i w wizji użytkownika oraz w procesie czytania, a nie z boku, jak np. w przypadku wideo banerowego.

Styczeń 5, 2017

Nowości w protokołach RTB

Protokół RTB w wersji 117 i plik cookie przesyłania zbiorczego w wersji 4
Drobne poprawki komentarzy w usłudze cookie-bulk-upload.proto
W 2017 r. wydłużyliśmy okres powiadamiania o naruszeniu praw autorskich

Styczeń 4, 2017

Nowości w raporcie o stanie fragmentu kodu (proto) w wersji 22

Dodano nowy powód odrzucenia: 93 Unsupported Flash Content

16 grudnia 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Zaktualizowaliśmy komentarze, aby wyjaśnić, że implementacja reklamy natywnej może odrzucić obraz o współczynniku proporcji, który odbiega od preferowanego współczynnika proporcji, i że spowoduje to skrócenie zbyt długich ciągów.

Nowości w protokole RTB w wersji 116

Dodano komentarze.
Zaktualizowaliśmy komentarze, aby wyjaśnić, że implementacja reklamy natywnej może odrzucić obraz o współczynniku proporcji, który odbiega od preferowanego współczynnika proporcji, i że spowoduje to skrócenie zbyt długich ciągów.

14 grudnia 2016 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Opis kodu stanu 99 został zmieniony na 99 Creative filtered because it lacks a required video MIME type in the VAST file (the specific missing type is not available).
Poprawki literówek w opisach kodów stanu 115,120, 131,147,148.

13 grudnia 2016 r.

Nowości w protokole RTB w wersji 115

Dodano miejsce: publisher_country
Kraj podany w adresie rozliczeniowym wydawcy. Może się on różnić od kraju wykrytego w identyfikatorze geo_criteria_id lub kraju, w którym jest hostowana witryna.
Wyjaśnij komentarze użytkowników geo_criteria_id i postal_code

5 grudnia 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Ta wersja po prostu aktualizuje komentarz dotyczący pola BidRequest.imp.video.protocols OpenRTB, aby odzwierciedlić zmianę w sposobie wypełniania pola. Zamiast zawsze zawierać numery protokołów VAST 3, pole to będzie zawierać poprawne numery protokołów VAST 2, VAST 3 lub VAST 4, w zależności od obsługiwanych funkcji (zobacz informacje o wersji protokołu RTB 114).

2 grudnia 2016 r.

Nowości w protokole RTB w wersji 114

Dodano miejsce: BidRequest.Video.protocols
To pole zawiera tablicę obsługiwanych protokołów reklam wideo, które odpowiadają działaniu OpenRTB 2.4. Obecnie możliwe są tylko te dane: VAST_2_0, VAST_3_0, VAST_2_0_WRAPPER, VAST_3_0_WRAPPER, VAST_4_0 i VAST_4_0_WRAPPER.

29 listopada 2016 r.

Nowości w protokole RTB w wersji 113

Dodaliśmy obsługę nowej metody odtwarzania filmów
Dodaliśmy nową wartość wyliczenia MOUSE_OVER do metody BidRequest.Video.VideoPlaybackMethod, aby zapewnić zgodność z OpenRTB 2.0.

18 listopada 2016 r.

Nowości w protokołu RTB w wersji 112

Usunięto stare wycofane pola.
Pola, które zostały wcześniej wycofane i nie są już ustawiane, są teraz całkowicie usuwane, aby zapewnić przejrzystość.

14 listopada 2016 r.

Nowości w protokole RTB w wersji 111

Wycofano: BidRequest.AdSlot.ExchangeBidding.dfp_network_code.
Wartość tego pola jest zawsze taka sama jak pierwsza część argumentu BidRequest.AdSlot.dfp_ad_unit_code, więc pole dfp_network_code nie jest już potrzebne.

9 listopada 2016 r.

Nowości w protokołu RTB w wersji 110

Dodano miejsce: BidResponse.Ad.NativeAd.click_link_url
Adres URL otwierany przez przeglądarkę lub pakiet SDK, gdy użytkownik klika reklamę. Może się zmieniać między stawkami. Jeśli jej nie skonfigurujesz, aby zapewnić zgodność wsteczną, przeglądarka lub pakiet SDK wczytuje pierwszy element click_through_url. Parametr click_through_url powinien jednak pozostać taki sam między stawkami w przypadku tego samego identyfikatora merchant_creative_id, a click_link_url może ulec zmianie.

4 listopada 2016 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 7
Dodano miejsce: BidResponse.SeatBid.Bid.exchange_deal_type
Używany tylko w przypadku giełd uczestniczących w Otwartym ustalaniu stawek (giełd zewnętrznych, które korzystają z określania stawek w czasie rzeczywistym w usłudze Ad Manager). Zawiera informacje o typie umowy, która dotyczy stawki na giełdzie.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 8
Dodaliśmy sygnały do rozszerzenia natywnego w żądaniu reklamy natywnej OpenRTB 1.1.
Dodano te pola: style_id, style_width, style_height i style_layout_type.

Nowości w protokole RTB w wersji 109

Dodano BidResponse.Ad.AdSlot.exchange_deal_id i BidResponse.Ad.AdSlot.exchange_deal_type.
Są one używane tylko w przypadku giełd uczestniczących w Otwartym ustalaniu stawek (giełd zewnętrznych, które korzystają z określania stawek w czasie rzeczywistym w usłudze DFP). Zawierają informacje o umowach, które dotyczą stawek na giełdzie.

3 listopada 2016 r.

Nowości w protokole RTB w wersji 108

Dodano: BidRequest.AdSlot.allowed_ad_types.
Zawiera powtarzające się wyliczenie reprezentujące typy reklam, które są dozwolone w odpowiedzi na stawkę. Możliwe wartości to ALLOWED_AD_TYPE_BANNER, ALLOWED_AD_TYPE_NATIVE i ALLOWED_AD_TYPE_VIDEO. To pole powinno ułatwić licytującym określenie typów reklam, które mogą zwracać.

2 listopada 2016 r.

Co nowego w Słownikach RTB – nowa wersja pliku geo-table.csv

Najważniejsze informacje o nowych celach geograficznych:
Około 100 parków narodowych USA/Kanady. Po raz pierwszy można kierować reklamy na parki narodowe.
Około 1200 miast i kodów pocztowych w Australii, Niemczech, Holandii i Francji.
78 gminy w Portoryko.
71 prowincji/okręgów w Bangladeszu.
21 prowincji/miast w Kostaryce.
2 nowe cele na poziomie kraju: Guernsey (GG) i Jersey (JE).
kilkaset prowincji w Ameryce Południowej, Afryce i na Bliskim Wschodzie;

31 października 2016 r.

Nowości w protokole RTB w wersji 107

Zaktualizuj do BidRequest.AdSlot.NativeAdTemplate.
Dodano te pola: style_id, style_width, style_height i style_layout_type.

Co nowego w słownikach RTB

Plik słownika ad-product-categories.txt uległ zmianie.
Dodaliśmy ponad 200 nowych kategorii ogólnych, których wydawcy mogą używać do blokowania reklam. Kategorie te są zwykle bardziej szczegółowe, dzięki czemu wydawcy mogą blokować węższe kategorie, np. kreacje Used Motor Vehicle zamiast wszystkich kreacji Automotive. Tak jak wcześniej, ten plik słownika przydaje się podczas mapowania identyfikatorów kategorii z pola excluded_product_category w pytaniach o stawkę na kategorie zrozumiałe dla człowieka.
Aby uzyskać więcej szczegółów, zapoznaj się z pełną listą różnic.

27 października 2016 r.

Nowości w protokole RTB w wersji 106

Dodano: BidRequest.AdSlot.sticky_settings.
Obejmują one różne typy ustawień zaangażowania, które wydawca może zadeklarować w swoich zasobach reklamowych. Obsługiwane są 3 rodzaje ustawień przyklejenia: „przyklejanie w pionie”, „przyklejanie w poziomie na dole” i „przyklejanie w poziomie na górze”.
Interfejs BidRequest.AdSlot.stickiness został wycofany.
To pole zostało wycofane i zastąpione BidRequest.AdSlot.sticky_settings.vertical_stickiness.

Co nowego w słownikach RTB

Plik słownika publisher-verticals.txt uległ zmianie.
Poprawiono literówki w niektórych nazwach kategorii. Szczegóły znajdziesz w liście różnic.

24 października 2016 r.

Nowości w protokole RTB w wersji 105

Wycofane pole BidRequest.user_demographics.
Pole BidRequest.user_demographics zostało wycofane.

21 października 2016 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 6
Dodano: BidRequest.imp.dfp_ad_unit_code.
Jest używana tylko w przypadku Otwartego ustalania stawek.

Nowości w protokole RTB w wersji 104

Dodano: BidRequest.AdSlot.non_browser_slot_source.
Ta wartość zostanie ustawiona, gdy wydawca zadeklaruje, że boks reklamowy jest wyświetlany w zasobach reklamowych innych niż przeglądarki. Będzie on określać rodzaj zasobów reklamowych innych niż przeglądarki.
Dodano: BidRequest.AdSlot.is_interstitial_slot.
Ustawienie zostanie ustawione, gdy wydawca zadeklaruje, że boks reklamowy jest reklamą pełnoekranową i zasłania treść przez określony czas.

20 października 2016 r.

Nowości w protokole RTB w wersji 103

Dodano: BidRequest.AdSlot.dfp_ad_unit_code.
Jest używana tylko w przypadku Otwartego ustalania stawek.

14 października 2016 r.

Co nowego w słownikach RTB

Plik słownika geo-table.csv uległ zmianie.
Poprawiono drobne błędy w pisowni i hierarchii geograficznej. Więcej informacji znajdziesz na liście różnic.

Nowości w OpenRTB

Protokół Google OpenRTB 2.4.1
Ta wersja nie wprowadza żadnych zmian w protosach, ale aktualizuje mapowanie za pomocą wstępnej obsługi OpenRTB 2.4:
Rozmiary wyświetleń banerów są teraz zmapowane na rozmiar Banner.format. Pola wmin, wmax, hmin i hmax zostały wycofane i nie będą wypełniane w przypadku wersji 2.4 lub nowszej. Pola w i h będą nadal wypełnione (z pierwszym wymiarem, jak wcześniej). Pole
Video.skip zostało uzupełnione. Element
Bid.api jest teraz obsługiwany.
Nagłówek HTTPx-openrtb-version to „2.4”.
Licytujący korzystający z OpenRTB/JSON mogą wyrazić zgodę na nową wersję 2.4 za pomocą interfejsu RTB API. Licytujący, którzy korzystają z OpenRTB/Protobuf, mogą używać tylko wersji 2.3. Przyszłe uaktualnienia zostaną ogłoszone oddzielnie.

13 października 2016 r.

Nowości w protokole RTB w wersji 102

Zaktualizowano opis „Connected_TV = 4”.
W protokole RTB zaktualizowaliśmy komentarz dotyczący „Connected_TV = 4”, by dokładniej opisać uwzględnione urządzenia.

11 października 2016 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 21

Dodano nowy powód odrzucenia: 92 Personal Loans

6 października 2016 r.

Nowości w protokole RTB w wersji 101

Zaktualizowano komentarz do szablonu reklam natywnych.
W protokole RTB zmodyfikowaliśmy komentarz szablonu reklam natywnych, aby zauważyć, że w pewnych okolicznościach można ustawić pole html_snippet lub video_url zamiast pola native_ad.

5 października 2016 r.

Nowości w protokole RTB w wersji 100

Zaktualizowano komentarz dotyczący identyfikatora reklamy mobilnej.
W protokole RTB zaktualizowaliśmy komentarz do pola BidRequest.Mobile.encrypted_advertising_id, aby wyjaśnić, na jakich platformach jest ono dostępne (oprócz urządzeń z iOS i Androidem).

30 września 2016 r.

Nowości w protokole RTB w wersji 99

Do określania stawek w czasie rzeczywistym dodaliśmy sygnał dotyczący współczynnika pełnych obejrzeń.
W protokole RTB dodano nowe pole video_completion_rate do wartości BidRequest.AdSlot. To pole wskazuje szacunkowe prawdopodobieństwo, że reklama wideo wyświetlana w tym boksie zostanie obejrzana w całości.

29 września 2016 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 880 Navegg.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

20 września 2016 r.

Co nowego w raporcie o stanie fragmentu kodu (Proto) w wersji 20

Dodano nowe przyczyny odrzucenia.
90 Maximum number of HTTP calls exceeded
91 Maximum number of cookies exceeded
Zmieniono nazwę przyczyny odrzucenia 36 z Invalid ad download size na Maximum download size exceeded

19 września 2016 r.

Co nowego w słownikach RTB

Plik słownika buyer-declarable-creative-attributes.txt uległ zmianie.
Dodano 105 Rendering: Sizeless AdX. Służy do deklarowania, czy kreacja HTML może dynamicznie zmieniać rozmiar, by wypełniać boksy o różnych rozmiarach. Więcej informacji znajdziesz w dokumentacji dotyczącej reklam pełnoekranowych.

15 września 2016 r.

Nowości w protokole RTB w wersji 98

Dodaliśmy obsługę natywnych reklam wideo w ramach określania stawek w czasie rzeczywistym.
W protokole RTB dodaliśmy nową wartość wyliczeniową VIDEO do BidRequest.NativeAdTemplate i nowe pole video_url do BidResponse.NativeAd. Dzięki temu licytujący będą mogli odesłać odpowiedź wideo w polu native_ad, gdy w polu BidRequest.native_ad_template.required_fields lub BidRequest.native_ad_template.recommended_fields występuje VIDEO.

13 września 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.1
Ta wersja zawiera drobne poprawki dotyczące OpenRTB 2.4, w szczególności informacje dotyczące stanu wycofania kilku pól, obsługi rozszerzeń dla Audio i Format oraz poprawnego typu wyliczenia w nowym polu Bid.qagmediarating.

8 września 2016 r.

Co nowego w słownikach RTB

Plik słownika creative-status-codes.txt uległ zmianie.
Zmieniliśmy opis stanu z 107 na Required elements specified in bid_request.adslot.native_ad_template.required_fields are missing or empty, aby odzwierciedlić zmianę polegającą na dodaniu filtrowania wymaganych elementów reklamy natywnej z wyraźnie pustymi wartościami.

7 września 2016 r.

Nowości w protokole RTB w wersji 97

Zaktualizowaliśmy komentarze, aby wyjaśnić, że w przypadku aplikacji na iOS parametr app_name jest dostarczany przez AppAnnie.

6 września 2016 r.

Co nowego w raporcie o stanie fragmentu kodu (Proto) w wersji 19

Dodano nowe przyczyny odrzucenia.
81 Film jest za długi
82 Narusza japońskie przepisy dotyczące aptek
83 Nieakredytowane apteki weterynaryjne
84 Niedozwolona treść: aborcja
85 Niedozwolona treść: antykoncepcja
86 Narusza wymagania dotyczące wyświetlania reklam w Chinach
87 Kreacja promuje aptekę bez odpowiednich certyfikatów
88 Treści nie dla całej rodziny lub przeznaczone dla dorosłych
89

2 września 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.4.0
To nowa, ważna wersja aktualizująca schemat protokołu na potrzeby najnowszych wersji specyfikacji: OpenRTB 2.4 i OpenRTB Native 1.1. Zmiana jest zgodna wstecznie na poziomie przewodu, ale włączenie nowego schematu do systemu licytującego może wymagać drobnych zmian w kodzie. Wprowadziliśmy 2 zmiany:
nowe pola zostały dodane zgodnie z najnowszą specyfikacją. Nie zostały jeszcze ustawione, a ich obsługa zapowiadamy osobno.
Wszystkie wyliczenia są teraz najwyższego poziomu, a nie zagnieżdżone. Nie zmienia to reprezentacji przewodów, ale wymaga poprawienia importów lub użycia inaczej kwalifikowanych nazw wyliczeniowych w niektórych językach.

31 sierpnia 2016 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 284 Research Now.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Dodano 284 Research Now.
Dodano 876 Exponential Expandable.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

22 sierpnia 2016 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 5
Dodano: BidRequest.imp.dfp_network_code.
Jest używana tylko w przypadku Otwartego ustalania stawek.

Nowości w protokole RTB w wersji 96

Element dfp_network_code został dodany do listy BidRequest.AdSlot.
Jest używana tylko w przypadku Otwartego ustalania stawek.

18 sierpnia 2016 r.

Nowości w protokole RTB w wersji 95

Zmieniono semantykę pola mediation_status.
W tym polu ustawiona jest wartość DIRECT_REQUEST lub UNKNOWN w zależności od tego, czy żądanie reklamy pochodzi bezpośrednio od wydawcy.

8 sierpnia 2016 r.

Nowości w protokole RTB w wersji 94

Element amp_ad_request_type został dodany do listy BidRequest.AdSlot.
To pole wskazuje, czy strona jest w postaci przyspieszonej strony mobilnej (AMP).

1 sierpnia 2016 r.

Nowości w protokole RTB w wersji 92

Odpowiedzi na pytania o stawkę są odfiltrowywane z aukcji, niezależnie od tego, czy pole is_test w pytaniu o stawkę ma podczas wstępnych testów z użyciem ruchu Google ustawione na true czy false.

26 lipca 2016 r.

Co nowego w słownikach RTB

Plik słownika gdn-vendors.txt uległ zmianie.
Dodano 874 Cint.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.
Plik słownika vendors.txt uległ zmianie.
Zmieniono 332 Audience Manger (DemDex/Omniture) na: 332 Audience Manger (DemDex).
Zmieniono 832 The AdExchange na 832 The ADEX.
Dodano 874 Cint.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

18 lipca 2016 r.

Nowości w protokole RTB w wersji 92

Zaktualizowaliśmy komentarze, aby wyjaśnić, że w przypadku reklam natywnych obiekt click_through_url podaje adres URL strony docelowej, na którą wyświetla się użytkownik, a element click_tracking_url określa adres URL, pod którym wątek w tle może wysyłać pingi na potrzeby śledzenia.

14 lipca 2016 r.

Co nowego w słownikach RTB

Plik słownika vendors.txt uległ zmianie.
Dodano 838 Revjet Expandable.
Dodano 863 Bonzai Expandable.
Dodano 864 INCUBIQ Solutions.
Pliki słownika vendors.txt i gdn-vendors.txt uległy zmianie.
Wyczyściliśmy wszystkich dostawców wideo VAST, którzy zostali wycofani od kwietnia 2016 r.: są oni zawsze dozwoleni (bez deklaracji) i nie pojawiają się w polu allowed_vendors w pytaniach o stawkę.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

13 lipca 2016 r.

Co nowego w raporcie o stanie fragmentu kodu (Proto) w wersji 18

Dodaliśmy nowe pole detected_domain, które ujawnia domeny wykryte podczas skanowania weryfikującego.

11 lipca 2016 r.

Nowości w protokole RTB w wersji 91

Zaktualizowano komentarze, aby wskazać, że fragmenty ciągu znaków klienta użytkownika mogą zostać usunięte lub zastąpione.

8 lipca 2016 r.

Nowości w protokole RTB w wersji 90

Zaktualizowano komentarze wyjaśniające, że w przypadku reklam natywnych używana jest tylko pierwsza wartość właściwości click_through_url.

29 czerwca 2016 r.

Nowości w protokole RTB w wersji 89

Zaktualizowano komentarze, aby wyjaśnić, że url zawsze zawiera protokół.

22 czerwca 2016 r.

Nowości w protokole RTB w wersji 88

Zaktualizowano komentarze, aby wyjaśnić, że click_through_rate nie zawiera danych zagregowanych z Google Ads.

Nowości w protokole RTB w wersji 87

W komentarzu BidResponse wyjaśniliśmy, że element BidRequest może mieć tylko 1 element AdSlot.
Wprowadzono drobne zmiany w treści komentarzy w innych komentarzach.

3 czerwca 2016 r.

Co nowego w Słownikach RTB – nowa wersja pliku geo-table.csv

Dodaje prawie 6000 nowych celów geograficznych. Te cele są już aktywne i obecne w pytaniach o stawkę (z wyjątkiem Mjanmy, która nie jest jeszcze aktywna). Najważniejsze nowości:
2214 dzielnic i kodów pocztowych w Holandii.
1423 miasta, dzielnice i kody pocztowe w Malezji
722 miasta, dzielnice i kody pocztowe w głównych krajach Europy Wschodniej (Polska, Czechy, Węgry) i w Grecji.
639 prowincji, miast i dzielnic na Filipinach.
155 miast i dzielnic w Szwecji.
104 miasta i kody pocztowe w Niemczech.
Oto kilka najważniejszych momentów z długiego ogona:
2 ważne dzielnice w Nowym Jorku – Manhattan i Queens.
44 reklamy kierowane na Mjanmę, obejmują też sam kraj (uwaga: jeszcze nie jest ona aktywna).
Stolice / duże miasta w wielu krajach, np. Nairobi w Kenii i Gwatemala w Gwatemali.

2 czerwca 2016 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 4
Dodano BidRequest.processing_time_ms.

30 maja 2016 r.

Nowości w raporcie o stanie fragmentu w wersji Proto 17

Dodano poprawkę do deklaracji VIDEO_IN_SNIPPET_ATTRIBUTE_ADDED.
Ta korekta jest stosowana wtedy, gdy fragment kodu HTML odtwarza treść wideo, więc należy ją blokować w zasobach reklamowych, które zabraniają wyświetlania filmów.
Dodano pole detected_language.
To pole zawiera informacje o językach wykrytych przez AdX w przypadku kreacji.
Te języki są używane do stosowania bloków językowych wydawcy. Zobacz też pole allowed_languages w protokole RTB.
Do wiadomości Correction dodano pole context.
To pole opisuje kontekst, w którym wprowadzana jest poprawka.
Konteksty korekty i wyświetlania oddzielają teraz internet mobilny od aplikacji mobilnej.
Dodano nowe wartości do wyliczenia Platform: ANDROID_IN_APP i IOS_IN_APP. Istniejące wartości ANDROID i IOS zostały zmienione na ANDROID_WEB i IOS_WEB.

26 maja 2016 r.

Co nowego w protosach OpenRTB

Protokół rozszerzeń Google OpenRTB w wersji 3
Dodano BidRequest.imp.publisher_parameter i BidResponse.SeatBid.Bid.bidder_name.
Oba pola są używane tylko w przypadku giełd, które biorą udział w Otwartym ustalaniu stawek (giełdach zewnętrznych, które korzystają z określania stawek w czasie rzeczywistym w usłudze Ad Manager).

Nowości w protokole RTB w wersji 86

Element allowed_languages został dodany do listy BidResponse.AdSlot.
To pole zawiera języki kreacji dozwolone przez wydawcę.
Jeśli zasada nie jest skonfigurowana, wszystkie języki są dozwolone.

25 maja 2016 r.

Nowości w protokole RTB w wersji 85

Dodano exchange_bidding do listy BidRequest.AdSlot i bidder_name do BidResponse.Ad.
Oba pola są używane tylko w przypadku giełd, które biorą udział w Otwartym ustalaniu stawek (giełdach zewnętrznych, które korzystają z określania stawek w czasie rzeczywistym w DFP).

19 maja 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.3.3
Poprawiono wartość Video.vasttag w odpowiedzi natywnej na wartość skalarną, a nie tablicę.
Zaktualizowano komentarze, aby odzwierciedlić zmiany w kodowaniu pól: BidRequest.id, User.customdata, Device.ifa.
Protokół rozszerzeń Google OpenRTB, wersja 2
Dodano BidRequest.imp.allowed_vendor_type i BidResponse.SeatBid.Bid.ad_choices_destination_url.

13 maja 2016 r.

Nowości w protokole RTB w wersji 84

Element ad_choices_destination_url został dodany do listy BidResponse.Ad.
W tym polu możesz podać link do strony preferencji reklam.
Ta funkcja jest obsługiwana tylko w przypadku reklam natywnych.
Jeśli taka ikona jest dostępna, do kreacji natywnej jest dodawana standardowa ikona Informacja i powiązana z tym adresem URL.

29 kwietnia 2016 r.

Co nowego w słownikach RTB

Usunęliśmy dostawców reklam VAST (wideo typu In-Stream) z listy możliwych do zadeklarowania.
Ci dostawcy są teraz dozwoleni bez deklaracji. Wydawcy nie mogą ich akceptować ani blokować, dlatego nie wysyłamy ich już w polu allowed_vendors w pytaniach o stawkę.
Więcej informacji znajdziesz na liście certyfikowanych dostawców.

28 kwietnia 2016 r.

Nowości w protokole RTB w wersji 83

Zaktualizowano komentarze wyjaśniające, że viewability może być szacowany na podstawie danych historycznych lub środowiskowych.

27 kwietnia 2016 r.

Co nowego w słownikach RTB

Usunięto dostawcę 113 "Image & Flash" z list, które można zgłosić.
Ten dostawca został wycofany. Nie należy deklarować jej w odpowiedziach na stawkę, ponieważ nie oznacza żadnej technologii wyświetlania reklam firm zewnętrznych (ale jeśli zostanie zadeklarowana, stawka nie będzie z tego powodu odfiltrowana). Licytujący powinni ignorować obecność lub brak tego dostawcy w polu allowed_vendors w pytaniach o stawkę, ponieważ nie jest to znaczący sygnał.

12 kwietnia 2016 r.

Co nowego w aplikacji BidResponse

Zaktualizowaliśmy komentarze, aby wyjaśnić, że odpowiedzi XML pobrane za pomocą video_url mogą być zgodne z VAST 2.0 lub 3.0.

11 kwietnia 2016 r.

Co nowego w słownikach RTB

Usunięto przestarzały plik słownika site-lists.txt
W październiku 2015 r. AdX przestał wypełniać pole site_list_id w pytaniach o stawkę, co wyeliminowało potrzebę korzystania ze słownika site-lists.txt. Usunęliśmy go, aby uniknąć nieporozumień.

1 kwietnia 2016 r.

Nowości w protokole RTB w wersji 81

Zaktualizowane komentarze
Zaktualizowaliśmy komentarz do pola creative_index obiektu BidResponseFeedback, aby zaznaczyć, że w odpowiedzi zawsze odwołuje się ono do indeksu reklamy.

30 marca 2016 r.

Nowości w raporcie o stanie fragmentu – aktualizacja zasad dotyczących umów

Szczegółowy stan jest podawany zarówno w przypadku aukcji otwartej, jak i umów.
Ogólnie rzecz biorąc, open_auction_status i deals_status zastępują parametr status, który został wycofany.
Nowe pole serving_restriction podaje szczegółowy stan kontekstowy.
Zastępuje ona wycofaną funkcję disapproval_reason. Pozwalają nam informować o stanie reklamy w konkretnym kontekście, np. że reklama została odrzucona na urządzeniach mobilnych, ponieważ zawiera elementy Flash lub nie może być wyświetlana w Rosji, ponieważ nie została tam jeszcze zweryfikowana.
Dodano nową wartość wyliczeniową Status: CONDITIONALLY_APPROVED
Używa się go wtedy, gdy reklama jest ogólnie zatwierdzona, ale w niektórych kontekstach podlega pewnym ograniczeniom. Większość reklam zostanie conditionALLY_APPROVED w aukcjach otwartych.

29 marca 2016 r.

Nowości w OpenRTB Proto w wersji 2.3.2

Ulepszyliśmy dokumentację kilku pól:
id w: BidRequest i BidResponse; ip, ipv6, carrier, dpidm5 i advertising_id w: Device; Geo w wiadomości; customdata w User; clicktrackers w: Link.

4 marca 2016 r.

Co nowego w protosach OpenRTB

Protokół Google OpenRTB 2.3.1 (już dostępny)
Zawiera najnowszą wersję protokołu OpenRTB z programu Authorized Buyers. Mapowania pól na protokół RTB usługi Authorized Buyers znajdziesz w komentarzach.
Protokół rozszerzeń Google OpenRTB w wersji 1 (obecnie dostępny)
Zawiera rozszerzenia z programu Authorized Buyers używane w protokole OpenRTB.

26 lutego 2016 r.

Nowości w protokole RTB w wersji 80

Zaktualizowano komentarze w polu fixed_cpm_micros umów bezpośrednich.
Zmieniliśmy nazwy wartości wyliczeniowych w polu VideoFormat, aby zwiększyć ich funkcjonalność: VIDEO_FLASH na VIDEO_FLV i VIDEO_HTML5 na VIDEO_MP4.
Do pola VideoFormat dodaliśmy nowe obsługiwane wartości: VPAID_FLASH (SWF) i VPAID_JS (JavaScript).

19 lutego 2016 r.

Nowości w protokołu RTB w wersji 79

Zaktualizowano komentarze do pola placement.

8 lutego 2016 r.

Nowości w protokołu RTB w wersji 78

Dodaliśmy nowe pole miejsca docelowego wideo, które zastąpiło pole inventory_type.
Wiadomość podrzędna wideo w protokole RTB ma teraz pole placement umożliwiające rozróżnienie reklam INSTREAM i PEŁNOEKRANOWYCH. Pole inventory_type zostało wycofane. Powiela informacje znalezione w innym miejscu protokołu RTB.
Do wiadomości podrzędnej boksu reklamowego dodaliśmy nowe pole renderer.
Pole renderer określa, kto kontroluje środowisko (Google czy wydawca), które wysyła żądanie reklamy i wyświetla reklamę. To pole jest ustawiane tylko w przypadku żądań, które zezwalają na reklamy wideo VAST.

29 stycznia 2016 r.

Nowości

Plik snippet-status-report-proto.txt został zaktualizowany do wersji 15
Dodano 2 wartości wyliczeniowe CorrectionType: IN_BANNER_VIDEO_ATTRIBUTE_ADDED i MRAID_ATTRIBUTE_ADDED. Więcej informacji znajdziesz w komentarzach na temat nowych wartości.

18 maja 2015 r.

Nowości

Authorized Buyers zaczyna egzekwować górny limit stawek
Aby chronić siebie i jej partnerów przed błędami i błędami konfiguracji, Authorized Buyers zaczyna egzekwować górny limit CPM w wysokości 5000 USD. Więcej informacji znajdziesz w sekcji Filtrowanie odpowiedzi na stawki.

11 lipca 2014 r.

Nowości

Deklaracja „Mniej Flash” w odpowiedzi na stawkę nie jest już potrzebna
Kupujący nie muszą już deklarować korzystania z kreacji bez Flash podczas ustalania stawek za zasoby reklamowe bez Flasha, ponieważ Authorized Buyers automatycznie wykrywają kreacje bez Flash. Kupujący nadal muszą uwzględniać kreacje bez Flash podczas ustalania stawek za zasoby reklamowe bez Flash. Jeśli w odpowiedzi na pytanie o stawkę nieopartą na technologii Flash kupujący wysyła kreację Flash, usługa Authorized Buyers wykryje obecność kreacji Flash i odfiltruje odpowiedź na stawkę. Pamiętaj, że Authorized Buyers nie wykryje, czy w odpowiedzi na stawkę załączono kreację zapasową bez Flash, a Authorized Buyers odfiltruje tę odpowiedź, aby uwzględnić w niej kreację Flash.
Nazwa pola „encrypted_idfa” została zmieniona na „encrypted_advertising_id”
W Authorized Buyers nazwa pola „Encrypt_idfa” zmieniła się na „encrypted_advertising_id”, dzięki czemu możemy przekazywać kupującym w żądaniu BidRequest identyfikator IDFA lub identyfikator wyświetlania reklam, w zależności od tego, która z nich jest dostępna. Kupujący mogą nadal odwoływać się do pierwotnej nazwy pola „encrypted_idfa”, dopóki nie pobiorą najnowszej wersji protokołu RTB i zaczną korzystać z niej. Gdy kupujący zacznie korzystać z najnowszej wersji protokołu RTB, musi zaktualizować system licytującego, aby jako nową nazwę tego pola nazywał się „encrypted_advertising_id”. Więcej informacji znajdziesz w artykule Kierowanie na zasoby reklamowe w aplikacjach mobilnych za pomocą identyfikatora IDFA.
Nowe pole do określania, czy odtwarzacz wideo jest osadzony
Do protokołu RTB w Authorized Buyers dodano nowe pole, które pozwala określić, czy odtwarzacz jest umieszczony poza witryną źródłową. Nowe pole ma nazwę „is_embedded_offsite”. Jeśli ma wartość prawda, film jest umieszczony na stronach spoza domeny wydawcy. Więcej informacji znajdziesz w przewodniku po integracji wideo z Authorized Buyers.

16 lipca 2013 r.

Nowości

[WAŻNE] W przypadku żądań wielu rozmiarów BidResponses musi zawierać rozmiar reklamy.

W przypadku wszystkich pytań o stawkę, które określają wiele rozmiarów reklam, BidResponse musi zawierać pola BidResponse.Ad.width i BidResponse.Ad.height. Odpowiedzi na pytania o stawkę na żądania o wielu rozmiarach, które nie zawierają tych pól, zostaną usunięte z aukcji. Spodziewamy się, że od 24 września 2013 r. około 5% żądań reklamy będzie zawierać reklamy w różnych rozmiarach, ponieważ 24 września 2013 r. włączymy w DFP alokację dynamiczną dla wielu rozmiarów. Spodziewamy się, że z czasem ten odsetek będzie rósł.

Chociaż odpowiedzi na pytania o stawkę w odpowiedzi na pytania o stawkę z jednym rozmiarem nie muszą zawierać pól Ad.width i Ad.height, zalecamy, aby zawsze je uwzględniać, zgodnie ze sprawdzoną metodą.

[PRZYPOMNIENIE] 9 lipca 2013 r. wycofamy raporty CSV z podziałem na regiony
Po 9 lipca raporty skuteczności w formacie CSV według regionu nie będą już dostępne do pobrania.
[PRZYPOMNIENIE] Rozmiar pliku do pobrania zwiększono do 150 kilobajtów
Zwiększyliśmy maksymalny dozwolony rozmiar pobierania z 50 do 150 KB. Włączymy też automatyczne egzekwowanie tych zasad, dzięki czemu reklamy o rozmiarze przekraczającym 150 KB będą odrzucane. Więcej informacji znajdziesz w dokumentacji w Centrum pomocy.
[PRZYPOMNIENIE] Deklaracja kreacji bez Flash dla zasobów reklamowych w aplikacjach mobilnych
Wszyscy kupujący, którzy uzyskali certyfikat RTB w aplikacji mobilnej MUSZĄ wskazywać, że w odpowiedzi na stawkę reklama nie zawiera Flasha, jeśli odpowiada na wywołanie aplikacji mobilnej. Jeśli brakuje prawidłowych deklaracji dotyczących kreacji, reklama może zostać odrzucona. Więcej informacji znajdziesz w dokumentacji Centrum pomocy.
[PRZYPOMNIENIE] operator_name i operator_country zostaną usunięte z pytań o stawkę
4 czerwca 2013 r. zakończyliśmy oficjalną obsługę pól przewoźnika_name i operator_country w odpowiedzi na żądanie BidRequest. Kupujący powinni wykorzystać nowe pole operatora_id. Więcej informacji znajdziesz w marcowym newsletterze.

20 maja 2013 r.

Nowości

Tabele odpowiedników hostowane przez Google (już dostępne)

Google może teraz przechowywać tabelę odpowiedników kupującego między identyfikatorami kupującego a identyfikatorami plików cookie Google. Zmniejsza to wymagania dotyczące infrastruktury, które muszą spełnić kupujący, aby tworzyć podstawy do dalszych ulepszeń dopasowywania plików cookie. Kupujący mogą teraz za pomocą jednego wywołania dodać użytkownika do co najmniej 1 listy użytkowników i ustawić plik cookie Ad Managera, jeśli nie ma go w ogóle.

Zdecydowanie zalecamy korzystanie z tabel odpowiedników hostowanych przez Google. Oprócz poprawy wydajności i oszczędności w związku z przejściem na nowszą wersję możesz także dołączyć do naszego programu testów beta dopasowywania pikseli, który poprawia współczynnik dopasowania plików cookie średnio o 20–30%. Aby móc skorzystać z tej funkcji, musisz używać tabel odpowiedników hostowanych przez Google. Zachęcamy więc wszystkich kupujących, którzy korzystają z AdX RTB, aby zrobili to jak najszybciej.

Zmiana sposobu dopasowywania plików cookie
7 maja w usłudze Ad Manager zmieni się sposób ustawiania plików cookie doubleclick.net. Domyślnie Ad Manager ustawia plik cookie podczas wszystkich wywołań dopasowywania plików cookie. Jeśli nie chcesz, by Ad Manager umieszczał plik cookie, zmień ustawienia systemu licytującego, aby podczas dopasowywania plików cookie uwzględniał nowy parametr google_no_sc. Więcej informacji o tej zmianie znajdziesz w naszej dokumentacji.
[WAŻNE PRZYPOMNIENIE] 4 czerwca 2013 r. wycofamy dopasowywanie plików cookie w wersji 1
Więcej informacji o tej zmianie znajdziesz w dokumentacji dotyczącej dopasowywania plików cookie lub w poprzednim newsletterze.
[PRZYPOMNIENIE] Zmień wymagania dotyczące funkcji Pixel Match
Od 9 lipca odpowiedzi Pixel Match, które nie będą zawierać określonej wartości google_push, będą usuwane. Ta zmiana pozwoli nam usprawnić rozwiązywanie problemów z opóźnieniami i zwiększyć efektywność dopasowywania pikseli. Szczegółowe informacje znajdziesz w naszym poprzednim newsletterze.
[PRZYPOMNIENIE] AKTUALIZACJA protokołu RTB – nowe pole agencji w odpowiedzi na stawkę
Aby umożliwić kupującym i sprzedającym tworzenie umów preferencyjnych i aukcji prywatnych dla określonej agencji, do parametru BidResponse dodano nowe pole: Agency_id. Utworzyliśmy nowy plik słownika z zaakceptowanymi agencjami w celu zaimplementowania tego pola. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją w Centrum pomocy lub skontaktuj się z technicznym menedżerem konta.
[PRZYPOMNIENIE] Pola geograficzne zostały zastąpione identyfikatorem geo_criteria_id
Wkrótce pola {country, region, city, metro} z protokołu RTB nie będą już przekazywane w pytaniach o stawkę. Te pola zostały zastąpione nowym polem geo_criteria_id. Więcej o tej ważnej zmianie znajdziesz w marcowym newsletterze lub na stronie dla programistów.

15 kwietnia 2013 r.

Nowości

[WAŻNE] Pole seller_network zostało wycofane.
Pole seller_network zostało zastąpione nowym polem seller_network_id, które zawiera liczbę całkowitą odpowiadającą sieci znalezionej w pliku słownika seller-network-ids.txt. Przestaliśmy ustawiać pole seller_network 2 kwietnia 2013 r. Zaktualizuj ustawienia licytującego, tak aby korzystał z nowego pola. Szczególnie dotyczy to zasobów z sieci reklamowej Google, które mają teraz wartość seller_network_id równą 1.
[WAŻNE] Zmień wymagania dotyczące funkcji Pixel Match
W połowie kwietnia zaczniemy przypisywać ciąg znaków do stosowania w adresie URL do parametru google_push w żądaniach dopasowania pikseli. Spodziewamy się zwrócić ten sam ciąg znaków do wykorzystania w adresie URL w ustawionym przez Ciebie parametrze google_push. Ta zmiana ułatwi nam rozwiązywanie problemów z opóźnieniami i poprawi wydajność dopasowywania pikseli.
Aktualizacja protokołu RTB – nowe pole agencji w BidResponse

Aby umożliwić kupującym i sprzedającym tworzenie umów preferencyjnych i aukcji prywatnych dla określonej agencji, dodaliśmy do interfejsu BidResponse nowe pole agency_id. Aby zaimplementować to nowe pole, utworzyliśmy nowy plik słownika agencies.txt z zaakceptowanymi agencjami.

Obsługa tego pola zapewni kupującym większą elastyczność w zakresie ich zautomatyzowanych ofert i pomoże negocjować więcej umów preferencyjnych z wydawcami szukającymi kupujących za pomocą tej funkcji. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją w Centrum pomocy lub skontaktuj się z technicznym menedżerem konta.

Kreacji hostowanych przez Google nie można już używać do określania stawek w czasie rzeczywistym
W przeszłości kupujący mogli używać hostowanych przez Google plików kreacji zarówno w kampaniach korzystających z określania stawek w czasie rzeczywistym, jak i w interfejsie użytkownika. Kupujący, którzy korzystają z RTB, nie mogą już odpowiadać kreacjom hostowanym przez Google. Wszystkie kreacje hostowane przez Google przesłane w polu creative_id przez RTB będą odrzucane. Kreacje hostowane są nadal dostępne dla kupujących korzystających z interfejsu.
Opinia o RTB w czasie rzeczywistym BETA
Aby ułatwić bardziej dynamiczne strategie ustalania stawek, możemy przekazywać w czasie rzeczywistym informacje zwrotne o przyczynach, dla których Twoja stawka nie wygrała, np. o blokowaniu przez wydawcę, niezatwierdzeniu kreacji lub podniesieniu stawki. Rzeczywista przyczyna zostanie przekazana w wiadomości podrzędnej BidResponsefeedback w kolejnym żądaniu BidRequest. Pełna lista możliwych przyczyn znajduje się na stronie pobierania w pliku creative-status-codes.txt. W przypadku przegranych stawek, które przekroczyły podaną cenę minimalną, oraz kreacji, które nie zostały odfiltrowane przed aukcją, zwrócimy cenę niezbędną do wygrania aukcji. W tych ograniczonych testach beta mogą wziąć udział tylko kupujący, którzy wyrazili zgodę na ujawnianie danych o zwycięskich stawkach. Jeśli chcesz z nich korzystać, skontaktuj się z technicznym menedżerem konta.

11 marca 2013 r.

Nowości

[WAŻNE] Wycofujemy dopasowywanie plików cookie w wersji 1
Od 4 czerwca 2013 r. nie będziemy obsługiwać dopasowywania plików cookie w wersji 1. Aby lepiej służyć kupującym, wprowadziliśmy w interfejsie API Cookie Matching wersja 2 bardziej zaawansowane funkcje, takie jak hostowane tabele odpowiedników. Jeśli jeszcze tego nie zrobiłeś, zdecydowanie zalecamy jak najszybsze przejście na nową wersję dopasowywania plików cookie.
[WAŻNE] Zaktualizuj zmianę atrybutu seller_network_id
Jeśli kupujesz zasoby reklamowe, kierując reklamy przy użyciu pola sellers_network_id, pamiętaj, że wprowadziliśmy zmiany w niektórych identyfikatorach w pliku seller-network-ids.txt. Te zmiany wynikają z jednorazowego ponownego indeksowania identyfikatorów, a dotychczasowe mapowania będą trwałe, a kolejne zmiany wprowadzone przez wydawcę będą dodawane na końcu pliku. Uwaga: identyfikator sprzedawcy w sieci reklamowej Google (GDN) reseller_network_id zmienił się z 0 na 1.
Pobierz najnowszy plik słownika z identyfikatorami sieci sprzedawców, aby mieć pewność, że prawidłowo kierujesz reklamy na sieć reklamową Google i inne sieci wydawców w AdX. Jeśli masz pytania, skontaktuj się z menedżerem konta.
[WAŻNE] Wyświetlenia kwalifikujące się do reklam o różnych rozmiarach muszą zawierać w odpowiedzi na stawkę szerokość i wysokość reklamy.
Wydawcy coraz częściej akceptują różne rozmiary reklam w jednym boksie reklamowym. Te wyświetlenia obejmują wiele rozmiarów w polu BidRequest.AdSlot i wymagają zwrócenia pól BidResponse.Ad.width i BidResponse.Ad.height w odpowiednich odpowiedziach na stawkę. Odpowiedzi na stawki w odpowiedzi na żądania reklam o różnych rozmiarach muszą zawierać te pola, ponieważ w przeciwnym razie zostaną automatycznie odfiltrowane z aukcji.
Obecnie wiele pytań o stawkę dla rozmiaru reklam jest dostępnych tylko dla kupujących, którzy w odpowiedzi na stawkę podają pola BidResponse.Ad.width i BidResponse.Ad.height. Stanowi to 3% dostępnych wyświetleń i wzrośnie w II kwartale po udostępnieniu kolejnych zasobów reklamowych przez klientów Ad Managera. Wkrótce utworzymy listę dozwolonych, aby udostępniać te zasoby reklamowe tylko kupującym, którzy ustawili rozmiar reklamy w odpowiedzi na wiele pytań o stawkę za rozmiar reklamy. Jeśli licytujący nie zwraca obecnie pól BidResponse.Ad.width i BidResponse.Ad.height w odpowiedziach na stawkę, zacznij to robić, aby kwalifikować się do korzystania z takich zasobów reklamowych. Aby dowiedzieć się, jak dołączyć do listy dozwolonych, skontaktuj się z menedżerem konta.
[WAŻNE PRZYPOMNIENIE] SSL – zbliżająca się zmiana w wyświetlaniu reklam firm zewnętrznych
Rozpoczynamy obsługę szyfrowanego ruchu SSL (Secure Socket Layer), dzięki czemu partnerzy Authorized Buyers będą mogli oferować naszym klientom dodatkowe typy zasobów reklamowych, w tym pocztę online i inne zasoby reklamowe pochodzące od zalogowanych użytkowników. Zasoby reklamowe SSL są wyjątkowe pod tym względem, że wszystkie kolejne wywołania innych firm po wstępnym żądaniu reklamy również muszą być oparte na protokole SSL – w przeciwnym razie przeglądarka wyświetli ostrzeżenie. Aby zapewnić klientom bezproblemowe korzystanie z AdX, wprowadzamy nowy certyfikat SSL, który potwierdza, że wszystkie technologie kupujących są zgodne z protokołem SSL.
Jak wspomnieliśmy pod koniec października zeszłego roku, pierwsze źródło zasobów reklamowych SSL w AdX będzie pochodzić od zalogowanych użytkowników usług należących do Google i zarządzanych przez Google, takich jak YouTube. Obecnie tylko niewielki odsetek zasobów reklamowych w YouTube obsługuje protokół SSL, ale w maju 2013 roku ta liczba będzie dostępna dla wszystkich zalogowanych użytkowników YouTube, co stanowi około 40% całego ruchu w YouTube. W tym roku liczba zasobów reklamowych zgodnych z protokołem SSL w AdX będzie rosła, bo dodajemy nowe zasoby z poczty online i innych bezpiecznych środowisk.
Zasoby reklamowe zgodne z protokołem SSL będą dostępne tylko dla kupujących, którzy uzyskali certyfikat zgodności z protokołem SSL wydany przez zespół ds. certyfikacji Google. Nie przegap tej okazji – jak najszybciej zacznij wdrażać protokół SSL na swojej platformie RTB i na platformie wyświetlania reklam innej firmy.
Kupujący w czasie rzeczywistym nie muszą używać osobnego identyfikatora Buyers_creative_id w przypadku fragmentów kodu SSL i nieSSL. Więcej informacji znajdziesz w dokumentacji Centrum pomocy.
[PRZYPOMNIENIE] Nowy format plików ustawień wydawcy
Niedawno zmieniliśmy format plików ustawień wydawcy (PSF), aby ułatwić ich przetwarzanie. Nowy format dzieli plik PSF na 2 pliki o wielkości 9 MB, zmniejszając całkowity rozmiar pliku o 60%.
Dodatkowo przejdziemy z pola „id” typu „w bajtach” do pola identyfikatora typu „Fix64”. Obecnie dostępne są oba pola, ale od 2 kwietnia 2013 r. będzie wypełnione tylko pole VAST64 ID.
Pliki PSF dostarczają kupującym informacje o wymaganiach dotyczących zasobów reklamowych poszczególnych wydawców, aby ułatwić licytującym podejmowanie lepszych decyzji. Te zasady zawierają takie informacje jak dozwolone technologie reklamowe, wykluczone kategorie i zablokowane strony docelowe. Jeśli masz pytania, skontaktuj się z technicznym menedżerem konta lub zapoznaj się z dokumentacją określania stawek w czasie rzeczywistym.
[Protokół RTB] PLANOWANIE DZIAŁANIA MAPY – w marcu pojawi się nowe pole agencji w odpowiedzi na stawkę
Wraz z rozwojem automatyzacji kupowania wydawcy coraz częściej chcą zawierać umowy automatyczne bezpośrednio z agencjami. Aby umożliwić kupującym i sprzedawcom tworzenie umów preferencyjnych podzielonych na segmenty według kupującego, agencji lub reklamodawcy, do odpowiedzi na stawkę zostanie dodane nowe pole Agencja. Możliwość tworzenia umów dla agencji zapewnia kupującym większą elastyczność w zautomatyzowaniu kupowania w AdX, ponieważ ogranicza konflikty wydatków z innymi reklamodawcami i agencjami na ich kontach.
Uważamy, że jest to ważna zmiana, która wymaga trochę pracy deweloperskiej, dlatego przesyłamy tę informację, aby dać Ci wystarczająco dużo czasu na zaplanowanie niezbędnych modyfikacji dotyczących licytujących. Zaczniemy akceptować to pole z końcem marca, a pod koniec drugiego kwartału pojawi się ono w umowach preferencyjnych. Obsługa tego pola zapewni kupującym większą elastyczność w ofercie automatyzacji i pomoże negocjować więcej umów preferencyjnych z wydawcami szukającymi kupujących za pomocą tej funkcji.
Gdy to zrobisz, będzie można wypełnić pole Agencja w momencie przesyłania kreacji lub w odpowiedzi na stawkę. Wkrótce podamy więcej informacji na temat wdrożenia nowego pola Agencja. W razie pytań skontaktuj się ze swoim menedżerem konta.
Makra dopasowywania plików cookie są już dostępne
Teraz możesz skonfigurować adresy URL dopasowywania plików cookie za pomocą 1 lub kilku makr, aby określić kolejność i lokalizację, w których parametry dopasowania plików cookie są dodawane do adresu URL. Użycie tych makr zapewnia większą elastyczność i kontrolę w dopasowywaniu plików cookie. Przeczytaj nasz Przewodnik na temat dopasowywania plików cookie, aby dowiedzieć się więcej o nowych makrach i sposobie ich używania.

Wersja z 15 października 2012 r.

Nowości

Nowy szablon typu geo_criteria_id
Od 2 kwietnia 2013 r. pola {country, region, city, metro} protokołu RTB nie będą już przekazywane w żądaniach stawek. Te pola zostaną zastąpione nowym polem geo_criteria_id, którym jest identyfikator reprezentujący lokalizacje geograficzne, który znajdziesz w tabeli Cele w witrynie dla deweloperów. Jeśli masz pytania, skontaktuj się z technicznym menedżerem konta.
[WYMAGANE DZIAŁANIE] Migracja z: seller_network do: seller_network_id
Pole seller_network zostanie zastąpione nowym polem seller_network_id, które zawiera liczbę całkowitą odpowiadającą sieci znajdującej się w pliku słownika seller-network-id.txt na stronie Pobrane. 2 kwietnia 2013 r. przestaniemy ustawiać pole seller_network.
Zaktualizuj licytującego, aby używał nowego pola, zwłaszcza do identyfikowania zasobów reklamowych z sieci reklamowej Google.
[WAŻNE] W przypadku wielu pytań o stawkę dla rozmiaru reklamy należy uwzględnić szerokość i wysokość reklamy
W przypadku wszystkich pytań o stawkę, które zawierają reklamy o różnych rozmiarach, BidResponse musi zawierać pola BidResponse.Ad.width i BidResponse.Ad.height. Odpowiedzi na pytania o stawkę w odpowiedzi na pytania o różnych rozmiarach reklam, które nie zawierają tych pól, zostaną odrzucone z aukcji.
Chociaż pytania o stawkę z jednym rozmiarem reklamy w obiekcie BidRequest.AdSlot nie muszą zawierać pól Ad.width i Ad.height, zalecamy zawsze zadeklarowanie rozmiaru reklamy.

Wersja z 2 lipca 2012 r.

Nowości

Nowe pole protokołu RTB
Pole BidRequest.AdSlot.ad_block_key w protokole RTB zawiera 64-bitową liczbę całkowitą, która zapewnia stabilny identyfikator kombinacji (web_property, boks, strona). To nowe pole umożliwia śledzenie skuteczności konkretnych kombinacji reklam w boksie reklamowym i reklam w boksie, co pozwala podejmować lepsze decyzje dotyczące stawek.
Jeśli masz pytania dotyczące nowego pola BidRequest.AdSlot.ad_block_key, skontaktuj się z technicznym menedżerem konta lub zapoznaj się z dokumentacją dla deweloperów dotyczącą protokołu RTB.
Identyfikator grupy reklam jest wymagany, jeśli element BidRequest ma wiele grup reklam
BidResponse musi zawierać pole billing_id w odpowiedzi na pytanie o stawkę z wieloma grupami reklam. Pytanie o stawkę, które ma wiele pól matching_ad_data (wiadomości podrzędnych), zawiera wiele grup reklam, ponieważ każde pole matching_ad_data zawiera dokładnie jedną grupę reklam.
Do 2 lipca 2012 roku odpowiedź na stawkę musiała zawierać pole billing_id tylko wtedy, gdy licytujący używał hostowanych kreacji lub scalonych strumieni. To wymaganie jest już nieaktualne.
Zbiorcze kierowanie na lokalizację w interfejsie
Narzędzie do zbiorczego przesyłania danych o lokalizacjach, które zwiększa skuteczność strategii kierowania na lokalizację, jest teraz częścią interfejsu Authorized Buyers.

Wersja z 5 czerwca 2012 r.

Nowości

GDN zastąpił(a) GCN jako dozwoloną wartość w polu seller_network
BidRequest wysyła teraz w polu seller_network wartość GDN, zastępując wartość GCN, która została wysłana przed 1 czerwca 2012 r. Zawsze gdy licytujący używa pola seller_network, sprawdź, czy kod jest sprawdzony i w razie potrzeby odpowiednio dostosowany, aby zmiana wartości nie spowodowała problemów.
Interaktywne reklamy wideo typu In-Stream w wersji beta na podstawie standardu VPAID 1.0
Specyfikacja VPAID oznacza „Video Player-Ad Interface Definition” i jest opublikowanym przez IAB standardem interaktywnych reklam wideo typu In-Stream. Rozpoczynamy ograniczoną obsługę reklam VPAID w wersji beta w ramach protokołu RTB i interfejsu. Więcej informacji uzyskasz od swojego opiekuna klienta.
Nowe pole mobile_device_type w: BidRequest
Pytania o stawkę dotyczące zasobów reklamowych na komórki zawierają teraz pole mobile_device_type. Wartość tego pola określa typ urządzenia mobilnego, na którym ma zostać wyświetlona reklama: TABLET lub HIGHEND_PHONE.
Nowa nazwa: umowy preferencyjne (wcześniej znane jako umowy bezpośrednie)
W interfejsie i w Pomocy termin „Umowa bezpośrednia” został zastąpiony przez „Umowa preferencyjna”. W najbliższej przyszłości w odpowiedniej sekcji dokumentacji interfejsu Buyer API typu REST pojawi się nowa nazwa.
Nowa wiadomość w usłudze UserList w grupie BidRequest
Pytania o stawkę mogą zawierać co najmniej jedną wiadomość typu UserList. Każda wiadomość UserList określa listę kierowania na odbiorców, do której użytkownik został dodany, oraz czas, jaki upłynął od jego dodania. Zobacz tematy pomocy w interfejsie kupującego dotyczące remarketingu. Lista kierowania na odbiorców jest nazywana listą remarketingową. Aby poprosić licytującego o korzystanie z tej funkcji, skontaktuj się ze swoim opiekunem klienta.
Przejście pola excluded_sensitive_category z ciągu tekstowego na int32
Licytujący może użyć pola excluded_sensitive_category w protobufach publisher-settings, aby sprawdzić, które kategorie treści są niedozwolone przez wydawców. Jeśli tak, pamiętaj, że to pole jest teraz wysyłane w 2 postaci: powtórzonego ciągu znaków int32 excluded_sensitive_category i ciągu powtórzonego DEPRECATED_excluded_sensitive_category. Zalecamy, aby w dogodnym momencie zmodyfikować licytującego tak, aby obsługiwał formę int32 tego pola. Dzięki temu przygotujesz się na wycofanie ciągu znaków.
Gdy wysyłasz pytania o stawkę bez adresu URL i anonimowego identyfikatora, Authorized Buyers może pominąć Twojego licytującego
Jeśli wolisz, żeby pytania o stawkę, które nie zawierają ani adresu URL strony, ani anonimowego identyfikatora, nigdy nie były wysyłane do licytującego, skontaktuj się z opiekunem klienta w sprawie tej nowej opcji.

Już wkrótce

Zbiorcze kierowanie na lokalizację w interfejsie
Narzędzie do zbiorczego przesyłania danych na temat lokalizacji, które zwiększa skuteczność strategii kierowania na lokalizację, jest stopniowo wdrażane w ramach interfejsu Authorized Buyers.
Identyfikator grupy reklam jest wymagany, gdy element BidRequest ma wiele grup reklam
Od 2 lipca 2012 r. BidResponse musi zawierać pole billing_id w odpowiedzi na pytanie o stawkę z wieloma grupami reklam. Aby sprawdzić, czy pytanie o stawkę ma kilka grup reklam, poszukaj wielu pól matching_ad_data (wiadomości podrzędnych). Każde pole matching_ad_data zawiera dokładnie jedną grupę reklam, więc obecność wielu pól matching_ad_data zawsze oznacza, że istnieje wiele grup reklam.
Po wejściu tych zmian w życie obecne wymaganie (oznaczające, że odpowiedź na stawkę musi zawierać pole billing_id za każdym razem, gdy licytujący używa hostowanych kreacji lub scalonych strumieni) stanie się przestarzały.

Rozwiązane problemy

Raport o stanie fragmentu zawiera teraz oczekiwane kategorie
Raport o stanie fragmentu ma wyświetlać kategorie treści, które znajdują się w pliku słownika ad-product-categories.txt. W niektórych przypadkach raport o stanie fragmentu pokazywał kategorie, których nie ma w pliku słownika. Rozwiązaliśmy ten problem.

Wersja z 11 maja 2012 r.

Nowości

Reklamy są teraz wyświetlane tylko w witrynach, które pasują zarówno do kierowania na tematy, jak i na miejsca docelowe
Wcześniej reklamy wyświetlały się w witrynach, które pasują albo na tematy, albo kierowanie na miejsca docelowe. Obecnie reklamy wyświetlają się tylko w witrynach, które pasują zarówno do tematu, jak i kierowania na miejsca docelowe.
Wielokierunkowe kreacje rozwijane (beta)
Authorized Buyers oferuje obsługę kreacji rozwijanych wielokierunkowo w wersji beta. Wielokierunkowe kreacje rozwijane można rozwijać do maksymalnego rozmiaru rozwiniętego zgodnego ze zaktualizowanymi Zasadami programu.
W Authorized Buyers zasoby reklamowe wideo w grze są już dostępne
Zasoby reklamowe wideo kupowane przez kampanie w Authorized Buyers obejmują teraz zasoby reklamowe wideo w grach oferowane przez wydawców, którzy oferują reklamy Google w grach.
W przypadku każdej kampanii, w której kupujesz reklamy wideo, te miejsca docelowe są automatycznie kupowane, chyba że do kampanii zostanie dodane wykluczenie kategorii „w grze”. Możesz dodać to wykluczenie za pomocą interfejsu Buyer SOAP API i za pomocą usługi CampaignCriterionService dodać parametr NegativeCampaignCriterion typu ContentLabel z parametrem contentLabelType ustawionym jako GAMES. Ta aktualizacja wersji beta funkcji wideo w Authorized Buyers obowiązuje od 1 maja 2012 r.
Wytyczne programu zaktualizowane
Zaktualizowaliśmy wytyczne programu, aby doprecyzować zakres zakazu przekazywania informacji umożliwiających identyfikację osób, poprawić spójność terminologii, usunąć tematy objęte interfejsami API i Warunkami korzystania z protokołów Authorized Buyers, wyjaśnić obsługę w wersji beta kreacji rozwijanych wielokierunkowo oraz wyjaśnić proces wyświetlania reklam firm zewnętrznych, w tym linki do listy zatwierdzonych dostawców technologii i wymagania dotyczące deklarowania dostawców technologii.
Kierowanie wyświetleń reklam wideo według rozmiaru odtwarzacza
W przypadku zasobów reklamowych wideo pola szerokości i wysokości w BidRequest.AdSlot opisują teraz odtwarzacz wideo. Ta aktualizacja dotycząca reklam wideo w Authorized Buyers w wersji beta umożliwia kierowanie wyświetleń wideo według rozmiaru odtwarzacza.

Już wkrótce

Zbiorcze kierowanie na lokalizację w interfejsie
W interfejsie Authorized Buyers stopniowo wprowadzamy nowe narzędzie do zbiorczego przesyłania danych na temat lokalizacji, które może zwiększyć skuteczność strategii kierowania na lokalizację.
GDN, aby zastąpić GCN jako dozwoloną wartość w polu seller_network;
Od 1 czerwca 2012 r. BidRequest będzie wysyłać do pola seller_network wartość GDN, zastępując wartość GCN wysłaną dzisiaj. Zawsze gdy licytujący używa pola seller_network, sprawdź i w razie potrzeby dostosuj kod tak, aby zmiana wartości nie spowodowała problemów.
Identyfikator grupy reklam jest wymagany, gdy element BidRequest ma wiele grup reklam
Od 2 lipca 2012 r. BidResponse musi zawierać pole billing_id w odpowiedzi na pytanie o stawkę z wieloma grupami reklam. Aby sprawdzić, czy pytanie o stawkę ma kilka grup reklam, poszukaj wielu pól matching_ad_data (wiadomości podrzędnych). Każde pole matching_ad_data zawiera dokładnie jedną grupę reklam, więc obecność wielu pól matching_ad_data zawsze oznacza, że istnieje wiele grup reklam.
Po wejściu tych zmian w życie obecne wymaganie (oznaczające, że odpowiedź na stawkę musi zawierać pole billing_id za każdym razem, gdy licytujący używa hostowanych kreacji lub scalonych strumieni) stanie się przestarzały.

Wersja z 30 listopada 2010 r.

  • W elemencie BidRequest znajduje się nowe pole o nazwie cookie_age_seconds. Po ustawieniu wskazuje, kiedy utworzono plik cookie używany w google_user_id.
  • W elemencie BidRequest.AdSlot.MatchingAdData znajduje się nowe pole o nazwie per_buyer_minimum_cpm. Jeśli ma wartość Prawda, to pole wskazuje, że wydawca ustawił minimalny CPM na koncie grupy reklam z kierowaniem wstępnym.
  • Teraz możesz opcjonalnie wyświetlać hostowane kreacje, zamiast zwracać reklamę w formie fragmentu kodu HTML. Więcej informacji znajdziesz w artykule Tworzenie odpowiedzi.
  • Nowa obsługa osobnych i skonsolidowanych strumieni ułatwia kupowanie za pomocą co najmniej 1 platformy DSP z osobnego konta Authorized Buyers. Więcej informacji znajdziesz w artykule Ustalanie stawek w przypadku wielu kont.

Wersja z 14 września 2010 r.

  • Zamiast adresu URL adxrtb.com w interfejsie dostępne jest teraz ustawienie kampanii, które służy do oznaczania kampanii i wszystkich jej grup reklam na potrzeby kierowania wstępnego. Adres URL adxrtb.com będzie działać do czasu, aż we wszystkich istniejących kampaniach zastosujemy nowe ustawienie. Reklamy zastępcze są nadal wymagane w grupach reklam z kierowaniem wstępnym, które korzystają z nowego ustawienia. Mimo to wymagają określenia docelowego adresu URL. Teraz możesz jednak opcjonalnie użyć rzeczywistego adresu URL, który odpowiada reklamie zastępczej we fragmencie kodu HTML. Możesz też nadal używać adresu URL adxrtb.com na potrzeby reklamy zastępczej, ale pamiętaj, że potrzebne jest też ustawienie kampanii. Pamiętaj, że jeśli używasz ustawień kampanii, grupy reklam z kierowaniem wstępnym i bez niego nie mogą występować w tej samej kampanii.
  • Dostępne są teraz raporty automatyczne, które zawierają informacje, które pomagają poznać skuteczność systemu licytującego. Raporty te są wysyłane e-mailem na adres podany mniej więcej co godzinę. Jeśli chcesz włączyć te raporty, skontaktuj się z technicznym menedżerem konta.

Wersja z 17 czerwca 2010 r.

  • Usługa dopasowywania plików cookie obsługuje teraz protokół HTTPS. Możesz teraz wysłać żądanie do cm.g.doubleclick.net za pomocą protokołu HTTPS zamiast HTTP. W takim przypadku przekierowanie zostanie przekierowane pod ten sam skonfigurowany adres URL, ale będzie też korzystać z protokołu HTTPS zamiast HTTP.
  • W elemencie BidRequest znajduje się nowe pole timezone_offset, które wskazuje wykrytą strefę czasową przeglądarki użytkownika (jeśli jest dostępna). Pobierz najnowszą wersję realtime-bidding.proto ze strony Pobrane, przeczytaj komentarze w nowym polu i wprowadź wymagane zmiany w aplikacji.
  • Dodajemy więcej etapów weryfikacji i weryfikacji w przypadku reklam wyświetlanych w czasie rzeczywistym (RTB). Aby mieć pewność, że Twoje reklamy zostaną zatwierdzone do wyświetlania w odpowiednim czasie, zadbaj o to, by mogły się prawidłowo renderować przez dłuższy czas po pierwotnym wyświetleniu. Anomalie i niespójności mogą czasem prowadzić do długich opóźnień lub odrzucenia produktów.

Wersja z 14 kwietnia 2010 r.

  • Informacje w części strony widocznej na ekranie są teraz dostępne w nowym polu slot_visibility. Nowa definicja bufora protokołu jest dostępna na stronie Pobrane pliki.
  • W nadchodzących miesiącach będziemy stopniowo przechodzić na nową taksonomię branżową. Nowy plik taksonomii jest dostępny na stronie Pobrane pliki, a do BidRequest dodano nowe pole vertical_dictionary_version, które wskazuje, kiedy nowa taksonomia ma być używana.
  • Teraz można wstawiać wartość pola google_user_id z BidRequest do adresu URL stawki. Możesz to zrobić, korzystając z makra GOOGLE_USER_ID. Więcej informacji znajdziesz w artykule o makrach adresów URL stawek.
  • Przypominamy, że dla żądań, które w polu BidRequest ustawiono pole is_ping, należy zawsze zwracać prawidłową wartość BidResponse z wartością protocol_version i processing_time_ms. To pomoże nam śledzić lokalizacje, które mogą docierać do Twojego licytującego, i wprowadzać na bieżąco wprowadzanie zmian w konfiguracji.

Wersja z 10 marca 2010 r.

z przyjemnością informujemy o nowym ulepszeniu usługi Authorized Buyers, które znacznie zwiększy ilość zasobów reklamowych dostępnych dla kupujących korzystających z określania stawek w czasie rzeczywistym. Zasoby reklamowe wydawcy, które ograniczają wyświetlanie reklam należących do co najmniej 1 „kategorii o charakterze kontrowersyjnym” (np. polityka, randki, religia, utrata wagi), są teraz dostępne w ramach RTB. Aby zachować zgodność z ograniczeniami dotyczącymi wydawców, Google klasyfikuje reklamy kupującego na podstawie treści strony docelowej. Klasyfikacja ta będzie przeprowadzana po każdym wykryciu nowej strony docelowej reklamy w 10-minutowych odstępach. W związku z tym przez krótki czas nowe reklamy mogą nie kwalifikować się do wyświetlania.

W połączeniu z siecią partnerską Google program Authorized Buyers zapowiada nową funkcję, która pozwala kupującym odfiltrowywać zasoby reklamowe w witrynach sieci partnerskiej Google w części ekranu widocznej po przewinięciu. Nowy filtr umożliwia wyświetlanie reklam tylko w miejscach widocznych na ekranie po załadowaniu strony, bez konieczności jej przewijania. Firma Google wdrożyła rozwiązanie oparte na statystykach w celu określenia, które reklamy znajdują się w części strony widocznej na ekranie, a które w części ekranu widocznej po przewinięciu. Model statystyczny uwzględnia reklamy w części strony widocznej na ekranie tylko wtedy, gdy są one w całości widoczne na ekranie po załadowaniu okna przeglądarki. Celem, który przyświecał nam podczas opracowywania nowej funkcji, było zapewnienie reklamodawcom większej kontroli nad miejscami wyświetlania ich reklam oraz zoptymalizowanie środowiska sieci partnerskiej Google pod kątem skuteczności i skuteczności kampanii promujących markę.

Kupujący, którzy korzystają z rozwiązania RTB, mogą w interfejsie wykluczać zasoby reklamowe w części strony widocznej po przewinięciu. Oprócz tej funkcji filtrowania każde pytanie o stawkę będzie zawierać informacje o lokalizacji jednostki reklamowej – w części strony widocznej na ekranie, w części strony widocznej po przewinięciu lub w nieznanej części strony. Dane te mogą się przydać przy obliczaniu stawki. Informacje znajdują się w nowym polu slot_visibility w BidRequest. Zaktualizowana definicję bufora protokołu znajdziesz na stronie Pobrane pliki.

Ponadto wprowadziliśmy następujące zmiany:

  • Ustawienia ograniczenia liczby wyświetleń w kampaniach z kierowaniem wstępnym są teraz uwzględniane przy podejmowaniu decyzji o wysyłaniu pytań o stawkę. Wcześniej wszystkie takie ustawienia wprowadzone w interfejsie były ignorowane.
  • Teraz możemy wysyłać prośby do licytujących w Europie. Ta opcja jest dostępna dla nowych klientów w zwykłym procesie testowania. Jeśli korzystasz już z określania stawek z innych lokalizacji, ale masz też serwery w Europie, nie musisz przeprowadzać dalszych testów. W takim przypadku zapytaj menedżera konta ds. technicznych o skonfigurowanie limitu.
  • W przypadku zasobów reklamowych wydawców, którzy korzystają z wykluczeń kategorii, możesz teraz określać stawki w czasie rzeczywistym. Aby ustalać stawki za te zasoby reklamowe, musisz zadeklarować kategorie w odpowiedzi na stawkę. W przeciwnym razie stawki zostaną usunięte.
  • System wysyła teraz niewielką liczbę BidRequests z polem is_ping ustawionym na „true”
  • Skrypt żądający został zaktualizowany na kilka sposobów, aby:
    • Pozostaw otwarte połączenia HTTP
    • uzupełnić wszystkie nowe pola wprowadzone w ostatnich wersjach usługi,
    • Opcjonalnie możesz określić zestaw google_user_ids do wysłania w BidRequests.
    • Wysyłanie 1% żądań z wartością is_ping true (prawda)
  • Na stronie Pobrane jest dostępna zaktualizowana wersja aplikacji vendors.txt.
  • W tej chwili nadal musisz poprosić technicznego menedżera konta o wprowadzenie zmian w limitach. Jeśli chcesz zwiększyć ruch, skontaktuj się z technicznym menedżerem konta i poproś o zwiększenie limitu.

Wersja z 24 lutego 2010 r.

Do interfejsu BidRequest dodano 2 pola publisher_settings_list_id. Jedna na poziomie strony, a druga na poziomie boksu. Obie wartości przekazują wartości, których można używać jako kluczy do wyszukiwania wpisów na listach ograniczeń dotyczących wydawców. Aby dowiedzieć się więcej, skontaktuj się z technicznym menedżerem konta.

W BidRequest pojawi się nowe pole seller_network. W przypadku nieanonimowych zasobów reklamowych (np. zasobów, w których przypadku ustawiono pole adresu URL) to pole jest wypełniane nazwą sieci sprzedającej wyświetlenie. Na przykład wszystkie zasoby reklamowe z sieci partnerskiej Google będą miały to pole wypełnione wartością „GCN”.

Ustawienie na poziomie konta wymienione w informacjach o wersji z 27 stycznia 2010 r. jest teraz aktywne. Jeśli chcesz zmienić to ustawienie, zapoznaj się z opisem w poprzednich uwagach i skontaktuj się z menedżerem konta.

Nowy plik provider.txt jest dostępny na stronie Pliki do pobrania. Zawiera ona więcej dostawców niż w poprzedniej wersji. Wszystkie identyfikatory z poprzedniej wersji są nadal prawidłowe.

W BidResponse pojawi się nowe pole kategorii. Aby dowiedzieć się, jak korzystać z tej nowej funkcji, przeczytaj komentarze w tym polu oraz w polu excluded_category w BidResponse. Na stronie Pobrane jest też nowy plik ad-categories.txt ze zaktualizowanymi kodami kategorii.

Zanim opublikujesz zmiany w systemie licytującym, na potrzeby testów użyj najnowszej wersji narzędzia zgłaszającego ze strony Pliki do pobrania.

Przypominamy, aby poprawnie zadeklarować wszystkie adresy URL reklam w polu click_through_url w polu BidResponse zgodnie z opisem w artykule Deklarowanie docelowych adresów URL w reklamach w Centrum pomocy. Pamiętaj, że musisz podać pełny protokół adresu URL (na przykład http://www.example.com, a nie www.example.com).

Wersja z 27 stycznia 2010 r.

Pole realtime-bidding.proto zawiera kilka nowych pól, a niektóre z nich zostały wycofane. Pobierz najnowszą wersję, przeczytaj komentarze we zmienionych polach i wprowadź niezbędne aktualizacje w aplikacji.

Zachęcamy do pobrania najnowszej wersji programu requester.tar.gz i używania go do testów za każdym razem, gdy wprowadzisz zmiany w programie określania stawek.

Adresy URL stawek według regionu są teraz obsługiwane. Skontaktuj się z nami, jeśli chcesz skonfigurować inny adres URL w każdym regionie (np. jeden na zachodnim i wschodnim).

W kolejnej wersji dodamy ustawienie na poziomie konta, które pozwala określić preferencję wysyłania wyświetleń jako anonimowych lub markowych (jeśli jest możliwy wybór). Wyświetlenia anonimowe często mają niższe minimalne progi CPM ustawione przez sprzedawcę, ale zamiast adresu URL witryny będą miały anonimowy identyfikator, a nie adres URL witryny. Wyświetlenia związane z marką zawierają adres URL witryny, ale mogą mieć wyższy minimalny próg CPM. Domyślnie ustawienie to będzie oznaczone marką. Jeśli chcesz, aby to ustawienie było inne niż domyślne, skontaktuj się z nami.