Integracja i optymalizacja usług ustalania stawek oraz usług aukcyjnych

W propozycji dotyczącej usług określania stawek i aukcji na Androidzie opisano szczegółowo przebieg i przepływ danych podczas przeprowadzania aukcji na Androidzie z użyciem zaufanego serwera określania stawek i aukcji. Aby mieć pewność, że dane podczas przesyłania są obsługiwane tylko przez interfejsy API chroniące prywatność i zaufane serwery, dane są szyfrowane między klientem a serwerem za pomocą dwukierunkowego hybrydowego szyfrowania kluczem publicznym.

Aby przeprowadzić aukcję w sposób opisany wcześniej, technologia reklamowa sprzedawcy na urządzeniu musi wykonać te czynności:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze
2. Wysyłanie żądania do usługi niezaufanego sprzedawcy
3. Otrzymywanie odpowiedzi z usługi niezaufanego sprzedawcy
4. Odszyfrowywanie odpowiedzi z aukcji Protected Audience API i uzyskiwanie wyniku aukcji

W ramach Protected Audience wprowadzamy 2 nowe interfejsy API, które umożliwiają przeprowadzanie aukcji na serwerze:

1. Interfejs getAdSelectionData API zbiera dane na potrzeby aukcji na serwerze i generuje zaszyfrowany ładunek zawierający dane aukcji. Serwer określania stawek i aukcji używa tego ładunku do przeprowadzenia aukcji, wygenerowania jej wyniku i zwrócenia go.
2. Klienci technologii reklamowych na urządzeniu mogą wywoływać interfejs API persistAdSelectionResult, aby odszyfrować wynik wygenerowany przez aukcję na serwerze i uzyskać adres URL renderowania zwycięskiej reklamy.

Aby przeprowadzić aukcję, technologia reklamowa sprzedawcy na urządzeniu musi zintegrować i zbudować te elementy:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze sprzedawcy: technologia reklamowa powinna wywołać interfejs getAdSelectionData API, aby uzyskać zaszyfrowany ładunek.
2. Wysyłanie żądania do usługi niezaufanego sprzedawcy: żądanie HTTP POST lub PUT zawierające zaszyfrowany ładunek wygenerowany przez getAdSelectionData interfejs API do usługi niezaufanego sprzedawcy oraz dane wymagane przez tę usługę do generowania wyników kontekstowych.
3. Otrzymywanie odpowiedzi z usługi niezaufanego sprzedawcy: odpowiedź z usługi niezaufanego sprzedawcy będzie zawierać zaszyfrowany wynik aukcji z użyciem Protected Audience API i wynik aukcji kontekstowej.
4. Odszyfrowanie odpowiedzi na aukcję Protected Audience i uzyskanie wyniku aukcji: aby odszyfrować wynik aukcji Protected Audience, technologia reklamowa sprzedawcy powinna wywołać interfejs API persistAdSelectionResult. Wynik wygenerowany przez persistAdSelectionResult pomoże dostawcom technologii reklamowych określić, czy aukcję wygrała reklama kontekstowa czy reklama kierowana na odbiorców objętych ochroną, a w odpowiednich przypadkach także adres URI wygrywającej reklamy kierowanej na odbiorców objętych ochroną.

Funkcje obsługiwane w przypadku aukcji na serwerze

Staramy się obsługiwać wszystkie funkcje dostępne w przypadku aukcji na urządzeniu. Harmonogram obsługi tych funkcji w aukcjach serwera jest następujący:

Przeprowadzanie aukcji na serwerze za pomocą interfejsów Protected Audience API

W ścieżce wersji przedpremierowej dla programistów interfejs AdSelectionManager udostępnia 2 nowe interfejsy API: getAdSelectionData i persistAdSelectionResult. Te interfejsy API umożliwiają integrację pakietów SDK technologii reklamowych z serwerami określania stawek i aukcji.

Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze

Interfejs getAdSelectionData API generuje wymagane dane wejściowe dla komponentów licytacji i aukcji, 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 ochroną prywatności, a o strategiach optymalizacji w sekcji Kwestie związane z rozmiarem.

