Usługi określania stawek i aukcji

We wstępnej ofercie pakietowej Protected Audience określanie stawek i aukcje w przypadku żądań reklam remarketingowych są przeprowadzane lokalnie na urządzeniu. To wymaganie może wymagać przetwarzania danych, które mogą być niepraktyczne w użyciu na urządzeniach z ograniczoną mocą obliczeniową lub zbyt wolne, aby wybierać i renderować reklamy ze względu na opóźnienia sieciowe.

Oferta dotycząca ustalania stawek i usług aukcyjnych pozwala na wykonywanie obliczeń w ramach Protected Audience API na serwerach w chmurze w zaufanym środowisku wykonawczym (TEE), a nie lokalnie na urządzeniu użytkownika. Oferta B&A ma zapewniać ujednolicony proces uwzględniania żądań reklam kontekstowych i remarketingowych. Przeniesienie obliczeń na serwery może pomóc w optymalizacji aukcji w ramach Protected Audience API przez skrócenie cykli obliczeniowych i przepustowości sieci dla urządzenia.

Google udostępni komponenty usługi B&A, które zostaną udostępnione na licencji open source. Zainteresowani specjaliści ds. technologii reklamowych mogą hostować własne instancje u obsługiwanych dostawców chmury publicznej. Więcej informacji o ofercie B&A znajdziesz na GitHub. Pamiętaj, że daty podane w tym dokumencie odzwierciedlają wdrożenie Chrome, a w przyszłości opublikujemy więcej informacji na temat integracji z Androidem. Ten dokument stanowi wprowadzenie do B&A, a nowe interfejsy API Androida zostaną udostępnione do interakcji z B&A. Bardziej techniczne informacje o sposobie korzystania z nowych interfejsów API będziemy publikować w kolejnych wersjach.

Usługi B&A

B&A zapewnia dodatkową opcję prowadzenia aukcji na zaufanych serwerach reklamowych AdTech, które uruchamiają plik binarny typu open source udostępniony przez Google. Dane użytkownika są nadal dostępne na urządzeniu, a Google zapewni interfejsy API umożliwiające bezpieczne przeniesienie ich do TEE. Więcej informacji o strategii szyfrowania znajdziesz poniżej.

Oznacza to, że niektóre części procesu aukcji odbywają się na urządzeniu, a inne w chmurze. Z perspektywy platformy DSP niestandardowi odbiorcy (uwzględnione reklamy kandydujące w kampaniach remarketingowych) są nadal zarządzane na urządzeniu za pomocą tych samych interfejsów API do zarządzania odbiorcami niestandardowymi co podczas aukcji na urządzeniu. Z perspektywy platformy SSP żądania są nadal aktywowane na urządzeniu, a ten dokument opisuje nowe interfejsy API, które będą używane. W przypadku wszystkich stron raportowanie wyniku aukcji jest wciąż rozpoczynane na urządzeniu po zakończeniu rozmowy w ramach B&A.

Główna różnica dotyczy miejsca wykonywania logiki określania stawek, oceniania i generowania adresów URL raportowania. Zamiast uruchamiania ustalania stawek, aukcji i raportowania na urządzeniu logika generateBid(), scoreAd(), reportResult() i reportWin() jest wykonywana w TEE. Logika ustalania stawek kupującego i reguła punktacji sprzedawcy jest przeprowadzana w jego środowisku B&A w trakcie procesu aukcji w ramach Protected Audience API:

Ilustracja przedstawiająca przebieg aukcji w ramach Protected Audience API z uwzględnieniem określania stawek i aukcji.
Przebieg aukcji w ramach Protected Audience

Szyfrowanie danych

W przypadku B&A informacje w ramach ochrony odbiorców, takie jak niestandardowe listy odbiorców i kwoty stawek, są przesyłane z urządzenia przez serwery technologii reklamowych sprzedawców, przez serwery technologii reklamowych kupujących i z powrotem na urządzenie. Dlatego platforma szyfruje dane przesyłane do usług Protected Audience API i może być odszyfrowywana tylko przez usługi, które zostały poświadczone. Więcej informacji o strategiach szyfrowania znajdziesz na GitHub.

Architektura i przepływ aukcji

Propozycja ta uwzględnia konieczność wprowadzenia kilku nowych komponentów opisanych na GitHub, w tym przepływu danych z urządzenia do pensjonatu i B&A.

Grafika przedstawiająca ujednolicony proces aukcji dotyczący odbiorców kontekstowych i chronionych.
Ujednolicony przebieg aukcji kontekstowych i chronionych odbiorców z usługami określania stawek i aukcji.

