Usługi określania stawek i aukcji

W pierwotnym projekcie Protected Audience określanie stawek i przeprowadzanie aukcji dotyczących popytu na reklamy remarketingowe odbywa się lokalnie na urządzeniu. Wymagania te mogą wymagać przetwarzania, które może być niepraktyczne na urządzeniach o ograniczonej mocy obliczeniowej, lub może być zbyt wolne, aby wybrać i wyrenderować 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. Proponowana zmiana w B&A ma na celu ułatwienie uwzględniania popytu na reklamy w ramach scentralizowanego procesu w przypadku reklam kontekstowych i remarketingowych. 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 publicznych usług w chmurze. Więcej informacji o propozycji dotyczącej fuzji i przejęcia znajdziesz na GitHub. Pamiętaj, że terminy podane w tym dokumencie odnoszą się do wdrożenia 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 B&A. W przyszłych aktualizacjach opublikujemy więcej informacji technicznych na temat korzystania z tych nowych interfejsów API.

Gdzie mieszczą się usługi B&A

B&A udostępnia dodatkową opcję przeprowadzania aukcji na należących do firmy adtech zaufanych serwerach, na których działa binarny plik binarny typu open source udostępniony przez Google. Dane użytkownika nadal znajdują się na urządzeniu, a Google udostępni interfejsy API do bezpiecznego przenoszenia tych danych do TEE. Poniżej znajdziesz więcej informacji o naszej strategii szyfrowania.

Oznacza to, że niektóre części procesu aukcji odbywają się na urządzeniu, a inne w chmurze. Z punktu widzenia platformy DSP listy niestandardowych odbiorców (w tym reklamy kandydujące na potrzeby kampanii remarketingowych) są nadal zarządzane na urządzeniu za pomocą tych samych interfejsów API do zarządzania niestandardowymi listami odbiorców, co w przypadku aukcji przeprowadzanych na urządzeniu. Z perspektywy dostawcy SSP żądania są nadal wywoływane na urządzeniu, a w tym dokumencie opisano nowe interfejsy API, które będą używane. W przypadku wszystkich stron raportowanie wyniku aukcji rozpoczyna się na urządzeniu po zakończeniu wywołania usługi B&A.

Główna różnica polega na tym, gdzie jest wykonywana logika generowania stawek, punktacji i URL-i do raportowania. Zamiast uruchamiania na urządzeniu logiki określania stawek, aukcji i raportowania, logika generateBid(), scoreAd(), reportResult() i reportWin() jest wykonywana w TEE. Logika określania stawek przez kupującego i logika oceniania przez sprzedawcę są wykonywane w ramach ich własnego środowiska automatyzacji reklamy w ramach procesu aukcji z zastosowaniem listy odbiorców chronionych:

Szyfrowanie danych

W ramach B&A informacje Protected Audience, takie jak listy niestandardowe i kwoty stawek, są przesyłane z urządzenia przez serwery technologii reklamowych sprzedawcy do serwerów technologii reklamowych kupującego i z powrotem na urządzenie. Dlatego platforma szyfruje dane przekazywane do usług Protected Audience i mogą je odszyfrować tylko usługi, które zostały poświadczone. Dowiedz się więcej o strategiach szyfrowania na GitHub.

Architektura i przebieg aukcji

Ta propozycja obejmuje potrzebę wprowadzenia kilku nowych komponentów opisanych na GitHub, w tym przepływu 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 getAdSelectionData API.
2. Pakiet SDK na urządzeniu wysyła żądanie do usługi reklamowej sprzedawcy. Ta prośba zawiera kontekstualny ładunek i zaszyfrowany ProtectedAudienceInput.
3. Usługa reklamy sprzedawcy wysyła żądanie do usługi określania stawek w czasie rzeczywistym (RTB) kupujących, która działa poza TEE, aby uzyskać reklamy kontekstowe kandydujące, 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 kupującego do usług BuyerFrontEnd.
6. Kupujący korzystają z własnej usługi klucza/wartości i usługi ustalania stawek, która generuje stawki dla kandydatów na reklamy pochodzących z urządzenia dla wszystkich grup niestandardowych uwzględnianych w remarketingu.
7. Usługa SellerFrontEnd odczytuje dane z usługi klucz-wartość i przypisze reklamom kandydatom odpowiednie oceny. Wynik jest szyfrowany i zwracany do usługi reklamy sprzedawcy.
8. Usługa reklamy sprzedawcy zwraca zaszyfrowany wynik zwycięski i opcjonalnie wynik kontekstowy do pakietu SDK na urządzeniu.
9. Na urządzeniu sprzedawcy pobierają reklamę zwycięską za pomocą interfejsu processAdSelectionResult API, który odszyfrowuje odpowiedź z usługi reklamy sprzedawcy.

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

