Protected Audience API (wcześniej FLEDGE)

W ramach Piaskownicy prywatności Chrome zaproponował interfejs Protected Audience API – interfejs w przeglądarce, który umożliwia reklamodawcom i firmom z branży technologii reklamowych wyświetlanie reklam kierowanych na grupy zainteresowań bez konieczności korzystania z plików cookie innych firm, a jednocześnie chroni użytkowników przed śledzeniem w różnych witrynach.

Chrome prowadzi testowanie origin interfejsu Protected Audience API. Partnerzy Authorized Buyers mogą uczestniczyć w testowaniu interfejsu Protected Audience API w zasobach reklamowych wydawcy w usłudze Ad Manager. Dzięki testowaniu interfejsu Protected Audience API oferenci mogą:

  • Iteracyjne testowanie skuteczności przepływów interfejsu Protected Audience API i zdobywanie wiedzy na ten temat.
  • Przekazywać opinie o potencjalnych ulepszeniach interfejsu API na forach publicznych, np. na GitHub.
  • Przygotuj się na obsługę reklam spersonalizowanych za pomocą interfejsu API bez korzystania z plików cookie innych firm.

Kupujący korzystający z usługi Authorized Buyers, którzy chcą przetestować tę funkcję, powinni zapoznać się ze szczegółami w sekcji Wprowadzenie.

Podsumowanie procesu wyświetlania

Oto podsumowanie procesu wyświetlania reklam w ramach Protected Audience API w przypadku partnerów korzystających z usługi Authorized Buyers:

Diagram przepływu

  1. Podmiot składający oferty współpracuje z reklamodawcami, aby utrzymywać grupy zainteresowań dla każdego z nich. Reklamodawcy często dodają tag licytującego do strony reklamodawcy, aby dodać przeglądarkę do grup zainteresowań.
  2. Użytkownik odwiedza stronę reklamodawcy. Strona może zawierać tag reklamodawcy.
  3. Tag reklamodawcy wywołuje interfejs Protected Audience APIjoinAdInterestGroup(). To wywołanie powoduje dodanie użytkownika do grupy zainteresowań przez przeglądarkę.
  4. Użytkownik odwiedza stronę wydawcy. Przeglądarka użytkownika wysyła żądanie tagu reklamy wydawcy Google.
  5. Tag reklamy wydawcy Google wysyła do serwera Google żądanie reklamy kontekstowej.
  6. Google wysyła do uczestniczących systemów licytujących pytania o stawkę kontekstową. Więcej informacji znajdziesz w sekcji dotyczącej zmian w żądaniach stawek.
  7. Licytujący zwraca odpowiedź na stawkę zawierającą komunikat InterestGroupBidding, który jest potrzebny do wzięcia udziału w aukcji grupy zainteresowań. W protokole OpenRTB jest to określone za pomocą pola BidResponse.ext.igbid, a w wycofanym protokole RTB od Google – za pomocą pola BidResponse.interest_group_bidding. Jeśli system licytujący nie poda tych informacji, Google nie uwzględni jego pochodzenia w interestGroupBuyers w konfiguracji aukcji. InterestGroupBidding może też zawierać opcjonalne sygnały specyficzne dla kupującego, które zostaną przekazane do funkcji ustalania stawek licytującego podczas aukcji w przeglądarce. W protokole OpenRTB jest to określone za pomocą pola BidResponse.ext.igbid.igbuyer.buyerdata, a w wycofanym protokole RTB Google za pomocą pola BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Więcej informacji znajdziesz w sekcji dotyczącej zmian w odpowiedzi na stawkę.
  8. Google przeprowadza aukcję po stronie serwera i zwraca do przeglądarki odpowiedź na stawkę. Aukcja po stronie serwera uwzględnia tradycyjne stawki po stronie serwera. Odpowiedź na pytanie o stawkę może zawierać informacje o kontekstowej wygrywającej stawce (jeśli taka istnieje).
  9. Odpowiedź na stawkę zawiera konfigurację aukcji w przeglądarce. Mogą to być sygnały kontekstowe od każdego uczestniczącego kupującego (wcześniej wysyłane za pomocą protokołu OpenRTB buyerdata lub wycofanego protokołu Google RTB per_buyer_signals), informacje o zwycięzcy kontekstowym oraz ustawienia kwalifikowania się do składania stawek.
  10. Tag wydawcy Google wywołuje interfejs Protected Audience APIrunAdAuction(), aby rozpocząć aukcję na urządzeniu dotyczącą grup zainteresowań. Google uwzględnia tylko kupujących, którzy zostali dodani jako InterestGroupBuyer w InterestGroupBidding podczas konfigurowania aukcji.
  11. Google przekazuje opcjonalne sygnały specyficzne dla kupującego każdego kwalifikującego się oferenta do konfiguracji aukcji Protected Audience.
  12. Jeśli grupy zainteresowań danego oferenta określiły trustedBiddingSignalsUrl, przeglądarka wysyła żądanie do każdego trustedBiddingSignalsUrl grupy, aby pobrać sygnały w czasie rzeczywistym dla każdej grupy. Szczegółowe informacje znajdziesz w specyfikacji interfejsu Protected Audience API.
  13. Przeglądarka wywołuje funkcję generateBid() licytującego dla każdej grupy zainteresowań, która wyraziła zgodę na udział w aukcji w przeglądarce i spełnia wymagania. Ten krok oblicza stawkę i wybiera kreację. generateBid() ma dostęp do opcjonalnych sygnałów kupujących dostarczanych przez licytującego oraz do sygnałów zaufanego określania stawek w przypadku danej grupy zainteresowań.
  14. Przeglądarka wywołuje funkcję scoreAd() sprzedawcy (w tym przypadku Google), aby przypisać rangę do każdej stawki w aukcji reklam w grupach zainteresowań. Stawki są klasyfikowane i filtrowane na podstawie zabezpieczeń wydawcy, zasad dotyczących reklam i innych ograniczeń.
  15. Przeglądarka przeprowadza aukcję z kwalifikującymi się stawkami za reklamy kierowane na określoną grupę zainteresowań. W aukcji w przeglądarce bierze udział najwyżej oceniona stawka kontekstowa.
  16. Po aukcji, jeśli wygrała grupa zainteresowań, przeglądarka wywołuje funkcje reportResult() sprzedawcy i reportWin() reklamodawcy, aby powiadomić każdą ze stron o zwycięzcy aukcji w przeglądarce.
  17. Jeśli wygra reklama grupy zainteresowań, tag wydawcy Google renderuje ją w ramce iframe.

