Protected Audience API (wcześniej FLEDGE)

W ramach Piaskownicy prywatności Chrome zaproponował interfejs Protected Audience API – działający w przeglądarce interfejs API, 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 witrynach.

Chrome przeprowadza test origin interfejsu Protected Audience API. Użytkownicy Authorized Buyers mogą uczestniczyć w testowaniu interfejsu Protected Audience API w zasobach reklamowych wydawcy w usłudze Ad Manager. Testując interfejs Protected Audience API, licytujący mogą:

  • Powtarzaj i poznawaj skuteczność przepływów w interfejsie Protected Audience API.
  • Podziel się opinią na temat potencjalnych ulepszeń interfejsu API na forach publicznych, np. w GitHub.
  • przygotować się do obsługi reklam spersonalizowanych przez interfejs API bez polegania na plikach cookie innych firm.

Kupujący w Authorized Buyers, którzy chcą przeprowadzać testy, powinni zapoznać się z sekcją dotyczącą wprowadzenia, aby uzyskać więcej informacji.

Podsumowanie procesu wyświetlania

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

Schemat przepływu

  1. Licytujący współpracuje ze swoimi reklamodawcami, aby utrzymywać grupy zainteresowań 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 licytującego.
  3. Tag licytującego wywołuje interfejs Protected Audience API joinAdInterestGroup(). To wywołanie prosi przeglądarkę o dodanie użytkownika do grupy zainteresowań.
  4. Użytkownik odwiedza stronę internetową wydawcy. Przeglądarka użytkownika wysyła żądanie 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 uczestniczących w programie. Więcej informacji znajdziesz w sekcji Zmiany w pytaniach o stawkę.
  7. Licytujący zwraca wartość BidResponse z polem interest_group_bidding. Jeśli licytujący nie określi pola interest_group_bidding, Google nie uwzględni go w parametrze interestGroupBuyers w konfiguracji aukcji. Odpowiedź na pytanie o stawkę może też zawierać parametr interest_group_bidding.per_buyer_signals. per_buyer_signals zostaną przekazane do funkcji określania stawek licytującego podczas aukcji w przeglądarce. Więcej informacji znajdziesz w sekcji Zmiany odpowiedzi na stawkę.
  8. Google przeprowadza aukcję po stronie serwera i zwraca przeglądarce odpowiedź na pytanie o stawkę. Aukcja po stronie serwera uwzględnia tradycyjne stawki po stronie serwera. Odpowiedź na pytanie o stawkę może zawierać informacje o zwycięskiej stawki kontekstowej (jeśli istnieje).
  9. Odpowiedź na stawkę zawiera konfigurację aukcji dla aukcji w przeglądarce. Mogą one obejmować sygnały kontekstowe od każdego kupującego uczestniczącego w programie (przesłane przez interest_group_bidding.per_buyer_signals), kontekstowe informacje o zwycięzcach i ustawienia uprawnień do ustalania stawek.
  10. Tag wydawcy Google wywołuje interfejs Protected Audience API runAdAuction(), aby rozpocząć aukcję grupy zainteresowań na urządzeniu. Google uwzględnia tylko tych kupujących, którzy wcześniej zwrócili w konfiguracji aukcji wartość interest_group_bidding jako interestGroupBuyers.
  11. Google przekazuje per_buyer_signals każdego kwalifikującego się licytującego do konfiguracji aukcji w ramach Protected Audience API.
  12. Jeśli grupy zainteresowań danego licytującego mają określony parametr trustedBiddingSignalsUrl, przeglądarka wysyła do trustedBiddingSignalsUrl każdej grupy żądanie, aby pobrać z każdej z nich sygnały w czasie rzeczywistym. Więcej informacji znajdziesz w specyfikacji interfejsu Protected Audience API.
  13. Przeglądarka wywołuje funkcję generateBid() licytującego w przypadku każdej grupy zainteresowań, która uczestniczy w aukcji w przeglądarce i może wziąć udział w aukcji. W ten sposób obliczana jest stawka i wybierana jest kreacja. generateBid() ma dostęp do danych per_buyer_signals dostarczonych przez licytującego oraz do zaufanych sygnałów ustalania stawek dla danej grupy zainteresowań.
  14. Przeglądarka wywołuje funkcję scoreAd() sprzedawcy (w tym przypadku Google), aby przypisać pozycję do każdej stawki biorącej udział w aukcji reklam kierowanej na grupę zainteresowań. Stawki są wyznaczane w rankingu i odfiltrowywane na podstawie zabezpieczeń wydawcy, zasad dotyczących reklam i innych ograniczeń.
  15. Przeglądarka przeprowadza aukcję z odpowiednimi stawkami grupy zainteresowań. Najwyżej oceniana stawka kontekstowa bierze udział w aukcji w przeglądarce.
  16. Jeśli po zakończeniu aukcji wyłoni zwycięzcę aukcji, przeglądarka wywołuje metodę reportResult() sprzedawcy oraz reportWin() licytującego, aby powiadomić obie strony o zwycięstwie aukcji w przeglądarce.
  17. Jeśli wygra reklama kierowana na grupę zainteresowań, tag wydawcy Google renderuje ją w elemencie iframe.