Ogólnie przepływ danych jest opisany w ten sposób:

  1. Na urządzeniu sprzedawcy zbierają informacje z Protected Audience API za pomocą interfejsu getAdSelectionData API.
  2. Pakiet SDK na urządzeniu wysyła żądanie do usługi reklam dla sprzedawców. To żądanie zawiera ładunek kontekstowy i zaszyfrowany plik ProtectedAudienceInput.
  3. Usługa reklam sprzedawcy wysyła żądanie do usługi określania stawek w czasie rzeczywistym (RTB) kupującego, która działa poza platformą TEE, aby uzyskać kandydujące reklamy kontekstowe, a następnie ocenia i wybiera zwycięską reklamę kontekstową.
  4. Usługa reklam sprzedawcy wysyła żądanie do usługi SellerFrontEnd w TEE.
  5. Usługa SellerFrontEnd wysyła do usług BuyerFrontEnd żądania z danymi dotyczącymi konkretnego kupującego.
  6. Kupujący korzystają z własnych usług kluczy/wartości i usługi określania stawek, która generuje stawki dla kandydatów reklam pozyskiwanych z urządzenia dla wszystkich odbiorców niestandardowych uwzględnianych na potrzeby remarketingu.
  7. Usługa SellerFrontEnd odczytuje dane z usługi kluczy/wartości i ocenia reklamy kandydujące. Wynik jest zaszyfrowany i zwracany do usługi reklam sprzedawcy.
  8. Usługa reklam sprzedawcy zwraca zaszyfrowany zwycięski wynik i opcjonalnie wynik kontekstowy do pakietu SDK na urządzeniu.
  9. Sprzedawcy pobierają na urządzeniu zwycięską reklamę za pomocą interfejsu API processAdSelectionResult, który odszyfrowuje odpowiedź z usługi reklam dla sprzedawców.

Szczegółowy opis każdego kroku i sposobu szyfrowania danych znajdziesz na GitHub. Kody tych komponentów zostaną udostępnione na licencji open source. Podany kod obsługuje federację żądań z usługi SellerFrontEnd do usług BuyerFrontEnd.

Wdrożenie Google Cloud

Technologie reklamowe wdrożą usługi B&A na obsługiwanej platformie publicznej w chmurze. Wdrożeniami tymi powinni zarządzać technicy reklamowi, którzy będą odpowiadać za definiowanie docelowego poziomu usługi dostępności.

Przeprowadzenie aukcji

Pierwszym krokiem do przeprowadzenia aukcji B&A jest zebranie danych pochodzących z niestandardowych list odbiorców na urządzeniu i zaszyfrowanie ich w celu wysłania do aukcji po stronie serwera. Aby to zrobić, użyj interfejsu API getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Metoda getAdSelectionData generuje wymagane dane wejściowe dla komponentów B&A, takich jak BuyerInput i ProtectedAudienceInput, oraz szyfruje dane przed udostępnieniem wyniku funkcji wywołującej. Aby zapobiec wyciekom danych między aplikacjami, zawierają one informacje od wszystkich kupujących, którzy korzystają z urządzenia. Więcej informacji o tej decyzji znajdziesz w sekcji Kwestie związane z prywatnością.

Ten interfejs API zwraca obiekt AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Za pomocą tego zdarzenia AdSelectionData pakiet SDK na urządzeniu może wysłać żądanie do usługi reklamowej sprzedawcy, uwzględniając dane w żądaniu POST lub PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

Za kodowanie tych danych odpowiada pakiet SDK na urządzeniu. Zalecamy korzystanie z rozwiązania, które zajmuje niewiele miejsca, np. wysyłanie żądania do usługi reklamowej sprzedawców jako multipart/form-data.

Po zainicjowaniu żądania usługa reklam sprzedawcy przekazuje je do usługi SellerFrontEnd w TEE. Podczas konfigurowania usługi SellerFrontEnd sprzedawcy podają listę adresów domen odpowiadających usługom BuyerFrontEnd prowadzonym przez kupujących, z którymi dany sprzedawca jest partnerem. Żądania będą sfederowane do różnych usług BuyerFrontEnd udostępnionych przez sprzedawcę, dzięki czemu kupujący będą mogli generować stawki dla wybranych kandydatów reklamy. W przypadku konkretnego kupującego B&A będzie wysyłać tylko informacje o niestandardowych listach odbiorców należących do kupującego, co zapobiega przenikaniu danych między kupującymi. Po wygenerowaniu stawek lista reklam kandydatów wraca do usługi SellerFrontEnd, w której wybierany jest zwycięzca. Na koniec usługa SellerFrontEnd zwraca na urządzenie zaszyfrowaną zwycięską reklamę.

Dzięki odpowiedzi na żądanie wysłane z powrotem do usługi reklam sprzedawcy na urządzeniu platforma oferuje drugi nowy interfejs API do odszyfrowywania wyniku i dostarcza AdSelectionOutcome, czyli ten sam obiekt, który jest zwracany dzisiaj z aukcji na urządzeniu.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Raportowanie

Adresy URL do raportowania zostaną wygenerowane w usługach B&A. Pingi do tych adresów URL na potrzeby raportowania wyświetleń i interakcji w ramach aukcji nadal muszą być wywoływane na urządzeniu. Pakiet SDK na urządzeniu nadal będzie musiał wywoływać interfejsy API reportImpression() i reportInteraction() przy użyciu interfejsów AdSelectionId wygenerowanych w ramach procedury B&A. Obrazy typu beacon generowane na potrzeby raportowania interakcji i odpowiadające im adresy URL są zawarte w odpowiedzi zaszyfrowanej, więc podczas odszyfrowywania odpowiedzi zdarzenia i mapowania adresów URL są przechowywane na urządzeniu.