Szczegóły przepływu obsługi

Przed wyświetleniem reklamy

Sprawdzanie kreacji

Zanim kreacje zaczną się wyświetlać w ramach aukcji w przeglądarce Protected Audience, muszą zostać sprawdzone i zatwierdzone przez Google. Kreacje możesz przesyłać do sprawdzenia za pomocą interfejsu Real-Time Bidding API lub automatycznego skanowania kreacji. Kreacje na potrzeby aukcji reklam kierowanych na grupy zainteresowań w ramach Protected Audience API w przeglądarce muszą zawierać renderUrls do sprawdzenia.

Wymagania dotyczące renderUrls:

  • Wartość renderUrl przesłana przez interfejs API powinna być zgodna z wartością renderUrl używaną w aukcji reklam w grupie zainteresowań.
  • Każdy renderUrl może reprezentować tylko jednego reklamodawcę lub jedną kampanię reklamową. Dany renderUrl nie może być używany do wyświetlania reklam w imieniu wielu reklamodawców. Każdy renderUrl musi być powiązany z jedną kreacją.
  • renderUrl musi być dostępny i możliwy do pobrania przez systemy weryfikacji kreacji offline Google przez maksymalnie 7 dni od ostatniego złożenia oferty za reklamę.
Real-time Bidding API

Uczestnicy aukcji mogą używać interfejsu Real-time Bidding API do przesyłania kreacji na potrzeby określania stawek za grupy zainteresowań.

Automatyczne skanowanie kreacji

Licytujący mogą skonfigurować automatyczne skanowanie kreacji, które nie zostały przesłane za pomocą interfejsu Real-time Bidding API.

Jeśli skonfigurujesz automatyczne skanowanie kreacji, Google znajdzie kreacje w aukcji w przeglądarce i automatycznie je przeskanuje, aby mogły brać udział w przyszłych aukcjach.

Aby włączyć automatyczne skanowanie kreacji:

  • Dodaj wszystkie renderUrlpochodzenia kreacji grupy zainteresowań na konto Autoryzowanego kupującego.

  • Dodaj do odpowiedzi HTTP kreacji te niestandardowe nagłówki HTTP:

    Authorized-Buyers-Creative-ID

    string

    Identyfikator kreacji kupującego. Maksymalna długość identyfikatora kreacji to 128 bajtów.
    Authorized-Buyers-Click-Through-URLs

    string

    Zestaw zadeklarowanych docelowych adresów URL kreacji zakodowanych zgodnie ze standardem RFC2396.

Przykład:

HTTP/1.1 200 OK
Date: Mon, 8 Jan 2022 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Mon, 8 Jan 2022 12:01:53 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
Authorized-Buyers-Creative-ID:123456
Authorized-Buyers-Click-Through-URLs:https://www.advertiser.com/clickUrl1,https://www.advertiser.com/clickUrl12

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Wygaśnięcie kreacji

Kreacje są zatwierdzane na 15 dni. Jeśli przesyłasz kreacje za pomocą interfejsu Real-Time Bidding API, musisz ponownie przesłać kreację po 15 dniach. Jeśli korzystasz z automatycznego skanowania kreacji, proces skanowania automatycznie skanuje je ponownie.

Identyfikator klienta na potrzeby raportów

Możesz podzielić dane raportowania (np. wyświetlenia) za pomocą wymiarów podanych przez kupującego (np. identyfikatora kampanii lub identyfikatora reklamodawcy). Aby dodać wymiar wydatków grupy zainteresowań, podczas dodawania urządzenia użytkownika do grupy zainteresowań określ buyerAndSellerReportingId w przypadku reklamy. Więcej informacji znajdziesz w dokumentacji interfejsu Protected Audience API.

Oto przykład dodawania symbolu buyerAndSellerReportingId do konfiguracji grupy zainteresowań:

const myGroup = {
  ...
  'ads': [
    {
      ...
      'buyerAndSellerReportingId':
        '{"google_signals": {"buyer_reporting_id": "12345"}}',
      ...
    }
  ]
}
joinAdInterestGroup(myGroup);

W Narzędziu raportowania dla autoryzowanych kupujących symbol buyer_reporting_id będzie widoczny jako nowy wymiar o nazwie Wymiar identyfikatora raportowania kupującego.

Aukcja po stronie serwera

Zmiany w pytaniach o stawkę

Oto wczesne wersje obsługiwanych protokołów, które można wykorzystać w eksperymencie:

Wskazywanie obsługi aukcji powiązanych z grupami zainteresowań

W prośbach o stawkę pojawiły się nowe pola wskazujące obsługę aukcji grup zainteresowań:

  • OpenRTB:
    • BidRequest.imp.ext.ae
    • BidRequest.imp.ext.igbid
  • Protokół RTB Google (wersja wycofana):
    • BidRequest.adslot.supported_auction_environment
    • BidRequest.adslot.interest_group_bidding_allowed

To pole umożliwia rozróżnianie możliwości wyświetlenia, które obsługują aukcję w przeglądarce z użyciem grup zainteresowań Protected Audience API, od tych, które obsługują tylko tradycyjną aukcję na giełdzie po stronie serwera. AuctionEnvironment enum może mieć te wartości:

  • SERVER_SIDE_AUCTION (OpenRTB JSON: 0): aukcja, która wyłania zwycięską reklamę, jest przeprowadzana na serwerach giełdy.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): żądania z obsługą Protected Audience API, w których aukcja kontekstowa jest przeprowadzana na serwerach platformy wymiany, a licytowanie w grupach zainteresowań i końcowa aukcja są przeprowadzane w przeglądarce.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): aukcja kontekstowa odbywa się na serwerach giełdy, a logika określania stawek w przypadku stawek za grupy zainteresowań i logika oceny służąca do określania ostatecznej zwycięskiej reklamy są uruchamiane na serwerach określania stawek i aukcji.
