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

Propozycja projektu Określanie stawek i usługi aukcyjne na Androida zawiera szczegółowe informacje o przeprowadzaniu i przepływie danych związanych z prowadzeniem aukcji na Androidzie z wykorzystaniem serwera Zaufanego określania stawek i serwera aukcji. Aby dane w ruchu były obsługiwane tylko przez interfejsy API chroniące prywatność i zaufane serwery, dane są szyfrowane między klientem a serwerem przy użyciu dwukierunkowego hybrydowego szyfrowania klucza publicznego.

Przebieg aukcji w ramach Protected Audience API.

Aby przeprowadzić aukcję zgodnie z wcześniejszymi informacjami, sprzedawca technologii reklamowej na urządzeniu musi wykonać te czynności:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji serwerów
2. Wyślij prośbę do usługi niezaufanych sprzedawców
3. Otrzymanie odpowiedzi z usługi niezaufanych sprzedawców
4. Odszyfrowywanie odpowiedzi aukcji w ramach Protected Audience API i uzyskiwanie wyniku aukcji

W ramach Protected Audience wprowadzamy 2 nowe interfejsy API do obsługi aukcji serwerów:

1. Interfejs getAdSelectionData API gromadzi dane na potrzeby aukcji serwera i generuje zaszyfrowany ładunek zawierający dane z aukcji. Na podstawie tego ładunku serwer aukcji i określania stawek przeprowadza aukcję, generuje jej wynik i zwraca wynik.
2. Klienci technologii reklamowych na urządzeniu mogą wywołać interfejs API persistAdSelectionResult, aby odszyfrować wynik aukcji serwera i uzyskać zwycięski URL do renderowania reklam.

Technologia reklamowa sprzedawcy na urządzeniu musi zintegrować i skompilować te elementy, aby przeprowadzić aukcję:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji serwera dla sprzedawcy: aby uzyskać zaszyfrowany ładunek, technologia reklamowa powinna wywołać interfejs API getAdSelectionData.
2. Wyślij żądanie do usługi niezaufanego sprzedawcy: żądanie HTTP POST lub PUT zawierające zaszyfrowany ładunek wygenerowany przez interfejs getAdSelectionData API do usługi niezaufanego sprzedawcy oraz dane wymagane przez usługę niezaufanego sprzedawcy do wygenerowania wyników kontekstowych.
3. Otrzymywanie odpowiedzi z usługi niezaufanych sprzedawców: odpowiedź z usługi niezaufanego sprzedawcy będzie zawierać zaszyfrowany wynik aukcji na chronionej grupie odbiorców i kontekstowy wynik aukcji.
4. Odszyfrowywanie odpowiedzi na aukcji chronionej grupy odbiorców i uzyskiwanie wyniku aukcji: Aby odszyfrować wynik aukcji chronionej listy odbiorców, technologia reklamowa sprzedawcy powinna wywołać interfejs API persistAdSelectionResult. Wynik wygenerowany przez funkcję persistAdSelectionResult pomoże technikom reklamowym określić, czy aukcję wygrała reklama kontekstowa czy reklama na podstawie list chronionych odbiorców, a w odpowiednich przypadkach także identyfikator URI zwycięskiej reklamy chronionej dla odbiorców.

Funkcje obsługiwane w przypadku aukcji serwera

Naszym celem jest obsługa wszystkich funkcji dostępnych obecnie w ramach aukcji na urządzeniu. Harmonogram obsługi tych funkcji w ramach aukcji serwera:

	Aukcja na urządzeniu		Aukcja serwera
	wersja przedpremierowa dla programistów	Beta	wersja przedpremierowa dla programistów	Beta
