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

Propozycja projektu Określanie stawek i usługi aukcyjne na Androida szczegółowo opisuje przeprowadzanie i przepływ danych w aukcjach prowadzonych na Androidzie z wykorzystaniem serwera aukcji i określania stawek. Aby zapewnić, że przesyłane dane są obsługiwane wyłącznie przez chroniące prywatność interfejsy API i zaufane serwery, dane są szyfrowane między klientem a serwerem przy użyciu dwukierunkowego hybrydowego szyfrowania klucza publicznego.

Aby przeprowadzić aukcję zgodnie z wcześniejszym opisem, sprzedawca na urządzeniu musi wykonać te czynności:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze
2. Wyślij prośbę do usługi niezaufanego sprzedawcy
3. Otrzymywanie odpowiedzi z usługi niezaufanego sprzedawcy
4. Odszyfrowanie odpowiedzi aukcji z Protected Audience API i uzyskanie wyniku aukcji

Protected Audience API wprowadza 2 nowe interfejsy API, aby wspierać przeprowadzanie aukcji serwerów:

1. Interfejs API getAdSelectionData zbiera dane z aukcji na serwerze i generuje zaszyfrowany ładunek z danymi aukcji. Serwer aukcji i ustalania stawek wykorzystuje ten ładunek do przeprowadzania aukcji, generowania wyniku aukcji i zwracania wyniku aukcji.
2. Klienci technologii reklamowych na urządzeniu mogą wywoływać interfejs API persistAdSelectionResult, aby odszyfrować wynik wygenerowany przez aukcję na serwerze i uzyskać zwycięski adres URL renderowania reklamy.

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

1. Gromadzenie i szyfrowanie danych na potrzeby aukcji z serwera dla sprzedawców: technika reklamowa powinna wywołać interfejs API getAdSelectionData, aby uzyskać zaszyfrowany ładunek.
2. Wyślij żądanie do niezaufanej usługi sprzedawcy: żądanie HTTP POST lub PUT zawierające zaszyfrowany ładunek wygenerowany przez interfejs getAdSelectionData API do jego niezaufanej usługi sprzedawcy oraz dane wymagane przez niezaufaną usługę sprzedawcy do wygenerowania wyników kontekstowych.
3. Odebranie odpowiedzi z usługi niezaufanego sprzedawcy: odpowiedź z usługi niezaufanej usługi sprzedawcy będzie zawierać zaszyfrowany wynik aukcji z Protected Audience API i kontekstowy wynik aukcji.
4. Odszyfrowanie odpowiedzi na aukcji z Protected Audience API i uzyskanie wyniku aukcji: aby odszyfrować wynik aukcji z Protected Audience API, 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 z Protected Audience API. W razie potrzeby także identyfikator URI zwycięskiej reklamy z Protected Audience API.

Funkcje obsługiwane w przypadku aukcji na serwerze

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

	Aukcja na urządzeniu		Aukcja serwerów
	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. 2024 r.
Filtrowanie limitów 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
Dołącz do przekazywania dostępu do niestandardowych odbiorców	III kw. 2023 roku	IV kw. 2023 roku	Nie dotyczy	IV kw. 2023 roku
Płatności bez CPM	III kw. 2023 roku	IV kw. 2023 roku
Raporty debugowania	III kw. 2023 roku	IV kw. 2023 roku	III kw. 2023 roku	IV kw. 2023 roku
Zapośredniczenie z Otwartym ustalaniem 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 serwerów przy użyciu interfejsów Protected Audience API

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

Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze

Interfejs getAdSelectionData API generuje wymagane dane wejściowe dla komponentów określania stawek i aukcji, np. BuyerInput i ProtectedAudienceInput, a potem szyfruje dane, zanim udostępni wynik elementowi wywołującemu. Aby zapobiec wyciekowi danych między aplikacjami, zawieramy informacje od wszystkich kupujących korzystających z urządzenia. Więcej informacji o tej decyzji znajdziesz w sekcji Uwagi na temat prywatności. Informacje o strategiach optymalizacji znajdziesz w sekcji Uwagi na temat rozmiaru.

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

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

GetAdSelectionDataRequest