Określanie rozmiaru boksu reklamowego w ramach Protected Audience API

Pytanie o stawkę zawiera te pola, które podają rozmiar miejsca na reklamę Protected Audience:

  • OpenRTB:
    • BidRequest.imp.ext.interest_group_auction.width
    • BidRequest.imp.ext.interest_group_auction.height
  • Protokół RTB Google (wersja wycofana):
    • BidRequest.adslot.interest_group_auction.width
    • BidRequest.adslot.interest_group_auction.height

Te pola wskazują rozmiar boksu reklamowego na potrzeby aukcji Protected Audience w pikselach.

Ten rozmiar może się różnić od rozmiarów w pytaniu kontekstowym, np. od rozmiarów w polach BidRequest.imp.banner.format.w i BidRequest.imp.banner.format.h protokołu OpenRTB lub w polach BidRequest.adslot.width i BidRequest.adslot.height wycofanego protokołu Google RTB.

Żądanie kontekstowe może dotyczyć wielu rozmiarów. Reklama wygrywająca aukcję na urządzeniu powinna wypełniać tylko jedno miejsce o stałym rozmiarze.

Wskazywanie możliwości renderowania reklam Protected Audience

Reklamy Protected Audience mogą się wyświetlać lub nie w zależności od bieżącego etapu integracji (patrz eksperyment z niewyświetlaniem). Pole render_interest_group_adsw żądaniu stawki wskazuje, czy zwycięska reklama Protected Audience API zostanie wyrenderowana.

  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Protokół RTB Google (wersja wycofana): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Ograniczanie zależności od identyfikatorów użytkowników

Kontekstowe żądania stawek objęte testami Protected Audience API mogą nadal zawierać tradycyjne identyfikatory oparte na plikach cookie, jeśli są dostępne w przeglądarce, np. pola BidRequest.user.id i BidRequest.user.buyerid lub BidRequest.google_user_id i BidRequest.hosted_match_data w wycofanym protokole Google RTB. Obecność takich identyfikatorów w żądaniach stawek podlega obowiązującym zasadom ochrony prywatności. Podczas testów nie zalecamy korzystania z identyfikatorów opartych na plikach cookie na potrzeby kierowania i określania stawek. Pozwoli to lepiej przygotować się do efektywnego kupowania, gdy zewnętrzne pliki cookie nie będą już dostępne.

Google może też przeprowadzać eksperymenty na małą skalę, w ramach których identyfikatory oparte na plikach cookie są usuwane z żądań stawek objętych testowaniem interfejsu Protected Audience API. Ma to na celu ocenę potencjalnego wpływu wycofania plików cookie innych firm.

Aby przygotować się na wycofanie plików cookie innych firm (3PCD) w 2024 roku, Chrome oferuje teraz testy ułatwione przez Chrome.

Witryny i dostawcy mogą używać testów ułatwianych przez Chrome, aby testować swoje systemy w ramach 3PCD. W ramach testu przeglądarki Chrome są przypisywane do grupy eksperymentalnej 3PCD w Trybie A lub Trybie B. Każdej przeglądarce przypisana jest spójna etykieta odpowiadająca konkretnej grupie eksperymentalnej 3PCD, do której możesz uzyskać dostęp za pomocą interfejsu Chrome API w przeglądarce.

Google przekazuje niezmodyfikowaną etykietę z interfejsu Chrome API w żądaniu stawki w czasie rzeczywistym. Ze względu na niewielkie fragmenty ruchu poszczególnych etykiet Google nie zawsze uwzględnia etykietę w kontekstach z ograniczeniami dotyczącymi prywatności.

Etykietę możesz zobaczyć w tych polach:

  • OpenRTB: BidRequest.device.ext.cdep
  • Protokół RTB Google (wersja wycofana): BidRequest.device.cookie_deprecation_label

Zmiany odpowiedzi na stawkę

Wskazywanie udziału w aukcji powiązanej z grupą zainteresowań

Użytkownik jest odpowiedzialny za wyraźne wskazanie zamiaru uczestniczenia w aukcji w przeglądarce przez zwrócenie obiektu InterestGroupBidding w odpowiedzi na pytanie o stawkę kontekstową:

  • OpenRTB: BidResponse.ext.igbid
  • Protokół RTB Google (wersja wycofana): BidResponse.interest_group_bidding

Musisz podać odpowiedź na pytanie o stawkę kontekstową. Odpowiedź nie musi zawierać stawki kontekstowej. Obiekt InterestGroupBidding powinien zawierać parametr origin dla każdego parametru InterestGroupBuyer, który powinien być zgodny z jednym z pochodzeń skonfigurowanych przez reklamodawcę dla jego konta. Symbol origin jest dodawany do interestGroupBuyers konfiguracji aukcji, gdy tag wydawcy Google wywołuje runAdAuction().

Przekazywanie sygnałów kontekstowych kupującego

W odpowiedzi na stawkę kontekstową możesz uwzględnić sygnały kupującego, które Google przekazuje jako obiekt JSON do funkcji określania stawek na urządzeniu za pomocą argumentu perBuyerSignals. Można to uwzględnić w odpowiedzi na stawkę w tych polach, w zależności od protokołu:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • Google RTB (wersja wycofana): BidResponse.interest_group_bidding.per_buyer_signals
Przekazywanie sygnałów renderowania kontekstowego kupującego

Kreacje grup zainteresowań mogą podczas renderowania używać ograniczonych sygnałów kontekstowych, wysyłając je w odpowiedzi na pytanie o stawkę kontekstową i otrzymując je w żądaniu adresu URL renderowania za pomocą rozwinięcia makra. Sygnały renderowania mogą na przykład służyć do dostosowywania wyglądu kreacji w celu zwiększenia skuteczności w kontekście danego boksu reklamowego lub strony wydawcy.

W odpowiedzi na kontekstową stawkę możesz umieścić sygnały renderowania kupującego serializowane jako bezpieczny dla adresu URL ciąg znaków. Google zastąpi go w adresie URL renderowania wygrywającej grupy zainteresowań, tworząc ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}makro.

Sygnały renderowania można określić w odpowiedzi na stawkę za pomocą tych pól, w zależności od protokołu:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.rsig
  • Google RTB (wersja wycofana): BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals

W odpowiedzi na licytację można uwzględnić maksymalnie 3 zestawy sygnałów renderowania z różnymi sufiksami makr, aby odróżnić różne sygnały. Na przykład sufiks może służyć do dopasowywania określonego zestawu sygnałów, które mają zastosowanie tylko do kreacji z odpowiednim makrem w adresie URL renderowania, co zmniejsza rozmiar przesyłanych danych.

Kupujący z grupy zainteresowań zostanie odrzucony z udziału w aukcji Protected Audience, jeśli sygnały nie są bezpieczne dla adresu URL, sufiksy makr nie są unikalne lub podano więcej niż 3 zestawy sygnałów.

Określanie maksymalnej stawki w przeglądarce

W propozycji dotyczącej Protected Audience obliczanie stawek i końcowa aukcja mają być przeprowadzane lokalnie na urządzeniu. Może to stwarzać potencjalne możliwości nadużyć, które mogą wpływać na integralność ostatecznych wyników aukcji, np. na cenę zwycięskiej stawki.

W ramach środków zaradczych obsługiwanych podczas testowania interfejsu Protected Audience API przez Google na potrzeby partnerów RTB możesz określić oczekiwaną maksymalną wartość stawki w każdej odpowiedzi na stawkę kontekstową. Oczekiwana maksymalna stawka to maksymalna cena stawki, którą powinna zwrócić funkcja ustalania stawek. Jeśli wygrywająca stawka zgłoszona z aukcji w przeglądarce przekracza tę kwotę, nie jest ona liczona jako zdarzenie podlegające rozliczeniu. To podejście może ulec zmianie.

W odpowiedzi na stawkę możesz określić oczekiwaną maksymalną wartość stawki w tych polach:

  • OpenRTB: BidResponse.igbid.igbuyer.maxbid(wyrażona w jednostkach waluty CPM)
  • Protokół RTB od Google (wycofany): BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (wyrażony w mikroCPM)
Przypisywanie wyświetleń do wielu kont

Aby przypisać wyświetlenia do stawki za grupę zainteresowań, reklamodawca musi wybrać identyfikator rozliczeniowy, korzystając z tych pól:

  • OpenRTB: BidResponse.igbid.igbuyer.billing_id
  • Protokół RTB od Google (wycofany):BidResponse.interest_group_bidding.interest_group_buyers.billing_id

Wybrany identyfikator płatności musi być kwalifikującym się identyfikatorem płatności z żądania stawki:

  • OpenRTB: BidRequest.imp.ext.billing_id
  • Protokół RTB od Google (wycofany):BidRequest.adslot.matching_ad_data.billing_id

Jeśli nie podasz identyfikatora rozliczeniowego, do którego mają być przypisywane wyświetlenia z określaniem stawek za grupy zainteresowań, uczestnik aukcji nie będzie brać udziału w aukcji Protected Audience API.

Konta podrzędne mogą mieć maksymalnie 2 identyfikatory rozliczeniowe. Kupujący może używać jednego identyfikatora rozliczeniowego w przypadku wydatków na reklamę kontekstową, a drugiego – w przypadku wydatków na reklamę w grupach o podobnych zainteresowaniach. Jeśli chcesz skonfigurować 2 identyfikatory rozliczeniowe na koncie podrzędnym, skontaktuj się z menedżerem konta.

Dla każdego identyfikatora rozliczeniowego można ustawić budżet dzienny. Skontaktuj się ze swoim menedżerem konta, aby ustawić budżet dzienny dla identyfikatorów rozliczeniowych kont podrzędnych.

Identyfikatory rozliczeniowe wszystkich kont podrzędnych z dostępnym budżetem, które kwalifikują się do licytowania wyświetlenia, pojawiają się w żądaniu stawki w celu wyboru atrybucji wydatków. Aby zmodyfikować budżet identyfikatora rozliczeniowego grupy zainteresowań, skontaktuj się z menedżerem konta.

Podczas aukcji w przeglądarce

Generowanie stawek w przeglądarce

Użyj generateBid(), aby generować stawki w przeglądarce.

Google udostępnia te parametry:

  • auctionSignals: Puste
  • perBuyerSignals: obiekt JavaScript zawierający te same sygnały, które dostawca wyświetleń przekazuje w odpowiedzi kontekstowej.

Zwracane są te parametry:

  • ad: Google ignoruje to pole.
  • bid: stawka numeryczna, która bierze udział w aukcji. Musi być podana w jednostkach CPM (nie w mikrojednostkach).
  • render: adres URL renderowany w celu wyświetlenia kreacji, jeśli stawka wygra aukcję. Google musi sprawdzić i zatwierdzić ten adres URL, w przeciwnym razie zostanie on odfiltrowany z aukcji.
  • allowComponentAuction: musi mieć wartość true. Google obecnie obsługuje testowanie aukcji z udziałem wielu sprzedawców.

Oto przykład:

function generateBid(...) {
  ...
  return {'ad': 'example',
          'bid': ad.metadata.bid,
          'render': ad.renderUrl,
          'allowComponentAuction': true};
}

Wyjaśnienie funkcji generateBid() znajdziesz w sekcji Licytowanie na urządzeniu specyfikacji Protected Audience.

Waluta stawki

Stawki w aukcji w przeglądarce są podawane w jednostkach CPM w wybranej walucie.

Waluta stawki musi być podana zarówno w odpowiedzi na kontekstową stawkę, jak i w wartości zwracanej przez funkcję generateBid. Musi to być prawidłowy kod alfa ISO 4217, np. „USD”, „EUR” lub „JPY”.

W protokole OpenRTB użyj nowego pola cur w obiekcie InterestGroupBuyer w rozszerzeniu odpowiedzi na ofertę Google.

Oto przykład:

ext {
  igbid {
    impid: "1"
    igbuyer {
      origin: "https://examplebuyerorigin.com"
      cur: "EUR"
    }
  }
}

W protokole RTB Google użyj nowego pola currency w wiadomości InterestGroupBuyer w odpowiedzi na żądanie stawki.

Oto przykład:

interest_group_bidding {
  adslot_id: 1
  interest_group_buyer {
    origin: "https://examplebuyerorigin.com"
    currency: "EUR"
  }
}

Funkcje generateBid oferentów muszą zwracać stawki w tej samej walucie, która jest wskazana w odpowiedzi na stawkę kontekstową. Wypełnij nową właściwość bidCurrency w wartości zwracanej przez generateBid:

function generateBid(...) {
  ...
  return {'ad': ad,
          'bid': bid,
          'bidCurrency': 'EUR',
          ...};
}

Jeśli waluta z odpowiedzi na pytanie o stawkę kontekstową różni się od waluty zwróconej przez generateBid lub jeśli któraś z nich zwróci nieprawidłową walutę, stawka zostanie odfiltrowana przed aukcją.

Sprawdzanie jakości reklam

Egzekwowanie zasad dotyczących kreacji i ustawień wydawców może być bardziej restrykcyjne w przypadku stawek za grupy zainteresowań w przeglądarce podczas testowania interfejsu Protected Audience API przez partnerów RTB.

Pomoc dotycząca aktu o usługach cyfrowych

Zgodnie z artykułem 26 aktu o usługach cyfrowych wydawcy mogą wymagać od kupujących wyświetlania informacji zapewniających przejrzystość w reklamie. Gdy wydawca włączy opcję „Poproś kupujących o wyświetlanie w mojej witrynie lub aplikacji w Europejskim Obszarze Gospodarczym reklam tylko z informacjami o przejrzystości zgodnymi z DSA”, kupujący z grupą zainteresowań mogą określić, w przypadku których możliwości będą musieli wyświetlać informacje o przejrzystości kupującego, sprawdzając wartości parametrów BidRequest.regs.dsa.required i BidRequest.dsa.pubrender w pytaniu o stawkę (odpowiednio BidRequest.dsa.dsa_support i BidRequest.dsa.publisher_rendering_support w przestarzałym protokole Google RTB).

Gdy licytujący, który chce brać udział w aukcjach Protected Audience API, otrzyma w pytaniu o stawkę sygnał, że w przypadku reklam wyświetlanych w ramach Protected Audience API muszą się wyświetlać zgodne z DSA informacje zapewniające przejrzystość, powinien ocenić, czy może prawidłowo wyświetlać wymagane informacje, i określić to, ustawiając wartość BidResponse.ext.igbid.igbuyer.dsaadrender (BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render w przestarzałym protokole Google RTB). W przeciwnym razie kupujący nie zostanie uwzględniony w aukcji z Protected Audience API.

Więcej informacji o przejrzystości reklam w ramach aktu o usługach cyfrowych znajdziesz w tym artykule w Centrum pomocy.

Filtrowanie stawek

Podczas aukcji na urządzeniu Google egzekwuje ustawienia wydawcy i zasady dotyczące reklam.

Po aukcji w przeglądarce

Zgłaszanie wyniku aukcji kupującemu: reportWin()

Google nie wypełnia tych argumentów:

  • auctionSignals
  • sellerSignals

Użyj reportWin(), aby przekazać kupującemu wynik aukcji.

Więcej informacji znajdziesz w sekcji Raportowanie przez kupującego zdarzeń renderowania i zdarzeń związanych z reklamami w wyjaśnieniu dotyczącym interfejsu Protected Audience API.

Makra

renderUrl, która odwołuje się do kreacji interfejsu Protected Audience API, może zawierać co najmniej 1 symbol zastępczy, zwany makrem. Po zakończeniu aukcji grupy zainteresowań, ale przed renderowaniem, makra są zastępowane odpowiednimi wartościami. renderUrl używane w aukcji na urządzeniu mogą zawierać te makra:

${GDPR} Rozwija się do wartości 0, jeśli RODO nie ma zastosowania, lub 1, jeśli RODO obowiązuje. Zobacz dokumentację.
${GDPR_CONSENT_XXXX} Rozwija się do ciągu tekstowego dotyczącego przejrzystości i zgody powiązanego z określonym żądaniem. Jeśli ciąg tekstowy dotyczący przejrzystości i zgody jest pusty lub nieprawidłowy, to makro się nie rozwinie.

Za pomocą tego makra możesz przekazywać ciąg tekstowy dotyczący przejrzystości i zgody dostawcy zarejestrowanemu na globalnej liście dostawców IAB w adresie URL. Zastąp XXXX identyfikatorem dostawcy zarejestrowanego na globalnej liście dostawców IAB. Jeśli ciąg tekstowy dotyczący przejrzystości i zgody jest pusty lub nieprawidłowy, to makro się nie rozwinie.

Kreacje z makrem ${GDPR_CONSENT_XXXX} mogą zostać zablokowane, jeśli dostawca zarejestrowany na globalnej liście dostawców IAB, który jest powiązany z wstawionym przez Ciebie identyfikatorem z tej listy, nie ma zgody użytkownika.

Makro ${GDPR_CONSENT_XXXX} powinno występować w elemencie renderUrl tylko raz.
${ADDL_CONSENT} Rozwija się do tekstu dotyczącego udzielenia dodatkowej zgody powiązanego z określonym żądaniem.
${AD_WIDTH}, ${AD_HEIGHT) Te makra wstawiają szerokość i wysokość boksu reklamowego.
${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}

Makro zawierające sygnały kupującego w czasie renderowania określone w odpowiedzi na pytanie o stawkę.

Zastąp symbol zastępczy buyer.origin.example pochodzeniem kupującego grupę zainteresowań, które powinno odpowiadać wartości interest_group_buyers.origin w odpowiedzi na pytanie o stawkę. Możesz dodać _OPTIONAL_SUFFIX, aby podać maksymalnie 3 różne wartości sygnałów renderowania.

Zliczanie wyświetleń

Podczas testowania Protected Audience API z partnerami RTB Google będzie zliczać wyświetlenia, gdy przeglądarka wywoła funkcję reportResult(), a następnie pobierze adres URL raportowania Google w wywołaniu funkcji sendReportTo().

Zdarzenie używane przez Google do zliczania wyświetleń w aukcjach w przeglądarce z interfejsem Protected Audience API może się różnić od zdarzenia używanego do zliczania wyświetleń przez partnerów Google w zakresie RTB, dlatego liczby wyświetleń mogą się różnić.