Raporty o wygranych na poziomie zdarzenia	I kw. 2023 roku	III kw. 2023 roku	Nie dotyczy	IV kw. 2023 roku
Zapośredniczenie kaskadowe	I kw. 2023 roku	IV kw. 2023 roku	Nie dotyczy	I kw. 24 roku
Filtrowanie limitu wyświetleń na użytkownika	II kw. 2023 roku	III kw. 2023 roku	Nie dotyczy	IV kw. 2023 roku
Przekazywanie reklam kontekstowych do procesu wyboru reklamy na potrzeby filtrowania	II kw. 2023 roku	I kw. 2024 roku	Nie dotyczy	Nie dotyczy
Raportowanie interakcji	II kw. 2023 roku	III kw. 2023 roku	Nie dotyczy	IV kw. 2023 roku
Przekazywanie dostępu do niestandardowych list odbiorców	III kw. 2023 roku	IV kw. 2023 roku	Nie dotyczy	IV kw. 2023 roku
płatności inne niż CPM	III kw. 2023 roku	IV kw. 2023 roku
Raportowanie debugowania	III kw. 2023 roku	IV kw. 2023 roku	III kw. 2023 roku	IV kw. 2023 roku
Zapośredniczenie Otwartego ustalania stawek	Nie dotyczy	Nie dotyczy	Nie dotyczy	I kw. 2024 roku
Filtrowanie reklam promujących instalacje aplikacji	II kw. 2023 roku	I kw. 2024 roku	Nie dotyczy	I kw. 2024 roku
Zarządzanie walutami	Nie dotyczy	Nie dotyczy	Nie dotyczy	I kw. 2024 roku
Integracja K-anon	Nie dotyczy	I kw. 2024 roku	Nie dotyczy	I kw. 2024 roku
Integracja agregacji prywatnej	Nie dotyczy	Nie dotyczy	Nie dotyczy	III kw. 2024 roku

Przeprowadzanie aukcji serwera z wykorzystaniem interfejsów Protected Audience API

Na ścieżce podglądu dla programistów AdSelectionManager udostępnia 2 nowe interfejsy API: getAdSelectionData i persistAdSelectionResult. Umożliwiają one integrację pakietów SDK technologii reklamowych z serwerami określania stawek i aukcji.

Zbieranie i szyfrowanie danych na potrzeby aukcji serwera

Interfejs getAdSelectionData API generuje wymagane dane wejściowe na potrzeby komponentów związanych z określaniem stawek i aukcji, np. BuyerInput i ProtectedAudienceInput, oraz szyfruje dane przed udostępnieniem wyniku funkcji wywołującej. Aby zapobiec wyciekom danych między aplikacjami, zawierają one informacje od wszystkich kupujących, którzy korzystają z urządzenia. Więcej informacji o tej decyzji znajdziesz w sekcji Kwestie dotyczące prywatności oraz w sekcji poświęconej kwestiom dotyczącym rozmiaru.

Aby uzyskać dostęp do interfejsu API, musisz mieć włączony dostęp do interfejsu Protected Audience API, a w pliku manifestu wywołania musisz określić uprawnienie ACCESS_ADSERVICES_CUSTOM_AUDIENCE.

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

GetAdSelectionDataRequest

Element wywołujący musi ustawić w żądaniu pole seller, ponieważ jest ono używane do sprawdzania rejestracji przed obsługą żądania.

public class GetAdSelectionDataRequest {
  Public setSeller(AdTechIdentifier seller);
}

Po weryfikacji żądania dane o kupujących na urządzeniu są zapisywane w znacznikach BuyerInput i ProtectedAudienceInput. Końcowy obiekt ładunku jest następnie szyfrowany przy użyciu dwukierunkowego hybrydowego szyfrowania klucza publicznego.

GetAdSelectionDataOutcome

GetAdSelectionDataOutcome jest generowany w wyniku działania interfejsu API getAdSelectionData. Zawiera ona te elementy:

1. adSelectionId: nieprzejrzysta liczba całkowita identyfikująca wywołanie getAdSelectionData. Klient technologii reklamowej powinien zachować tę wartość adSelectionId, ponieważ działa jako wskaźnik wywołania getAdSelectionData. Ten identyfikator jest wymagany przez interfejs API persistAdSelectionResult do odszyfrowywania wyniku aukcji z serwera określania stawek i aukcji. Jest on też wymagany przez interfejsy API reportImpression i reportEvent.
2. adSelectionData: to zaszyfrowane dane z aukcji, które są wymagane przez serwer ustalania stawek i aukcji do przeprowadzenia aukcji. Ta metoda obejmuje:
   1. Odfiltrowano dane o odbiorcach niestandardowych na podstawie ograniczenia liczby wyświetleń, filtrów instalacji aplikacji i wymagań dotyczących aukcji serwera w przypadku niestandardowych list odbiorców.
   2. W jednej z przyszłych wersji będzie on zawierać dane o instalacjach aplikacji.

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

