Usługi określania stawek i aukcji

W pierwotnej propozycji dotyczącej Protected Audience określanie stawek i aukcje w przypadku popytu na reklamy remarketingowe są przeprowadzane lokalnie na urządzeniu. To wymaganie może wiązać się z koniecznością przeprowadzenia obliczeń, które mogą być niepraktyczne na urządzeniach o ograniczonej mocy obliczeniowej lub zbyt wolne, aby wybrać i wyświetlić reklamy z powodu opóźnień w sieci.

W propozycji dotyczącej usług określania stawek i aukcji opisano sposób, w jaki można umożliwić przetwarzanie danych Protected Audience na serwerach w chmurze w zaufanym środowisku wykonawczym (TEE), zamiast na urządzeniu użytkownika. Propozycja B&A ma na celu wspieranie ujednoliconego procesu uwzględniania popytu na reklamy kontekstowe i remarketingowe. Przeniesienie obliczeń na serwery może pomóc w optymalizacji aukcji z użyciem Protected Audience, ponieważ pozwala uwolnić cykle obliczeniowe i przepustowość sieci na urządzeniu.

Google udostępni komponenty B&A jako oprogramowanie typu open source. Zainteresowani dostawcy technologii reklamowych mogą hostować własne instancje u obsługiwanych dostawców chmury publicznej. Więcej informacji o propozycji B&A znajdziesz w GitHub. Pamiętaj, że daty podane w tym dokumencie dotyczą implementacji w Chrome. Więcej informacji o integracji z Androidem opublikujemy w przyszłości. Ten dokument stanowi wprowadzenie do B&A i nowych interfejsów API, które Android udostępni do interakcji z tą usługą. Więcej informacji technicznych o tym, jak korzystać z tych nowych interfejsów API, podamy w przyszłych aktualizacjach.

Miejsce usług B&A w strukturze Google

B&A to dodatkowa opcja przeprowadzania aukcji w ramach technologii reklamowej na serwerach należących do zaufanych podmiotów, na których działa binarny kod open source udostępniony przez Google. Dane użytkownika nadal będą przechowywane na urządzeniu, a Google udostępni interfejsy API do bezpiecznego przenoszenia tych danych do środowiska TEE. Więcej informacji o naszej 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 niestandardowe listy odbiorców (w tym kandydaci na reklamy w kampaniach remarketingowych) są nadal zarządzane na urządzeniu przy użyciu tych samych interfejsów API do zarządzania niestandardowymi listami odbiorców, co w przypadku aukcji przeprowadzanej na urządzeniu. Z perspektywy platformy SSP żądania są nadal wywoływane na urządzeniu. W tym dokumencie opisujemy nowe interfejsy API, które będą używane. W przypadku wszystkich stron zgłaszanie wyniku aukcji nadal rozpoczyna się na urządzeniu po zakończeniu wywołania B&A.

Główna różnica polega na tym, gdzie jest wykonywana logika generowania adresu URL na potrzeby określania stawek, oceniania i raportowania. Zamiast uruchamiać na urządzeniu logikę określania stawek, aukcji i raportowania, logikę generateBid(), scoreAd(), reportResult() i reportWin() wykonuje się w TEE. Logika określania stawek kupującego i logika oceny sprzedawcy są wykonywane w ich własnym środowisku B&A, w środku procesu aukcji Protected Audience:

Szyfrowanie danych

W przypadku B&A informacje o Protected Audience, takie jak niestandardowe listy odbiorców i kwoty stawek, przepływają z urządzenia przez serwery technologii reklamowych sprzedawcy do serwerów technologii reklamowych kupującego i z powrotem do urządzenia. Z tego powodu platforma szyfruje dane przesyłane do usług Protected Audience i mogą je odszyfrować tylko usługi, które przeszły atest. Więcej informacji o strategiach szyfrowania znajdziesz na GitHub.

Architektura i przebieg aukcji

Propozycja ta obejmuje kilka nowych komponentów, które są szczegółowo opisane na GitHub, w tym przepływ danych z urządzenia do B&A.

Ogólnie przepływ danych wygląda tak:

1. Na urządzeniu sprzedawcy zbierają informacje z Protected Audience za pomocą interfejsu API.getAdSelectionData
2. Pakiet SDK na urządzeniu wysyła żądanie do usługi reklamowej sprzedawcy. To żądanie zawiera ładunek kontekstowy i zaszyfrowany parametr ProtectedAudienceInput.
3. Usługa reklam sprzedawcy wysyła żądanie do usługi określania stawek w czasie rzeczywistym (RTB) kupujących działającej poza środowiskiem TEE, aby uzyskać kandydatów na reklamy kontekstowe, a następnie ocenia i wybiera zwycięską reklamę kontekstową.
4. Usługa reklamy sprzedawcy wysyła żądanie do usługi SellerFrontEnd działającej w TEE.
5. Usługa SellerFrontEnd wysyła żądania z danymi konkretnego kupującego do usług BuyerFrontEnd.
6. Kupujący korzystają z własnej usługi klucz/wartość i usługi określania stawek, które generują stawki w przypadku kandydatów do reklam pochodzących z urządzenia dla wszystkich odbiorców niestandardowych branych pod uwagę w remarketingu.
7. Usługa SellerFrontEnd odczytuje dane z usługi Key/Value i ocenia potencjalne reklamy. Wynik jest szyfrowany i zwracany do usługi Seller Ad.
8. Usługa reklam sprzedawcy zwraca zaszyfrowany wynik zwycięskiej reklamy, a opcjonalnie także wynik kontekstowy, do pakietu SDK na urządzeniu.
9. Na urządzeniu sprzedawcy pobierają zwycięską reklamę za pomocą interfejsu API processAdSelectionResult, który odszyfrowuje odpowiedź z usługi Seller Ad.

Szczegółowy opis każdego kroku i sposobu szyfrowania danych znajdziesz w GitHub. Kod tych komponentów będzie udostępniany jako oprogramowanie open source. Podany kod będzie obsługiwać federację żądań z usługi SellerFrontEnd do usług BuyerFrontEnd.

Wdrożenie w chmurze

Dostawcy technologii reklamowych wdrażają usługi B&A na obsługiwanej platformie chmury publicznej. Wdrożeniami tymi będą zarządzać dostawcy technologii reklamowych, którzy będą odpowiedzialni za określenie celu poziomu usług w zakresie dostępności.

Przeprowadzanie aukcji

Pierwszym krokiem w przeprowadzaniu aukcji B&A jest zebranie danych 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, zanim udostępni wynik wywołującemu. Aby zapobiec wyciekowi danych między aplikacjami, te dane zawierają informacje od wszystkich kupujących na urządzeniu. 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.
}

Korzystając z tego AdSelectionData, pakiet SDK na urządzeniu może wysłać żądanie do usługi reklamowej sprzedawcy, dołączając dane do żądania 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 stosowanie rozwiązania oszczędzającego miejsce, takiego jak wysyłanie żądania do usługi Seller Ad jako multipart/form-data.

Po zainicjowaniu żądania usługa Seller Ad przekazuje je do usługi SellerFrontEnd działającej w TEE. Podczas konfigurowania usługi SellerFrontEnd sprzedawcy podają listę adresów domen, które odpowiadają usługom BuyerFrontEnd obsługiwanym przez kupujących, z którymi sprzedawca współpracuje. Żądania będą przekazywane do różnych usług BuyerFrontEnd udostępnianych przez sprzedawcę, aby kupujący mogli generować stawki za wybrane przez siebie kandydatów do wyświetlenia reklamy. W przypadku konkretnego kupującego B&A będzie wysyłać tylko informacje o niestandardowych listach odbiorców, których jest właścicielem, aby zapobiec wyciekowi 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ę.

Po otrzymaniu odpowiedzi z usługi reklam sprzedawcy na urządzeniu platforma udostępnia drugi nowy interfejs API do odszyfrowania wyniku i zwrócenia obiektu AdSelectionOutcome, czyli tego samego obiektu, który jest obecnie zwracany 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 raportowania będą generowane w usługach B&A. Pingi do tych adresów URL w celu raportowania wyświetleń i interakcji w przypadku 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() za pomocą parametru AdSelectionId wygenerowanego podczas procesu B&A. Sygnały generowane na potrzeby raportowania interakcji i odpowiednie adresy URL są zawarte w zaszyfrowanej odpowiedzi, więc podczas odszyfrowywania odpowiedzi zdarzenia i mapowania adresów URL są przechowywane na urządzeniu.

Kwestie dotyczące prywatności

W propozycji interfejsu Browser Bidding & Auction API w GitHubie opisano, jak uwzględniono kwestie związane z prywatnością. Ta propozycja korzysta z nomenklatury Chrome, ale te same zasady mają zastosowanie w przypadku Androida.