Jednym z celów testowania interfejsu Protected Audience API jest identyfikowanie i ograniczanie tych rozbieżności.

Atrybucja wyświetleń podlegających rozliczeniu

Wszystkie wydatki podmiotu ustalającego stawki w ramach aukcji w przeglądarce Protected Audience są przypisywane do jednego konta podmiotu ustalającego stawki na podstawie mapowania pochodzenia właścicieli grup zainteresowań skonfigurowanego dla tego podmiotu. Przypisywanie wydatków do różnych podrzędnych kont platformy reklamowej nie jest obsługiwane.

Limit budżetu dziennego

Podczas testowania interfejsu Protected Audience API każde konto ma limit budżetu dziennego na wydatki związane z Protected Audience. Limit budżetu dziennego ogranicza ryzyko w środowisku aukcji w przeglądarce. Po osiągnięciu limitu budżetu dziennego konto nie będzie już otrzymywać kwalifikujących się do Protected Audience API pytań o stawkę.

Po osiągnięciu limitu Protected Audience konto może nadal brać udział w aukcjach kontekstowych po stronie serwera. Na przykład konto licytującego, które osiągnęło limit Protected Audience, może otrzymać żądanie stawki z parametrem auction_environment = SERVER_SIDE_AUCTION (OpenRTB JSON: 0), nawet jeśli żądanie stawki kwalifikuje się do aukcji Protected Audience.

Informacje zwrotne w czasie rzeczywistym i minimalna stawka potrzebna do wygrania

Licytujący, którzy zgodzili się na otrzymywanie informacji zwrotnych w czasie rzeczywistym, będą otrzymywać informacje zwrotne dotyczące kupujących z grup zainteresowań, którzy mają zostać uwzględnieni w aukcji Protected Audience API na urządzeniu. Każdy kupujący z grupy zainteresowań, którego oferent określi w odpowiedzi na pytanie o stawkę, otrzyma 1 obiekt opinii, niezależnie od tego, ile stawek kupujący z grupy zainteresowań złoży w aukcji Protected Audience API. W obiekcie opinii kupującego o grupie zainteresowań będą dostępne te informacje:

  • Typ opinii w obiekcie opinii będzie miał wartość INTEREST_GROUP_BUYER_FEEDBACK.
  • Pochodzenie kupującego z grupy zainteresowań.
  • Minimalna stawka potrzebna do wygrania aukcji przez kupującego z grupy zainteresowań.
  • Minimalna stawka potrzebna do wygrania dla kupującego z grupy zainteresowań, aby pokonać najwyżej ocenioną stawkę z komponentu aukcji po stronie serwera.
  • Kod stanu kupującego z grupy zainteresowań. Możliwe kody stanu są zdefiniowane w pliku interest-group-buyer-status-codes.txt.

Nazwy poszczególnych pól znajdziesz w dokumentacji protokołu RTB Authorized Buyers i rozszerzeń OpenRTB.

Powiadomienie o opiniach dotyczących stawek

Chrome udostępnia tymczasowy interfejs API do debugowania interfejsu Protected Audience API, który umożliwia usłudze Ad Manager wysyłanie w czasie rzeczywistym powiadomień debugowania typu serwer-serwer zawierających opinie na temat stawki Protected Audience. To powiadomienie będzie zawierać powody, dla których stawki mogły zostać odfiltrowane podczas aukcji w przeglądarce Protected Audience, a także inne informacje o stawce opisane poniżej.

Aby skonfigurować statyczny adres URL, który będzie używany do dostarczania powiadomień z informacjami zwrotnymi o stawkach na potrzeby debugowania interfejsu Protected Audience API, oferenci mogą skontaktować się z menedżerem konta. Ten statyczny adres URL zostanie pobrany z serwerów Google z wybranymi makrami zastąpionymi po zakończeniu aukcji z Protected Audience API. Obsługiwane są te makra:

  • %%GOOGLE_QUERY_ID%%: to makro jest zastępowane identyfikatorem zapytania Google, który został wysłany w pytaniu o stawkę kontekową z włączoną funkcją Protected Audience. W protokole OpenRTB jest to określone za pomocą znaku BidRequest.ext.google_query_id, a w wycofanym protokole RTB firmy Google – za pomocą znaku BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: pochodzenie właściciela grupy zainteresowań.
  • %%BID_CPM%%: stawka w CPM określona przez kupującego w funkcji generateBid().
  • %%RENDER_URL%%: adres URL renderowania kreacji.
  • %%STATUS%%: kod stanu, jeśli oferta została odrzucona w ciągu scoreAd(). Wartości to kody stanu kreacji.

Oto przykładowy statyczny adres URL, który oferent może przekazać menedżerowi konta:

https://dsp.example/debug?google_query_id=%%GOOGLE_QUERY_ID%%&ig_owner=%%INTEREST_GROUP_OWNER%%&render_url=%%RENDER_URL%%&bid=%%BID_CPM%%&status=%%STATUS%%

Powiadomienie o opinii na temat stawki to funkcja tymczasowa, która zależy od tymczasowego interfejsu API Chrome.ForDebuggingOnly

TURTLEDOVE na poziomie produktu

Reklamy składające się z wielu elementów lub TURTLEDOVE na poziomie produktu (PLTD) są obsługiwane w przypadku partnerów Google RTB podczas testowania interfejsu Protected Audience API. Jeśli planujesz testowanie PLTD, poinformuj o tym menedżera konta podczas integracji, ponieważ wymaga to dodatkowych zasobów i konfiguracji.

Wprowadzenie

Interfejs Protected Audience API możesz przetestować w ten sposób:

Kroki

  1. Aby dołączyć do eksperymentu z interfejsem Protected Audience API, wypełnij formularz zgłoszeniowy.
  2. Po przesłaniu formularza prośby skontaktuj się z menedżerem konta lub prześlij zgłoszenie w Centrum pomocy Authorized Buyers.
  3. Po skonfigurowaniu konta zarówno Google, jak i partner mogą zweryfikować integrację, wykonując czynności opisane w sekcji Etapy testowania.

Sprawdzanie kreacji