Błędy, wyjątki i obsługa błędów

Jeśli nie można wygenerować danych o wyborze reklamy z powodu nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia zasobów, wywołanie zwrotne OutcomeReceiver.onError() powoduje wystąpienie AdServicesException o takim działaniu:

1. Jeśli funkcja getAdSelectionData jest inicjowana z nieprawidłowymi argumentami, AdServicesException wskazuje jako przyczynę wyjątek IllegalArgumentException.
2. W przypadku pozostałych błędów wyświetlany jest komunikat AdServicesException z przyczyną IllegalStateException.

Wyślij prośbę do usługi niezaufanego sprzedawcy

Za pomocą AdSelectionData pakiet SDK na urządzeniu może wysłać żądanie do usługi reklamowej sprzedawcy, uwzględniają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 korzystanie z rozwiązania, które zajmuje niewiele miejsca, np. wysyłanie żądania do usługi reklamowej sprzedawcy w postaci danych wieloczęściowych lub danych formularzy.

Otrzymanie odpowiedzi od usługi niezaufanego sprzedawcy

Jak opisano w wyjaśnieniu dotyczącym serwera aukcji i określania stawek, gdy usługa niezaufanego sprzedawcy otrzyma żądanie, wysyła do kupujących partnerów reklamy kontekstowe.

Usługa niezaufanych sprzedawców przekazuje zaszyfrowane adSelectionData i AuctionConfig do usługi SellerFrontEnd serwera określania stawek i aukcji w TEE.

Po zakończeniu aukcji w ramach Protected Audience API usługa SellerFrontEnd szyfruje wynik aukcji i zwraca go w odpowiedzi na usługę niezaufanego sprzedawcy.

Usługa niezaufanego sprzedawcy wysyła na urządzenie odpowiedź zawierającą reklamę kontekstową lub zaszyfrowany wynik aukcji w ramach Protected Audience API.

Po otrzymaniu odpowiedzi kod technologii reklamowej sprzedawcy na urządzeniu może wybrać w odpowiedzi tylko reklamę kontekstową lub jeśli uzna, że uzyskanie wyniku Protected Audience API ma przyrostową wartość, może odszyfrować wynik Protected Audience API, wywołując interfejs API PersistAdSelectionResult.

Interfejs API PersistAdSelectionResult

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

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

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

PersistAdSelectionResultRequest

Element wywołujący musi ustawić w żądaniu te dane:

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

1. adSelectionId: nieprzejrzysty identyfikator generowany przez wywołanie getAdSelectionData, którego wynik chce odszyfrować element wywołujący.
2. seller: w żądaniu musi być ustawiony identyfikator technologii reklam sprzedawcy, aby można było przeprowadzić weryfikację rejestracji przed jego przetworzeniem.
3. adSelectionResult: zaszyfrowany wynik aukcji wygenerowany przez serwer ustalania stawek i serwer aukcji, który chcesz odszyfrować przez element wywołujący.

Odpowiedź na wynik wyboru reklamy

Jeśli zwycięzca wygrywa w ramach Protected Audience, AdSelectionOutcome zwraca identyfikator URI zwycięskiej renderowania reklamy.Po odszyfrowaniu parametru adSelectionResult dane raportowania są zapisywane wewnętrznie. Wywołanie zwrotne OutcomeReceiver.onResult() zwraca wartość AdSelectionOutcome, która zawiera:

• URI: jeśli wygra reklama w ramach Protected Audience API, zwracany jest URL wyrenderowanej reklamy. Jeśli nie uda się wyłonić zwycięzcy testu w ramach Protected Audience, zwracany jest typ „Uri.EMPTY”.
• adSelectionId: adSelectionId powiązany z tym przebiegiem aukcji na serwerze.