adSelectionData jest szyfrowany, aby dane podczas przesyłania były dostępne tylko dla PPAPI i zaufanych serwerów. Aby zmniejszyć ryzyko wycieku danych z powodu zmian rozmiaru adSelectionData, planujemy generować ten sam adSelectionData w przypadku wszystkich wywołań interfejsu API getAdSelectionData. Oznacza to, że wszystkie CustomAudience na urządzeniu są używane do tworzenia adSelectionData. Planujemy też ograniczyć wpływ GetAdSelectionDataparametrów wejściowych na adSelectionDatagenerowane wyniki.

Generowanie tego samego adSelectionData dla wszystkich technologii reklamowych przy użyciu wszystkich danych z aukcji na urządzeniu prowadzi do większego rozmiaru pakietu danych, który musi być przesyłany w każdym wywołaniu serwera technologii reklamowej, a jednocześnie może narażać ekosystem na nadużycia ze strony złośliwych podmiotów. Te kwestie zostały omówione w sekcjach Rozmiar i Zapobieganie nadużyciom.

Rozmiar

Pakiet SDK klienta technologii reklamowej powinien spakować zaszyfrowane bajtyadSelectionData do wywołania reklam kontekstowych kierowanego na serwer sprzedawcy. Aby uzyskać optymalną wydajność, ważne jest zoptymalizowanie rozmiaruadSelectionData bez utraty funkcjonalności. Planujemy wprowadzić optymalizacje opisane w wyjaśnieniu dotyczącym optymalizacji ładunku, aby zmniejszyć rozmiar adSelectionData. Optymalizacje te będą obejmować:

1. Dodanie ad_render_id w CustomAudience, aby wysyłać go za pomocą adSelectionData zamiast identyfikatora URI renderowania reklamy i metadanych. Technologie reklamowe mogą dodatkowo zoptymalizować ten proces, nie wysyłając danych o reklamach w adSelectionData. Ta opcja będzie obsługiwana w CustomAudience API w przyszłych wersjach.
2. Upewnij się, że user_bidding_signals nie są wysyłane w adSelectionData. Zamiast tego platformy reklamowe mogą pobierać user_bidding_signals z serwera par klucz-wartość.
3. Zezwalaj kupującym na priorytetowe traktowanie CustomAudience.
4. Zezwalaj kupującemu na określanie priorytetu sprzedawcy.
5. Generuj adSelectionData w kilku stałych przedziałach, aby ograniczyć wyciek bitów i zmniejszyć rozmiar pakietu.

Optymalizacja rozmiaru będzie przeprowadzana z uwzględnieniem kwestii związanych z prywatnością.

Kwestie związane z przeciwdziałaniem nadużyciom

Jak wspomnieliśmy w sekcji Ochrona prywatności, wartość adSelectionData jest generowana na podstawie wszystkich danych kupującego na urządzeniu.

Otwiera to ekosystem na potencjalnie szkodliwe podmioty, które mogą dodawać fałszywe dane kupujących, co może obniżać skuteczność, zwiększać rozmiar pakietów danych i zwiększać koszty itp.

Aby zapobiegać nadużyciom adSelectionData, wprowadzimy te środki:

• Zezwól CustomAudience na wyraźne określanie zatwierdzonych sprzedawców i priorytetu sprzedawcy
• Umożliwienie platformom SSP wyraźnego określania w generowanym ładunku kupującego, priorytetu kupującego i limitu na kupującego
• Udostępnij platformom SSP mechanizm określania maksymalnej liczby kupujących na wywołanie lub maksymalnego rozmiaru na kupującego.

Te środki mają na celu umożliwienie dostawcom technologii reklamowych określania, z którymi innymi dostawcami technologii reklamowych współpracują, oraz ustalania dopuszczalnych limitów adSelectionData ładunku, który muszą przetworzyć. Proponujemy, aby sprzedawca mógł określać tę listę kupujących i priorytet w osobnym wywołaniu. Ta specyfikacja będzie stała w określonym przedziale czasu, aby uniknąć ujawniania dodatkowych danych o użytkowniku w wyniku wielokrotnych wywołań.

Te środki zaradcze są obecnie omawiane i mogą się zmieniać z czasem. Jak wspomnieliśmy, wszystkie środki zapobiegawcze wprowadzone w celu przeciwdziałania nadużyciom i ograniczeniom rozmiaru muszą uwzględniać kwestie związane z prywatnością.