Aby ustalać stawki za pomocą reklam na poziomie produktu (reklam składających się z wielu elementów) w aukcjach Protected Audience API, musisz spełniać te wymagania:

  • W kontenerze reklamy komponentu (nazywanym też renderUrl najwyższego poziomu) umieść parametr zapytania &pltd=True w renderUrl, aby podczas sprawdzania kreacji odróżnić renderUrls najwyższego poziomu.
  • Wyświetlaj reprezentatywną kreację, gdy kontener reklamy komponentowej jest pobierany przez Google w celu sprawdzenia kreacji. Aby dowiedzieć się, kiedy powinna być zwracana reprezentatywna wersja reklamy, możesz zapoznać się z validation=True parametrem zapytania ustawionym przez system sprawdzania kreacji Google.

Lista kontrolna integracji

  • Skonfiguruj punkt końcowy żądania stawki, który będzie wypełniać pola związane z interfejsem Protected Audience API w odpowiedzi na żądanie stawki kontekstowej, np. interest_group_bidding.
  • Wdróż tagowanie na stronach reklamodawcy, aby dołączyć przeglądarkę użytkownika do grupy zainteresowań.
  • Zaimplementuj funkcje generateBid() i reportWin().
  • Wybierz źródła właścicieli grup zainteresowań i dodaj je do konta Autoryzowanego kupującego.
    • Pochodzenie właściciela grupy zainteresowań powinno być zgodne z pochodzeniem, w którym są hostowane funkcje generateBid().
    • Aby wykonać ten krok, skontaktuj się z menedżerem konta lub prześlij zgłoszenie w Centrum pomocy dla autoryzowanych kupujących.
  • Skonfiguruj wstępne kierowanie na zasoby reklamowe odpowiednie do testowania interfejsu Protected Audience API.
  • Przesyłaj kreacje do sprawdzenia i zatwierdzenia za pomocą interfejsu Creatives API.
  • (Opcjonalnie) Skonfiguruj punkty końcowe zaufanych sygnałów do ustalania stawek.
  • (Opcjonalnie) Skonfiguruj testową stronę reklamodawcy, która umożliwi inżynierom Google dodanie przeglądarki do grup zainteresowań należących do pochodzenia kupującego grupy zainteresowań. Umożliwia to ręczne wywoływanie aukcji z użyciem Protected Audience API.
  • (Opcjonalnie) Włącz na koncie opinie w czasie rzeczywistym, aby otrzymywać informacje zwrotne od kupujących z grup zainteresowań, którzy chcą brać udział w aukcji Protected Audience API.
  • (Opcjonalnie) Skontaktuj się z menedżerem konta, aby skonfigurować statyczny adres URL, który będzie otrzymywać powiadomienia serwer-serwer zawierające informacje o stawkach Protected Audience, czyli informacje o stanie stawki z aukcji Protected Audience na urządzeniu. Pomoże to w rozwiązywaniu nieoczekiwanych problemów. Więcej informacji znajdziesz w powiadomieniu o opiniach na temat stawek.

Etapy testu

Etap 1. Test ręczny

Aby ręcznie wywołać aukcję z Protected Audience API, upewnić się, że reklama może zostać wyrenderowana, i zarejestrować wyświetlenie:

  1. Używaj Chrome w wersji 101 lub nowszej.
  2. Włącz interfejs API Piaskownicy prywatności i ramkę ograniczoną za pomocą funkcji chrome://flags/#privacy-sandbox-ads-apis i chrome://flags/#enable-fenced-frames. Więcej informacji znajdziesz w artykule Testowanie Piaskownicy prywatności.
  3. Prześlij kreację do zatwierdzenia za pomocą interfejsu Real-Time Bidding API.
  4. Użyj strony reklamodawcy dostarczonej przez licytującego, aby dodać przeglądarkę do grupy zainteresowań należącej do licytującego.

  5. Aby wywołać aukcję Protected Audience API, użyj tej strony testowej wydawcy udostępnionej przez Google:

    https://fledge-testing.uc.r.appspot.com/?nid=allow_all

    Grupa zainteresowań w przeglądarce musi określić wystarczająco wysoką stawkę, aby wygrać aukcję, ponieważ może konkurować z tradycyjnymi stawkami po stronie serwera. Google udostępnia też każdemu partnerowi specjalną stronę wydawcy testowego, na której tylko dany partner może brać udział w aukcji. Na stronie konkretnego partnera łatwiej jest wygrywać aukcje w przeglądarce.

  6. Potwierdź te informacje:

    1. Wyświetlana jest oczekiwana zwycięska reklama.
    2. Wynik aukcji jest wysyłany po stronie serwera, co oznacza, że zwycięski oferent otrzymuje ping zwrotny z reportWin().
    3. Konsola strony wydawcy testowego rejestruje komunikat debugowania dla każdej stawki, który zawiera te informacje:
      • renderUrl: adres URL renderowania stawki.
      • interestGroupOwner: właściciel grupy zainteresowań, do której należy stawka.
      • accepted: to pole ma wartość true, jeśli oferta została zaakceptowana, a false, jeśli została odrzucona przez scoreAd().
      • externalBidStatus: kod stanu, jeśli stawka została odrzucona w ramach scoreAd(). Wartości to kody stanu kreacji.

Etap 2. (Opcjonalny) Eksperyment bez renderowania

Gdy Google i partner ręcznie sprawdzą, czy może on uczestniczyć w aukcji Protected Audience, Google umożliwi mu przejście do następnego etapu testowania.

Google przydziela niewielką ilość ruchu na żywo na potrzeby przeprowadzania aukcji z wykorzystaniem Protected Audience API. W takim przypadku Google i partner nie muszą już ręcznie wywoływać aukcji Protected Audience. Wynik aukcji z Protected Audience API nie jest renderowany. Umożliwia nam to testowanie integracji na dużą skalę.

Gdy będziesz gotowy(-a), skontaktuj się z menedżerem konta lub prześlij zgłoszenie w Centrum pomocy Authorized Buyer. Google włączy konto na tym etapie.

Etap 3. Eksperyment renderowania