Aby uzyskać dostęp do interfejsu API, musi być włączony dostęp do Protected Audience API, a w pliku manifestuACCESS_ADSERVICES_CUSTOM_AUDIENCE wywołującego musi być zdefiniowane uprawnienie ACCESS_ADSERVICES_CUSTOM_AUDIENCE.

public class AdSelectionManager {
    public void getAdSelectionData(
            GetAdSelectionDataRequest getAdSelectionDataRequest,
            Executor executor,
            OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}

GetAdSelectionDataRequest

1. Wywołujący musi ustawić pole seller w żądaniu, ponieważ jest ono używane do sprawdzania rejestracji przed obsługą żądania.
2. Pole coordinatorOriginUri jest opcjonalne.
   1. Jeśli jest ustawiony, powinien być równy schematowi, nazwie hosta i portowi adresu URL koordynatora, który został skonfigurowany podczas wdrażania serwera B&A sprzedawcy.
   2. Koordynator musi znajdować się na liście zatwierdzonych koordynatorów:

      Dostawca	Identyfikator URI	Identyfikator URI źródła	Domyślny
      Google Cloud	https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.gcp.privacysandboxservices.com	Tak
      Amazon Web Services	https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys	https://publickeyservice.pa.aws.privacysandboxservices.com	Nie