Kwestie dotyczące prywatności

Propozycja określania stawek w przeglądarce i interfejsu API aukcji w serwisie GitHub opisuje, jak wzięto pod uwagę kwestie związane z ochroną prywatności. W tej propozycji zastosowano nazwą Chrome, ale te same zasady dotyczą Androida.

Protokół adSelectionData jest szyfrowany, aby zapewnić, że dane w ruchu są dostępne tylko dla PPAPI i zaufanych serwerów. Aby zmniejszyć ryzyko wycieku danych z powodu zmiany rozmiaru (adSelectionData), planujemy generować ten sam atrybut adSelectionData dla wszystkich wywołań interfejsu getAdSelectionData API. Oznacza to, że wszystkie CustomAudience na urządzeniu są używane do tworzenia elementu adSelectionData. Planujemy też ograniczyć wpływ parametrów wejściowych (GetAdSelectionData) na generowane dane adSelectionData.

Wygenerowanie tego samego parametru adSelectionData dla wszystkich technologii reklamowych, które korzystają ze wszystkich danych z aukcji na urządzeniu, prowadzi do większego ładunku, który trzeba przesyłać przy każdym wywołaniu serwera technologii reklamowych. Może też narazić ekosystem na nadużycia ze strony szkodliwych elementów. Odpowiedzi na te wątpliwości znajdziesz poniżej w sekcjach Uwagi na temat rozmiaru i Zapobieganie nadużyciom.

Znaczenie rozmiaru

Pakiet SDK klienta technologii reklamowych powinien spakować zaszyfrowane bajty pliku adSelectionData w wywołanie reklam kontekstowych wysyłanych do serwera sprzedawcy. Aby uzyskać optymalną wydajność, zoptymalizuj rozmiar elementu adSelectionData bez ograniczania funkcjonalności. Planujemy wprowadzić optymalizacje zgodnie z opisem w objaśnieniu optymalizacji ładunku, aby zmniejszyć rozmiar adSelectionData. Optymalizacje te będą obejmować:

  1. Dodanie parametru ad_render_id w elemencie CustomAudience sprawi, że będzie on wysyłany za pomocą parametru adSelectionData zamiast używania identyfikatora URI i metadanych renderowania reklam. Technologie reklamowe mogą jeszcze bardziej zoptymalizować tę sytuację, nie wysyłając danych reklam w adSelectionData. Ta opcja będzie obsługiwana w CustomAudience API w kolejnych wersjach.
  2. Upewnij się, że w pliku adSelectionData nie są wysyłane user_bidding_signals. Zamiast tego technologie reklamowe mogą pobierać elementy user_bidding_signals ze swojego serwera klucz-wartość.
  3. Pozwól kupującym priorytetowo traktować CustomAudience.
  4. Zezwalaj kupującemu na określanie priorytetu sprzedawcy.
  5. Wygeneruj adSelectionData w kilku stałych zasobnikach, aby ograniczyć wyciek bitów i zmniejszyć rozmiar ładunku.

Będziemy optymalizować rozmiar, nie zapominając przy tym o kwestiach związanych z ochroną prywatności.

Uwagi na temat zapobiegania nadużyciom

Jak wspomnieliśmy w sekcji dotyczącej prywatności, wartość adSelectionData jest generowana z wykorzystaniem wszystkich danych kupującego na urządzeniu.

Spowoduje to otwarcie ekosystemu na potencjalne złośliwe jednostki, które mogłyby dodawać fałszywe dane o kupujących i zmniejszać wydajność, zwiększać ładunki, zwiększać koszty itp.

Aby zapobiec nadużywaniu usługi adSelectionData, wprowadzimy następujące środki:

  • Zezwalaj usłudze CustomAudience na jawne określanie zatwierdzonych sprzedawców i priorytetów
  • Zezwalaj platformom SSP na jawne określanie kupującego, priorytetu kupującego i limitu na kupującego w wygenerowanym ładunku
  • Udostępniaj przez platformy SSP mechanizm określania maksymalnej liczby kupujących na połączenie lub maksymalnej wielkości na kupującego.

Dzięki temu technologie reklamowe mogą określić, z którymi innymi technologiami reklamowymi współpracują, a także ustalić dopuszczalne limity ładunku danych adSelectionData, które muszą przetworzyć. Proponujemy, aby sprzedawca mógł określić tę listę kupujących i priorytet w osobnym wywołaniu. Ta specyfikacja będzie stała przez pewien czas, aby uniknąć ujawniania dodatkowych danych o użytkowniku za pomocą powtarzających się wywołań.

Opisane powyżej środki zaradcze są obecnie omawiane i mogą się z czasem zmieniać. Jak już wspomnieliśmy, wszystkie środki łagodzące związane z nadużyciami oraz ograniczenia rozmiaru i nadużycia muszą być zgodne z kwestiami dotyczącymi prywatności.