Szczegóły procesu wyświetlania

Przed wyświetleniem reklamy

Sprawdzanie kreacji

Aby kreacje mogły być wyświetlane w ramach aukcji w przeglądarce pod kątem ochrony odbiorców, muszą zostać sprawdzone i zatwierdzone przez Google. Kreacje możesz przesyłać do sprawdzenia za pomocą interfejsu API określania stawek w czasie rzeczywistym lub automatycznego skanowania kreacji. Kreacje w ramach aukcji reklam kierowanych na grupy zainteresowań w ramach Protected Audience API w przeglądarce muszą zawierać do sprawdzenia renderUrls. Przesłany plik renderUrl powinien odpowiadać parametrowi renderUrl używanemu w aukcji reklam kierowanych na grupy zainteresowań. Każda kreacja może mieć tylko 1 adres URL renderowania na licytującego.

Real-time Bidding API

Licytujący mogą przesyłać kreacje na potrzeby ustalania stawek na potrzeby grupy zainteresowań za pomocą interfejsu API określania stawek w czasie rzeczywistym.

Automatyczne skanowanie kreacji

Licytujący mogą skonfigurować automatyczne skanowanie kreacji, które nie zostały przesłane za pomocą interfejsu API określania stawek w czasie rzeczywistym.

Jeśli skonfigurujesz automatyczne skanowanie kreacji, Google znajdzie kreacje w aukcji w przeglądarce i skanuje je automatycznie, aby kwalifikowały się do przyszłych aukcji.

Aby włączyć automatyczne skanowanie kreacji:

  • Dodaj wszystkie źródła kreacji z grupy zainteresowań (renderUrl) do konta Authorized Buyers.

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

    Authorized-Buyers-Creative-ID

    ciąg znaków

    Identyfikator kreacji przypisany do 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, zakodowane 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 przez interfejs API określania stawek w czasie rzeczywistym, musisz je przesłać ponownie po 15 dniach. Jeśli korzystasz z automatycznego skanowania kreacji, proces skanowania odbywa się automatycznie ponownie.

Identyfikator raportowania kupującego

Możesz dzielić dane raportowania (np. wyświetlenia) na segmenty według wymiarów określonych przez kupującego (np. identyfikatora kampanii lub identyfikatora reklamodawcy). Aby dodać wymiar wydatków na grupę zainteresowań, podczas dodawania do grupy zainteresowań określ buyerAndSellerReportingId dla reklamy. Więcej informacji znajdziesz w dokumentacji Protected Audience API.

Poniżej znajdziesz przykład dodania dyrektywy buyerAndSellerReportingId do konfiguracji grupy zainteresowań:

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

buyer_reporting_id pojawi się jako nowy wymiar w narzędziu do raportowania Authorized Buyers jako wymiar Identyfikator raportowania kupującego.

Aukcja po stronie serwera

Zmiany w pytaniach o stawkę

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