Błędy, wyjątki i obsługa błędów

Jeśli nie można wygenerować danych o wyborze reklamy z powodu nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia zasobów, wywołanie zwrotne OutcomeReceiver.onError() powoduje wystąpienie AdServicesException o takim działaniu:

1. Jeśli funkcja getAdSelectionData jest inicjowana z nieprawidłowymi argumentami, AdServicesException wskazuje jako przyczynę IllegalArgumentException.
2. W przypadku pozostałych błędów wyświetlany jest komunikat AdServicesException z przyczyną IllegalStateException.

Kwestie dotyczące prywatności

Protokół adSelectionData jest szyfrowany, aby zapewnić, że dane w ruchu są dostępne tylko dla PPAPI i zaufanych serwerów.

Mimo szyfrowania może dojść do wycieku danych z powodu rozmiaru pliku adSelectionData. Rozmiar elementu adSelectionData może się różnić z tych powodów:

1. Na urządzeniu występują zmiany w danych CustomAudience.
2. Zmiany w logice filtrowania CustomAudience.
3. Zmieniono dane wejściowe w połączeniu z funkcją getAdSelectionData.

Zmiana rozmiaru adSelectionData może służyć do generowania identyfikatora pochodzącego z różnych aplikacji, jak wspomniano w 1-bitowej dyskusji na temat wycieku. Można tu też zastosować wiele środków łagodzących dla wycieku 1-bitowego kodu.

Aby radzić sobie z tymi wyciekami, planujemy generować tę samą wartość adSelectionData w przypadku wszystkich wywołań interfejsu getAdSelectionData API. W pierwszej wersji wszystkie CustomAudiences na urządzeniu są używane do tworzenia adSelectionData, a zaszyfrowany ładunek będzie dopełniany, aby maskować wahania rozmiaru. Ograniczymy też wpływ parametrów wejściowych GetAdSelectionData na generowane parametry adSelectionData.

Jednak wygenerowanie tego samego parametru adSelectionData dla wszystkich technologii reklamowych korzystających ze wszystkich danych z aukcji na urządzeniu powoduje utworzenie dużego ładunku, który trzeba teraz przekazywać w przypadku każdego wywołania serwera technologii reklamowych. Wykorzystywanie wszystkich niestandardowych list odbiorców na urządzeniu do generowania ładunku aukcji stwarza też ryzyko nadużyć ze strony złośliwych podmiotów. Omówiliśmy te wątpliwości w sekcjach Optymalizacje rozmiaru i Łagodzenie nadużyć poniżej.

Optymalizacje rozmiaru

Pakiet SDK klienta technologii reklam w pakiecie zaszyfrowanych bajtów pliku adSelectionData powinien umieścić w wywołaniu kontekstowym HTTP PUT/POST wysyłanym do serwera technologii reklamowych. Aby zminimalizować czas i koszty przesyłania w obie strony, należy jak najbardziej zmniejszyć rozmiar adSelectionData bez negatywnego wpływu na użyteczność.

W kolejnych wersjach planujemy zapoznać się z tymi optymalizacjami i wprowadzić ewentualne zmiany, dzięki którym zmniejszymy rozmiar adSelectionData:

1. Ładunek generowany w zasobniku o stałych rozmiarach z dopełnieniem: aby zminimalizować wyciek spowodowany zmiennością rozmiaru przy jednoczesnym zapewnieniu mniejszego ładunku, zalecamy użycie dla wygenerowanego ładunku zasobników o stałym rozmiarze. Mała liczba zasobników (na przykład 7) spowoduje, że w jednym wywołaniu funkcji getAdSelectionData pojawi się mniej niż 3 bity entropii wycieku.

   Jeśli dane na urządzeniu przekraczają maksymalny rozmiar zasobnika, do określania, które dane mają zostać pominięte, używane są strategie opisane poniżej, takie jak wartości priorytetu.

