Protected Audience API (wcześniej FLEDGE)

W ramach Piaskownicy prywatności w Chrome zaproponowano interfejs Protected Audience API, 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 między witrynami.

Chrome prowadzi testy origin interfejsu Protected Audience API. Uczestnicy programu Authorized Buyers mogą brać udział w testowaniu interfejsu Protected Audience API w zasobach reklamowych wydawców w usłudze Ad Manager. Dzięki testowaniu interfejsu Protected Audience API licytujący mogą uzyskać te korzyści:

  • Sprawdzenie skuteczności przepływów w Protected Audience API i poznawanie ich skuteczności.
  • Zbierajcie opinie na temat potencjalnych ulepszeń interfejsu API na forach publicznych – dla na przykład GitHub.
  • Przygotuj się na obsługę reklam spersonalizowanych przez interfejs API bez używania plików cookie innych firm.

Kupujący z Authorized Buyers, którzy chcą przeprowadzić testy, powinni zapoznać się z instrukcjami wprowadzającymi .

Podsumowanie procesu wyświetlania reklam

Oto podsumowanie procesu wyświetlania reklam z użyciem Protected Audience API w przypadku Authorized Buyers partnerzy:

Schemat przepływu

  1. Licytujący współpracuje z reklamodawcami, aby tworzyć grupy zainteresowań dla każdej reklamodawcy. Często reklamodawcy dodają tag oferentanta do strony reklamodawcy, aby dodać przeglądarkę do grup zainteresowań.
  2. Użytkownik odwiedza stronę reklamodawcy. Może ona zawierać dane licytującego .
  3. Tag oferenta wywołuje interfejs Protected Audience API joinAdInterestGroup(). Ten wywołanie prosi przeglądarkę o dodanie użytkownika do grupy zainteresowań.
  4. Użytkownik końcowy odwiedza stronę wydawcy. Przeglądarka użytkownika wysyła żądania do tagu reklamy wydawcy Google.
  5. Tag reklamy wydawcy Google wysyła kontekstowe żądanie reklamy do serwera Google.
  6. Google wysyła pytania o stawkę kontekstową do licytujących, którzy się do niej zgłosili. Więcej informacji znajdziesz w sekcji Zmiany w żądaniach stawek.
  7. Licytujący zwraca odpowiedź na stawkę, która zawiera wiadomość InterestGroupBidding, która jest potrzebna do udziału w aukcji grupy zainteresowań. W OpenRTB jest to określane za pomocą pola BidResponse.ext.igbid, a w wycofanym protokole RTB Google – za pomocą pola BidResponse.interest_group_bidding. Jeśli system licytujący nie poda tych informacji, Google nie uwzględni pochodzenia w parametrze interestGroupBuyers w konfiguracji aukcji. InterestGroupBidding może też zawierać opcjonalne sygnały dotyczące kupujących, które zostaną przekazane funkcji ustalania stawek licytującego podczas aukcji w przeglądarce. W OpenRTB jest to pole BidResponse.ext.igbid.igbuyer.buyerdata, a w wycofanym protokole Google RTB – pole BidResponse.interest_group_bidding.interest_group_buyers.per_buyer_signals. Więcej informacji znajdziesz w sekcji Zmiany odpowiedzi z uwzględnieniem stawek.
  8. Google przeprowadza licytację po stronie serwera i zwraca odpowiedź na stawkę do przeglądarki. Aukcja po stronie serwera uwzględnia tradycyjne stawki po stronie serwera. Odpowiedź na pytanie o stawkę może zawierać informacje o kontekstualnej stawce zwycięskiej (jeśli taka istnieje).
  9. Odpowiedź na stawkę zawiera konfigurację aukcji dla aukcji w przeglądarce. Mogą to być sygnały kontekstowe od każdego uczestniczącego kupującego (wysłane wcześniej przez OpenRTB buyerdata lub przestarzały protokół Google RTB per_buyer_signals), informacje o kontekstowym zwycięzcy oraz ustawienia dotyczące kwalifikowania się do udziału w licytacji.
  10. Tag wydawcy Google wywołuje interfejs Protected Audience API runAdAuction() aby rozpocząć aukcję na podstawie grupy zainteresowań na urządzeniu. Google uwzględnia tylko kupujących, którzy zostali uwzględnieni jako InterestGroupBuyer w InterestGroupBidding podczas konfiguracji aukcji.
  11. Google przekazuje opcjonalne sygnały dotyczące kupujących do konfiguracji aukcji z listą odbiorców chronionych.
  12. Jeśli grupy zainteresowań danego oferenta określają trustedBiddingSignalsUrl, przeglądarka wysyła żądanie do trustedBiddingSignalsUrl każdej grupy, aby pobrać sygnały w czasie rzeczywistym. Zobacz szczegóły w interfejsie Protected Audience API specyfikacja.
  13. Przeglądarka wywołuje generateBid() licytanta dla każdej grupy zainteresowań, która została włączona i może uczestniczyć w aukcji w przeglądarce. W tym kroku obliczana jest stawka i wybierana jest kreacja. generateBid() ma dostęp do opcjonalnych sygnałów kupujących udostępnianych przez licytującego oraz zaufanych sygnałów ustalania stawek dla danej grupy zainteresowań.
  14. Przeglądarka wywołuje usługę sprzedawcy (w tym przypadku Google) scoreAd(), aby przypisać pozycję każdej stawce w aukcji reklam grupy zainteresowań. Stawki są oceniane i filtrowane na podstawie zabezpieczeń wydawcy, zasad dotyczących reklam i innych ograniczeń.
  15. Przeglądarka przeprowadza aukcję z odpowiednimi stawkami na potrzeby grup zainteresowań. stawka kontekstowa o najwyższej pozycji bierze udział w aukcji w przeglądarce.
  16. Jeśli po aukcji zostanie wyłoniony zwycięzca grupy zainteresowań, przeglądarka wywołuje reportResult() sprzedawcy i reportWin() licytującego do powiadomienia wszystkich na temat zwycięzcy aukcji w przeglądarce.
  17. Jeśli wygra reklama kierowana na grupę zainteresowań, tag wydawcy Google wyrenderuje ją w iframe.