   3. Jeśli nie podasz źródła koordynatora, użyty zostanie domyślny koordynator.
   4. Chociaż jest mało prawdopodobne, że adres URL koordynatora ulegnie zmianie, zdecydowanie zalecamy wdrożenie mechanizmu dynamicznego zarządzania tym adresem URL. Dzięki temu wszelkie przyszłe zmiany adresu URL będą mogły zostać uwzględnione bez konieczności publikowania nowej wersji pakietu SDK.

public class GetAdSelectionDataRequest {
  public setSeller(AdTechIdentifier seller);
  public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}

Po zweryfikowaniu żądania dane kupującego na urządzeniu są łączone w BuyerInput i ProtectedAudienceInput. Końcowy obiekt ładunku jest następnie szyfrowany przy użyciu dwukierunkowego hybrydowego szyfrowania kluczem publicznym.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome jest generowany w wyniku działania interfejsu getAdSelectionData. Zawiera on:

1. adSelectionId: nieprzezroczysta liczba całkowita służąca do identyfikowania tego wywołania funkcji getAdSelectionData. Klient technologii reklamowej powinien zachować tę wartość, ponieważ działa ona jako wskaźnik wywołania.adSelectionIdgetAdSelectionData Ten identyfikator jest wymagany przez interfejs persistAdSelectionResult API do odszyfrowania wyniku aukcji z serwera licytacji i aukcji oraz przez interfejsy reportImpression i reportEvent API.
2. adSelectionData: są to zaszyfrowane dane aukcji, które są wymagane przez serwer określania stawek i aukcji do przeprowadzania aukcji. Ta metoda zawiera:
   1. Filtrowane dane niestandardowych list odbiorców na podstawie ograniczenia liczby wyświetleń, filtrów instalacji aplikacji i wymagań aukcji na serwerze dotyczących niestandardowych list odbiorców.
   2. W przyszłej wersji będzie zawierać dane o instalacjach aplikacji.

public class GetAdSelectionDataOutcome {
  Public getAdSelectionId(long adSelectionId);
  public byte[] getAdSelectionData();
}

Błędy, wyjątki i obsługa awarii

Jeśli generowanie danych do wyboru reklamy nie może zostać ukończone z powodu np. nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia zasobów, wywołanie zwrotne OutcomeReceiver.onError() zapewnia AdServicesException o następujących właściwościach:

1. Jeśli funkcja getAdSelectionData zostanie zainicjowana z nieprawidłowymi argumentami, AdServicesException` wskazuje, że przyczyną jest wyjątek IllegalArgumentException.
2. W przypadku wszystkich innych błędów wyświetla się ikona AdServicesException z przyczyną IllegalStateException.

Wysyłanie żądania do usługi sprzedawcy, która nie jest zaufana

Za pomocą interfejsu 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, np. wysyłanie żądania do usługi reklamowej sprzedawcy w formacie multipart/form-data.

Otrzymywanie odpowiedzi z niezaufanej usługi sprzedawcy

Jak opisano w wyjaśnieniu dotyczącym serwera określania stawek i aukcji, gdy niezaufana usługa sprzedawcy otrzyma żądanie, wysyła wywołania do kupujących będących partnerami w zakresie reklam kontekstowych.

Niezaufana usługa sprzedawcy przekazuje zaszyfrowane wartości adSelectionData i AuctionConfig do usługi SellerFrontEnd serwera określania stawek i aukcji działającej w TEE.

Po zakończeniu aukcji z użyciem Protected Audience API usługa SellerFrontEnd szyfruje wynik aukcji i zwraca go jako odpowiedź do niezaufanej usługi sprzedawcy.

Usługa sprzedawcy, któremu nie ufamy, wysyła na urządzenie odpowiedź zawierającą reklamę kontekstową lub zaszyfrowany wynik aukcji z użyciem Protected Audience API.

Po otrzymaniu odpowiedzi kod technologii reklamowej sprzedawcy na urządzeniu może zdecydować, czy użyć tylko reklamy kontekstowej z odpowiedzi, czy też, jeśli uzna, że uzyskanie wyniku Protected Audience przyniesie dodatkową wartość, może odszyfrować ten wynik, wywołując interfejs PersistAdSelectionResult.

PersistAdSelectionResult API

Aby odszyfrować wynik Protected Audience, dostawca technologii reklamowych sprzedawcy może wywołać drugi interfejs Protected Audience APIpersistAdSelectionResult. Interfejs API odszyfrowuje wynik i zwraca obiekt AdSelectionOutcome, czyli ten sam obiekt, który jest obecnie zwracany z aukcji na urządzeniu.

Aby uzyskać dostęp do interfejsu API, wywołujący musi włączyć dostęp do Protected Audience API i zdefiniować uprawnienie ACCESS_ADSERVICES_CUSTOM_AUDIENCE w pliku manifestu.

    public void persistAdSelectionResult(
            PersistAdSelectionResultRequest persistAdSelectionResultRequest,
            Executor executor,
            OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}

PersistAdSelectionResultRequest

W żądaniu wywołujący musi ustawić te parametry:

public final class PersistAdSelectionResultRequest {
  Public setAdSelectionId(long adSelectionId);
  public setSeller(AdTechIdentifier seller);
  public setAdSelectionResult(byte[] adSelectionResult);
}

1. adSelectionId: nieprzezroczysty identyfikator wygenerowany przez wywołanie getAdSelectionData, którego wynik rozmówca chce odszyfrować.
2. seller: w żądaniu musi być ustawiony identyfikator technologii reklamowej sprzedawcy, aby przed jego obsługą można było przeprowadzić weryfikację rejestracji.
3. adSelectionResult: zaszyfrowany wynik aukcji wygenerowany przez serwer licytacji i aukcji, który wywołujący chce odszyfrować.

Odpowiedź AdSelectionOutcome

Jeśli jest zwycięzca Protected Audience, funkcja AdSelectionOutcome zwraca adres URI wyrenderowanej zwycięskiej reklamy.Po odszyfrowaniu funkcji adSelectionResult dane raportowania są przechowywane wewnętrznie. Wywołanie zwrotne OutcomeReceiver.onResult() zwraca obiekt AdSelectionOutcome, który zawiera:

• URI: Jeśli jest zwycięska reklama Protected Audience, zwracany jest adres URL renderowania reklamy dla zwycięskiej reklamy. Jeśli nie ma zwycięzcy aukcji z Protected Audience API, zwracana jest wartość `Uri.EMPTY.
• adSelectionId: adSelectionId powiązany z tą aukcją serwera.

Błędy, wyjątki i obsługa awarii

Jeśli generowanie danych do wyboru reklamy nie może zostać ukończone z powodu np. nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia zasobów, wywołanie zwrotne OutcomeReceiver.onError() zapewnia AdServicesException o następujących właściwościach:

1. Jeśli funkcja getAdSelectionData zostanie zainicjowana z nieprawidłowymi argumentami, funkcja AdServicesException wskaże IllegalArgumentException jako przyczynę.
2. W przypadku wszystkich innych błędów wyświetla się ikona AdServicesException z przyczyną IllegalStateException.

Kwestie dotyczące prywatności

adSelectionData jest szyfrowany, aby dane podczas przesyłania były dostępne tylko dla PPAPI i zaufanych serwerów.

Pomimo szyfrowania może dojść do wycieku danych z powodu rozmiaru adSelectionData. RozmiaradSelectionData może się różnić z powodu:

1. Zmiany w danych CustomAudience na urządzeniu.
2. Zmiany w logice filtrowania CustomAudience.
3. Zmiany w danych wejściowych połączenia getAdSelectionData.

Zmiana rozmiaru adSelectionData może być używana do generowania identyfikatora w różnych aplikacjach, jak wspomniano w dyskusji na temat wycieku 1 bitu. Wiele środków zaradczych stosowanych w przypadku wycieku 1-bitowego ma zastosowanie również w tym przypadku.

Aby zarządzać tymi wyciekami, planujemy generować ten sam adSelectionData dla wszystkich wywołań interfejsu getAdSelectionData API. W pierwszych wersjach wszystkie CustomAudiences na urządzeniu są używane do tworzenia adSelectionData, a zaszyfrowany ładunek będzie uzupełniany, aby ukryć różnice w rozmiarze. Ograniczymy też wpływ parametrów wejściowych GetAdSelectionData na wygenerowane adSelectionData.

Generowanie tego samego parametru adSelectionData dla wszystkich technologii reklamowych przy użyciu wszystkich danych z aukcji na urządzeniu powoduje jednak utworzenie dużego pakietu danych, który musi być przesyłany w każdym wywołaniu serwera technologii reklamowej. Używanie wszystkich niestandardowych list odbiorców na urządzeniu do generowania ładunku aukcji również naraża ekosystem na nadużycia ze strony złośliwych podmiotów. Odpowiedzi na te pytania znajdziesz w sekcjach Optymalizacja rozmiaru i Ograniczanie nadużyć.

Optymalizacje rozmiaru

Pakiet SDK klienta technologii reklamowej powinien spakować zaszyfrowane bajty adSelectionData do HTTP PUT/POST wywołania kontekstowego wysyłanego na serwer technologii reklamowej. Aby zmniejszyć opóźnienie i koszty, należy jak najbardziej zredukować adSelectionData, nie wpływając przy tym na użyteczność.

W najbliższych wersjach planujemy wprowadzić te optymalizacje, aby zmniejszyć rozmiar adSelectionData:

1. Ładunek generowany w stałym zestawie rozmiarów przedziałów z wypełnieniem: aby zminimalizować wyciek informacji wynikający z różnic w rozmiarach, a jednocześnie umożliwić mniejsze ładunki, zalecamy używanie przedziałów o stałym rozmiarze w przypadku generowanego ładunku. Utrzymywanie małej liczby przedziałów, np. 7, spowoduje wyciek entropii mniejszy niż 3 bity na każde wywołanie funkcji getAdSelectionData.

