Usługi określania stawek i aukcji

W początkowej ofercie pakietowej z Protected Audience API określanie stawek i aukcji żądania reklam remarketingowych są wykonywane lokalnie na urządzeniu. Ten wymóg może wymagać wymagania obliczeniowe, których wykonanie na urządzeniach z ograniczona moc obliczeniowa lub może działać zbyt wolno, by wybierać i renderować reklamy ze względu na: opóźnienia w sieci.

Propozycja usługi ustalania stawek i usług aukcyjnych umożliwia przetwarzania danych z użyciem Protected Audience API na serwery w chmurze w w środowisku wykonawczym (TEE), a nie lokalnie na urządzeniu użytkownika. Oferta B&A ma zapewnić jednolity proces analizowania kontekstu na reklamy remarketingowe. Przeniesienie obliczeń na serwery może pomóc zoptymalizować aukcja z Protected Audience API, która uwalnia cykle obliczeniowe i sieć dla każdego urządzenia.

Google dostarczy składniki B&A i zostaną one udostępnione jako oprogramowania open source. Zainteresowani technicy mogą hostować własne instancje za pomocą dostawców chmury publicznej. Więcej informacji o ofercie B&A znajdziesz na GitHub Daty podane w dokumencie odzwierciedlają na temat implementacji w przeglądarce Chrome. integracji z Androidem w przyszłości. Ten dokument stanowi wprowadzenie oraz nowe interfejsy API, które Android zapewni do interakcji z B&A. Zamieścimy więcej informacji technicznych na temat korzystania z nowych interfejsów API w kolejnych aktualizacjach.

Usługi B&A

Usługa B&A udostępnia dodatkową opcję prowadzenia aukcji w ramach technologii reklamowych na zaufanych serwerach z plikiem binarnym open source udostępnionym przez Google. Dane użytkownika wciąż istnieje na urządzeniu, a Google dostarczy interfejsy API do bezpiecznego przenoszenia danych. do TEE. Więcej informacji o naszej strategii szyfrowania znajdziesz poniżej.

Oznacza to, że niektóre etapy procesu aukcji mają miejsce na urządzeniu, a inne w chmurze. Z perspektywy platformy DSP: niestandardowi odbiorcy (obejmujący reklamy kandydujące) dla kampanii remarketingowych) są nadal zarządzane na urządzeniu za pomocą tych samych niestandardowych wartości do zarządzania odbiorcami, tak jak podczas aukcji na urządzeniu. Źródło: Z perspektywy platform SSP, żądania są nadal wywoływane na urządzeniu – ten dokument zawiera opis nowych interfejsów API, które zostaną użyte. W przypadku wszystkich stron zgłoszenie wyniku aukcji nadal rozpoczyna się na urządzeniu po zakończeniu rozmowy w usłudze B&A.

Główna różnica dotyczy miejsca, w którym adresy URL do określania stawek, wyników i raportowania logika generowania zasobów. Zamiast ustalać stawki, aukcje i raportowanie logika na urządzeniu generateBid(), scoreAd(), reportResult() oraz W TEE wykonywana jest logika reportWin(). Logika ustalania stawek kupującego i sprzedawca logika punktacji jest przeprowadzana w ich własnym środowisku B&A, w środku Przebieg aukcji w ramach Protected Audience API:

Ilustracja przedstawiająca przebieg aukcji z użyciem Protected Audience API z uwzględnieniem stawek i aukcji.
Przebieg aukcji w ramach Protected Audience API

Szyfrowanie danych

W przypadku funkcji B&A informacje z Protected Audience API takie jak niestandardowi odbiorcy i stawka Kwoty przepływów z urządzenia przez serwery technologii reklamowych sprzedawcy z serwerów Google i z powrotem do urządzenia. Z tego powodu platforma szyfruje danych trafiających do usług Protected Audience API i mogą być odszyfrowane tylko usług, które zostały potwierdzone. Dowiedz się więcej o strategiach szyfrowania w GitHub

Architektura i przepływ aukcji

Ta oferta wymaga dodania kilku nowych komponentów wymienionych GitHub – obejmuje przepływ danych z urządzenia do B&A.