Szczegóły procesu obsługi

Przed wyświetlaniem reklam

Sprawdzanie kreacji

Zanim kreacje będą mogły się wyświetlać w ramach aukcji w przeglądarce dla chronionych danych, 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 dla Aukcje reklam w ramach grupy zainteresowań w ramach Protected Audience API muszą zawierać renderUrls do sprawdzenia.

Wymagania związane z usługą renderUrls:

  • Wartość renderUrl przesłana za pomocą interfejsu API powinna być zgodna z użytą wartością w polu renderUrl w aukcji reklam kierowanej na określoną grupę zainteresowań.
  • Każdy element renderUrl może reprezentować tylko jednego reklamodawcę lub jedną reklamę kampanii. Tagu renderUrl nie można używać do renderowania reklam w imieniu kilku reklamodawców. Każdy element renderUrl musi być zmapowany na jedną kreację.
  • Element renderUrl musi być dostępny i możliwy do pobrania przez tryb offline Google przez maksymalnie 7 dni od ostatniej licytacji reklamy.
Real-time Bidding API

Licytujący mogą używać określania stawek w czasie rzeczywistym API do przesyłania kreacji określania stawek według grupy zainteresowań.

Automatyczne skanowanie kreacji

Licytujący mogą skonfigurować automatyczne skanowanie kreacji, które nie są przesłany za pomocą interfejsu Real-timeReporting API.

Jeśli ustawisz automatyczne skanowanie kreacji, Google znajdzie kreacje które są automatycznie skanowane pod kątem aukcji, aukcji.

Aby włączyć automatyczne skanowanie kreacji:

  • Dodaj do konta Authorized Buyer wszystkie renderUrlźródła kreacji grupy zainteresowań.

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

    Authorized-Buyers-Creative-ID

    ciąg znaków

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

    ciąg znaków

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

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 API określania stawek w czasie rzeczywistym, musisz je ponownie przesłać po 15 dniach. Jeśli polegasz na automatycznego skanowania kreacji, są one automatycznie skanowane ponownie.

Identyfikator raportowania kupującego

Dane raportowania (np. wyświetlenia) możesz podzielić na podgrupy za pomocą wymiarów podanych przez kupującego (np. identyfikatora kampanii lub identyfikatora reklamodawcy). Aby dodać wymiar wydatków na grupę zainteresowań, podaj buyerAndSellerReportingId dla reklamy, gdy dodajesz urządzenie użytkownika do grupy zainteresowań. Więcej informacji znajdziesz w dokumentacji Protected Audience.

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

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

Wymiar buyer_reporting_id pojawi się jako nowy wymiar w narzędziu do generowania raportów Authorized Buyer o nazwie Wymiar identyfikatora raportowania kupującego.

Aukcja po stronie serwera

Zmiany pytań o stawkę

Oto wczesne wersje obsługiwanych protokołów do użytku w eksperyment:

Określanie obsługi aukcji dla określonej grupy zainteresowań

W żądaniach stawek pojawiły się nowe pola, które wskazują obsługę aukcji grup zainteresowań:

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

Za pomocą tego pola możesz odróżnić możliwości wyświetleń, które obsługują aukcję w grupie zainteresowań w przeglądarce Protected Audience, od tych, które obsługują tylko tradycyjną aukcję na giełdzie po stronie serwera. Wyliczenie AuctionEnvironment może mieć następujące wartości:

  • SERVER_SIDE_AUCTION (JSON JSON: 0): aukcja określająca jest wyświetlana na serwerach giełdy.
  • ON_DEVICE_INTEREST_GROUP_AUCTION (JSON JSON: 1): żądania z obsługę Protected Audience API, w ramach której na serwerów giełdy i ustalania stawek dla grupy zainteresowań oraz aukcji końcowej. które działa w przeglądarce.
  • SERVER_SIDE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 3): aukcja kontekstowa działa na serwerach giełdy, a logika określania stawek za grupy zainteresowań i logika punktacji służąca do określania ostatecznej reklamy zwycięskiej działają na serwerach określania stawek i aukcji.