   Jeśli dane na urządzeniu przekroczą maksymalny rozmiar zasobnika, do określenia, które dane zostaną usunięte, będą używane strategie takie jak wartości priorytetowe.

2. Konfiguracja kupującego: oceniamy możliwość umożliwienia kupującym skonfigurowania ładunku dla każdego kupującego. Ta konfiguracja może być przydatna do określania, w których aukcjach kupujący jest zainteresowany udziałem. Jeśli to możliwe, podczas rejestracji technologia reklamowa kupującego może zarejestrować punkt końcowy, z którego Protected Audience będzie codziennie pobierać konfigurację ładunku. Alternatywnie interfejsy API chroniące prywatność udostępniałyby interfejs API, który umożliwiałby rejestrowanie tego punktu końcowego przez technologie reklamowe kupujących.

   Ta konfiguracja będzie następnie używana do oceny udziału kupującego w adSelectionData wygenerowanych w przypadku każdego żądania getAdSelectionData.

   Konfiguracja ładunku kupującego umożliwia kupującym określenie:

   1. Lista dozwolonych sprzedawców: niestandardowe listy odbiorców kupującego będą dodawane do ładunku tylko wtedy, gdy wywołanie getAdSelectionData zostanie zainicjowane przez sprzedawcę z listy dozwolonych. Konfigurację ładunku będziemy pobierać codziennie, aby lista dozwolonych była aktualna.
   2. Limit rozmiaru dla poszczególnych sprzedawców: kupujący może określić limit rozmiaru dla poszczególnych sprzedawców, aby określić rozmiar danych, które mają być wysyłane w ładunku, gdy aukcja jest inicjowana przez określonego sprzedawcę. Może to być przydatne, jeśli kupujący chce przeznaczyć więcej zasobów na przetwarzanie danych aukcyjnych od określonych sprzedawców. Usługa SellerFrontendService przekazuje do każdej usługi BuyerFrontendService tylko dane dotyczące kupującego. Dzięki zdefiniowaniu limitu rozmiaru dla każdego sprzedawcy kupujący może wyraźnie kontrolować ilość danych pobieranych i przetwarzanych przez usługę BuyerFrontendService na serwerze określania stawek i aukcji w przypadku aukcji prowadzonych przez sprzedawcę.

3. Konfiguracja sprzedawcy: sprawdzamy możliwość wprowadzenia konfiguracji aukcji dla poszczególnych sprzedawców, która pozwoli im określać parametry aukcji w celu kontrolowania rozmiaru ładunku i uczestników aukcji. Jeśli to możliwe, podczas rejestracji technologia reklamowa sprzedawcy będzie mogła określić punkt końcowy, z którego interfejs Protected Audience API będzie regularnie pobierać konfigurację aukcji dla poszczególnych sprzedawców. Ta konfiguracja będzie następnie używana do określania składu i limitów adSelectionData generowanych dla każdego żądania getAdSelectionData.