1. Element wywołujący musi ustawić w żądaniu pole seller, ponieważ służy ono do uruchamiania testów rejestracji przed obsługą żądania.
2. Pole coordinatorOriginUri jest opcjonalne.
   1. Jeśli jest ustawiony, powinien odpowiadać 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	Źródło identyfikatora URI	Domyślne
      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 podano punktu początkowego koordynatora, używany jest domyślny koordynator.
   4. Mimo że jest mało prawdopodobne, aby adres URL koordynatora ulegnie zmianie, zdecydowanie zalecamy wdrożenie mechanizmu dynamicznego zarządzania tym adresem URL. Dzięki temu możliwe będzie wprowadzenie w przyszłości zmian w tym adresie URL bez konieczności tworzenia nowej wersji pakietu SDK.

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

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

GetAdSelectionDataOutcome

W wyniku użycia interfejsu API getAdSelectionData generowany jest identyfikator GetAdSelectionDataOutcome. Zawiera ona następujące elementy:

1. adSelectionId: nieprzejrzysta liczba całkowita identyfikująca to wywołanie funkcji getAdSelectionData. Klient AdTech powinien zachować tę wartość adSelectionId, ponieważ jest ona wskaźnikiem do wywołania getAdSelectionData. Ten identyfikator jest wymagany przez interfejs API persistAdSelectionResult do odszyfrowywania wyniku aukcji z serwera ustalania stawek i aukcji. Jest też wymagany przez interfejsy API reportImpression i reportEvent.
2. adSelectionData: to zaszyfrowane dane aukcji, które są potrzebne serwerowi ustalania stawek i serwerowi aukcji do prowadzenia aukcji. Ta metoda obejmuje:
   1. Dane dotyczące niestandardowych odbiorców są przefiltrowane na podstawie ograniczenia liczby wyświetleń, filtrów instalacji aplikacji i wymagań aukcji na serwerze w przypadku niestandardowych odbiorców.
   2. W przyszłej wersji będzie zawierać dane o instalacjach aplikacji.

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

Obsługa błędów, wyjątków i błędów

Jeśli z powodów takich jak nieprawidłowe argumenty, przekroczenie czasu oczekiwania lub nadmierne zużycie zasobów nie można dokończyć generowania danych o wyborze reklamy, wywołanie zwrotne OutcomeReceiver.onError() wywoła AdServicesException z takim zachowaniem:

1. Jeśli funkcja getAdSelectionData została zainicjowana z nieprawidłowymi argumentami, AdServicesException wskazuje jako przyczynę błędu IllegalArgumentException.
2. Wszystkie pozostałe błędy otrzymują komunikat AdServicesException z określonym IllegalStateException jako przyczyną.

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

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

Otrzymanie odpowiedzi z usługi niezaufanej usługi sprzedawcy

Zgodnie z opisem w objaśnieniu dotyczącym określania stawek i serwera aukcji, gdy usługa niezaufanego sprzedawcy otrzymuje żądanie, wywołuje kupujących partnerów w celu wyświetlenia reklam kontekstowych.

Usługa niezaufanego sprzedawcy przekazuje zaszyfrowane identyfikatory adSelectionData i AuctionConfig do usługi SellerFrontEnd na serwerze aukcji i środowiska TEE.

Po zakończeniu aukcji z Protected Audience API usługa SellerFrontEnd szyfruje wynik aukcji i zwraca go w odpowiedzi do niezaufanej usługi sprzedawcy.

Usługa niezaufanego sprzedawcy wysyła odpowiedź do urządzenia z reklamą kontekstową lub zaszyfrowanym wynikiem aukcji z użyciem Protected Audience API.

Po otrzymaniu odpowiedzi kod technologii reklamy sprzedawcy na urządzeniu może użyć w odpowiedzi tylko reklamy kontekstowej. Jeśli uzna, że wynik z Protected Audience API zwiększy wartość tego wyniku, może odszyfrować go, wywołując interfejs API PersistAdSelectionResult.

Interfejs API PersistAdSelectionResult API

Aby odszyfrować wynik w ramach Protected Audience API, technologia reklamowa sprzedawcy może wywołać drugi interfejs Protected Audience API (persistAdSelectionResult). Interfejs API odszyfrowuje wynik i zwraca AdSelectionOutcome, czyli ten sam obiekt, który jest dziś 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 zdefiniować uprawnienie ACCESS_ADSERVICES_CUSTOM_AUDIENCE w pliku manifestu.

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

PersistAdSelectionResultRequest