Określanie rozmiaru boksu reklamowego z Protected Audience API

Żądanie stawki zawiera te pola, aby zapewnić Ci rozmiar zablokowanego miejsca na reklamę w grupie odbiorców:

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

Te pola określają rozmiar boksu reklamowego na potrzeby aukcji z Protected Audience API w pikselach.

Wielkość ta może się różnić od rozmiarów w zapytaniu kontekstowym, np. w polach BidRequest.imp.banner.format.w i BidRequest.imp.banner.format.h w OpenRTB lub w polach BidRequest.adslot.width i BidRequest.adslot.height w zastąpionym protokole Google RTB.

Żądanie kontekstowe może mieć wiele rozmiarów. Zwycięska aukcja na urządzeniu powinna wypełniać tylko jeden stały rozmiar boksu.

Wskazanie możliwości renderowania reklamy w Protected Audience

Reklamy z Protected Audience API mogą lub nie być renderowane w zależności od bieżącego etapie integracji (patrz sekcja dotycząca bez renderowania eksperyment). Pole render_interest_group_ads w żądaniu stawki wskazuje, czy wyświetli się reklama z Protected Audience, która wygrała aukcję.

  • OpenRTB:BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
  • Protokół Google RTB (przestarzały): BidRequest.adslot.interest_group_auction.render_interest_group_ads
Ogranicz poleganie na identyfikatorach użytkownika

Kontekstowe pytania o stawkę w ramach testowania interfejsu Protected Audience API mogą nadal będą przechowywać tradycyjne identyfikatory oparte na plikach cookie, jeśli są dostępne przeglądarki, np. pól BidRequest.user.id i BidRequest.user.buyerid, lub BidRequest.google_user_id i BidRequest.hosted_match_data in wycofanego protokołu Google RTB. Obecność takich identyfikatorów w prośbach o określenie stawki podlega obowiązującym zasadom ochrony prywatności. Zalecamy, aby podczas testowania nie polegać na identyfikatorach opartych na plikach cookie do celów kierowania i określania stawek, aby lepiej przygotować się do skutecznego zakupu, gdy pliki cookie innych firm 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 pytań o stawkę objętych testami interfejsu Protected Audience API. Ma to na celu ocenę potencjalnego wpływu wycofania plików cookie innych firm.

Aby przygotować się do wycofanie plików cookie innych firm w 2024 r. Chrome oferuje Testy przeprowadzane przy użyciu Chrome.

Strony i dostawcy mogą korzystać z testów wspomaganych przez Chrome, aby testować swoje systemy w ramach 3PCD. W ramach testu przeglądarki Chrome są przypisywane do grupy eksperymentalnej 3PCD, do trybu A lub B. Każda przeglądarka ma przypisaną spójną etykietę odpowiadającej konkretnej grupie eksperymentalnej 3PCD, do której masz dostęp interfejs API Chrome w przeglądarce.

Google przekazuje niezmodyfikowaną etykietę z interfejsu API Chrome dla stawki RTB. użytkownika. Ze względu na niewielkie ilości ruchu związane z poszczególnymi etykietami Google nie zawsze uwzględnia ich w kontekstach z ograniczeniami dotyczącymi prywatności.

Oto pola, w których możesz wyświetlić etykietę:

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

Zmiany odpowiedzi na stawkę

Określanie udziału w aukcji grupy zainteresowań

Ponosisz odpowiedzialność za wyraźne poinformowanie o swoim zamiarze udziału w aukcji w przeglądarce przez zwrócenie obiektu InterestGroupBidding w tagu kontekstowa odpowiedź na stawkę:

  • OpenRTB: BidResponse.ext.igbid
  • Protokół Google RTB (przestarzały): BidResponse.interest_group_bidding

Musisz podać kontekstową odpowiedź na pytanie o stawkę. Odpowiedź nie musi zawierać stawki kontekstowej. Obiekt InterestGroupBidding powinien zawierać element origin dla każdego elementu InterestGroupBuyer, który powinien być zgodny z jedną z wartości źródła skonfigurowanych przez licytującego na swoim koncie. Element origin jest dodawany do aukcji na wartość interestGroupBuyers konfiguracji po wywołaniu przez tag wydawcy Google runAdAuction()

Propagowanie sygnałów kontekstowych kupującego

Możesz uwzględniać sygnały kupującego w kontekstowej odpowiedzi na stawkę, która jest rozpowszechniana jako obiekt JSON do funkcji określania stawek na urządzeniu za pomocą perBuyerSignals argument. Tę wartość można uwzględnić w odpowiedzi na pytanie o stawkę wraz z parametrem następujące pola w zależności od protokołu:

  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
  • RTB Google (wycofane): BidResponse.interest_group_bidding.per_buyer_signals
Przekazywanie sygnałów kontekstowych dotyczących wyświetlania kupującemu