2. Konfiguracja kupującego: oceniamy możliwość umożliwienia kupującym skonfigurowania ładunku dla poszczególnych kupujących. Pomoże to określić, do których aukcji kupujący chce dołączyć. Jeśli to możliwe, podczas rejestracji technologia reklamowa kupująca może zarejestrować punkt końcowy, z którego usługa Protected Audience API będzie pobierać konfigurację ładunku codziennie i w regularnych odstępach czasu. Z kolei interfejsy API chroniące prywatność udostępniłyby interfejs API, który umożliwiłby technikom reklamowym kupujących zarejestrowanie tego punktu końcowego.

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

   Konfiguracja ładunku kupującego pozwoliłaby kupującym określić:

   1. Lista dopuszczonych sprzedawców: niestandardowe listy odbiorców kupującego zostaną dodane do ładunku tylko wtedy, gdy wywołanie getAdSelectionData zostanie zainicjowane przez sprzedawcę znajdującego się na liście dozwolonych. Konfigurację ładunku pobieraliśmy codziennie, aby lista dozwolonych była aktualna.
   2. Limit rozmiaru na sprzedawcę: kupujący może określić limit rozmiaru na sprzedawcę, aby określić rozmiar danych wysyłanych w ładunku, gdy określony sprzedawca zainicjuje aukcję. Takie rozwiązanie jest przydatne, gdy kupujący chce przeznaczyć więcej zasobów na przetwarzanie danych z aukcji pochodzących 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 na sprzedawcę kupujący może wyraźnie kontrolować ilość danych pozyskiwanych i przetwarzanych przez usługę BuyerFrontendService na serwerze określania stawek i serwera aukcji na potrzeby aukcji prowadzonych przez sprzedawcę.

3. Konfiguracja sprzedawcy: oceniamy możliwość utworzenia konfiguracji aukcji dla poszczególnych sprzedawców, która umożliwiłaby sprzedawcom definiowanie parametrów aukcji w celu kontrolowania ł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 funkcja Protected Audience może regularnie pobierać konfigurację aukcji dla poszczególnych sprzedawców. Ta konfiguracja zostanie następnie użyta do określenia składu i limitów funkcji adSelectionData generowanych dla każdego żądania getAdSelectionData.

   Podobnie jak w przypadku konfiguracji kupującego, konfiguracja dla poszczególnych sprzedawców umożliwia sprzedawcom określenie grupy kupujących, których spodziewają się wziąć udział w aukcji, oraz określenie limitów udziału poszczególnych kupujących w rozmiarze ładunku.

   Konfiguracja aukcji sprzedawcy pozwoliłaby określić:

   1. Dozwolona lista kupujących: w przypadku aukcji rozpoczętych przez danego sprzedawcę listy niestandardowych odbiorców na potrzeby aukcji będą mogli uwzględniać tylko kupujący z listy dozwolonych. Konfiguracja aukcji musi być codziennie aktualizowana w taki sposób, aby lista dozwolonych była aktualizowana o listę dozwolonych kupujących po stronie serwera.
   2. Limit rozmiaru na kupującego: sprzedawcy mogą określić limit na kupującego, aby określić 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 pobrania danych z uwzględnieniem oczekiwanych limitów zostanie użyty priorytet odbiorców niestandardowych określony w konfiguracji ładunku kupującego.
   3. Priorytet dla kupującego: pozwól sprzedawcom określać priorytet dla konkretnego kupującego. Priorytet kupującego będzie używany do określenia, które dane kupującego należy zachować w ładunku, jeśli rozmiar ładunku przekracza limit rozmiaru ładunku.
   4. Maksymalny limit rozmiaru ładunku: różni sprzedawcy mogą mieć różne przydziały zasobów i mogą chcieć ustawić maksymalny rozmiar ładunku aukcji na żądanie. Limit maksymalnego rozmiaru uwzględnia zasobniki o stałym rozmiarze ustawione przez Protected Audience API.

4. Zmiany dotyczące niestandardowych list odbiorców

   1. Określanie priorytetu niestandardowych list odbiorców: pozwala kupującym określać wartość priorytetu w sekcji niestandardowej listy odbiorców. Pole priority służy do wskazywania niestandardowych odbiorców, którzy powinni zostać uwzględnieni w aukcji, jeśli zestaw takich list odbiorców przekracza limity rozmiaru na sprzedawcę lub kupującego. Nieokreślona wartość priorytetu na liście odbiorców niestandardowych miałaby domyślną wartość 0.0.