Wskaż obsługę aukcji dla grupy zainteresowań

Pytania o stawkę mają nowe pole: auction_environment.

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

Możesz używać tego pola do odróżnienia możliwości realizacji wyświetleń, które obsługują aukcję w ramach Protected Audience API w przeglądarce, od tych, które obsługują tylko tradycyjną aukcję po stronie serwera. Wyliczenie auction_environment może mieć te wartości:

  • SERVER_SIDE_AUCTION (format JSON OpenRTB: 0): tradycyjne aukcje po stronie serwera
  • ON_DEVICE_INTEREST_GROUP_AUCTION (OpenRTB JSON: 1): żądania z obsługą Protected Audience API, w ramach których na serwerach giełdy uruchamiana jest aukcja kontekstowa, a w przeglądarce jest przeprowadzana w przeglądarce aukcja oparta na grupie zainteresowań.
Określ rozmiar boksu reklamowego w ramach Protected Audience API

Pytanie o stawkę zawiera te pola, w których podajesz rozmiar boksu reklamowego Protected Audience API:

  • 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 wskazują w pikselach rozmiar boksu reklamowego na potrzeby aukcji Protected Audience API.

Może się on różnić od rozmiarów w przypadku żądania kontekstowego (Adslot.widthorazAdslot.height lub OpenRTB: BidRequest.imp.banner.format).

Żądanie kontekstowe może mieć wiele rozmiarów. Zwycięska reklama w aukcji na urządzeniu powinna wypełnić tylko 1 boks o stałym rozmiarze.

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

Reklamy w ramach Protected Audience API mogą się wyświetlać lub nie, w zależności od bieżącego etapu integracji (patrz eksperyment dotyczący braku renderowania). Pole render_interest_group_ads w pytaniu o stawkę wskazuje, czy zwycięska reklama w ramach Protected Audience API zostanie wyrenderowana.

  • Protokół Google RTB: BidRequest.adslot.interest_group_auction.render_interest_group_ads
  • OpenRTB: BidRequest.imp.ext.interest_group_auction.render_interest_group_ads
Ogranicz korzystanie z identyfikatorów użytkowników do minimum.

Kontekstowe pytania o stawkę objęte testami Protected Audience API mogą nadal zawierać tradycyjne identyfikatory oparte na plikach cookie, o ile są dostępne w przeglądarce, takie jak pola google_user_id (BidRequest.user.id w OpenRTB) i hosted_match_data (BidRequest.user.buyerid w OpenRTB). Używanie takich identyfikatorów w pytaniach o stawkę będzie nadal podlegało obowiązującej polityce prywatności. Nie zalecamy używania identyfikatorów opartych na plikach cookie do kierowania reklam i określania stawek podczas testów, aby lepiej przygotować się do efektywnego zakupu, gdy pliki cookie innych firm przestaną być 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.

W ramach przygotowań do wycofania plików cookie innych firm (3PCD) w 2024 r. wprowadziliśmy w Chrome testy obsługiwane przez Chrome.

Witryny i dostawcy mogą korzystać z testów przeprowadzanych w Chrome do testowania systemów w trybie 3PCD. W teście przeglądarki Chrome są przypisywane do grupy eksperymentalnej 3PCD w Trybie A lub B. Każda przeglądarka ma przypisaną spójną etykietę odpowiadającą określonej grupie eksperymentalnej 3PCD, do której można uzyskać dostęp za pomocą interfejsu API Chrome w przeglądarce.

Google przekazuje niezmodyfikowaną etykietę z interfejsu Chrome API w pytaniu o stawkę RTB. Ze względu na niewielkie wycinki ruchu przypisanej do danej etykiety Google nie zawsze uwzględnia ją 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 grupy zainteresowań w aukcji

Odpowiadasz za wyraźne wskazanie zamiaru udziału w aukcji w przeglądarce przez zwrócenie obiektu InterestGroupBidding w odpowiedzi na pytanie o stawkę kontekstową.

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