Wdrażanie w chmurze

Specjaliści od technologii reklamowych wdrożą usługi analityki i zbierania danych na obsługiwanej platformie chmury publicznej. Zarządzanie tymi wdrożeniami będzie należeć do specjalistów ds. technologii reklamy, którzy będą odpowiedzialni za określenie celu na poziomie usługi dotyczącego dostępności.

Przeprowadzanie aukcji

Pierwszym krokiem do przeprowadzenia aukcji B&A jest zebranie danych z list odbiorców niestandardowych na urządzeniu i zaszyfrowanie ich w celu przesł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, a następnie szyfruje je, zanim udostępni je wywołującemu. Aby zapobiec wyciekowi danych między aplikacjami, te dane zawierają informacje o wszystkich kupujących na urządzeniu. Więcej informacji o tej decyzji znajdziesz w sekcji Uwzględnianie 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 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 stosowanie rozwiązania oszczędzającego miejsce, takiego jak wysyłanie żądania do usługi reklamowej sprzedawcy w formacie multipart/form-data.

Po zainicjowaniu żądania usługa SellerAd przekazuje je do usługi SellerFrontEnd działającej w TEE. Podczas konfigurowania usługi SellerFrontEnd sprzedawcy podają listę adresów domen odpowiadających usługom BuyerFrontEnd obsługiwanym przez kupujących, z którymi współpracuje sprzedawca. Żądania będą przekazywane do różnych usług BuyerFrontEnd udostępnionych przez sprzedawcę, aby kupujący mogli generować stawki dla wybranych kandydatów reklam. W przypadku konkretnego kupującego B&A będzie wysyłać tylko informacje o niestandardowych listach odbiorców należących do tego kupującego, aby nie dochodziło do wycieków danych między kupującymi. Po wygenerowaniu stawek lista reklam kandydatów wraca do usługi SellerFrontEnd, gdzie wybierany jest zwycięzca. Na koniec usługa SellerFrontEnd zwraca zaszyfrowaną zwycięską reklamę na urządzenie.

Po otrzymaniu odpowiedzi na żądanie usługi reklamy sprzedawcy z urządzenia platforma udostępnia drugi nowy interfejs API, który umożliwia odszyfrowanie wyniku i uzyskanie obiektu AdSelectionOutcome, czyli tego samego obiektu, który jest 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 raportów będą generowane w usługach B&A. Pingi do tych adresów URL służące do raportowania wyświetleń i interakcji w ramach aukcji nadal będą musiały być wywoływane na urządzeniu. Pakiet SDK na urządzeniu nadal będzie musiał wywoływać interfejsy API reportImpression() i reportInteraction() za pomocą AdSelectionId wygenerowanego podczas procesu wymiany danych. Beacony wygenerowane na potrzeby raportowania interakcji i odpowiednie adresy URL są zawarte w zaszyfrowanej odpowiedzi, więc podczas jej odszyfrowywania te zdarzenia i mapowania adresów URL są przechowywane na urządzeniu.

Uwagi dotyczące prywatności

Propozycja interfejsu API licytowania w przeglądarce i aukcji na GitHubie opisuje, jak zostały uwzględnione kwestie związane z prywatnością. W tej propozycji używamy terminologii Chrome, ale te same zasady obowiązują w przypadku Androida.