   Podobnie jak w przypadku konfiguracji kupującego, konfiguracja dla każdego sprzedawcy umożliwia sprzedawcom określenie, których kupujących oczekują na aukcji, oraz określenie limitów udziału poszczególnych kupujących w rozmiarze pakietu danych.

   Konfiguracja aukcji sprzedawcy umożliwia sprzedawcom określanie:

   1. Lista dozwolonych kupujących: w przypadku aukcji zainicjowanych przez danego sprzedawcę tylko kupujący z listy dozwolonych będą mogli przekazywać na aukcję listy CustomAudience. Konfigurację aukcji trzeba będzie aktualizować codziennie, aby lista dozwolonych była zgodna z listą dozwolonych kupujących po stronie serwera.
   2. Limit rozmiaru na kupującego: sprzedawcy mogą określić limit na kupującego, aby regulować rozmiar danych przesyłanych przez każdego kupującego do ładunku wysyłanego do usługi SellerFrontendService. Jeśli kupujący przekroczy limit rozmiaru na kupującego, do uzyskania danych w oczekiwanych limitach zostanie użyty priorytet CustomAudience ustawiony w konfiguracji ładunku kupującego.
   3. Priorytet dla kupującego: umożliwia sprzedawcom ustawianie priorytetu dla kupującego. Priorytet kupującego będzie używany do określania, które dane kupującego należy zachować w ładunku, jeśli jego rozmiar przekroczy limit.
   4. Maksymalny limit rozmiaru ładunku: różni sprzedawcy mogą mieć różne przydziały zasobów i chcieć ustawić maksymalny limit rozmiaru ładunku aukcji w przypadku poszczególnych żądań. Maksymalny limit rozmiaru będzie uwzględniać stałe przedziały rozmiarów ustawione przez interfejs Protected Audience API.

4. Zmiany na niestandardowych listach odbiorców