Wywołujący musi w żądaniu ustawić te elementy:

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ć.
2. seller: w żądaniu musi być ustawiony identyfikator technologii reklamowej sprzedawcy, aby można było przeprowadzić weryfikację rejestracji przed jego obsługą.
3. adSelectionResult: zaszyfrowany wynik aukcji wygenerowany przez serwer ustalania stawek i aukcji, który element wywołujący chce odszyfrować.

Reakcja wyniku wyboru reklamy

W przypadku zwycięzcy w ramach Protected Audience API funkcja AdSelectionOutcome zwraca identyfikator URI zwycięskiego renderowania reklamy.Po odszyfrowaniu identyfikatora adSelectionResult dane raportowania są zachowywane wewnętrznie. Wywołanie zwrotne OutcomeReceiver.onResult() zwraca wartość AdSelectionOutcome, która zawiera:

• URI: w przypadku zwycięskiej reklamy z Protected Audience API zwracany jest adres URL wyrenderowanej reklamy zwycięskiej. Jeśli nie ma zwycięskiej grupy z Protected Audience API, zwracany jest komunikat „Uri.EMPTY”.
• adSelectionId: pole adSelectionId powiązane z tym uruchomieniem aukcji na serwerze.

Obsługa błędów, wyjątków i błędów

Jeśli z powodów takich jak nieprawidłowe argumenty, przekroczenie czasu oczekiwania lub nadmierne zużycie zasobów nie można dokończyć generowania danych o wyborze reklamy, wywołanie zwrotne OutcomeReceiver.onError() wywoła AdServicesException z takim zachowaniem:

1. Jeśli funkcja getAdSelectionData została zainicjowana z użyciem nieprawidłowych argumentów, AdServicesException wskazuje IllegalArgumentException jako przyczynę.
2. Wszystkie pozostałe błędy otrzymują komunikat AdServicesException z określonym IllegalStateException jako przyczyną.

Kwestie dotyczące prywatności

Plik adSelectionData jest zaszyfrowany, aby zapewnić, że przesyłane dane są dostępne tylko dla PPAPI i zaufanych serwerów.

Mimo szyfrowania dane mogą wyciec z powodu rozmiaru adSelectionData. Rozmiar adSelectionData może się różnić z tych powodów:

1. Na urządzeniu są zmiany w danych CustomAudience.
2. Zmiany w logice filtrowania funkcji CustomAudience.
3. Zmieniono metodę wprowadzania na wywołanie getAdSelectionData.

Zmiana rozmiaru adSelectionData może być używana do generowania identyfikatora w różnych aplikacjach, jak wspomniano w omawianiu o wycieku danych w różnych aplikacjach. Ma to również zastosowanie w przypadku wycieku 1-bitowego.

Aby zarządzać tymi wyciekami, planujemy wygenerować ten sam adSelectionData dla wszystkich wywołań interfejsu getAdSelectionData API. W początkowych wersjach do tworzenia adSelectionData służą wszystkie CustomAudiences na urządzeniu, a zaszyfrowany ładunek zostanie uzupełniony o wersje rozmiaru maski. Ograniczymy też wpływ parametrów wejściowych GetAdSelectionData na wygenerowany element adSelectionData.

Wygenerowanie tego samego elementu adSelectionData jednak dla wszystkich technologii reklamowych korzystających ze wszystkich danych z aukcji na urządzeniu tworzy jednak duży ładunek, który trzeba teraz przekazywać przy każdym wywołaniu do serwera technologii reklamowych. Wykorzystanie wszystkich niestandardowych list odbiorców na urządzeniu do generowania ładunku aukcji otwiera też ekosystem na nadużycia ze strony szkodliwych podmiotów. Omówiliśmy te wątpliwości w sekcjach Optymalizacja rozmiaru i Eliminowanie nadużyć poniżej.

Optymalizacje rozmiaru

Pakiet SDK klienta technologii reklamowych powinien spakować zaszyfrowane bajty instancji adSelectionData w kontekstowe wywołanie HTTP PUT/POST wysyłane do serwera technologii reklamowych. Aby zmniejszyć czas oczekiwania i koszty przesyłania w obie strony, należy maksymalnie ograniczyć rozmiar adSelectionData, jednocześnie nie wpływając na użyteczność.

W nadchodzących wersjach planujemy przeanalizować i ewentualnie wprowadzić te optymalizacje, które pozwolą zmniejszyć rozmiar pliku adSelectionData:

1. Ładunek wygenerowany w stałym zestawie rozmiarów zasobników z dopełnieniem: aby zminimalizować wyciek ze zmian rozmiaru, a jednocześnie uwzględnić mniejsze ładunki, zalecamy stosowanie grupowania wygenerowanego ładunku w stałym rozmiarze. Jeśli na przykład liczba zasobników jest niewielka, liczba zasobników wynosi 7, co spowoduje mniej niż 3 bity ujawnionej entropii na wywołanie funkcji getAdSelectionData.

   Jeśli dane na urządzeniu przekraczają maksymalny rozmiar zasobnika, do określenia, które dane zostaną usunięte, zostaną użyte strategie wymienione poniżej (np. wartości priorytetu).

2. Konfiguracja kupującego: oceniamy możliwość umożliwienia kupującym skonfigurowania ładunku dla poszczególnych kupujących. Taka konfiguracja pomaga określić, w których aukcjach kupujący chce wziąć udział. Jeśli to możliwe, podczas rejestracji kupujący korzystający z technologii reklamowej mógł zarejestrować punkt końcowy, z którego Protected Audience będzie pobierać konfigurację ładunku w regularnych odstępach czasu. Interfejsy API chroniące prywatność mogą też udostępnić interfejs API, aby umożliwić kupującym zarejestrowanie tego punktu końcowego.

   Ta konfiguracja będzie następnie używana do oceny wkładu kupującego na rzecz adSelectionData wygenerowanego dla każdego żądania getAdSelectionData.

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

   1. Lista dozwolonych sprzedawców: niestandardowe listy odbiorców kupujących będą dodawane do ładunku tylko wtedy, gdy wywołanie getAdSelectionData zostanie zainicjowane przez sprzedawcę z listy 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 przesyłanych w ładunku, gdy aukcja została zainicjowana przez określonego sprzedawcę. Przydaje się to, gdy kupujący chce poświęcić więcej zasobów na przetwarzanie danych z aukcji 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 bezpośrednio kontrolować ilość danych pozyskanych i przetwarzanych przez usługę BuyerFrontendService na potrzeby aukcji prowadzonych przez sprzedawcę na potrzeby aukcji i określania stawek.

3. Konfiguracja sprzedawcy: oceniamy wykonalność konfiguracji aukcji dla konkretnego sprzedawcy, która umożliwiłaby sprzedawcom definiowanie parametrów aukcji w celu kontrolowania rozmiaru ładunku i uczestników aukcji. Jeśli to możliwe, podczas rejestracji sprzedawca technologii reklamowych będzie mógł określić punkt końcowy, z którego Protected Audience będzie pobierać konfigurację aukcji dla danego sprzedawcy w regularnym cyklu. Ta konfiguracja będzie następnie używana do określenia kompozycji i limitów zasobu adSelectionData wygenerowanego dla każdego żądania getAdSelectionData.

   Podobnie jak w przypadku konfiguracji kupującego, konfiguracja na sprzedawcę pozwala sprzedawcom określić, jakiego zbioru kupujących mogą się spodziewać na aukcji, a także na określenie limitów wielkości ładunku przypadających na kupującego.

   Konfiguracja aukcji sprzedawcy umożliwia sprzedawcom określenie:

   1. Lista dozwolonych kupujących: w przypadku aukcji zainicjowanych przez danego sprzedawcę tylko kupujący z listy dozwolonych mogą dodawać do aukcji niestandardowych odbiorców. Konfiguracja aukcji musi być aktualizowana codziennie, aby lista dozwolonych była aktualizowana codziennie o listy dozwolonych kupujących po stronie serwera.
   2. Limit rozmiaru na kupującego: sprzedawcy mogą określić limit na kupującego, aby kontrolować rozmiar danych przesyłanych przez każdego kupującego do ładunku wysyłanego do SellerFrontendService. Jeśli kupujący przekroczy limit rozmiaru na kupującego, do pobrania danych w oczekiwanych limitach zostanie wykorzystany priorytet niestandardowych odbiorców ustawiony w konfiguracji ładunku kupującego.
   3. Priorytet na kupującego: zezwalaj sprzedawcom na ustawianie priorytetu dla poszczególnych kupujących. Priorytet kupującego określa, które dane kupującego powinny zostać zachowane w ładunku, jeśli rozmiar ładunku przekracza limit rozmiaru ładunku.
   4. Maksymalny limit rozmiaru ładunku: poszczególni sprzedawcy mogą mieć różne przydziały zasobów i mogą ustawić maksymalny rozmiar ładunku aukcji na żądanie. Limit maksymalnego rozmiaru uwzględnia zasobniki o stałym rozmiarze ustawione przez interfejs Protected Audience API.