Kreacje kierowane na grupy zainteresowań mogą używać podczas renderowania ograniczonych sygnałów kontekstowych przez: wysyłanie tych sygnałów przez kontekstową odpowiedź na pytanie o stawkę i otrzymywanie ich w żądaniu wyrenderowanego adresu URL za pomocą rozwinięcia makra. Na przykład renderowanie można wykorzystać do dostosowania wyglądu i sposobu działania kreacji skuteczności w kontekście danego boksu reklamowego lub strony wydawcy.

W odpowiedzi na stawkę kontekstową możesz uwzględnić sygnały renderowania kupującego zaserializowane jako ciąg znaków bezpiecznych dla adresu URL. Google zastąpi je w adresie URL renderowania zwycięskiej grupy zainteresowań, tworząc makro ${RENDER_DATA_buyer.origin.example[_OPTIONAL_SUFFIX]}.

Sygnały renderowania można określić w odpowiedzi na stawkę w ten sposób: w zależności od protokołu:

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

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

Kupujący korzystający z grupy odbiorców o zainteresowaniach nie może uczestniczyć w aukcji chronionych odbiorców, jeśli sygnały nie są bezpieczne pod względem adresu URL, sufiksy makro nie są unikalne lub podano więcej niż 3 zestawy sygnałów.

Określanie maksymalnej stawki w przeglądarce

Na liście Protected Audience API , czyli obliczanie stawki, a ostateczna aukcja powinna odbyć się lokalnie na urządzeniu. Może to spowodować potencjalnie nadużycia, które mogą wpływać na integralność ostatecznej aukcji. takich jak zwycięska stawka.

W ramach działań zapobiegawczych Google wspieranych przez Google API interfejsu Protected Audience w przypadku partnerów RTB możesz w każdej odpowiedzi z uwzględnieniem kontekstu określić oczekiwaną maksymalną wartość stawki. Oczekiwana maksymalna stawka to maksymalna stawka, która funkcja określania stawek powinna zwrócić Twoje wyniki. Jeśli stawka wygrana w aukcji w przeglądarce przekracza tę kwotę, nie jest ona liczona jako zdarzenie podlegające rozliczeniu. To podejście może się zmienić.

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

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

Licytujący musi wybrać identyfikator płatności, aby przypisać swoje zainteresowania stawki grupy wyświetleń, korzystając z następujących pól:

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

Wybrany identyfikator płatności musi być odpowiednim identyfikatorem płatności z pytania o stawkę:

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

Jeśli nie podasz identyfikatora rozliczeniowego, do którego mają być przypisywane wyświetlenia z ustalaniem stawek w grupie odbiorców zainteresowanych, licytujący nie będzie uczestniczyć w aukcji z użyciem interfejsu Protected Audience API.

Konta podrzędne mogą mieć maksymalnie 2 identyfikatory płatności. Kupujący może używać jednego identyfikatora rozliczeniowego na potrzeby wydatków na reklamy kontekstowe, a drugiego na potrzeby wydatków na reklamy kierowane na grupy zainteresowań. Jeśli chcesz skonfigurować dwa identyfikatory płatności, skontaktuj się ze swoim menedżerem konta. na koncie dziecka.

Dla każdego identyfikatora płatności można ustawić budżet dzienny. Skontaktuj się ze swoim menedżera konta, aby ustalić budżet dzienny dla identyfikatorów płatności kont podrzędnych.

Identyfikatory płatności wszystkich kont podrzędnych z dostępnym budżetem, które mogą uczestniczyć w licytowaniu pojawi się w pytaniu o stawkę w ramach wyboru atrybucji wydatków. Aby zmodyfikować budżet dla identyfikatora rozliczeniowego grupy zainteresowań, skontaktuj się z menedżerem konta.

Podczas aukcji w przeglądarce

Generowanie stawek w przeglądarce

Używaj funkcji generateBid() do generowania stawek w przeglądarce.

Google udostępnia te parametry:

  • auctionSignals: pusta
  • perBuyerSignals: obiekt JavaScriptu tych samych sygnałów dostarczanych przez licytujący w odpowiedzi kontekstowej

Zwracane są te parametry:

  • ad: Google ignoruje to pole.
  • bid: stawka liczbowa biorąca udział w aukcji. Musi być w jednostkach CPM (nie mikro).
  • render: adres URL renderowany do wyświetlania kreacji, jeśli stawka wygrała aukcję. Google musi sprawdzić i zatwierdzić ten adres URL, w przeciwnym razie zostanie on odfiltrowany z aukcji.
  • allowComponentAuction: musi być true. Google obecnie obsługuje testowanie aukcji z wieloma sprzedawcami.

Oto przykład:

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

Zobacz specyfikację Protected Audience API na urządzeniu Ustalanie stawek , gdzie znajdziesz wyjaśnienie funkcji generateBid().

Waluta stawki

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

Waluta oferty musi być wskazana zarówno w odpowiedzi na zapytanie o ofertę kontekstową, jak i w wartości zwracanej generateBid. Musi to być prawidłowy kod alfanumeryczny ISO 4217, np. „USD”, „EUR” lub „JPY”.