Musisz podać odpowiedź na pytanie o stawkę kontekstową. Odpowiedź nie musi zawierać stawki kontekstowej. Obiekt InterestGroupBidding powinien zawierać wartość origin właściciela grupy zainteresowań, która powinna być zgodna z jednym ze źródeł skonfigurowanych przez licytującego na jego koncie. Element origin jest dodawany do parametru interestGroupBuyers konfiguracji aukcji, gdy tag wydawcy Google wywołuje metodę runAdAuction().

Propagowanie sygnałów kontekstowych kupującego (perBuyerSignals)

Możesz uwzględnić sygnały kupującego w odpowiedzi na pytanie o stawkę kontekstową, która jest rozpowszechniana przez Google jako obiekt JSON do jego funkcji ustalania stawek na urządzeniu za pomocą argumentu perBuyerSignals. W zależności od protokołu można ją umieścić w odpowiedzi na stawkę w tych polach:

  • RTB Google: BidResponse.interest_group_bidding.per_buyer_signals
  • OpenRTB: BidResponse.ext.igbid.igbuyer.buyerdata
Określanie maksymalnej stawki w przeglądarce

W ofercie pakietowej Ochrona odbiorców obliczanie stawek i końcowa aukcja powinny odbywać się lokalnie na urządzeniu. Może to prowadzić do powstania potencjalnych nadużyć, które mogą wpłynąć na integralność wyników ostatecznej aukcji, np. o zwycięską stawkę.

W ramach łagodzenia skutków działania interfejsu Protected Audience API przez Google przeprowadzanych przez Google na potrzeby partnerów RTB możesz podać oczekiwaną maksymalną wartość stawki w każdej odpowiedzi na stawkę kontekstową. Oczekiwana maksymalna stawka to maksymalna stawka, którą powinna zwrócić funkcja określania stawek. Jeśli zwycięska stawka zarejestrowana w aukcji w przeglądarce przekracza tę kwotę, zwycięska stawka nie zostanie policzona jako zdarzenie podlegające rozliczeniu. To podejście może ulec zmianie.

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

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

Licytujący musi wybrać identyfikator płatności, aby przypisać wyświetlenia stawki grupy zainteresowań w tych polach:

  • 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 można przypisać wyświetlenia w ramach ustalania stawek w grupie zainteresowań, nie zostanie podany, licytujący nie będzie brać udziału w aukcji Protected Audience.

Konta podrzędne mogą mieć maksymalnie 2 identyfikatory płatności. Kupujący może użyć jednego identyfikatora płatności do wydatków kontekstowych, a drugiego do wydatków na grupę zainteresowań. Jeśli chcesz skonfigurować 2 identyfikatory płatności na koncie podrzędnym, skontaktuj się ze swoim menedżerem konta.

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

Identyfikatory płatności wszystkich kont podrzędnych z dostępnym budżetem kwalifikującym się do ustalania stawek za wyświetlenia są widoczne w pytaniu o stawkę na potrzeby wyboru atrybucji wydatków. Skontaktuj się ze swoim menedżerem konta, aby zmienić budżet dla identyfikatora płatności grupy zainteresowań.

Podczas aukcji w przeglądarce

Generuj stawki w przeglądarce

Użyj narzędzia generateBid(), by generować stawki w przeglądarce.

Google podaje następujące parametry:

  • auctionSignals: puste
  • perBuyerSignals: obiekt JavaScript zawierający te same sygnały, które system licytujący dostarczył w odpowiedzi kontekstowej.

Wyświetlane są te parametry:

  • ad: Google ignoruje to pole.
  • bid: stawka numeryczna, która bierze udział w aukcji. Musi być wyrażona w jednostkach CPM (nie w części mikro).
  • render: URL wyrenderowany do wyświetlania kreacji, jeśli stawka wygra aukcję. Google musi sprawdzić i zatwierdzić ten URL. W przeciwnym razie zostanie on odfiltrowany z aukcji.
  • allowComponentAuction: wymagany jest true. Google obsługuje obecnie testowanie aukcji wielu sprzedawców.

Oto przykład:

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

Objaśnienie funkcji generateBid() znajdziesz w sekcji dotyczącej określania stawek na urządzeniu w specyfikacji Protected Audience API.