Grafika przedstawiająca proces aukcji z ujednoliconymi kontekstami i chronionymi odbiorcami, opisany poniżej.
Ujednolicone kontekstowe i Przebieg aukcji z użyciem Protected Audience API z włączonym ustalaniem stawek i usługami aukcyjnymi.

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

  1. Na urządzeniu sprzedawcy zbierają informacje z Protected Audience API za pomocą Interfejs API getAdSelectionData.
  2. Pakiet SDK na urządzeniu wysyła żądanie do reklamy sprzedawcy usługi. To żądanie zawiera ładunek kontekstowy i Zaszyfrowano plik ProtectedAudienceInput.
  3. Usługa reklamowa sprzedawcy wysyła żądanie do kupującego określanie stawek w czasie rzeczywistym (RTB) działającej poza TEE w celu otrzymywania reklam kontekstowych dla kandydatów, wyniku i wybierz zwycięską reklamę kontekstową.
  4. Usługa reklamowa sprzedawcy wysyła żądanie do SellerFrontEnd. usługi działającej w TEE.
  5. Usługa SellerFrontEnd wysyła żądania z danymi kupującego do Usługi BuyerFrontEnd
  6. Kupujący używają własnej usługi klucz-wartość oraz określania stawek , która generuje stawki dla kandydatów pozyskanych ze źródeł na wszystkich niestandardowych odbiorcach uwzględnianych w remarketingu.
  7. Usługa SellerFrontEnd odczytuje dane ze swojej wartości usługę i oceniaj reklamy kandydujące. Wynik jest zaszyfrowany i wrócił do usługi reklamowej sprzedawcy.
  8. Usługa reklamowa sprzedawcy zwraca zaszyfrowany zwycięski wynik oraz opcjonalnie wyniki kontekstowe do pakietu SDK na urządzeniu.
  9. Na urządzeniu sprzedawcy pobierają zwycięską reklamę za pomocą processAdSelectionResult API, który odszyfrowuje odpowiedź z reklamy sprzedawcy. posprzedażna.

Szczegółowy opis każdego etapu i sposobu szyfrowania danych znajdziesz na GitHub Kod tych komponentów zostanie udostępniony w ramach oprogramowania open source. Podany kod będzie obsługiwać federację żądań z usługa SellerFrontEnd dla usług BuyerFrontEnd.

Wdrożenie Google Cloud

Specjaliści ds. technologii reklamowych wdrażają usługi B&A w obsługiwanej chmurze publicznej . Wdrożeniami zarządzają specjaliści z branży technologii reklamowych, będzie odpowiedzialna za określenie docelowego poziomu usługi w zakresie dostępności.

Przeprowadź aukcję

Pierwszym krokiem do przeprowadzenia aukcji jest zebranie danych do niestandardowych odbiorców i zaszyfrować je, aby trafiły do aukcji po stronie serwera. Do zrobienia tego, użyj interfejsu API getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Metoda getAdSelectionData generuje wymagane dane wejściowe dla komponentów B&A, na przykład BuyerInput, a ProtectedAudienceInput, a następnie szyfruje dane przed wynik jest dostępny dla rozmówcy. Aby zapobiec wyciekowi danych między aplikacjami, zawierają informacje od wszystkich kupujących dostępnych w urządzeniu. Więcej informacji o w sekcji Uwagi na temat 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 komponentu (AdSelectionData) pakiet SDK na urządzeniu może wysłać żądanie do swojego w usłudze reklamowej sprzedawcy przez uwzględnienie danych 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. Zalecane: za pomocą rozwiązania, które zajmuje mało miejsca, np. wysyła żądanie do reklamy sprzedawcy usługę jako multipart/form-data.

Po zainicjowaniu żądania usługa reklamowa sprzedawcy przekazuje je do Usługa SellerFrontEnd działająca w TEE. Podczas konfigurowania interfejsu SellerFrontEnd , sprzedawca poda listę adresów domen, które odpowiadają usługom BuyerFrontEnd realizowanym przez nabywców, współpracuje z Google. Żądania będą sfederowane do różnych interfejsów BuyerFrontEnd usług świadczonych przez sprzedawcę, tak aby kupujący mogli generować stawki wybranych kandydatów. W przypadku konkretnego kupującego usługa B&A będzie wysyłać tylko informacje o listach niestandardowych odbiorców należących do kupującego, dzięki czemu nie i wymianę danych między kupującymi. Po wygenerowaniu stawek lista są wysyłane do usługi SellerFrontEnd, w której zwycięzca zaznaczono. Wreszcie usługa SellerFrontEnd zwraca zaszyfrowaną zwycięską reklamę. do urządzenia.

Gdy odpowiedź z żądania do usługi reklamowej sprzedawcy trafi z powrotem na urządzenie, platforma udostępnia drugi nowy interfejs API do odszyfrowywania wyniku i dostarczania AdSelectionOutcome, ten sam obiekt zwracany z aukcji na urządzeniu. dzisiaj.

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 zostaną wygenerowane w usługach B&A. Pingowanie tych adresów URL w przypadku raportowanie wyświetleń i interakcji w aukcjach będzie nadal wymagało uruchomione na urządzeniu. Pakiet SDK na urządzeniu nadal musi wywołać funkcję reportImpression() i reportInteraction() interfejsów API używających AdSelectionId wygenerowano podczas procesu B&A. Obrazy typu beacon wygenerowane dla raportowania interakcji, a odpowiadające im adresy URL są zawarte w zaszyfrowaną odpowiedzią, więc podczas odszyfrowywania odpowiedzi zdarzenia i adresy URL są przechowywane na urządzeniu.

Kwestie dotyczące prywatności