4. Zmiany związane z listami niestandardowych odbiorców

   1. Określanie priorytetu niestandardowych odbiorców: zezwalaj kupującym na określenie wartości priorytetu na liście niestandardowych odbiorców. Pole priority służy do identyfikowania niestandardowych odbiorców, którzy powinni być uwzględnieni w aukcji, jeśli zestaw niestandardowych odbiorców kupującego przekracza limity rozmiaru na sprzedawcę lub kupującego. Nieokreślona wartość priorytetu w przypadku listy niestandardowych odbiorców miałaby domyślnie wartość 0.0.

5. Zmiany danych ładunku

   1. Ogranicz ilość danych wysyłanych w ładunku: zgodnie z informacjami w sekcji Optymalizacja ładunku usług określania stawek i usług aukcyjnych większy ładunek jest generowany na podstawie danych niestandardowych ads odbiorców, sygnałów określania stawek przez użytkownika oraz sygnałów Androida. Większe ładunki mogą zostać obniżone przez:
      1. Klient wysyła identyfikatory renderowania reklam (zamiast obiektów reklam) w ładunku.
      2. Klient nie wysyła żadnych danych reklam w ładunku.
      3. Sygnały dotyczące określania stawek przez użytkownika nie są wysyłane w ładunku klienta.

Wymienione powyżej strategie pozwalają technikom reklamowym definiować konfiguracje w celu zarządzania kompozycją i limitami ładunków adSelectionData, ale mogą też stać się czynnikiem wpływającym na modulowanie rozmiaru elementu adSelectionData przez zmianę parametrów konfiguracji. Aby tego uniknąć, konfiguracja będzie codziennie pobierana przez Protected Audience API ze skonfigurowanego punktu końcowego.

Optymalizacja czasu oczekiwania

Aby aukcje serwerów miały odpowiedni poziom przydatności, musimy dopilnować, aby interfejsy getAdSelectionData API i persistAdSelectionResult API miały małe opóźnienie na wywołanie. Zamierzamy zapewnić obsługę tych funkcji w 2023 r., jednak w kolejnej wersji skupimy się na analizach porównawczych czasu oczekiwania i optymalizacji tych interfejsów.

Opracowujemy następujące strategie, aby zmieścić się w akceptowalnych limitach:

1. Przed generowaniem danych z Protected Audience API dla poszczególnych sprzedawców: konfiguracja aukcji sprzedawcy i ładunku kupującego są stabilne przez dłuższy czas (codzienny), dlatego platforma może wstępnie obliczać i przechowywać odpowiednie dane z Protected Audience API.

   Wymaga to utworzenia mechanizmu do monitorowania niestandardowych aktualizacji list odbiorców i modyfikowania wstępnie wygenerowanych danych z Protected Audience API na podstawie tych aktualizacji. Platforma musi także zadeklarować docelowe poziomy usług dla technologii reklamowych z opóźnieniem wyścigu, kiedy nastąpi aktualizacja niestandardowych list odbiorców, a zmiana wartości adSelectionData wygenerowana dla aukcji serwera.

   Urządzenie ma ograniczony model obliczeń zasobów o różnych priorytetach procesów, dlatego zdajemy sobie sprawę, że ta jednostka przedgeneracyjna musi mieć wysoką niezawodność i gwarancje docelowego poziomu usług.

   Dane z Protected Audience API zostałyby wygenerowane wstępnie na podstawie

   1. Akceptacja przez sprzedawcę wstępnego generowania danych z Protected Audience API.
   2. Kupujący kwalifikujący się do udziału w aukcji zainicjowanej przez konkretnego sprzedawcę.
   3. Określanie niestandardowych grup odbiorców w przypadku poszczególnych kupujących, którzy będą częścią ładunku, na podstawie:
      1. Limity wielkości i priorytetu na kupującego, określone w konfiguracji sprzedawcy,
      2. Limit wielkości dla poszczególnych sprzedawców, niestandardowy priorytet odbiorców zdefiniowany w konfiguracji kupującego.

