Ta strona została przetłumaczona przez Cloud Translation API.

Protected Audience API (wcześniej FLEDGE)

W ramach Piaskownicy prywatności Chrome zaproponował Protected Audience API API – interfejs API w przeglądarce, który umożliwia reklamodawcom i firmom z branży technologii reklamowych wyświetlanie reklam kierowanych na grupy zainteresowań bez użycia plików cookie innych firm, przy jednoczesnej ochronie użytkowników przed śledzenie konwersji.

Chrome uruchamia źródło okres próbny dla interfejsu Protected Audience API. Uczestnicy tego programu mogą uczestniczyć w programie: testowania 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ę do obsługi reklam spersonalizowanych za pomocą interfejsu API bez korzystając z 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

Licytujący współpracuje z reklamodawcami, aby tworzyć grupy zainteresowań dla każdej reklamodawcy. Reklamodawcy często dodają tag licytującego do reklamodawcy, aby dodać przeglądarkę do grup zainteresowań.
Użytkownik odwiedza stronę reklamodawcy. Może ona zawierać dane licytującego .
Tag licytującego wywołuje interfejs Protected Audience API joinAdInterestGroup(). To wywołanie wysyła do przeglądarki żądanie dodania użytkownika do grupy zainteresowań.
Użytkownik odwiedza stronę internetową wydawcy. żądania przeglądarki użytkownika. Tag reklamy wydawcy Google.
Tag reklamy wydawcy Google wysyła kontekstowe żądanie reklamy do serwera Google.
Google wysyła kontekstowe pytania o stawkę do uczestniczących systemów licytujących. Zobacz Sekcja Zmiany w pytaniach o stawkę.
Licytujący zwraca wartość BidResponse z polem interest_group_bidding. Jeśli licytujący nie wskaże elementu interest_group_bidding, Google nie uwzględnij pochodzenie licytującego w kolumnie interestGroupBuyers w aukcji Odpowiedź na stawkę może też zawierać parametr interest_group_bidding.per_buyer_signals. Wartość per_buyer_signals zostanie przekazana do funkcji określania stawek licytującego podczas aukcji w przeglądarce. Zobacz Zmiany opcji określania stawek .
Google przeprowadza aukcję po stronie serwera i zwraca odpowiedź na stawkę przeglądarki. Aukcja po stronie serwera uwzględnia tradycyjne stawki po stronie serwera. Odpowiedź na stawkę może zawierać informacje o kontekstowej zwycięskiej stawce (jeśli dowolne).
Odpowiedź na stawkę zawiera konfigurację aukcji w przeglądarce. aukcji. Mogą to być sygnały kontekstowe od każdego kupującego uczestniczącego w programie. (wysłane przez: interest_group_bidding.per_buyer_signals), kontekstowych informacji o zwycięzcy oraz ustawieniach kryteriów kwalifikacji stawki.
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ący, którzy wcześniej zwrócili interest_group_bidding jako interestGroupBuyers w konfiguracji aukcji.
Google przekazuje per_buyer_signals każdego kwalifikującego się licytującego do Konfiguracja aukcji odbiorców.
Jeśli grupy zainteresowań danego licytującego określały parametr trustedBiddingSignalsUrl, przeglądarka wysyła żądanie do stron każdej grupy trustedBiddingSignalsUrl, aby pobrać sygnały w czasie rzeczywistym dla każdej grupy. Zobacz szczegóły w interfejsie Protected Audience API specyfikacja.
Przeglądarka wywołuje metodę generateBid() licytującego w przypadku każdej grupy zainteresowań które zostały włączone i mogą wziąć udział w aukcji w przeglądarce. Ten oblicza stawkę i wybiera kreację. generateBid() ma dostęp do wartość typu per_buyer_signals podaną przez licytującego i zaufanego licytującego dla danej grupy zainteresowań.
Przeglądarka wywołuje metodę scoreAd() sprzedawcy (w tym przypadku Google), aby przypisać ranking każdej stawce w aukcji reklam dla grupy zainteresowań. Stawki są ustalane w rankingu i filtrowane na podstawie zabezpieczeń wydawcy, zasad reklamowych itp. .
Przeglądarka przeprowadza aukcję z odpowiednimi stawkami grupy zainteresowań. stawka kontekstowa o najwyższej pozycji bierze udział w aukcji w przeglądarce.
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.
Jeśli wygra reklama kierowana na grupę zainteresowań, tag wydawcy Google wyrenderuje ją w iframe.