Ustalanie stawek w przeglądarce Propozycja interfejsu aukcji w GitHubie opisuje w jaki sposób wzięto pod uwagę kwestie prywatności. Ta oferta korzysta z ale te same zasady dotyczą Androida.

Usługa adSelectionData jest szyfrowana, aby zapewnić, że przesyłane dane są dostępne tylko z protokołem PPAPI i zaufanymi serwerami. Aby zmniejszyć ryzyko wycieku danych ze względu na Liczba zmian rozmiaru: adSelectionData, planujemy wygenerować ten sam adSelectionData dla wszystkich wywołań interfejsu getAdSelectionData API. Oznacza to, że wszystkie CustomAudience na urządzeniu służą do tworzenia zasobu adSelectionData. Dodatkowo planujemy ograniczyć wpływ parametrów wejściowych GetAdSelectionData na Wygenerowano: adSelectionData.

Wygenerowanie tego samego parametru adSelectionData w przypadku wszystkich technologii reklamowych z wykorzystaniem wszystkich elementów na urządzeniu danych aukcji przekłada się na większy ładunek, który musi być przesyłany do serwera technologii reklamowych, potencjalnie otwierając ekosystem na nadużycia przed szkodliwymi elementami. Odpowiedzi na te pytania można znaleźć w artykule na temat rozmiaru uwagi i Uwagi na temat przeciwdziałania nadużyciom poniżej.

Kwestie dotyczące rozmiaru

Pakiet SDK klienta technologii reklamowych powinien umieścić w pakiecie zaszyfrowane bajty adSelectionData do wywołania reklam kontekstowych wysłanych na serwer sprzedawcy. Aby uzyskać optymalną skuteczność, należy zoptymalizować rozmiar adSelectionData bez ograniczania funkcjonalności. Planujemy wprowadzić zgodnie z opisem w sekcji Optymalizacja ładunku wyjaśnienie, by zmniejszyć rozmiar adSelectionData. Te optymalizacje będą obejmować:

  1. Dodaję plik ad_render_id w regionie CustomAudience, aby był wysyłany za pomocą: adSelectionData zamiast używania metadanych i identyfikatora URI renderowania reklamy. Technologie reklamowe aby ją zoptymalizować, nie wysyłaj danych reklam w grupie adSelectionData. Ta opcja będzie obsługiwana w CustomAudience API w kolejnych wersjach.
  2. Upewnij się, że w polu adSelectionData nie są wysyłane pola user_bidding_signals. Zamiast tego reklama technicy mogą pobrać user_bidding_signals ze swojego serwera klucz-wartość.
  3. Zezwalaj kupującym na priorytetowe traktowanie atrybutu CustomAudience.
  4. Zezwalaj kupującemu na określanie priorytetu sprzedawcy.
  5. Wygeneruj adSelectionData w kilku stałych zasobnikach, aby ograniczyć wyciek bitów zmniejszając rozmiar ładunku.

Zoptymalizujemy rozmiar, aby zachować zgodność z zastrzeżeniami dotyczącymi prywatności. zalety i wady dostępnych metodologii.

Kwestie związane z przeciwdziałaniem nadużyciom

Jak wspomnieliśmy w sekcji „Kwestie dotyczące prywatności”, plik adSelectionData jest generowany na podstawie użycia funkcji wszystkie dane kupującego na urządzeniu.

Otwiera to ekosystem potencjalnie złośliwych podmiotów, które mogą dodawać fałszywe dane o kupujących, które mogą pogorszyć wydajność, nadmiernie zwiększyć ładunki koszty itd.

Aby zwalczać nadużycia związane z usługą adSelectionData, wprowadzimy następujące środki:

  • Zezwalaj usłudze CustomAudience na wyraźne określanie zatwierdzonych sprzedawców i sprzedawców priorytet
  • Zezwalaj platformom SSP na bezpośrednie określanie kupującego, priorytetu kupującego i limitu dla poszczególnych kupujących wygenerowany ładunek
  • zapewnić platformom SSP mechanizm definiowania maksymalnej liczby kupujących na połączenie lub maksymalny rozmiar na kupującego.

Działania te mają umożliwić technikom reklamowym określenie, które inne technologie z którymi współpracuje, i ustalać dopuszczalne limity na adSelectionData niezbędne do przetworzenia ładunku. Sugerujemy umożliwienie sprzedawcy określenia tę listę kupujących i priorytet w osobnym wywołaniu. Ta specyfikacja zostanie stały w określonym przedziale czasu, co pozwala uniknąć ujawniania dodatkowych danych. o użytkowniku przez powtarzające się połączenia.

Wspomniane powyżej środki łagodzące są w trakcie dyskusji i mogą jeszcze ulec zmianie. obecnie się znajdujesz. Jak już wspomnieliśmy, wszystkie środki zaradcze wprowadzone w celu przeciwdziałania nadużyciom oraz rozmiaru ograniczenia muszą być zgodne z zasadami dotyczącymi prywatności.