   1. Określanie priorytetu listy odbiorców niestandardowych: umożliwia kupującym określanie wartości priorytetu na liście odbiorców niestandardowych. Pole priority służy do identyfikowania niestandardowych list odbiorców, które powinny być uwzględniane w aukcji, jeśli zbiór niestandardowych list odbiorców kupującego przekracza limity rozmiaru dla sprzedawcy lub kupującego. Nieokreślona wartość priorytetu w przypadku odbiorców niestandardowych będzie domyślnie przyjmować wartość 0.0.

5. Zmiany w danych ładunku

   1. Ograniczanie ilości danych przesyłanych w ładunku: jak opisano w artykule Optymalizacja ładunku usług ustalania stawek i aukcji, większy ładunek jest spowodowany przez dane ads dotyczące niestandardowych list odbiorców, sygnały licytowania użytkowników i sygnały Androida. Większe rozmiary plików mogą zostać zmniejszone przez:
      1. Klient wysyła w ładunku identyfikatory renderowania reklam (zamiast obiektów reklam).
      2. Klient nie przesyła w ładunku żadnych danych reklam.
      3. Nie wysyłaj sygnałów określania stawek użytkownika w ładunku klienta.

Te strategie umożliwiają dostawcom technologii reklamowych określanie konfiguracji do zarządzania adSelectionData kompozycją i limitami ładunku, ale mogą też wpływać na rozmiar adSelectionData przez zmianę parametrów konfiguracji. Aby tego uniknąć, Protected Audience będzie codziennie pobierać konfigurację ze skonfigurowanego punktu końcowego.

Optymalizacja opóźnienia

Aby aukcje na serwerze były przydatne, musimy mieć pewność, że interfejsy getAdSelectionData API i persistAdSelectionResult API mają małe opóźnienie na wywołanie. Chociaż w 2023 r. planujemy wprowadzić obsługę funkcji w interfejsach API, w kolejnej wersji skupimy się na testach porównawczych opóźnień i optymalizacji interfejsów API.

Aby utrzymać opóźnienie w dopuszczalnych granicach, rozważamy te strategie:

1. Wstępne generowanie danych Protected Audience dla każdego sprzedawcy: ponieważ konfiguracja aukcji sprzedawcy i konfiguracja ładunku kupującego będą stabilne przez dłuższy czas (codziennie), platforma może wstępnie obliczać i przechowywać odpowiednie dane Protected Audience.

   Wymagałoby to od platformy stworzenia mechanizmu monitorowania aktualizacji niestandardowych list odbiorców i modyfikowania wstępnie wygenerowanych danych o chronionych odbiorcach na podstawie tych aktualizacji. Platforma musiałaby też zadeklarować poziomy usług (SLO) dotyczące opóźnienia, jakiego technologia reklamowa może oczekiwać między aktualizacjami list odbiorców niestandardowych a widocznością zmiany w adSelectionData wygenerowanym na potrzeby aukcji na serwerze.

   Urządzenie udostępnia model obliczeniowy o ograniczonych zasobach i różnych priorytetach procesów, dlatego zdajemy sobie sprawę, że udostępnienie tej funkcji wstępnego generowania musi wiązać się z wysoką niezawodnością i gwarancjami dotyczącymi poziomów usług.

   Wstępne generowanie danych odbiorców chronionych będzie wtedy oparte na

   1. Sprzedawca może wyrazić zgodę na wstępne generowanie danych Protected Audience.
   2. Kupujący, którzy mogą uczestniczyć w aukcji zainicjowanej przez konkretnego sprzedawcę.
   3. Identyfikowanie niestandardowych list odbiorców dla każdego kupującego, które będą częścią ładunku na podstawie:
      1. limity rozmiaru na kupującego, priorytet na kupującego i limity maksymalnego rozmiaru określone w konfiguracji sprzedawcy,
      2. Limit rozmiaru na sprzedawcę, priorytet grupy odbiorców niestandardowych określony w konfiguracji kupującego.

2. Szybkie stosowanie filtrowania negatywnego: jeśli sprzedawca sobie tego życzy, platforma może wstępnie obliczyć wartość adSelectionData, generując z wyprzedzeniem dane chronionej listy odbiorców i stosując filtrowanie negatywne poza krytycznym wywołaniem getAdSelectionData. Pozwoli to sprzedawcom zrównoważyć zmniejszenie opóźnienia z akceptacją nieaktualności w przypadku filtrowania negatywnego.