5. Zmiany danych ładunku

   1. Ogranicz ilość danych wysyłanych w ładunku: zgodnie z opisem w sekcji Optymalizacja ładunku usług ustalania stawek i usług aukcji większy ładunek jest generowany na podstawie danych ads o odbiorcach niestandardowych, sygnałów określania stawek przez użytkowników i sygnałów z Androida. Większe ładunki mogą być obniżane przez:
      1. Klient powinien wysyłać w ładunku identyfikatory renderowania reklamy (zamiast obiektów reklam).
      2. Umożliwienie klientowi wysyłania danych reklam w ładunku.
      3. W ładunku klienta nie są wysyłane sygnały dotyczące określania stawek przez użytkownika.

Wymienione wyżej strategie umożliwiają technikom reklamowym definiowanie konfiguracji w celu zarządzania kompozycją i limitami ładunku adSelectionData, ale mogą one również wpływać na modyfikowanie rozmiaru elementu adSelectionData przez zmianę parametrów konfiguracji. Aby tego uniknąć, konfiguracja będzie codziennie pobierana ze skonfigurowanego punktu końcowego przez Protected Audience API.

Optymalizacja czasu oczekiwania

Aby aukcje serwerów miały pożądany poziom użyteczności, musimy zadbać o krótki czas oczekiwania na wywołanie interfejsu API getAdSelectionData i persistAdSelectionResult. Naszym celem jest udostępnienie obsługi funkcji interfejsów API w 2023 roku, ale kolejna wersja będzie skupiać się na testach porównawczych i optymalizacji czasu oczekiwania w przypadku interfejsów API.

Sprawdzamy poniższe strategie, aby utrzymać akceptowalne limity czasu oczekiwania:

1. Wstępne generowanie danych w ramach Protected Audience API według sprzedawcy: konfiguracja aukcji sprzedawcy i konfiguracja ładunku kupującego będą stabilne przez znaczny czas (codziennie), dlatego platforma może wstępnie obliczyć i przechowywać odpowiednie dane w ramach Protected Audience API.

   Platforma musi więc utworzyć mechanizm monitorowania aktualizacji niestandardowych list odbiorców i modyfikowania wstępnie wygenerowanych danych Protected Audience API na podstawie tych zmian. Platforma musiała też zadeklarować docelowe poziomy usług w przypadku technologii reklam z opóźnieniem w czasie wyścigu między aktualizacjami niestandardowych list odbiorców a zauważeniem zmiany wartości adSelectionData wygenerowanej dla aukcji serwera.

   Urządzenie ma model obliczeniowy o ograniczonej liczbie zasobów i z różnymi priorytetami procesu, dlatego zdajemy sobie sprawę, że udostępnienie takiej usługi wstępnej generowania musi zapewniać wysoką niezawodność i gwarancję docelowego poziomu usług.

   Wstępne generowanie danych w ramach Protected Audience API byłoby wtedy oparte na

   1. Zgoda sprzedawcy na wstępne generowanie danych w ramach Protected Audience API.
   2. Kupujący, którzy mogą brać udział w aukcji zainicjowanej przez konkretnego sprzedawcę.
   3. Określenie niestandardowych odbiorców na kupującego, którzy będą częścią ładunku, na podstawie:
      1. limity rozmiarów na kupującego, priorytety na kupującego i limity rozmiarów maksymalnych określone w konfiguracji sprzedawcy,
      2. Limit rozmiaru poszczególnych sprzedawców i niestandardowy priorytet odbiorców określony w konfiguracji kupującego.