Szczegóły przepływu wyświetlania

Przed wyświetleniem reklam

Sprawdzanie kreacji

Kreacje muszą zostać sprawdzone i zatwierdzone przez Google, zanim zaczną się wyświetlać z: aukcji z użyciem Protected Audience API w przeglądarce. Można przesyłać kreacje do sprawdzenia za pomocą interfejsu Real-time Reporting 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. Wybranego elementu renderUrl nie można używać do renderowania reklam w imieniu: wielu 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 wszystkie źródła renderUrl kreacji przeznaczonej do grupy zainteresowań do sekcji Konto Authorized Buyers.

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 z zgodnie z dokumentem 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ą zatwierdzone przez 15 dni. Jeśli przesyłasz kreacje za pomocą raportu Czas rzeczywisty API ustalania stawek, musisz ponownie przesłać kreację po 15 dniach. Jeśli polegasz na automatycznego skanowania kreacji, są one automatycznie skanowane ponownie.

Identyfikator raportowania kupującego

Można dzielić dane raportowania (np. wyświetlenia) za pomocą wymiarów podane przez kupującego (np. identyfikator kampanii lub reklamodawcy). Aby dodać dla wydatków w grupie zainteresowań, podaj buyerAndSellerReportingId dla gdy dodasz urządzenie użytkownika do grupy zainteresowań. Zobacz dodatkowe . Szczegółowe informacje znajdziesz w artykule Protected Audience API. dokumentacji.

Poniżej znajdziesz przykład dodawania elementu buyerAndSellerReportingId do konfiguracja grupy zainteresowań:

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

buyer_reporting_id pojawi się jako nowy wymiar w raporcie autoryzowanych. Narzędzie do raportowania kupującego jako wymiar Identyfikator raportowania kupującego.

Aukcja po stronie serwera

Zmiany pytań o stawkę

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

Wcześniejsze połączenie protokołu Google RTB
Wcześniejszy link OpenRTB

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

Pytania o stawkę zawierają nowe pole: auction_environment.

Protokół Google RTB: BidRequest.adslot.auction_environment
OpenRTB: BidRequest.imp.ext.auction_environment

Za pomocą tego pola możesz rozróżnić możliwości realizacji wyświetleń, które do obsługi aukcji w ramach Protected Audience API w przeglądarce oraz tych, obsługują tylko tradycyjne aukcje na giełdach po stronie serwera. Wyliczenie auction_environment może mieć następujące wartości:

SERVER_SIDE_AUCTION (OpenRTB JSON: 0): tradycyjne aukcje po stronie serwera
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ń, a także ostatecznych przebiegów aukcji. w przeglądarce

Określanie rozmiaru boksu reklamowego z Protected Audience API

Pytanie o stawkę zawiera te pola, które pozwalają wyświetlić Wielkość boksu reklamowego związanego z odbiorcami:

Protokół Google RTB:
- BidRequest.adslot.interest_group_auction.width
- BidRequest.adslot.interest_group_auction.height
OpenRTB:
- BidRequest.imp.ext.interest_group_auction.width
- BidRequest.imp.ext.interest_group_auction.height

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

Ten rozmiar może się różnić od rozmiarów w żądaniu kontekstowym (Adslot.widthiAdslot.height lub w obiekcie OpenRTB: BidRequest.imp.banner.format).

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