W obiekcie OpenRTB użyj nowego pola cur w obiekcie InterestGroupBuyer w Rozszerzenie odpowiedzi Google na pytania o stawkę.

Oto przykład:

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

W protokole Google RTB użyj nowego pola currency w wiadomości InterestGroupBuyer w odpowiedzi na stawkę.

Oto przykład:

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

Licytujący Funkcje generateBid muszą zwracać stawki w tej samej walucie, co w kontekstowej odpowiedzi na stawkę. Wypełnij nową właściwość bidCurrency w wartości zwracanej przez funkcję generateBid:

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

Jeśli waluta odpowiedzi kontekstowej na stawkę jest inna niż waluta zwracanych przez funkcję generateBid, albo jeśli któraś z nich zwraca nieprawidłową walutę, zostanie odfiltrowana przed aukcją.

Sprawdzanie jakości reklam

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

Pomoc dotycząca aktu o usługach cyfrowych

Ze względu na art. 26 aktu o usługach cyfrowych wydawcy mogą wymagać od kupujących renderowania informacji o przejrzystości. 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 w grupach zainteresowań mogą określić, dla których możliwości będą musieli wyświetlać informacje o przejrzystości kupującego. Aby to zrobić, muszą zwrócić uwagę na wartości BidRequest.regs.dsa.required i BidRequest.dsa.pubrender w pytaniu o stawkę (odpowiednio BidRequest.dsa.dsa_support i BidRequest.dsa.publisher_rendering_support w wycofanym protokole Google RTB).

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

Więcej informacji o przejrzystości reklam na mocy aktu o usługach cyfrowych znajdziesz w Artykuł w Centrum pomocy: wsparcie aktu o usługach cyfrowych

Filtrowanie stawek

Google egzekwuje przestrzeganie zasad wydawców elementy sterujące i reklama zasady podczas aukcji na urządzeniu.

Po aukcji w przeglądarce

Raportuj kupującemu wynik aukcji: reportWin()

Google nie wypełnia tych argumentów:

  • auctionSignals
  • sellerSignals

Aby przekazać kupującemu wynik aukcji, użyj polecenia reportWin().

Zobacz raporty dla kupujących dotyczące renderowania i reklam. Wydarzenia w wyjaśnieniu interfejsu Protected Audience API.

Makra

Obiekt renderUrl odwołujący się do kreacji interfejsu Protected Audience API może zawierać jeden lub kilka obiektów zastępczych, nazywanych makrami. Po zakończeniu aukcji grupy zainteresowań, ale przed renderowaniem makro są zastępowane odpowiednimi wartościami. renderUrl używane w aukcji na urządzeniu może zawierać te makropolecenia:

${GDPR} Rozwija się do 0, jeśli RODO nie ma zastosowania, lub 1, jeśli RODO ma zastosowanie. Zapoznaj się z dokumentacją.
${GDPR_CONSENT_XXXX} Rozwija się do przejrzystości &amp; Ciąg tekstowy dotyczący zgody powiązany z żą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 na przetwarzanie danych w adresie URL do dostawcy zarejestrowanego na globalnej liście dostawców IAB. Zastąp XXXX identyfikatorem GVL firmy IAB zarejestrowanego dostawcy. 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 liście GVL IAB powiązany z wstawionym przez Ciebie identyfikatorem z globalnej listy dostawców firmy IAB nie ma zgody użytkownika.

Makro ${GDPR_CONSENT_XXXX} powinno występować w elementach 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ślonych w odpowiedzi na stawkę.

Zastąp placeholder buyer.origin.example wartością źródła kupującego grupę zainteresowań, która powinna odpowiadać wartości interest_group_buyers.origin w odpowiedzi na pytanie o stawkę. Możesz Uwzględnij _OPTIONAL_SUFFIX, aby podać maksymalnie 3 różne wartości sygnałów renderowania.

Zliczanie wyświetleń

Podczas testowania interfejsu Protected Audience API we współpracy z partnerami RTB Google będzie zliczać wyświetleń, gdy przeglądarka wywoła funkcję reportResult() i następnie pobiera URL raportowania Google w wywołaniu sendReportTo().

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

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

Atrybucja wyświetleń podlegających rozliczeniu

Cała kwota wydatków oferenta z aukcji w przeglądarce w ramach Protected Audience jest przypisywana do jednego konta oferenta na podstawie mapowania źródeł danych właściciela listy odbiorców skonfigurowanych dla tego oferenta. Przypisywanie wydatków do różnych konta kont podrzędnych licytującego nie są obsługiwane.

Limit budżetu dziennego

Podczas testów interfejsu Protected Audience API każde konto ma przypisany poziom konta Limit budżetu dziennego w ramach Protected Audience API. Limit budżetu dziennego ogranicza ryzyko w środowisku aukcji w przeglądarce. Po osiągnięciu limitu budżetu dziennego konto nie otrzymuje już pytań o stawkę odpowiednich dla Protected Audience API.

