Protected Audience API (wcześniej FLEDGE)

Uwaga: niektóre technologie Piaskownicy prywatności zostaną wycofane. Więcej informacji znajdziesz w najnowszych informacjach o planach dotyczących technologii Piaskownicy prywatności. Więcej informacji o stanie poszczególnych interfejsów API i funkcji platformy znajdziesz na stronie Stan funkcji Piaskownicy prywatności.

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 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.

Partnerzy Authorized Buyers, którzy chcą przetestować tę funkcję, powinni zapoznać się ze szczegółami w sekcji Wprowadzenie.

Beta: opisane tu działanie może się w przyszłości zmienić, gdy przeanalizujemy dane z testowania i zbierzemy opinie od wydawców i Authorized Buyers.

Uwaga: testowanie interfejsu Protected Audience API jest dostępne tylko dla Authorized Buyers. Licytujący z giełd i sieci uczestniczących w Otwartym ustalaniu stawek nie są jeszcze obsługiwani.

Uwaga: gdy interfejs Protected Audience API (wcześniej FLEDGE) stanie się ogólnie dostępny w Chrome, Ad Manager zacznie stopniowo zwiększać ilość ruchu uwzględnianego w testach. Będziemy sprawdzać wpływ tej zmiany na przychody wydawców, powoli zwiększając odsetek ruchu. Jednak będziemy to robić tylko do momentu ewentualnego spadku wartości przychodów. Przewidujemy, że pod koniec 2023 roku testy interfejsu Protected Audience API obejmą maksymalnie 10% ruchu w Chrome.

Podsumowanie procesu wyświetlania

Oto podsumowanie procesu wyświetlania reklam w ramach Protected Audience API w przypadku partnerów Authorized Buyers:

1. Platforma licytująca 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 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 pochodzenia systemu licytującego 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 dotyczące kupującego każdego kwalifikującego się oferenta do konfiguracji aukcji Protected Audience API.
12. Jeśli grupy zainteresowań danego oferenta określiły wartość trustedBiddingSignalsUrl, przeglądarka wysyła żądanie do każdego z tych adresów trustedBiddingSignalsUrl, 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ń, określ buyerAndSellerReportingId w przypadku reklamy, gdy dodajesz urządzenie użytkownika do grupy zainteresowań. Więcej informacji znajdziesz w dokumentacji interfejsu Protected Audience API.

Poniżej znajdziesz 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 Authorized Buyers pojawi się nowy wymiar buyer_reporting_id, czyli 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:

• Wczesny link OpenRTB
• Protokół RTB od Google (wycofany) wczesny link

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 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 giełdy, 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 zapytaniu o stawkę 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 testowaniem interfejsu 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 skutecznego kupowania, gdy zewnętrzne pliki cookie nie będą już dostępne.

Google może też przeprowadzać eksperymenty na małą skalę, w 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.

Testowanie wycofania plików cookie innych firm przy użyciu Chrome

Aby przygotować się na wycofanie plików cookie innych firm (3PCD) w 2024 roku, Chrome oferuje teraz testowanie 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 ramach określania stawek 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ć element origin dla każdego elementu 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. Na przykład sygnały renderowania mogą służyć do dostosowywania wyglądu kreacji w celu zwiększenia skuteczności w kontekście danego boksu reklamowego lub strony wydawcy.

Ostrzeżenie: ta funkcja zależy od deprecatedRenderURLReplacements obsługi przeglądarki.

W odpowiedzi na stawkę kontekstową możesz umieścić sygnały renderowania kupującego serializowane jako ciąg znaków bezpieczny dla adresu URL. Google zastąpi je w adresie URL renderowania zwycięskiej 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 w tych polach:

• 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 określania stawek 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 kontekstowych, a drugiego w przypadku wydatków na grupy zainteresowań. 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 mogą licytować wyświetlenie, pojawiają się w żądaniu stawki w przypadku 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 w specyfikacji Protected Audience API.

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 stawkę 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 ofertę.

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 będzie uwzględniany 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 reklamą w wyjaśnieniu dotyczącym Protected Audience API.

Makra

Uwaga: makra są przeznaczone do testowania interfejsu Protected Audience API i w przyszłości mogą nie być obsługiwane.

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 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 ciągu tekstowego 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 testów interfejsu Protected Audience API każde konto ma limit budżetu dziennego na wydatki związane z Protected Audience na poziomie konta. 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ć pytań o stawkę kwalifikujących się do Protected Audience API.

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 kwalifikuje się ono do aukcji Protected Audience.

Informacje zwrotne w czasie rzeczywistym i minimalna stawka potrzebna do wygrania

Licytujący, którzy włączyli otrzymywanie informacji zwrotnych w czasie rzeczywistym, będą otrzymywać informacje zwrotne dotyczące kupujących kierujących reklamy na grupy zainteresowań, którzy chcą wziąć udział 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 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 przez 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 informacje o stawce Protected Audience. To powiadomienie będzie zawierać powody, dla których stawki mogły zostać odfiltrowane podczas aukcji Protected Audience w przeglądarce, 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 o debugowaniu stawek w interfejsie 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 w ciągu scoreAd() oferta została odrzucona. 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 ForDebuggingOnlyinterfejsu API Chrome.

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

Aby przetestować interfejs Protected Audience API:

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=Trueparametrem 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 Authorized Buyer.
  • 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 ustalania stawek.
• (Opcjonalnie) Skonfiguruj testową stronę reklamodawcy, która umożliwi inżynierom Google dodanie przeglądarki do grup zainteresowań należących do kupującego grupy zainteresowań z Twojego źródła. 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 o kupujących z grup zainteresowań, którzy mają być uwzględniani w aukcji Protected Audience API.
• (Opcjonalnie) Skontaktuj się z menedżerem konta, aby skonfigurować statyczny adres URL do otrzymywania powiadomień serwer-serwer, które zawierają informacje o stawce Protected Audience i stanie stawki z aukcji Protected Audience na urządzeniu. Pomoże to w debugowaniu 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 element Fenced Frame 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 należącej do niego grupy zainteresowań.

5. Aby wywołać aukcję z 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 wartość false, jeśli została odrzucona przez scoreAd().
      • externalBidStatus: kod stanu, jeśli oferta 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 API, 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 to testowanie integracji na dużą skalę.

Gdy będziesz gotowy, 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 wygrywające reklamy w grupach zainteresowań są wyświetlane. Stawki licytujących biorących udział w określaniu stawek w przeglądarce konkurują z tradycyjnymi stawkami.

Gdy będziesz gotowy, 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:

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ń 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 etapy aukcji na urządzeniu zostaną ukończone 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 pochodząca od danego oferenta, która została uwzględniona w aukcji równoległej, będzie miała odpowiadający jej 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 w odpowiedzi na pytanie o stawkę wskażą zainteresowanie, podając prawidłowe i kwalifikujące się sygnałyInterestGroupBuyer, spowodują dodanie do pamięci podręcznej odpowiednich źródeł kupującego z grupy zainteresowań. Te źródła będą 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.