Określanie możliwości renderowania reklam w ramach Protected Audience API

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). render_interest_group_ads pole w pytaniu o stawkę wskazuje, czy zwycięska reklama z Protected Audience API zostaną wyrenderowane.

Protokół Google RTB: BidRequest.adslot.interest_group_auction.render_interest_group_ads
OpenRTB: BidRequest.imp.ext.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ądarce, takiej jak google_user_id (BidRequest.user.id w OpenRTB) hosted_match_data (BidRequest.user.buyerid w polu OpenRTB). Obecność takich identyfikatorów w pytaniach o stawkę nadal będą podlegać polityki prywatności. Odradzamy stosowanie identyfikatorów opartych na plikach cookie do kierowania reklam i ustalania stawek w czasie testów, aby lepiej przygotować się zakup, gdy pliki cookie innych firm nie są już dostępne.

Google może też przeprowadzać eksperymenty na małą skalę, w których identyfikatory oparte na plikach cookie usunięte z pytań o stawkę objętych testami interfejsu Protected Audience API. Ten jest ocena potencjalnego wpływu wycofania plików cookie innych firm.

Testowanie wycofania plików cookie innych firm obsługiwane przez Chrome

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

Witryny i dostawcy mogą korzystać z testów obsługiwanych przez Chrome, aby testować swoje systemy 3PCD. W teście przeglądarki Chrome są przypisywane do grupy eksperymentalnej 3PCD, albo trybu A, albo trybu 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 małe wycinki ruchu przypisane do poszczególnych etykiet Google nie zawsze uwzględnia etykietę w kontekstach ograniczonych do prywatności.

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

Protokół Google RTB: BidRequest.device.cookie_deprecation_label
OpenRTB: BidRequest.device.ext.cdep

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ę:

Protokół Google RTB: BidResponse.interest_group_bidding
OpenRTB: BidResponse.ext.igbid

Musisz podać kontekstową odpowiedź na pytanie o stawkę. Odpowiedź nie jest wymagana na uwzględnij stawkę kontekstową. Obiekt InterestGroupBidding powinien zawierać origin właściciela grupy zainteresowań, który powinien być zgodny z jednym ze źródeł skonfigurowane przez licytującego na jego koncie. Element origin jest dodawany do aukcji ma wartość interestGroupBuyers w przypadku wywołania tagu wydawcy Google. runAdAuction()