2. Pewne zastosowanie filtrowania negatywnych: jeśli sprzedawca preferuje ten sposób, platforma może wstępnie obliczyć wartość adSelectionData, włączając wstępne generowanie danych z Protected Audience API i filtrowanie negatywnego wpływu na kluczowe wywołanie getAdSelectionData. Dzięki temu sprzedawcy mogą zrównoważyć skrócenie czasu oczekiwania z zachowaniem nieaktualności w filtrowaniu ujemnym.

   Platforma może to ułatwić, ustawiając w konfiguracji sprzedawcy domyślną opcję z limitem braku aktualizacji i opcją zastąpienia w getAdSelectionData, aby w razie potrzeby umożliwić najnowsze obliczenia. Platforma mogłaby też udostępnić dodatkowy interfejs API inicjowania, który należy wywołać przed getAdSelectionData w celu rozgrzewki aukcji.

3. Obliczanie ładunku na potrzeby wielu aukcji: w niektórych sytuacjach korzystne może być użycie interfejsu API zapewniającego czas oczekiwania kosztem zwiększonej nieaktualności danych. W tym celu platforma może wprowadzić interfejs API inicjowania, który oblicza cały ładunek i udostępnia wywołującemu odniesienie do obliczonego ładunku.

   W przypadku kolejnych wywołań funkcji getAdSelectionData element wywołujący może podać odwołanie do wstępnie obliczonego ładunku, który ma zostać użyty do wygenerowania adSelectionData.

Wszystkie 3 wspomniane powyżej strategie są na początkowym etapie odkrywania i mają opisywać kierunek, w jakim platforma może być optymalizowana pod kątem czasu oczekiwania. W miarę poznawania bardziej szczegółowych profili czasu oczekiwania związanych z interfejsami API i wymaganiami dotyczącymi technologii reklamowych będziemy nadal proponować dodatkowe strategie.

Łagodzenie skutków nadużyć i rozpoznawanie ich

Jak wspomnieliśmy w sekcji „Uwagi na temat prywatności”, wartość adSelectionData jest generowana na podstawie wszystkich danych kupującego na urządzeniu.

Jeśli jednak do wygenerowania danych wyjściowych adSelectionData używane są wszystkie dane kupującego na urządzeniu, złośliwy podmiot może podszywać się pod kupującego i tworzyć fałszywe dane o kupującym, aby pogorszyć wydajność Androida, zwiększyć ładunek w celu zwiększenia kosztów technologii reklamowej na potrzeby przeprowadzania aukcji lub licytacji itd.

Łagodzenie

Niektóre środki wymienione w sekcji kwestii dotyczących rozmiaru, np. konfiguracja ładunku kupującego obejmującego sprzedawców z listy dozwolonych i konfiguracja aukcji sprzedawcy z uwzględnieniem kupujących z listy dozwolonych, pomagają wykluczyć nieoczekiwane dane w ładunku.

Inne wskaźniki, które określają rozmiar ładunku, takie jak umożliwienie platformom SSP określania priorytetu kupującego, umieszczanie w wygenerowanym ładunku limitu dla poszczególnych kupujących i ustawianie maksymalnego rozmiaru ładunku na aukcji, również mogą ograniczyć wpływ nadmiernego ładunku złośliwego oprogramowania. Te działania mają umożliwić technikom reklamowym określenie, z jaką technologią będą współpracować, i ustalenie dopuszczalnych limitów ładunku, które muszą przetworzyć.

Jak już wspomnieliśmy, wszystkie środki łagodzące związane z przeciwdziałaniem nadużyciom i ograniczeniom rozmiaru muszą być zgodne z zasadami ochrony prywatności.

Identyfikacja złośliwych elementów

Wymienione powyżej środki zaradcze chronią generację adSelectionData na potrzeby aukcji serwerów, ale nie pomagają identyfikować złośliwych podmiotów ani chronić platformy przed nadużyciami, takimi jak niespotykana dotąd liczba niestandardowych list odbiorców na stronie kupującego.

Aby zapewnić stabilność i poprawność platformy, musimy znaleźć mechanizm umożliwiający identyfikowanie złośliwych podmiotów, identyfikowanie wektorów nadużyć i określanie motywacji do konkretnych ataków. W kolejnych wersjach wprowadzimy wyjaśnienia, szczegółowo omawiamy potencjalne wektory nadużyć i zabezpieczenia chroniące przed nimi.