Gdy Google i partner zweryfikują aukcje Protected Audience na dużą skalę bez renderowania, Google może zezwolić partnerowi na renderowanie zwycięskiej reklamy Protected Audience. Google ma niewielki ruch, w przypadku którego aukcje Protected Audience mogą się odbywać, a reklamy w grupach zainteresowań, które wygrały aukcję, są wyświetlane. Stawki licytujących biorących udział w określaniu stawek w przeglądarce konkurują z tradycyjnymi stawkami.

Gdy będziesz gotowy(-a), skontaktuj się z menedżerem konta lub prześlij zgłoszenie w Centrum pomocy Authorized Buyer. Google włączy konto na tym etapie.

Dodatkowe funkcje

Poniższe funkcje są rozszerzeniami protokołu podstawowego.

Równoległość

Równoległość to optymalizacja, która zmniejsza całkowity czas oczekiwania na aukcję, ponieważ żądanie reklamy kontekstowej jest inicjowane równolegle z żądaniami wysyłanymi do zaufanych serwerów kupującego określonych w trustedBiddingSignalsUrl.

Równoległe przetwarzanie zmniejsza opóźnienia, ale wpływa na kwalifikowanie się kupujących do grup zainteresowań i obsługę skoordynowanych eksperymentów. Równoległe przetwarzanie dotyczy wszystkich licytujących, którzy biorą udział w aukcji grup zainteresowań na urządzeniu. Aby brać udział w aukcjach równoległych, oferenci nie muszą podejmować żadnych działań, ale powinni zapoznać się z tym, jak równoległość może wpływać na ich uprawnienia do udziału w aukcjach na urządzeniu. Identyfikatory grup eksperymentalnych w przypadku skoordynowanych eksperymentów nie są jeszcze obsługiwane w ramach aukcji równoległych.

Podsumowanie procesu wyświetlania

Oto podsumowanie przebiegu aukcji równoległej:Diagram przepływu

Kwalifikacje kupującego do aukcji na urządzeniu powiązanej z grupą zainteresowań

W przypadku aukcji równoległych wywołanie navigator.runAdAuction następuje przed zwróceniem odpowiedzi reklamy kontekstowej. Aby zainicjować wywołania zaufanych serwerów kupującego, navigator.runAdAuction wymaga, aby parametr interestGroupBuyers był przekazywany jako wartość, a pozostałe parametry aukcji akceptowały obietnice JavaScript, które można rozwiązać po otrzymaniu odpowiedzi z reklamą kontekstową. Ponieważ parametr interestGroupBuyers jest przekazywany przed odpowiedzią na reklamę kontekstową, odpowiedź na reklamę kontekstową (w tym odpowiedzi na pytania o stawkę) nie może być używana do wybierania kupujących, którzy biorą udział w równoległej aukcji w przypadku danego żądania. Zamiast tego tag wydawcy Google buforuje w przeglądarce użytkownika parametr interestGroupBuyers z poprzednichnavigator.runAdAuction wykonań w tej samej domenie.

Równoległe przetwarzanie wiąże się z kilkoma ważnymi kwestiami:

  1. Sygnały aukcji, które nie są potrzebne w przypadku żądań z zaufanego serwera kupującego, np. perBuyerSignals, mogą być nadal określane w odpowiedziach na stawki RTB w taki sam sposób jak w przypadku aukcji nieprzeprowadzanych równolegle. Gdy obietnice dotyczące tych sygnałów zostaną spełnione, pozostałe kroki aukcji na urządzeniu zostaną wykonane w taki sam sposób jak w przypadku aukcji nieprzeprowadzanej równolegle.

  2. Równoległe aukcje są oparte na buforowaniu listy kupujących w grupach zainteresowań, dlatego Google nie zawsze przeprowadza aukcję równoległą, ponieważ pamięć podręczna równoległych aukcji może być pusta lub nieaktualna. Jeśli pamięć podręczna jest pusta lub wygasła, Google przeprowadza standardową, nieparalelną aukcję Protected Audience API i wykorzystuje intencje kupującego, aby wziąć w niej udział i utworzyć pamięć podręczną kupującego w grupie zainteresowań.

  3. Jeśli w przypadku bieżącej domeny wydawcy w pamięci podręcznej znajduje się co najmniej 1 kupujący dla dowolnego oferenta, Google przeprowadzi aukcję równoległą, co zostanie wskazane w żądaniu stawki:

    • Protokół RTB firmy Google: BidRequest.adslot.interest_group_auction.parallelized
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.parallelized

  4. Każda zarejestrowana grupa zainteresowań kupujących dla danego oferenta, która została uwzględniona w aukcji równoległej, będzie miała odpowiedni wpis ParallelAuctionBuyer:

    • Protokół RTB firmy Google: BidRequest.adslot.interest_group_auction.parallel_auction_buyer
    • OpenRTB: BidRequest.imp.ext.interest_group_auction.pbuyer

  5. Jeśli aukcja równoległa jest przeprowadzana, ale w pamięci podręcznej nie ma konkretnego pochodzenia kupującego, nie można go dodać do bieżącej aukcji na urządzeniu. Wskazuje na to żądanie z parametrem parallelized=True, w którym brakuje wpisu ParallelAuctionBuyer dla danego pochodzenia kupującego z grupy zainteresowań. Jednak oferenci, którzy wykazują zainteresowanie, uwzględniając w odpowiedzi na pytanie o stawkę prawidłowe i kwalifikujące się sygnały InterestGroupBuyer(s), będą mieli w pamięci podręcznej dodane odpowiednie pochodzenie kupującego z grupy zainteresowań, a pochodzenie to będzie kwalifikować się do przyszłych zrównoleglonych żądań z tej samej przeglądarki i domeny. Zamiar uczestniczenia w aukcjach grup zainteresowań można wskazać w tych polach:

    • Protokół RTB firmy Google: BidResponse.adslot.interest_group_bidding.interest_group_buyers
    • OpenRTB: BidResponse.ext.igbid.igbuyer

  6. Pochodzenia kupujących w pamięci podręcznej (które są uwzględnione w parametrze interestGroupBuyers aukcji równoległej), w przypadku których licytujący nie wskazuje zamiaru uczestniczenia w odpowiedzi na stawkę, mogą otrzymać wywołanie zaufanego serwera kupującego, ale nie będą uczestniczyć w aukcji równoległej.