2. Prawdziwe zastosowanie filtrowania wykluczającego: jeśli sprzedawca na to zezwolił, platforma może wstępnie obliczyć adSelectionData, wstępnie generując dane w ramach Protected Audience API i stosując filtrowanie ujemne w przypadku krytycznego wywołania funkcji getAdSelectionData. Dzięki temu sprzedawcy będą mogli zrównoważyć skrócenie czasu oczekiwania przy akceptowaniu nieaktualności w filtrach negatywnych.

   Platforma może zapewnić tę pomoc przez udostępnienie w konfiguracji sprzedawcy opcji domyślnej z limitem braku aktualizacji danych i opcją zastąpienia w getAdSelectionData, aby w razie potrzeby umożliwić najświeższe obliczenia. Platforma może też udostępniać dodatkowy interfejs API inicjowania, który zostanie wywołany przed getAdSelectionData w celu przygotowania aukcji.

3. Obliczanie ładunku na potrzeby wielu aukcji: w niektórych sytuacjach korzystne może być skorzystanie z interfejsu API odpornego na czas oczekiwania, bo wiąże się to z większą brakiem aktualizacji danych. Aby to udostępnić, platforma może wprowadzić interfejs API inicjowania, aby obliczyć cały ładunek, i podać do elementu wywołującego odwołanie do obliczonego ładunku.

   W przypadku kolejnych wywołań funkcji getAdSelectionData element wywołujący może podać odniesienie do wstępnie obliczonego ładunku na potrzeby generowania adSelectionData.

Wszystkie 3 opisane wyżej strategie znajdują się na początkowym etapie eksploracji i mają na celu opisanie kierunku, w jakim platforma może działać w celu optymalizacji pod kątem czasu oczekiwania. W miarę pogłębiania szczegółowych profili czasu oczekiwania związanych z interfejsem API i wymagań dotyczących technologii reklamowych będziemy proponować kolejne strategie.

Wykrywanie nadużyć i łagodzenie ich

Jak wspomnieliśmy w sekcji dotyczącej prywatności, wartość adSelectionData jest generowana z wykorzystaniem wszystkich danych kupującego na urządzeniu.

Jeśli jednak wszystkie dane o kupujących na urządzeniu są używane do generowania wyników typu adSelectionData, złośliwy podmiot może udawać kupującego i generować fałszywe dane o kupujących w celu pogorszenia skuteczności Androida, nadmiarowy ładunek, aby zwiększyć koszty technologii reklamowej do prowadzenia aukcji lub ustalania stawek itd.

Łagodzenie

Niektóre środki wymienione w sekcji dotyczącej rozmiaru, takie jak konfiguracja ładunku kupującego, która zawiera sprzedawców z listy dozwolonych lub konfiguracja aukcji sprzedawców z kupującymi z listy dozwolonych, mogą pomóc wykluczyć z ładunku nieoczekiwane dane.

Inne rozwiązania zwiększające zainteresowanie zakupem, takie jak umożliwienie platformom SSP określania priorytetu kupujących, umieszczenie limitu na kupującego w wygenerowanym ładunku czy ustawienie maksymalnego rozmiaru na ładunek aukcji, również mogą pomóc złagodzić skutki wynikające ze wzrostu ładunku złośliwego oprogramowania. Dzięki temu technologie reklamowe mogą decydować, z którymi technologiami reklamowymi współpracują, a także ustalać akceptowalne limity dotyczące ładunku, które będą musieli przetwarzać.

Jak już wspomnieliśmy, wszystkie środki łagodzące związane z nadużyciami oraz ograniczenia rozmiaru i nadużycia muszą być zgodne z kwestiami dotyczącymi prywatności.

Identyfikacja złośliwych elementów

Wymienione powyżej środki zaradcze chronią generowanie adSelectionData na potrzeby aukcji serwera, ale nie pomagają zidentyfikować złośliwych elementów ani chronić platformy przed nadużyciami, takimi jak utworzenie niespotykanej liczby niestandardowych list odbiorców od kupującego.

Aby zapewnić stabilność i prawidłowe działanie platformy, musimy znaleźć mechanizm identyfikacji szkodliwych podmiotów, identyfikacji wektorów nadużyć i umotywowania konkretnych ataków. W kolejnych wersjach wprowadzimy wyjaśnienia ze szczegółowymi informacjami o potencjalnych nadużyciach i zabezpieczeniach, które mają na celu zwalczanie tych zagrożeń.