   Platforma może zapewnić tę obsługę, udostępniając opcję domyślną w konfiguracji sprzedawcy z limitem nieaktualności i opcją zastąpienia w getAdSelectionData, aby w razie potrzeby umożliwić obliczanie najświeższych danych. Platforma może też udostępnić dodatkowy interfejs API inicjowania, który należy wywołać przed wywołaniem funkcji getAdSelectionData, aby przygotować aukcję.

3. Obliczanie ładunku w przypadku wielu aukcji: w niektórych sytuacjach korzystniejsze może być użycie interfejsu API o niskim poziomie opóźnień, nawet kosztem większej nieaktualności danych. Aby to umożliwić, platforma może wprowadzić interfejs API inicjowania, który oblicza cały ładunek i przekazuje do wywołującego odwołanie do obliczonego ładunku.

   W przypadku kolejnych połączeń z numerem getAdSelectionData dzwoniący może podać odniesienie do wstępnie obliczonego ładunku, który ma być użyty do wygenerowania adSelectionData.

Te 3 strategie są na początkowym etapie eksploracji i mają na celu opisanie kierunku, w którym platforma może zmierzać, aby zoptymalizować opóźnienie. W miarę poznawania bardziej szczegółowych profili opóźnień interfejsu API i wymagań technologii reklamowych będziemy proponować kolejne strategie.

Ograniczanie nadużyć i ich identyfikowanie

Zgodnie z informacjami w sekcji Względy dotyczące prywatności wartość adSelectionData jest generowana na podstawie wszystkich danych kupującego na urządzeniu.

Jeśli jednak wszystkie dane kupującego na urządzeniu są używane do generowania danych wyjściowych adSelectionData, złośliwy podmiot może podszywać się pod kupującego i tworzyć fałszywe dane kupującego, aby obniżyć wydajność Androida, zwiększyć rozmiar pakietu danych, aby zwiększyć koszt przeprowadzania aukcji lub ustalania stawek przez technologię reklamową, i tak dalej.

Łagodzenie

Niektóre środki wymienione w sekcji dotyczącej rozmiaru, takie jak konfiguracja ładunku kupującego zawierająca autoryzowanych sprzedawców i konfiguracja aukcji sprzedawcy zawierająca autoryzowanych kupujących, pomogą wykluczyć nieoczekiwane dane z ładunku.

Inne środki dotyczące rozmiaru, takie jak umożliwienie platformom SSP określania priorytetu kupującego, umieszczanie w wygenerowanym ładunku limitu dla każdego kupującego i ustawianie maksymalnego rozmiaru ładunku na aukcję, mogą również pomóc w ograniczeniu wpływu złośliwego zwiększania rozmiaru ładunku. Te środki mają na celu umożliwienie dostawcom technologii reklamowych określania, z którymi dostawcami chcą współpracować, oraz ustalania dopuszczalnych limitów danych, które będą musieli przetwarzać.

Jak wspomnieliśmy wcześniej, wszystkie środki zapobiegawcze wprowadzone w celu przeciwdziałania nadużyciom i ograniczeniom rozmiaru muszą być zgodne z zasadami ochrony prywatności.

Identyfikowanie szkodliwych podmiotów

Te środki zapobiegawcze chronią generowanie adSelectionData w przypadku aukcji na serwerze, ale nie pomagają w identyfikowaniu złośliwych podmiotów ani w ochronie platformy przed nadużyciami, takimi jak tworzenie przez kupującego bezprecedensowej liczby niestandardowych list odbiorców.

Aby sprawdzić stabilność i stan platformy, musimy znaleźć mechanizm identyfikowania złośliwych podmiotów, wektorów nadużyć i motywacji konkretnych ataków. W kolejnych wersjach udostępnimy wyjaśnienia szczegółowo opisujące potencjalne wektory nadużyć i zabezpieczenia, które im przeciwdziałają.