Po osiągnięciu limitu Protected Audience konto może nadal uczestniczyć w aukcjach kontekstowych po stronie serwera. Na przykład konto licytującego, które osiągnie limit Protected Audience, może otrzymać żądanie stawki z wartością 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

Użytkownicy, którzy zdecydują się otrzymywać informacje zwrotne w czasie rzeczywistym, będą otrzymywać informacje zwrotne o grupach zainteresowań, które zostały uwzględnione w aukcji Protected Audience na urządzeniu. Każdy kupujący grup zainteresowań, którego stawka jest określona w odpowiedzi na pytanie o stawkę, otrzyma jeden obiekt informacji zwrotnej niezależnie od tego, ile stawek wskaże w ramach aukcji Protected Audience. W obiekcie opinii kupujących dotyczących grupy zainteresowań będą dostępne te informacje:

  • Obiektem opinii będzie typ opinii INTEREST_GROUP_BUYER_FEEDBACK
  • Pochodzenie kupującego korzystającego z grupy zainteresowań.
  • Minimalna stawka potrzebna do wygrania w przypadku kupującego z grupy zainteresowań, by wygrać wszystkich aukcji.
  • Minimalna stawka potrzebna do wygrania przez kupującego z grupy zainteresowań, aby pokonać najwyższą stawkę w komponencie po stronie serwera w ramach ogólnej aukcji.
  • Kod stanu kupującego z grupy zainteresowań. Możliwe kody stanu: zdefiniowane w interest-group-buyer-status-codes.txt.

Nazwy poszczególnych pól znajdziesz w dokumentacji dotyczącej protokołów RTB Authorized Buyers i OpenRTB Extensions.

Powiadomienie o opinii dotyczącej stawek

Chrome umożliwia tymczasowe debugowanie Interfejs API na potrzeby interfejsu Protected Audience API, który umożliwia Ad Managerowi wysyłanie w czasie rzeczywistym powiadomienia o debugowaniu między serwerami, które zawierają opinię na temat Stawka za odbiorców. Powiadomienie będzie zawierać powody, dla których stawki mogły zostać odfiltrowane w aukcji Protected Audience w przeglądarce, a także inne informacje o stawce opisane poniżej.

Licytujący mogą skontaktować się ze swoim menedżerem konta, aby skonfigurować statyczny adres URL, który będzie używane do dostarczania powiadomień o stawkach na potrzeby debugowania w ramach Protected Audience API. Ten statyczny URL zostanie pobrany z serwerów Google, a wybrane makra zostaną zastąpione po zakończeniu aukcji z Protected Audience API. Te makra są obsługiwane:

  • %%GOOGLE_QUERY_ID%%: to makro jest zastępowane identyfikatorem zapytania Google wysłane w odpowiedzi na pytanie o stawkę z użyciem Protected Audience API za pomocą kontekstowych pytań o stawkę. W protokole OpenRTB jest to określane za pomocą wartości BidRequest.ext.google_query_id, natomiast w protokole Google RTB, który jest wycofany, używa się wartości BidRequest.google_query_id.
  • %%INTEREST_GROUP_OWNER%%: pochodzenie właściciela grupy zainteresowań.
  • %%BID_CPM%%: stawka (CPM) określona przez kupującego w funkcji generateBid().
  • %%RENDER_URL%%: adres URL renderowania kreacji.
  • %%STATUS%%: kod stanu, jeśli stawka została odrzucona w ciągu scoreAd(). Wartości to kody stanów kreacji.

Oto przykładowy adres URL statyczny, który licytujący może podać swojemu 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 dotyczącej stawki to tymczasowa funkcja, która zależy od tymczasowego interfejsu API ForDebuggingOnly w Chrome.

TURTLEDOVE na poziomie usługi

Reklamy złożone z kilku elementów lub TURTLEDOVE na poziomie produktu są obsługiwane w przypadku partnerów korzystających z Google RTB podczas testowania interfejsu Protected Audience API. Jeśli planujesz przetestować PLTD, poinformuj o tym menedżera konta podczas integracji, ponieważ potrzebne są dodatkowe zasoby i konfiguracja.

Wprowadzenie

Aby przetestować interfejs Protected Audience API:

Kroki

  1. Wypełnij formularz prośby. aby dołączyć do eksperymentu w ramach Protected Audience API.
  2. Po przesłaniu formularza skontaktuj się z menedżerem konta lub plikiem zgłoszenia w Centrum pomocy dla autoryzowanych kupujących pomocy.
  3. Po skonfigurowaniu konta zarówno Google, jak i partner mogą zweryfikować można zintegrować, 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 kilku elementów) w ramach aukcji interfejsu Protected Audience API, musisz spełnić te wymagania:

  • Umieść parametr zapytania &pltd=True w elemencie renderUrl dla parametru kontenera reklamy komponentu (zwanego też renderUrl najwyższego poziomu), odróżniać renderUrls najwyższego poziomu podczas sprawdzania kreacji.
  • Renderuj reprezentatywną kreację, gdy kontener reklamy komponentu jest pobrane do sprawdzenia przez Google. Aby dowiedzieć się, kiedy powinno zostać zwrócone reprezentatywne renderowanie reklamy, możesz sprawdzić parametr zapytania validation=True ustawiony przez system sprawdzania kreacji Google.