adSelectionData jest szyfrowany, aby mieć pewność, że dane w trakcie przesyłania są dostępne tylko dla PPAPI i zaufanych serwerów. Aby zmniejszyć ryzyko wycieku danych spowodowanego zmianami rozmiaru adSelectionData, planujemy generowanie tego samego adSelectionData dla wszystkich wywołań interfejsu getAdSelectionData API. Oznacza to, że wszystkie CustomAudience na urządzeniu są używane do tworzenia adSelectionData. Planujemy też ograniczyć wpływ parametrów wejściowych GetAdSelectionData na generowane wyniki adSelectionData.

Generowanie tych samych adSelectionData dla wszystkich technologii reklamowych z użyciem wszystkich danych aukcji na urządzeniu powoduje zwiększenie ładunku, który musi być przesyłany w każdym wywołaniu serwera technologii reklamowej, a zarazem potencjalnie otwiera ekosystem na nadużycia ze strony złośliwych podmiotów. Te kwestie omawiamy w sekcjach Rozmiary i Zwalczanie nadużyć.

Uwzględnienie rozmiaru

Pakiet SDK klienta adtech ma za zadanie spakowanie zaszyfrowanych bajtów adSelectionData do wywołania reklam kontekstowych na serwerze sprzedawcy. Aby uzyskać optymalną wydajność, ważne jest zoptymalizowanie rozmiaru adSelectionData bez uszczerbku na funkcjonalności. Planujemy wprowadzić optymalizacje opisane w artykule na temat optymalizacji ładunku, aby zmniejszyć rozmiar adSelectionData. Te optymalizacje obejmą:

1. Dodanie elementu ad_render_id w elementzie CustomAudience, aby był on wysyłany za pomocą elementu adSelectionData zamiast identyfikatora URI renderowania reklamy i metadanych. Firmy zajmujące się technologiami reklamowymi mogą jeszcze bardziej zoptymalizować ten proces, nie wysyłając danych reklamowych w pliku adSelectionData. Ta opcja będzie obsługiwana w CustomAudience API w kolejnych wersjach.
2. Upewnij się, że user_bidding_signals nie są wysyłane w adSelectionData. Zamiast tego technologie reklamowe mogą pobierać user_bidding_signals z serwera klucz-wartość.
3. Zezwalaj kupującym na ustalanie priorytetów CustomAudience.
4. Zezwalanie kupującemu na określenie priorytetu sprzedawcy.
5. Generuj adSelectionData w kilku stałych zbiornikach, aby ograniczyć wyciek bitów przy jednoczesnym zmniejszeniu rozmiaru ładunku.

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

Uwagi dotyczące zapobiegania nadużyciom

Jak wspomniano w sekcji dotyczącej prywatności, adSelectionData jest generowany na podstawie wszystkich danych kupującego na urządzeniu.

Otwiera to ekosystem dla potencjalnych podmiotów o złośliwych zamiarach, które mogą dodawać nieuczciwe dane o kupujących, co może obniżyć skuteczność, zwiększać rozmiary ładunków i podnosić koszty.

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

• Zezwalanie CustomAudience na wyraźne określanie autoryzowanych sprzedawców i priorytetu sprzedawcy
• zezwalanie dostawcom SSP na wyraźne określanie kupujących, priorytetów kupujących i kwot na kupującego w generowanym ładunku danych;
• Udostępnij mechanizm dla SSP, aby zdefiniować maksymalną liczbę kupujących na wywołanie lub maksymalny rozmiar na kupującego.

Te środki mają umożliwić dostawcom technologii reklamowych określenie, z jakimi innymi dostawcami technologii reklamowych współpracują, oraz ustawienie dopuszczalnych limitów adSelectionData danych, które muszą przetwarzać. Proponujemy, aby sprzedawca mógł określić tę listę kupujących i priorytet w oddzielnym wywołaniu. Te specyfikacje będą niezmienne przez pewien przedział czasu, aby uniknąć ujawniania dodatkowych danych o użytkowniku za pomocą powtarzających się wywołań.

Te środki zaradcze są obecnie omawiane i mogą ulec zmianie w czasie. Jak już wspomnieliśmy, wszystkie środki zapobiegające nadużyciom i ograniczenia rozmiaru muszą być zgodne z zasadami ochrony prywatności.