Waluta stawki

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

Waluta stawki musi być podana zarówno w odpowiedzi na pytanie o stawkę kontekstową, jak i w zwracanej wartości generateBid. Musi też być prawidłowym kodem alfanumerycznym ISO 4217, np. „USD”, „EUR” lub „JPY”.

W obiekcie 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 Google RTB użyj nowego pola currency w komunikacie InterestGroupBuyer w odpowiedzi na stawkę.

Oto przykład:

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

Funkcje generateBid licytujących muszą zwracać stawki w tej samej walucie, która została określona w odpowiedzi na pytanie o stawkę kontekstową. Wypełnij nową właściwość bidCurrency w wartości zwracanej przez parametr generateBid:

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

Jeśli waluta w odpowiedzi na pytanie o stawkę kontekstową jest inna niż waluta zwracana przez funkcję generateBid lub któraś z nich zwróci nieprawidłową walutę, stawka zostanie odfiltrowana przed aukcją.

Kontrole jakości reklamy

Egzekwowanie zasad dotyczących kreacji i ustawień wydawcy może być bardziej restrykcyjne w przypadku stawek za określone grupy zainteresowań w przeglądarce podczas testów interfejsu Protected Audience API w przypadku partnerów korzystających z RTB.

Pomoc dotycząca aktu prawnego o usługach cyfrowych

Zgodnie z art. 26 aktu o usługach cyfrowych wydawcy mogą wymagać od kupujących udostępniania informacji o przejrzystości w reklamie. Gdy wydawca włączy ustawienie „Poproś kupujących, aby wyświetlały się w mojej witrynie lub aplikacji w Europejskim Obszarze Gospodarczym tylko reklamy z informacjami o przejrzystości reklam DSA w mojej witrynie lub aplikacji w Europejskim Obszarze Gospodarczym”, kupujący korzystający z grup zainteresowań mogą określić, jakie możliwości będą musieli zadbać o przejrzystość kupującego. W tym celu przy odbieraniu pytań o stawkę zanotują te pola: BidRequest.dsa.dsa_support i BidRequest.dsa.publisher_rendering_support (w przypadku protokołu Google Authorized Buyers) oraz BidRequest.regs.dsa.required i BidRequest.dsa.pubrender (w przypadku protokołu OpenRTB).

Gdy licytujący, który chce wziąć udział w aukcjach interfejsu Protected Audience API, otrzyma w pytaniu o stawkę sygnał, że w przypadku reklam wyświetlanych przez Protected Audience API musi wyświetlić się przejrzystość DSA, powinien ocenić, czy może prawidłowo wyświetlać wymagane informacje, i określić, czy chodzi o BidResponse.interest_group_bidding.interest_group_buyers.dsa_buyer_renderprotokół Google Authorized Buyers czy BidResponse.ext.igbid.igbuyer.dsaadrenderprotokół OpenRTB. W przeciwnym razie kupujący nie zostanie uwzględniony w aukcji Protected Audience API.

Więcej informacji na temat przejrzystości reklam na mocy aktu o usługach cyfrowych znajdziesz w artykule w Centrum pomocy: Wspieranie aktu prawnego o usługach cyfrowych.

Filtrowanie stawek

Podczas aukcji na urządzeniu Google egzekwuje zasady dotyczące wydawców i zasady reklamowe.

Po aukcji w przeglądarce

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

Google nie wypełni tych argumentów:

  • auctionSignals
  • sellerSignals

Aby zgłosić kupującemu wynik aukcji, użyj funkcji reportWin().

Więcej informacji znajdziesz w sekcji dotyczącej raportów kupującego na temat renderowania i zdarzeń reklamowych w objaśnieniu dotyczącym interfejsu Protected Audience API.

Makra

Element renderUrl, który odwołuje się do kreacji Protected Audience API, może zawierać co najmniej 1 zmienną nazywaną makrami. Po zakończeniu aukcji dla grup zainteresowań, ale przed renderowaniem makra są zastępowane odpowiednimi wartościami. Zdarzenia renderUrl używane w aukcji na urządzeniu mogą zawierać te makra:

${GDPR} Rozwija się do 0, jeśli RODO nie ma zastosowania, lub do 1, jeśli RODO ma zastosowanie. Zobacz dokumentację.
${GDPR_CONSENT_XXXX} Rozwija się do ciągu tekstowego dotyczącego przejrzystości i zgody na przetwarzanie danych 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.

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 zarejestrowanego dostawcy 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 podanym przez Ciebie identyfikatorem GVL firmy IAB nie ma zgody użytkownika.

Makro ${GDPR_CONSENT_XXXX} powinno występować tylko raz w obrębie renderUrl.
${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.

Zliczanie wyświetleń

Podczas testowania interfejsu Protected Audience API we współpracy 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 liczenia wyświetleń w ramach aukcji Protected Audience API w przeglądarce może być inne niż zdarzenie używane do zliczania wyświetleń przez partnerów kupujących, którzy korzystają z RTB, więc liczba wyświetleń może być inna.

Jednym z celów Google dotyczących testowania interfejsu Protected Audience API jest wykrywanie i zmniejszanie tych rozbieżności.

Atrybucja wyświetleń podlegających rozliczeniu

Wszystkie wydatki licytującego z aukcji Protected Audience w przeglądarce są przypisywane do jednego konta licytującego na podstawie mapowania ze źródeł właściciela grupy zainteresowań skonfigurowanych na potrzeby tego licytującego. Przypisywanie wydatków do różnych kont podrzędnych licytującego nie jest obsługiwane.

Dzienny limit budżetu

Podczas testowania interfejsu Protected Audience API na każdym koncie obowiązuje dzienny limit budżetu wydatków w ramach Protected Audience API 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ę objętych programem Protected Audience API.

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

Opinie w czasie rzeczywistym i minimalna stawka zapewniająca wygraną

Licytujący, którzy zgodzili się na otrzymywanie opinii w czasie rzeczywistym, będą otrzymywać opinie na temat kupujących w grupach zainteresowań, którzy zostali poproszeni o udział w aukcji Protected Audience na urządzeniu. Każdy kupujący na podstawie grupy zainteresowań określony przez licytującego w odpowiedzi na stawkę otrzyma 1 obiekt opinii niezależnie od tego, ile stawek zadał grupie zainteresowań w aukcji Protected Audience. W obiekcie opinii kupującego korzystającego z grupy zainteresowań będą dostępne te informacje:

  • Typ opinii obiektu opinii to INTEREST_GROUP_BUYER_FEEDBACK.
  • Pochodzenie kupującego korzystającego z grupy zainteresowań.
  • Minimalna stawka potrzebna do wygrania w przypadku kupującego z grupy zainteresowań, która umożliwi wygranie ogólnej aukcji.
  • Minimalna stawka potrzebna do wygrania w przypadku kupującego z grupy zainteresowań, która pozwoli przebić najwyższą stawkę z komponentu po stronie serwera w ogólnej aukcji.
  • Kod stanu kupującego korzystającego z grupy zainteresowań. Możliwe kody stanu znajdziesz w pliku interest-group-buyer-status-codes.txt.

Nazwy konkretnych pól znajdziesz w dokumentacji protokołu w sekcji dotyczącej RTB w Authorized Buyers i rozszerzeń OpenRTB.

Powiadomienie dotyczące opinii o stawkach

Chrome udostępnia tymczasowy interfejs API do debugowania na potrzeby interfejsu Protected Audience API, który umożliwia Ad Managerowi wysyłanie w czasie rzeczywistym między serwerami powiadomień debugowania między serwerami, które zawierają informacje zwrotne na temat stawki w ramach Protected Audience API. Będą one zawierać informacje o powodach, dla których stawki mogły zostać odfiltrowane w aukcji Protected Audience w przeglądarce, oraz inne informacje o stawkach opisane poniżej.

Licytujący mogą skontaktować się z menedżerem konta, aby skonfigurować statyczny adres URL, który będzie używany do przesyłania opinii o stawkach na potrzeby debugowania w ramach Protected Audience API. Ten statyczny URL zostanie pobrany z serwerów Google i zastąpi wybrane makra po zakończeniu aukcji Protected Audience API. Obsługiwane są te makra:

  • %%GOOGLE_QUERY_ID%%: to makro jest zastępowane identyfikatorem zapytania Google (BidRequest.google_query_id w protokole Authorized Buyers i BidRequest.ext.google_query_id w protokole OpenRTB), który został wysłany w pytaniu o stawkę kontekstową z włączoną funkcją Protected Audience.
  • %%INTEREST_GROUP_OWNER%%: pochodzenie właściciela grupy zainteresowań.
  • %%BID_CPM%%: stawka w CPM, która została określona przez kupującego w funkcji generateBid().
  • %%RENDER_URL%%: URL renderowania kreacji.
  • %%STATUS%%: kod stanu, jeśli stawka została odrzucona w ciągu scoreAd(). Wartości to kody stanu 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%%

Powiadomienia z opinią o stawkach to tymczasowa funkcja zależna od tymczasowego interfejsu API ForDebuggingOnly Chrome.

Zdarzenia kliknięcia

Licytujący mogą zgłaszać do Google zdarzenia kliknięć reklam w ramach Protected Audience API za pomocą interfejsu Fenced Frame Reporting API. Aby powiadamiać Google o kliknięciach, licytujący powinni używać typu zdarzenia click. Oto przykład:

window.fence.reportEvent({
    'eventType': 'click',
    // Google does not require bidders to send data to Google in 'eventData'.
    // However, 'eventData' must be a non-null value, such as an empty string.
    'eventData': '',
    'destinations': ['direct-seller']
});

TURTLEDOVE na poziomie produktu

W trakcie testów interfejsu Protected Audience API partnerzy Google RTB obsługują reklamy złożone z wielu elementów lub TURTLEDOVE na poziomie produktu. Poinformuj podczas integracji menedżera konta, czy planujesz przetestować PLTD, ponieważ wymagane są dodatkowe zasoby i konfiguracja.

Wprowadzenie

Aby przetestować interfejs Protected Audience API:

Kroki

  1. Wypełnij formularz prośby, aby dołączyć do eksperymentu interfejsu Protected Audience API.
  2. Po przesłaniu formularza skontaktuj się ze swoim 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.

Lista kontrolna integracji

  • Skonfiguruj punkt końcowy pytania o stawkę, który będzie wypełniać pola związane z Protected Audience API w odpowiedzi na pytanie o stawkę kontekstową, np. interest_group_bidding.
  • Zaimplementować tagowanie na stronach reklamodawcy, aby dołączyć przeglądarkę użytkownika do grupy zainteresowań.
  • Wdróż generateBid() i reportWin().
  • Wybierz źródła właścicieli grup zainteresowań i dodaj je do konta Authorized Buyers.
    • Punkty początkowe właściciela grupy zainteresowań powinny być zgodne z punktami początkowymi, w których hostowane są funkcje generateBid().
    • Aby ukończyć ten krok, skontaktuj się z menedżerem konta lub prześlij zgłoszenie w Centrum pomocy Authorized Buyers.
  • skonfigurować kierowanie wstępne w przypadku zasobów reklamowych powiązanych z testowaniem interfejsu Protected Audience API;
  • Prześlij kreacje do sprawdzenia i zatwierdzenia za pomocą interfejsu API kreacji.
  • (Opcjonalnie) Skonfiguruj punkty końcowe zaufanych sygnałów ustalania stawek.
  • (Opcjonalnie) Skonfiguruj stronę reklamodawcy testowego, która pozwoli inżynierom Google dodać przeglądarkę do grup zainteresowań należących do pochodzenia kupującego. Dzięki temu możemy ręcznie uruchamiać aukcje w ramach Protected Audience API.
  • (Opcjonalnie) Włącz na swoim koncie informacje w czasie rzeczywistym, aby otrzymywać opinie od kupujących na podstawie grup zainteresowań, którzy zostali poproszeni o obecność w aukcji Protected Audience.
  • (Opcjonalnie) Skontaktuj się ze swoim menedżerem konta, aby skonfigurować statyczny adres URL. Dzięki temu będziesz otrzymywać między serwerami powiadomienia o stawkach w ramach Protected Audience API dotyczące stanu stawki z aukcji Protected Audience na urządzeniu. Pomaga to w debugowaniu nieoczekiwanych problemów. Więcej informacji znajdziesz w powiadomieniu o opinii o stawkach.

Etapy testów

Etap 1. Test ręczny

Aby ręcznie aktywować aukcję w ramach Protected Audience API, upewnić się, że reklama może zostać wyrenderowana, i zarejestrować wyświetlenie:

  1. używać Chrome 101 lub nowszej wersji,
  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 w artykule Testowanie piaskownicy prywatności.
  3. Prześlij kreację do zatwierdzenia za pomocą interfejsu API określania stawek w czasie rzeczywistym.
  4. Na stronie reklamodawcy udostępnionej przez licytującego możesz dodać przeglądarkę do grupy zainteresowań należącej do licytującego.
  5. Aby uruchomić aukcję w ramach Protected Audience API, użyj udostępnionej przez Google testowej strony wydawcy:

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

    Grupa zainteresowań użytkowników przeglądarki musi mieć wystarczająco wysoką stawkę, aby wygrać aukcję, ponieważ może konkurować ze standardowymi stawkami po stronie serwera. Google udostępnia też dla każdego partnera osobną testową stronę wydawcy, na której w aukcji może brać udział tylko wybrany partner. Może to być łatwiejsze wygranie aukcji w przeglądarce na stronie partnera.

  6. Sprawdź, czy:

    1. Wyświetlona zostanie oczekiwana zwycięska reklama.
    2. Wynik aukcji jest wysyłany po stronie serwera, co oznacza, że zwycięzca aukcji otrzymuje ping zwrotny z reportWin().
    3. W przypadku każdej stawki testowej konsola stron wydawcy rejestruje komunikat debugowania, który zawiera te informacje:
      • renderUrl: URL renderowania stawki.
      • interestGroupOwner: właściciel grupy zainteresowań, do której należy stawka.
      • accepted: to pole zawiera wartość true, jeśli stawka została zaakceptowana, i false, jeśli została odrzucona przez scoreAd().
      • externalBidStatus: kod stanu, jeśli stawka została odrzucona w ciągu scoreAd(). Wartości to kody stanu kreacji.

Etap 2. (Opcjonalnie) Eksperyment bez renderowania

Gdy Google i partner stwierdzą ręcznie, że może on uczestniczyć w aukcji Protected Audience, umożliwi mu przejście na kolejny etap testowania.

Do przeprowadzania aukcji w ramach Protected Audience API Google przydziela niewielką ilość rzeczywistego ruchu. Dzięki temu Google i partner nie będą już musieli ręcznie uruchamiać aukcji w ramach Protected Audience API. Wynik aukcji Protected Audience API nie jest renderowany. Dzięki temu możemy testować integrację na dużą skalę.

Gdy wszystko będzie gotowe, skontaktuj się ze swoim menedżerem konta lub prześlij zgłoszenie w Centrum pomocy programu Authorized Buyers. Google włączy konto na tym etapie.

Etap 3. Eksperyment z renderowaniem

Gdy Google i partner zweryfikują na dużą skalę aukcje Protected Audience API bez renderowania, Google może umożliwić partnerowi wyrenderowanie zwycięskiej reklamy w ramach Protected Audience API. Google ma niewielki ruch, w ramach których mogą być prowadzone aukcje w ramach Protected Audience API, a w ramach renderowania zwycięskich reklam kierowanych na grupy zainteresowań. Stawki licytujących w przeglądarce, którzy uczestniczą w programie, konkurują z tradycyjnymi stawkami.

Gdy wszystko będzie gotowe, skontaktuj się ze swoim menedżerem konta lub prześlij zgłoszenie w Centrum pomocy programu Authorized Buyers. Google włączy konto na tym etapie.