Lista kontrolna integracji

  • Skonfiguruj punkt końcowy pytania o stawkę, który będzie wypełniać interfejs Protected Audience API powiązanych pól w kontekstowej odpowiedzi na stawkę – np. interest_group_bidding
  • Implementacja tagów na stronach reklamodawcy, dzięki czemu przeglądarka użytkownika grupę zainteresowań.
  • Wdróż generateBid() i reportWin().
  • Wybierz właścicieli grup odbiorców na podstawie zainteresowań i dodaj ich do konta Autoryzowanego kupującego.
    • Źródła danych właściciela grupy zainteresowań powinny być zgodne ze źródłami, w których 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.
  • Konfigurowanie kierowania wstępnego w przypadku zasobów reklamowych powiązanych z interfejsem Protected Audience API i testowania.
  • Przesyłanie kreacji do sprawdzenia i zatwierdzenia za pomocą interfejsu API Kreacji.
  • (Opcjonalnie) Skonfiguruj punkty końcowe zaufanych sygnałów ustalania stawek.
  • (Opcjonalnie) Skonfiguruj testową stronę reklamodawcy, która pozwoli inżynierom Google dodawać przeglądarkę do grup zainteresowań należących do dostawcy grup zainteresowań. Dzięki temu możemy ręcznie wywoływać aukcje Protected Audience.
  • (Opcjonalnie) Włącz na swoim koncie informacje zwrotne w czasie rzeczywistym, aby otrzymywać informacje zwrotne od kupujących, którzy poprosili o włączenie ich do aukcji Protected Audience.
  • (Opcjonalnie) Skontaktuj się z menedżerem konta, aby skonfigurować statyczny adres URL, który będzie wysyłał powiadomienia z serwera na serwer. Zawierać one będą informacje o stanie stawki z aukcji na urządzeniach z użyciem listy odbiorców chronionych, co ułatwi debugowanie nieoczekiwanych problemów. Zobacz informacje o stawkach , aby dowiedzieć się więcej.

Etapy testu

Etap 1. Test ręczny

Jak ręcznie uruchomić aukcję z Protected Audience API, aby reklama mogła i zarejestrować wyświetlenie:

  1. Użyj Chrome w wersji 101 lub nowszej.
  2. Włącz interfejs API Piaskownicy prywatności i Fenced Frame za pomocą chrome://flags/#privacy-sandbox-ads-apis i chrome://flags/#enable-fenced-frames Więcej informacji znajdziesz na stronie Testowanie prywatności w środowisku piaskownicy.
  3. Prześlij kreację do zatwierdzenia za pomocą interfejsu API określania stawek w czasie rzeczywistym.
  4. Aby dodać przeglądarkę do listy należącej do licytującego, skorzystaj ze strony reklamodawcy udostępnionego przez licytującego grupy zainteresowań.

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

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

    Grupa zainteresowań w przeglądarce musi ustalać wystarczająco wysoką stawkę, aby wygrać aukcję, ponieważ może konkurować ze zwykłymi stawkami po stronie serwera. Google udostępnia też dedykowaną stronę testową dla każdego partnera, na której tylko on może uczestniczyć w aukcji. Na stronie partnera łatwiej jest z pewnością wygrać aukcje w przeglądarce.

  6. Zweryfikuj te kwestie:

    1. Wyświetla się oczekiwana zwycięska reklama.
    2. Wynik aukcji jest wysyłany po stronie serwera, co oznacza, że zwycięski oferent otrzymuje odpowiedź od reportWin().
    3. Konsolę testowej strony wydawcy rejestruje wiadomość debugowania dla każdego stawki z tymi informacjami:
      • renderUrl: adres URL renderowania oferty.
      • interestGroupOwner: właściciel grupy zainteresowań, do której należy stawka.
      • accepted: to pole ma wartość true, jeśli stawka została zaakceptowana, i false, jeśli została odrzucona przez scoreAd().
      • externalBidStatus: kod stanu, jeśli oferta została odrzucona w ramach scoreAd(). Wartości to kody stanów kreacji.

Etap 2. (Opcjonalnie) Eksperyment bez renderowania

Gdy Google i partner potwierdzą ręcznie, że partner może uczestniczyć w aukcji chronionych odbiorców, Google umożliwi mu przejście do następnego etapu testów.

Google przeznacza niewielką część rzeczywistego ruchu na potrzeby obsługi Protected Audience API aukcji. Dzięki temu Google i partner nie muszą już ręcznie aktywować aukcja z Protected Audience API. Wynik aukcji z Protected Audience API nie jest renderowany. Dzięki temu możemy przetestować integrację 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łączymy to konto na tym etapie.

Etap 3. Eksperyment z renderowaniem

