Usługi określania stawek i aukcji

bookmark_border Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

W pierwotnym zgłoszeniu 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.

Propozycja dotycząca usług ustalania stawek i aukcji (B&A) opisuje sposób, w jaki można umożliwić przeprowadzenie obliczeń dotyczących chronionych danych odbiorców na serwerach w chmurze w zaufanym środowisku wykonania (TEE), zamiast na urządzeniu użytkownika. Proponowana zmiana w B&A ma na celu umożliwienie jednolitego przetwarzania żądań reklamy w kontekście i remarketingu. Przeniesienie obliczeń na serwery może pomóc w optymalizacji aukcji Protected Audience, ponieważ pozwala zwolnić cykle obliczeniowe i przepustowość sieci na urządzeniu.

Google udostępni komponenty B&A jako oprogramowanie typu open source. Dostawcy technologii reklamowych, którzy są zainteresowani tą usługą, mogą hostować własne instancje u obsługiwanych dostawców publicznych usług w chmurze. Więcej informacji o propozycji dotyczącej B&A 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 Androida, które umożliwiają interakcję z B&A. W przyszłych aktualizacjach opublikujemy więcej informacji technicznych na temat korzystania z tych nowych interfejsów API.

W jakich sytuacjach warto skorzystać z usług B&A

B&A udostępnia dodatkową opcję przeprowadzania aukcji na należących do firmy adtech zaufanych serwerach, na których działa binarna wersja oprogramowania open source udostępniona przez Google. Dane użytkownika nadal znajdują się na urządzeniu, a Google udostępni interfejsy API do bezpiecznego przenoszenia tych danych do 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 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 dostawców usług porównawczych żądania są nadal wywoływane na urządzeniu. 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 ustalania stawek i oceny w środku procesu aukcji z użyciem list odbiorców chronionych:

Szyfrowanie danych

W ramach B&A informacje Protected Audience, takie jak listy odbiorców i kwoty stawek, są przesyłane z urządzenia na serwery technologii reklamowych sprzedawcy, a następnie na serwery technologii reklamowych kupującego i z powrotem na urządzenie. Dlatego platforma szyfruje dane przesyłane do usług Protected Audience i można je odszyfrować tylko za pomocą usług, które zostały poświadczone. Więcej informacji o strategiach szyfrowania znajdziesz 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 APIgetAdSelectionData.
2. Pakiet SDK na urządzeniu wysyła żądanie do usługi reklamy 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 Seller Ad 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 jako oprogramowanie open source. Podany kod będzie obsługiwać federację żądań z usługi SellerFrontEnd do usług BuyerFrontEnd.

Wdrażanie w chmurze

Specjaliści ds. technologii reklamowych wdrożą usługi dotyczące testowania i optymalizacji reklam na obsługiwanej platformie publicznej chmury. 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, aby można było przesłać je do aukcji po stronie serwera. Aby to zrobić, użyj interfejsu getAdSelectionData API:

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 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, które nie wymaga dużo miejsca, np. wysyłanie żądania do usługi reklamowej sprzedawcy jako 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 listach niestandardowych 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, w której wybierany jest zwycięzca. Na koniec usługa SellerFrontEnd zwraca zaszyfrowaną zwycięską reklamę na urządzenie.

Po otrzymaniu odpowiedzi na żądanie z usługi reklamy sprzedawcy z powrotem na urządzeniu 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.

Uwzględnienie kwestii 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 zapewnić, że dane w transmisji 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 zwiększa ilość danych, które należy przesyłać w każdym wywołaniu serwera technologii reklamowej, a zarazem potencjalnie otwiera ekosystem na nadużycia ze strony podmiotów szkodliwych. Te kwestie są omówione 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 zapewnić 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. Specjaliści od technologii reklamowych mogą dodatkowo 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 danych.

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 na potencjalnie szkodliwe podmioty, które mogą dodawać nieuczciwe dane o kupujących, co może obniżyć wydajność, zwiększać rozmiary ładunków, podnosić koszty itp.

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

• Zezwalanie CustomAudience na wyraźne określanie zatwierdzonych sprzedawców i priorytetu sprzedawcy
• zezwalanie SSP na wyraźne określanie kupującego, priorytetu kupującego i kwot na kupującego w generowanym ładunku;
• Udostępnij SSP mechanizm definiowania maksymalnej liczby kupujących na wywołanie lub maksymalnego rozmiaru 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 dla 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 czas, aby uniknąć ujawniania dodatkowych danych o użytkowniku w przypadku powtarzających się wywołań.

Wspomniane wyżej środki zaradcze są obecnie omawiane i mogą ulec zmianie w ciągu czasu. Jak wspomnieliśmy wcześniej, wszystkie środki zapobiegawcze wprowadzone w celu ochrony przed nadużywaniem i ograniczenia rozmiaru muszą być zgodne z zasadami ochrony prywatności.