Propaguj sygnały kontekstowe kupującego (sygnały według 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:

RTB Google: BidResponse.interest_group_bidding.per_buyer_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata

Propaguj kontekstowe sygnały renderujące kupującego

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 kontekstową odpowiedź na pytanie o stawkę, którą Google zastąpi w przypadku zwycięskiego interesu. pogrupuj renderowany URL, 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:

RTB Google: BidResponse.interest_group_bidding.interest_group_buyer.rendering_signals
OpenRTB: BidResponse.ext.igbid.igbuyer.rsig

Można uwzględnić maksymalnie 3 zbiory sygnałów renderowania z różnymi sufiksami makr w odpowiedzi na stawkę, aby odróżnić różne sygnały. Może to być na przykład sufiks. mogą służyć do dopasowywania konkretnego zestawu sygnałów, który ma zastosowanie tylko do kreacji z odpowiednim makrem w URL-u renderowania, ograniczając przesyłanie danych. rozmiaru.

Kupujący z grupy zainteresowań zostanie odrzucony z udziału w programie aukcja odbiorców, jeśli sygnały nie są bezpieczne w adresie URL, sufiksy makr nie są unikalne; lub więcej niż 3 zbiory 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 złagodzeń wspieranych podczas testowania interfejsu Protected Audience API przez Google dla swoich partnerów RTB, w każdym z nich możesz podać oczekiwaną maksymalną wartość stawki kontekstową odpowiedź na pytanie o stawkę. Oczekiwana maksymalna stawka to maksymalna stawka, która funkcja określania stawek powinna zwrócić Twoje wyniki. Jeśli zwycięska stawka raportowana z aukcja w przeglądarce przekroczy tę kwotę, zwycięska stawka nie będzie brana pod uwagę 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:

Protokół Google RTB: BidResponse.interest_group_bidding.interest_group_buyers.max_bid_cpm_micros (wyrażony w mikroCPM)
OpenRTB: BidResponse.igbid.igbuyer.maxbid(wyrażony w jednostkach waluty CPM)

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:

Protokół Google RTB: BidResponse.interest_group_bidding.interest_group_buyers.billing_id
OpenRTB: BidResponse.igbid.igbuyer.billing_id

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

Protokół Google RTB: BidRequest.adslot.matching_ad_data.billing_id
OpenRTB: BidRequest.imp.ext.billing_id

Jeśli identyfikator płatności, do którego chcesz przypisać wyświetlenia z określaniem stawek w grupie zainteresowań, to nie oznacza to, że licytujący nie weźmie udziału w aukcji z Protected Audience API.

Konta podrzędne mogą mieć maksymalnie 2 identyfikatory płatności. Kupujący może użyć jednej z tych metod identyfikator płatności powiązany z wydatkami kontekstowymi, a drugi – wydatki 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. Zwróć się o pomoc menedżer konta, aby zmienić budżet dla identyfikatora płatności grupy zainteresowań.

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: URL wyrenderowany w celu wyświetlenia kreacji, jeśli stawka wygrywa aukcji. Google musi sprawdzić i zatwierdzić ten adres URL – w przeciwnym razie zostanie on odfiltrowany z aukcji.
allowComponentAuction: musi być true. Obecnie Google obsługuje testy aukcji wielu sprzedawców.

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 aukcji w przeglądarce są podawane w jednostkach CPM wybranej waluty.

Walutę stawki należy podać zarówno w kontekstowej odpowiedzi na stawkę, jak i w zwracaną wartość generateBid i musi być prawidłowym kodem alfa ISO 4217, takim „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 RTB Google użyj nowego pola currency w polu 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ę. Uzupełnij nową właściwość bidCurrency w: Wartość zwrócona 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

Egzekwowanie zasad dotyczących kreacji i ustawień wydawców może być bardziej restrykcyjne w przypadku stawki grup zainteresowań w przeglądarce podczas testowania interfejsu Protected Audience API pod kątem RTB partnerów.

Obsługa aktu prawnego 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 pole „Poproś kupujących o wyświetlanie reklam tylko z dynamicznymi reklamami w wyszukiwarce informacji o przejrzystości w mojej witrynie lub aplikacji w Europejskim Obszarze Gospodarczym” element sterujący jest włączony przez wydawcy, nabywcy grup zainteresowań mogą określić, jakie możliwości wymagane do zapewnienia przejrzystości dla kupujących, przez zaznaczenie następujących pól na stronie otrzymane pytania o stawkę: BidRequest.dsa.dsa_support i BidRequest.dsa.publisher_rendering_support dla protokołu Google Authorized Buyers i BidRequest.regs.dsa.required i BidRequest.dsa.pubrender w przypadku protokołu OpenRTB.

Gdy licytujący, który chce uczestniczyć w aukcjach Protected Audience API, otrzymuje w pytaniu o stawkę sygnał, że w przypadku reklam DSA trzeba wyświetlić przejrzystość informacji DSA wyświetlanych przy użyciu interfejsu Protected Audience API, mogą odpowiednio wyświetlić wymagane informacje i określić za pomocą parametru BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_render dla protokołu Google Authorized Buyers, BidResponse.ext.igbid.igbuyer.dsaadrenderw przypadku protokołu OpenRTB. 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 uzupełnia tych argumentów:

auctionSignals
sellerSignals

Użyj pola reportWin(), by zgłosić kupującemu wynik aukcji.

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 aukcji dla określonej grupy zainteresowań ale przed renderowaniem makra są zastępowane odpowiednimi . renderUrl w aukcji na urządzeniu może obejmować te elementy :

`${GDPR}`	Rozwija się do 0, jeśli RODO nie ma zastosowania, lub 1, jeśli RODO ma zastosowanie. Zobacz dokumentację.
`${GDPR_CONSENT_XXXX}`	Rozwija się do przejrzystości i Ciąg tekstowy dotyczący zgody powiązany z żądaniem. Jeśli sekcja Transparency & Ciąg tekstowy dotyczący zgody użytkownika jest pusty lub nieprawidłowy. To makro się nie rozwija. Użyj tego makra, aby przekazać ciąg tekstowy dotyczący przejrzystości i zgody do dostawcy zarejestrowanego na globalnej liście dostawców IAB w adresie URL. Zastąp `XXXX` identyfikatorem GVL firmy IAB zarejestrowanym na globalnej liście dostawców firmy IAB 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ć jest zablokowany, jeśli dostawca zarejestrowany na globalnej liście dostawców IAB powiązany z identyfikatorem GVL firmy IAB nie ma zgody użytkownika. Makro `${GDPR_CONSENT_XXXX}` powinno wystąpić tylko raz w ciągu `renderUrl`.
`${ADDL_CONSENT}`	Rozwija do Dodatkowe Ciąg tekstowy dotyczący zgody powiązany z żą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 obiekt zastępczy `buyer.origin.example` elementem początkowym nabywcy grupy zainteresowań, który powinien odpowiadać `interest_group_buyers.origin` w odpowiedzi na 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().

Ponieważ zdarzenie używane przez Google do zliczania wyświetleń w ramach Protected Audience API aukcje w przeglądarce mogą się różnić od zdarzenia używanego do zliczania konwersji przez partnerów kupujących RTB, liczba wyświetleń może się różnić.

Jednym z celów Google dotyczących testowania interfejsu Protected Audience API jest identyfikowanie aby zmniejszyć te rozbieżności.

Atrybucja wyświetleń podlegających rozliczeniu

Wszystkie wydatki licytującego na aukcje w ramach Protected Audience API w przeglądarce wynoszą przypisane do jednego konta licytującego na podstawie mapowania z zainteresowania źródeł właściciela grupy skonfigurowane dla licytującego. 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.

Konto może nadal uczestniczyć w aukcjach kontekstowych po stronie serwera po osiągnięcie limitu w ramach Protected Audience API. Na przykład konto licytującego, które dociera do limit Protected Audience API może otrzymać pytanie o stawkę z parametrem auction_environment = SERVER_SIDE_AUCTION (OpenRTB: 0) nawet wtedy, gdy pytanie o stawkę kwalifikuje się do aukcja z Protected Audience API.

Informacje zwrotne w czasie rzeczywistym i minimalna stawka potrzebna do wygrania

Licytujący, którzy zgodzili się na otrzymywanie opinie w czasie rzeczywistym otrzyma opinię dla nabywców grup zainteresowań, którzy poprosili o dołączenie do aukcja z Protected Audience API na urządzeniu. Każdy kupujący grupy zainteresowań, który licytujący określony w odpowiedzi na stawkę otrzyma 1 obiekt opinii niezależnie od tego, stawki, którą kupujący grupy zainteresowań określa w aukcji z Protected Audience API. następujące informacje będą dostępne w opiniach kupujących korzystających z grupy zainteresowań obiekt:

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 w przypadku kupującego z grupy zainteresowań, by przebić najwyższej stawki po stronie serwera w całej aukcji.
Kod stanu kupującego z grupy zainteresowań. Możliwe kody stanu: zdefiniowane w interest-group-buyer-status-codes.txt.

Zapoznaj się z dokumentacją protokołu dotyczącą RTB w Authorized Buyers, i rozszerzenia OpenRTB dla poszczególnych nazw pól.

Powiadomienie o opinii o stawce

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ć przyczyny, dla których stawki mogły zostać odfiltrowane w aukcji Protected Audience w przeglądarce oprócz innych, informacje na temat stawki 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 (BidRequest.google_query_id w protokole Authorized Buyers, BidRequest.ext.google_query_id w protokole OpenRTB), która została wysłana Pytanie o stawkę kontekstową z włączoną usługą Protected Audience API.
%%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 stan kreacji .

Oto przykładowy statyczny adres URL, 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 o stawce to funkcja tymczasowa zależna od tymczasowy interfejs API ForDebuggingOnly.

TURTLEDOVE na poziomie produktu

Reklamy złożone z wielu elementów lub na poziomie produktu TURTLEDOVE (PLTD) jest obsługiwany w przypadku partnerów Google RTB podczas korzystania z Protected Audience API i testowania. Jeśli zamierzasz przeprowadzić testy, podczas integracji poinformuj o tym menedżera konta. PLTD, ponieważ wymagane są dodatkowe zasoby i konfiguracja.

Wprowadzenie

Aby przetestować interfejs Protected Audience API:

Kroki

Wypełnij formularz prośby. aby dołączyć do eksperymentu w ramach Protected Audience API.
Po przesłaniu formularza skontaktuj się z menedżerem konta lub plikiem zgłoszenia w Centrum pomocy dla autoryzowanych kupujących pomocy.
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

W celu ustalania stawek za reklamy na poziomie produktu (reklamy składające się z wielu elementów) w aukcjach interfejsu Protected Audience API musisz spełniać 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 sposób renderowania reklam był reprezentatywny, możesz skorzystać z validation=True parametr zapytania 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().
Wybieranie źródeł właścicieli grupy zainteresowań i dodawanie ich do programu Authorized Buyers koncie.
- Pochodzenie właściciela grupy zainteresowań powinno odpowiadać punktom początkowym, w których Hostowane funkcje generateBid() są hostowane.
- Skontaktuj się z menedżerem konta lub prześlij zgłoszenie, korzystając z Autoryzowanego Centrum pomocy dla kupujących, wykonaj tę czynność.
Konfigurowanie kierowania wstępnego w przypadku zasobów reklamowych powiązanych z interfejsem Protected Audience API i testowania.
Przesłać kreacje do sprawdzenia i zatwierdzenia za pomocą narzędzia Kreacje API.
(Opcjonalnie) Skonfiguruj punkty końcowe zaufanych sygnałów określania stawek.
(Opcjonalnie) Skonfiguruj stronę reklamodawcy testowego, aby inżynierowie Google mogli dodawać jego przeglądarki do grup zainteresowań należących do pochodzeniu danych. Dzięki temu możemy ręcznie uruchamiać aukcje z użyciem Protected Audience API.
(Opcjonalnie) Włącz przesyłanie opinii w czasie rzeczywistym na swoim koncie, aby otrzymywać opinie na temat: kupujących grupy zainteresowań, których dotyczy prośba o uwzględnienie w Protected Audience API aukcji.
(Opcjonalnie) Skontaktuj się ze swoim menedżerem konta i poproś o skonfigurowanie statycznego adresu URL otrzymać powiadomienie między serwerami z informacją o stawce z użyciem Protected Audience API. informacje zwrotne o stanie stawki z Protected Audience API na urządzeniu. pomaga w debugowaniu 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:

Używaj Chrome 101 lub nowszej wersji.
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.
Prześlij kreację do zatwierdzenia za pomocą określania stawek w czasie rzeczywistym API.
Aby dodać przeglądarkę do listy należącej do licytującego, skorzystaj ze strony reklamodawcy udostępnionego przez licytującego grupy zainteresowań.
Aby aktywować chroniona, użyj tej udostępnionej przez Google strony wydawcy testowego Aukcja odbiorców:

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

Grupa zainteresowań w przeglądarce musi oferować wystarczająco wysoką stawkę, aby wygrać aukcję, ponieważ mogą konkurować ze standardowymi stawkami po stronie serwera. Google udostępnia też dedykowaną testową stronę wydawcy dla każdego partnera, przy czym tylko dany partner mogą brać udział w aukcji. Może być łatwiej wygrać aukcji w przeglądarce na stronie partnera.
Zweryfikuj te kwestie:
1. Wyświetlana jest oczekiwana zwycięska reklama.
2. Wynik aukcji jest wysyłany po stronie serwera – co oznacza, że zwycięzca licytuje otrzymuje ping zwrotny od reportWin().
3. Testowa konsola strony wydawcy rejestruje komunikat debugowania w przypadku każdej stawki z następujące informacje:
  - renderUrl: URL renderowania stawki.
  - interestGroupOwner: właściciel grupy zainteresowań, dla której jest ustalana stawka.
  - accepted: to pole ma wartość true, jeśli stawka została zaakceptowana, a false jeśli stawka została odrzucona przez scoreAd().
  - externalBidStatus: kod stanu, jeśli stawka została odrzucona w ciągu scoreAd() Wartości to stan kreacji .

Etap 2. (Opcjonalnie) Eksperyment nierenderujący

Gdy Google i partner ręcznie zweryfikują, czy partner może uczestniczyć w aukcji z Protected Audience API, Google umożliwia partnerowi do kolejnego etapu testowania.

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 wyrenderowano. Dzięki temu możemy przetestować integrację na dużą skalę.

Skontaktuj się ze swoim menedżerem konta lub prześlij zgłoszenie za pośrednictwem Authorized Buyers Centrum pomocy. 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. Uczestniczący licytujący stawki w przeglądarce konkurują ze standardowymi stawkami. stawki.

Skontaktuj się ze swoim menedżerem konta lub prześlij zgłoszenie za pośrednictwem Authorized Buyers Centrum pomocy. 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 skraca czas oczekiwania na zakończenie aukcji inicjowania kontekstowego żądania reklamy równolegle z żądaniami wysyłanymi do zaufane serwery kupującego określono w funkcji 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 reklam

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

Wymagania dotyczące kupujących w ramach grupy 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ć kupującego jako zaufanego, wywołań serwera, navigator.runAdAuction wymaga, aby para klucz-wartość Wymagany jest parametr interestGroupBuyers przekazywane jako wartość, a pozostałe parametry aukcji akceptują JavaScript. Obietnice, które można zrealizować po reakcji kontekstowej na reklamę. 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 w pamięci podręcznej tagu wydawcy Google, w przeglądarce użytkownika parametr interestGroupBuyers z poprzedniego Uruchomienia navigator.runAdAuction w tej samej domenie.

W przypadku równoległego stosowania należy pamiętać o kilku ważnych kwestiach:

sygnały aukcji, które nie są potrzebne w przypadku żądań z zaufanego serwera kupującego. takich jak perBuyerSignals, można nadal określać w odpowiedziach na pytania o stawkę RTB. tak samo jak w przypadku aukcji nierównoległych. Po spełnieniu obietnic dotyczących tych sygnałów pozostałe kroki procedury aukcja na urządzeniu zakończy się tak samo jak przebieg aukcji.
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 wygasła, Google uruchamia nierównoległą aukcją Protected Audience API, która wykorzystuje zamiar kupującego do wziąć udział w aukcji nierównoległej, aby zbudować pamięć podręczną kupujących grupy zainteresowań.
Jeśli w przypadku bieżącego wydawcy w pamięci podręcznej jest zapisany 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
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
Jeśli prowadzona jest równoległa aukcja, ale nie podano konkretnego źródła kupującego pamięci podręcznej, wtedy nie będzie można dodać danego kupującego do bieżącego aukcji. 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. Zamiar uczestniczenia w aukcjach opartych na grupach zainteresowań można wskazać w tych polach:
- Protokół Google RTB: BidResponse.adslot.interest_group_bidding.interest_group_buyers
- OpenRTB: BidResponse.ext.igbid.igbuyer
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.