Po zweryfikowaniu przez Google i partnera aukcji z użyciem Protected Audience API na dużą skalę bez renderowania Google może umożliwić partnerowi renderowanie Reklama, która wygrała odbiorców. Google odnotowuje niewielką ilość ruchu tam, gdzie są Aukcje odbiorców mogą być aktywne, a zwycięskie reklamy kierowane na grupy zainteresowań są wyrenderowano. Stawki w przeglądarce pochodzące od licytujących uczestniczących w programie konkurują ze stawkami tradycyjnymi.

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

Dodatkowe funkcje

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

równoległość

Równoległość to optymalizacja, która zmniejsza opóźnienie aukcji od początku do końca, inicjując żądanie reklamy kontekstowej równolegle z żądaniami do zaufanych serwerów kupującego określonych w trustedBiddingSignalsUrl.

Równoległość skraca czas oczekiwania, ale wpływa na grupę zainteresowań kryteria kwalifikacji kupujących oraz pomoc eksperymentów skoordynowanych. Równoległość dotyczy wszystkich licytujących, którzy aukcji na urządzeniu. Licytujący nie muszą podejmować żadnych działań, uczestniczyć w aukcjach równoległych, ale powinien się zapoznać jak równoległość może wpłynąć na możliwość udziału w aukcjach na urządzeniu. Identyfikatory grup eksperymentów w skoordynowanych eksperymentach nie są jeszcze obsługiwane w ramach równoległych aukcji.

Podsumowanie procesu wyświetlania

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

Kryteria kwalifikacji kupujących w grupach zainteresowań na urządzeniu

W przypadku aukcji równoległych wywołanie użytkownika navigator.runAdAuction ma miejsce przed odpowiedź kontekstowa na reklamę. Aby zainicjować wywołania wiarygodnego serwera kupującego, navigator.runAdAuction wymaga, aby parametr interestGroupBuyers został przekazany jako wartość, podczas gdy pozostałe parametry aukcji akceptują obietnice JavaScript, które można rozwiązać po odpowiedzi na reklamę kontekstową. Od Wartość interestGroupBuyers jest przekazywana przed kontekstową odpowiedzią na reklamę, kontekstową odpowiedź na reklamę (w tym odpowiedzi na stawkę). nie można użyć do wyboru kupujących, którzy biorą udział w aukcji równoległej dla danego żądania. Zamiast tego tag wydawcy Google zapisuje w pamięci podręcznej przeglądarki użytkownika parametr interestGroupBuyers z poprzednich wywołań navigator.runAdAuction w tej samej domenie.

W przypadku równoległości należy wziąć pod uwagę kilka ważnych kwestii:

  1. Sygnały aukcji, które nie są potrzebne do obsługi żądań z zaufanego serwera kupującego, takie jak perBuyerSignals, można nadal określać w odpowiedziach na pytania o stawkę w RTB w taki sam sposób jak w przypadku aukcji nieparalalnych. Gdy zobowiązania 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 nierównoległego przebiegu aukcji.

  2. Równoległość działania opiera się na buforowaniu listy kupujących grupy zainteresowań, Google nie zawsze przeprowadza równoległą aukcję, ponieważ pamięć podręczna wczytywania równoległego mogą być puste lub straciły ważność. Jeśli pamięć podręczna jest pusta lub jej ważność wygasła, Google przeprowadza standardową nierównoległą aukcję interfejsu Protected Audience API i korzysta z zamiarów kupującego, aby uczestniczyć w nierównoległej aukcji i tworzyć pamięć podręczną kupującego na podstawie grupy zainteresowań.

  3. Jeśli w pamięci podręcznej danego wydawcy zapisany jest co najmniej 1 kupujący dowolny licytujący Google równolegle który zostanie wskazany w pytaniu o stawkę:

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

  4. Każde źródło kupującego zarejestrowanej grupy zainteresowań dla danego licytującego, które uwzględnione w aukcji równoległej będzie mieć odpowiedni ParallelAuctionBuyer wpis:

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

  5. Jeśli aukcji równoległej nie można uruchomić, ponieważ w pamięci podręcznej nie ma informacji o pochodzącym z niej kupującym, nie można go dodać do bieżącej aukcji na urządzeniu. Wskazują na to żądanie z parametrem parallelized=True, w którym brakuje parametru Wpis ParallelAuctionBuyer dotyczący źródła kupującego z danej grupy zainteresowań. Licytujący, którzy wyrażają zainteresowanie, podając prawidłowe i kwalifikujące się Odpowiedzi na stawkę: InterestGroupBuyer będzie mieć odpowiedniego kupującego korzystającego z grupy zainteresowań źródeł dodanych do pamięci podręcznej, a te źródła będą mogły korzystać z przyszłe równoległe żądania z tej samej przeglądarki i tej samej domeny. Chęć udziału w aukcjach grup zainteresowań można wskazać w tych polach:

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

  6. Początki kupujących w pamięci podręcznej (które są uwzględniane w ramach interestGroupBuyers), w przypadku których licytujący nie wskazuje zamiaru do udziału w odpowiedzi na stawkę może otrzymać wywołanie kupującego z zaufanego serwera ale nie biorą udziału w aukcji równoległej.