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

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

W propozycji projektu usług określania stawek i usług aukcyjnych na Androida opisano szczegóły wykonywania aukcji na Androidzie za pomocą serwera Trusted Bidding and Auction. Aby zapewnić, że dane w trakcie przesyłania są obsługiwane tylko przez interfejsy API chroniące prywatność i zaufane serwery, są one szyfrowane między klientem a serwerem za pomocą dwukierunkowego szyfrowania hybrydowego kluczem publicznym.

Aby przeprowadzić aukcję zgodnie z opisem powyżej, technologia reklamowa sprzedawcy na urządzeniu musi wykonać te czynności:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji serwera
2. Wysyłanie prośby do usługi dotyczącej nieuczciwego sprzedawcy
3. Odbieranie odpowiedzi od nieuczciwego sprzedawcy
4. Odszyfrowanie odpowiedzi z aukcji Protected Audience i uzyskanie wyniku aukcji

Aby obsługiwać aukcji na serwerze, Protected Audience wprowadza 2 nowe interfejsy API:

1. Interfejs getAdSelectionData API zbiera dane do 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 tego wyniku.
2. Klienci technologii reklamowych działające na urządzeniu mogą wywołać interfejs API persistAdSelectionResult, aby odszyfrować wynik wygenerowany przez aukcję serwera i uzyskać adres URL renderowania reklamy, która wygrała aukcję.

Aby prowadzić aukcję, sprzedawca musi zintegrować technologię reklamową na urządzeniu z tymi elementami:

1. Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze dla sprzedawcy: usługa adtech powinna wywołać interfejs API getAdSelectionData, aby uzyskać zaszyfrowany ładunek danych.
2. Wyślij prośbę do niesprawdzonego sprzedawcy: HTTP POST lub PUT zawierające zaszyfrowany ładunek wygenerowany przez interfejs API getAdSelectionData do niesprawdzonego sprzedawcy oraz dane wymagane przez niesprawdzonego sprzedawcę do wygenerowania wyników kontekstowych.
3. Otrzymanie odpowiedzi od niesprawdzonego sprzedawcy: odpowiedź od niesprawdzonego sprzedawcy będzie zawierać zaszyfrowany wynik aukcji z użyciem Protected Audience API oraz wynik aukcji kontekstowej.
4. Odszyfrowanie odpowiedzi z aukcji w ramach chronionych danych odbiorców i uzyskanie wyniku aukcji: aby odszyfrować wynik aukcji w ramach chronionych danych odbiorców, sprzedawca powinien wywołać interfejs API persistAdSelectionResult. Wynik z persistAdSelectionResult pomoże specjalistom ds. technologii reklamowych określić, czy wygrała aukcja reklamy kontekstowej czy reklamy dla chronionych odbiorców, a także (w odpowiednich przypadkach) URI zwycięskiej reklamy dla chronionych odbiorców.

Funkcje obsługiwane w ramach aukcji na serwerze

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

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

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

Zbieranie i szyfrowanie danych na potrzeby aukcji serwera

Interfejs API getAdSelectionData generuje dane wejściowe wymagane do określania stawek i komponentów aukcji, takie jak BuyerInput i ProtectedAudienceInput, a także szyfruje dane przed udostępnieniem wyników wywołującemu. Aby zapobiec wyciekowi danych między aplikacjami, te dane zawierają informacje o wszystkich kupujących na urządzeniu. Więcej informacji o tym, dlaczego podjęliśmy tę decyzję, znajdziesz w sekcji Uwzględnianie prywatności, a strategię optymalizacji znajdziesz w sekcji Uwzględnianie rozmiaru.

Aby uzyskać dostęp do interfejsu API, musisz włączyć Protected Audience API i zdefiniować w pliku manifestu wywołującego 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ć w żądaniu pole seller, ponieważ jest ono używane do sprawdzania rejestracji przed obsłużeniem żądania.
2. Pole coordinatorOriginUri jest opcjonalne.
   1. Jeśli jest ustawiona, powinna być równa schematowi, nazwie hosta i porcie adresu URL koordynatora skonfigurowanego podczas wdrażania serwera B&A sprzedawcy.
   2. Koordynator musi być na liście zatwierdzonych koordynatorów:

      Dostawca	Identyfikator URI	Źródło identyfikatora URI	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 podano źródła koordynatora, używany jest koordynator domyślny.
   4. Mimo że zmiana adresu URL koordynatora jest mało prawdopodobna, zdecydowanie zalecamy wdrożenie mechanizmu dynamicznego zarządzania tym adresem. Dzięki temu można wprowadzić przyszłe zmiany w adresie URL 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 elementy BuyerInput i ProtectedAudienceInput. Następnie końcowy obiekt danych jest szyfrowany za pomocą dwukierunkowego hybrydowego szyfrowania kluczem publicznym.

GetAdSelectionDataOutcome

Wartość GetAdSelectionDataOutcome jest generowana na podstawie interfejsu API getAdSelectionData. Zawiera on:

1. adSelectionId: nieprzejrzysty typ całkowity służący do identyfikacji wywołania funkcji getAdSelectionData. Klient adtech powinien zachować tę wartość adSelectionId, ponieważ działa ona jako wskaźnik do wywołania getAdSelectionData. Ten identyfikator jest wymagany przez interfejs API persistAdSelectionResult do odszyfrowywania wyników aukcji z serwera licytowania i aukcji. Jest on również wymagany przez interfejsy API reportImpression i reportEvent.
2. adSelectionData: są to zaszyfrowane dane aukcji, które są wymagane przez serwer Bidding and Auction do przeprowadzania aukcji. Ta metoda obejmuje:
   1. Odfiltrowane dane niestandardowych list odbiorców na podstawie ograniczania liczby wyświetleń, filtrów instalacji aplikacji i wymagań aukcji serwera 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 błędów

Jeśli nie można utworzyć danych doboru reklamy z takich powodów jak nieprawidłowe argumenty, przekroczenie limitu czasu lub nadmierne wykorzystanie zasobów, wywołanie zwrotne OutcomeReceiver.onError() przekazuje AdServicesException z tymi zachowaniami:

1. Jeśli funkcja getAdSelectionData zostanie zainicjowana nieprawidłowymi argumentami, funkcja AdServicesException wskazuje jako przyczynę błąd IllegalArgumentException.
2. Wszystkie inne błędy otrzymują kod AdServicesException z wartością IllegalStateException jako przyczyna.

Wysyłanie prośby do niesprawdzonego sprzedawcy

Za pomocą pakietu SDK na urządzeniu można wysłać żądanie do usługi reklamowej sprzedawcy, dołączając dane do żądania POST lub PUT:AdSelectionData

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
...
})

Za kodowanie tych danych odpowiada pakiet SDK na urządzeniu. Zalecamy stosowanie rozwiązania, które nie wymaga dużo miejsca, np. wysyłanie żądania do usługi reklamowej sprzedawcy w postaci danych multipart/form-data.

Odbieranie odpowiedzi od niesprawdzonego sprzedawcy

Jak opisano w opisie określania stawek i serwera aukcji, gdy usługa niesprawdzonego sprzedawcy otrzyma żądanie, wykona wywołania do kupujących partnerskich reklam kontekstowych.

Usługa nie zaufanego sprzedawcy przekazuje zaszyfrowane dane adSelectionData i AuctionConfig do usługi SellerFrontEnd serwera określania stawek i aukcji, która działa w TEE.

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

Usługa nieufnego sprzedawcy wysyła odpowiedź do urządzenia z reklamą kontekstową lub zaszyfrowanym wynikiem aukcji Protected Audience.

Po otrzymaniu odpowiedzi kod technologii reklamowej sprzedawcy na urządzeniu może zdecydować się na użycie w odpowiedzi tylko reklamy kontekstowej lub, jeśli uzna, że wynik Protected Audience może być wartościowy, może odszyfrować wynik Protected Audience, wywołując interfejs API PersistAdSelectionResult.

PersistAdSelectionResult API

Aby odszyfrować wynik Protected Audience, sprzedawca może wywołać drugi interfejs Protected Audience API persistAdSelectionResult. Interfejs API odszyfrowuje wynik i zwraca obiekt AdSelectionOutcome, czyli ten sam obiekt, który jest 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

Wywołujący musi ustawić w żądaniu 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: aby przed obsłużeniem żądania można było przeprowadzić weryfikację rejestracji, w żądaniu musi być ustawiony identyfikator technologii reklamowej sprzedawcy.
3. adSelectionResult: zaszyfrowany wynik aukcji wygenerowany przez serwer licytowania i aukcji, który wywołujący chce odszyfrować.

Odpowiedź AdSelectionOutcome

Jeśli zwycięzcą jest Protected Audience API, AdSelectionOutcome zwraca URI renderowania zwycięskiej reklamy.Gdy adSelectionResult zostanie odszyfrowany, dane raportowania są zapisywane wewnętrznie. Wywołanie OutcomeReceiver.onResult() zwraca AdSelectionOutcome, które zawiera:

• URI: jeśli jest reklama z wyświetloną treścią z poziomu Protected Audience, zwracany jest adres URL jej renderowania. Jeśli nie ma zwycięzcy w Protected Audience, zwracana jest wartość Uri.EMPTY.
• adSelectionId: adSelectionId powiązany z tą aukcją serwera.

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

Jeśli nie można utworzyć danych doboru reklamy z takich powodów jak nieprawidłowe argumenty, przekroczenie limitu czasu lub nadmierne wykorzystanie zasobów, wywołanie zwrotne OutcomeReceiver.onError() przekazuje AdServicesException z tymi zachowaniami:

1. Jeśli funkcja getAdSelectionData zostanie uruchomiona z nieprawidłowymi argumentami, funkcja AdServicesException zwróci wartość IllegalArgumentException jako przyczynę.
2. Wszystkie inne błędy otrzymują kod AdServicesException z wartością IllegalStateException jako przyczyna.

Uwzględnienie kwestii prywatności

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

Pomimo szyfrowania wyciek danych może wystąpić z powodu rozmiaru adSelectionData. Rozmiar adSelectionData może się różnić z powodu:

1. Zmiany danych CustomAudience na urządzeniu.
2. Zmiany w logice filtrowania CustomAudience.
3. Zmiana wejścia na getAdSelectionData call.

Zmiana rozmiaru adSelectionData może służyć do generowania identyfikatora międzyaplikacyjnym, jak wspomniano w dyskusji na temat wycieku 1-bitowego adresu IP. Wiele środków zaradczych dotyczących wycieku 1-bitowego jest również skutecznych w tym przypadku.

Aby zapobiec tym wyciekom, planujemy generować te same adSelectionData dla wszystkich wywołań interfejsu API getAdSelectionData. W pierwszych wersjach wszystkie CustomAudiences na urządzeniu są używane do tworzenia adSelectionData, a zaszyfrowane dane będą wypełniane, aby ukryć różnice w rozmiarze. Ograniczymy też wpływ parametrów wejściowych GetAdSelectionData na generowane adSelectionData.

Jednak generowanie tych samych wartości adSelectionData dla wszystkich technologii reklamowych na podstawie wszystkich danych aukcji na urządzeniu powoduje powstanie dużej ładowności, która musi być przesyłana w każdym wywołaniu do serwera technologii reklamowej. Korzystanie ze wszystkich niestandardowych list odbiorców na urządzeniu do generowania ładunku aukcji stwarza też możliwość nadużyć przez złośliwe podmioty. Te problemy zostały omówione w sekcjach Optymalizacja rozmiaru i Zapobieganie nadużyciom.

Optymalizacja rozmiaru

Pakiet SDK klienta technologii reklamowych powinien pakować zaszyfrowane bajty adSelectionData w ramach wywołania kontekstowego HTTP PUT/POST wysyłanego do serwera technologii reklamowych. Aby zmniejszyć opóźnienie i koszt przesyłania danych w obie strony, należy zminimalizować rozmiar adSelectionData, nie wpływając przy tym na użyteczność.

W przyszłych wersjach planujemy sprawdzić i wprowadzić optymalizacje, które mogą zmniejszyć rozmiar adSelectionData:

1. Dane generowane w ramach stałego zbioru rozmiarów z dodatkiem: aby zminimalizować wyciek danych spowodowany przez zmiany rozmiaru, a jednocześnie umożliwić tworzenie mniejszych danych, zalecamy użycie zbioru danych o stałym rozmiarze. Utrzymanie niewielkiej liczby zasobników, np. 7, spowoduje, że w przypadku wywołania funkcji getAdSelectionData zostanie uwolniona mniej niż 3 bity entropii.

   Jeśli dane na urządzeniu przekroczą maksymalny rozmiar zasobnika, do określenia, które dane mają zostać odrzucone, zostaną użyte strategie wymienione poniżej, np. wartości priorytetów.

2. Konfiguracja kupującego: sprawdzamy, czy można umożliwić kupującym konfigurowanie konfiguracji danych ładunku dla poszczególnych kupujących. Ta konfiguracja jest przydatna do określania, w których aukcjach kupujący chce brać udział. Jeśli to możliwe, podczas rejestracji kupujący może zarejestrować punkt końcowy, z którego Protected Audience będzie pobierać konfigurację ładunku w regularnych odstępach czasowych. Alternatywnie interfejsy API chroniące prywatność mogłyby udostępniać interfejs API, który umożliwiłby technologiom reklamowym kupujących rejestrowanie tego punktu końcowego.

   Ta konfiguracja służyłaby do oceny udziału kupującego w generowaniu adSelectionData w przypadku każdego żądania getAdSelectionData.

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

   1. Lista dozwolonych sprzedawców: listy niestandardowych odbiorców kupującego zostaną dodane do ładunku tylko wtedy, gdy wywołanie getAdSelectionData zostanie zainicjowane przez sprzedawcę z listy dozwolonych. Konfigurację ładunku pobieramy codziennie, aby lista dozwolonych adresów była aktualna.
   2. Limit rozmiaru na sprzedawcę: kupujący może określić limit rozmiaru na sprzedawcę, aby określić rozmiar danych, które mają być wysyłane w danych ładunku, gdy aukcja jest inicjowana przez określonego sprzedawcę. Może to być przydatne, jeśli kupujący chce poświęcić więcej zasobów na przetwarzanie danych 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 wielkości na sprzedawcę kupujący może wyraźnie kontrolować ilość danych pozyskiwanych i przetwarzanych przez usługę BuyerFrontendService na serwerze licytowania i aukcji w przypadku aukcji prowadzonych przez sprzedawcę.

3. Konfiguracja sprzedawcy: oceniamy wykonalność konfiguracji aukcji dla poszczególnych sprzedawców, która pozwoliłaby im definiować parametry aukcji w celu kontrolowania rozmiaru ładunku i uczestników aukcji. Jeśli to możliwe, podczas rejestracji sprzedawca będzie mógł określić punkt końcowy, z którego Protected Audience będzie regularnie pobierać konfigurację aukcji dla poszczególnych sprzedawców. Ta konfiguracja służyłaby do określania składu i limitów adSelectionData generowanych w przypadku każdego żądania getAdSelectionData.

   Podobnie jak w przypadku konfiguracji kupującego, konfiguracja według sprzedawcy pozwoliłaby sprzedawcom określić, jaki zestaw kupujących chcą zobaczyć w aukcji, oraz określić limity udziału kupujących w rozmiarze danych.

   Konfiguracja aukcji sprzedawcy pozwoliłaby sprzedawcom określić:

   1. Lista dozwolonych kupujących: w przypadku aukcji inicjowanych przez danego sprzedawcę tylko kupujący z listy dozwolonych mogą tworzyć listy CustomAudiences na potrzeby aukcji. Konfiguracja aukcji musiałaby być aktualizowana 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 danych przesyłanych do SellerFrontendService. Jeśli kupujący przekroczy limit rozmiaru na kupującego, do pobrania danych w oczekiwanym zakresie zostanie użyty priorytet ustawiony w konfiguracji danych ładunku kupującego.
   3. Priorytet dla poszczególnych kupujących: zezwala sprzedawcom na ustawianie priorytetów dla poszczególnych kupujących. Priorytet kupującego służy do określania, które dane kupującego powinny być zachowane w ładunku, jeśli jego rozmiar przekroczy limit.
   4. Maksymalny rozmiar danych: różni sprzedawcy mogą mieć różne przydziały zasobów i mogą chcieć ustawić maksymalny rozmiar danych na potrzeby aukcji na podstawie żądania. Maksymalny rozmiar będzie uwzględniał przedziały o stałym rozmiarze określone przez interfejs Protected Audience API.

4. Zmiany w niestandardowych listach odbiorców

   1. Określanie priorytetu listy niestandardowych odbiorców: kupujący mogą określić wartość priorytetu na liście niestandardowych odbiorców. Pole priority służy do identyfikowania list odbiorców niestandardowych, które powinny być uwzględniane w aukcji, jeśli zestaw list odbiorców niestandardowych kupujących przekracza limity wielkości dotyczące sprzedawców lub kupujących. Nieokreślona wartość priorytetu w grupie niestandardowej przyjmuje domyślnie wartość 0.0.

5. Zmiany danych ładunku

   1. Zmniejsz ilość danych przesyłanych w pliku danych: jak opisano w artykule Optymalizacja pliku danych usług ustalania stawek i aukcji, większy plik danych generują dane o listach odbiorców niestandardowych ads, sygnały dotyczące stawek użytkowników i sygnały z Androida. Większe ładunki można zmniejszyć:
      1. Klient wysyła w ładunku reklamy identyfikatory renderowania reklam (zamiast obiektów reklamy).
      2. klient nie wysyła żadnych danych reklamy w pliku danych;
      3. Brak wysyłania sygnałów licytowania przez użytkownika w danych klienta.

Strategie wymienione powyżej umożliwiają specjalistom ds. technologii reklamowych definiowanie konfiguracji w celu zarządzania składem i limitami adSelectionData, ale mogą też stać się czynnikiem wpływającym na modyfikowanie rozmiaru adSelectionData przez zmianę parametrów konfiguracji. Aby tego uniknąć, Protected Audience będzie codziennie pobierać konfigurację z skonfigurowanego punktu końcowego.

Optymalizacja opóźnień

Aby aukcje serwera miały odpowiedni poziom przydatności, musimy zadbać o to, aby interfejsy API getAdSelectionData i persistAdSelectionResult miały niską latencję na wywołanie. Chociaż naszym celem jest zapewnienie obsługi funkcji interfejsów API w 2023 roku, nasza kolejna wersja będzie się koncentrować na benchmarkach i optymalizacji interfejsów API pod kątem opóźnień.

Aby utrzymać opóźnienie w akceptowalnych granicach, testujemy następujące strategie:

1. Przedwczesna generacja danych dotyczących chronionych odbiorców przez sprzedawcę: ponieważ konfiguracja aukcji sprzedawcy i konfiguracja danych ładunku kupującego będą stabilne przez długi czas (codziennie), platforma może z wyprzedzeniem obliczyć i zapisać odpowiednie dane dotyczące chronionych odbiorców.

   Wymagałoby to stworzenia mechanizmu monitorowania aktualizacji list odbiorców niestandardowych i modyfikowania na ich podstawie wcześniej wygenerowanych danych o chronionych listach odbiorców. Platforma musi też zadeklarować SLO dotyczące opóźnienia, jakie może wystąpić w przypadku technologii reklamowych między aktualizacjami list odbiorców niestandardowych a zauważeniem zmiany w adSelectionData wygenerowanej na potrzeby aukcji na serwerze.

   Ponieważ urządzenie zapewnia model obliczeniowy z ograniczonymi zasobami i zmiennymi priorytetami procesów, zdajemy sobie sprawę, że udostępnienie tej funkcji wstępnej generacji musi być powiązane z wysoką niezawodnością i gwarancjami SLO.

   Wstępna generacja danych dotyczących chronionych odbiorców odbywałaby się na podstawie

   1. Sprzedawca musi wyrazić zgodę na wstępną generację danych Protected Audience.
   2. Kupujący kwalifikujący się do udziału w aukcji zainicjowanej przez konkretnego sprzedawcę.
   3. Identyfikowanie niestandardowych list odbiorców na podstawie kupującego, które będą częścią danych ładunku:
      1. Limity rozmiarów na kupującego, priorytety dla kupujących i maksymalne limity rozmiarów zdefiniowane w konfiguracji sprzedawcy,
      2. Limit wielkości na sprzedawcę, priorytet niestandardowych odbiorców zdefiniowany w konfiguracji kupującego.

2. Efektywne stosowanie odfiltrowywania negatywnego: jeśli sprzedawca woli, platforma może wstępnie obliczyć adSelectionData, generując wstępnie dane dotyczące chronionych odbiorców i stosując odfiltrowywanie negatywne poza wywołaniem funkcji getAdSelectionData. Pozwoliłoby to sprzedawcom zrównoważyć zmniejszenie opóźnień przy jednoczesnym akceptowaniu nieaktualnych danych w filtrowaniu negatywnym.

   Platforma mogłaby zapewnić taką obsługę, oferując domyślną opcję w konfiguracji sprzedawcy z limitem nieaktualności i opcję zastąpienia w getAdSelectionData, aby umożliwić obliczenie najnowszych danych, jeśli to konieczne. Platforma może też udostępnić dodatkowy interfejs API do inicjalizacji, który można wywołać przed getAdSelectionData, aby rozgrzać aukcję.

3. Obliczanie danych w przypadku wielu aukcji: w niektórych sytuacjach może być korzystniejsze korzystanie z interfejsu API o krótszym czasie oczekiwania, ale z większym opóźnieniem danych. Aby to umożliwić, platforma może wprowadzić interfejs API inicjalizacji, który oblicza cały ładunek i przekazuje wywołującemu odwołanie do obliczonych danych.

   W przypadku kolejnych wywołań funkcji getAdSelectionData dzwoniący może podać odwołanie do wcześniej obliczonego ładunku, który ma być użyty do wygenerowania adSelectionData.

Wszystkie 3 wymienione powyżej strategie są na etapie wstępnej eksploracji i mają na celu opis kierunków, w których platforma może się rozwijać, aby optymalizować opóźnienia. W miarę poznawania bardziej szczegółowych profili opóźnień interfejsu API i wymagań technologii reklamowych będziemy proponować kolejne strategie.

Zapobieganie nadużyciom i ich identyfikowanie

Jak wspomniano w sekcji dotyczącej prywatności, adSelectionData jest generowany na podstawie wszystkich danych kupującego na urządzeniu.

Jeśli jednak do wygenerowania danych adSelectionData używane są wszystkie dane kupującego na urządzeniu, podmiot o złośliwych zamiarach może się podać za kupującego i utworzyć fałszywe dane kupującego, aby obniżyć wydajność Androida, zwiększyć objętość danych, aby zwiększyć koszty technologii reklamowych na potrzeby przeprowadzania aukcji lub licytacji itp.

Łagodzenie

Niektóre z wymienionych w sekcji dotyczącej rozmiaru środków, takich jak konfiguracja pliku danych kupującego zawierająca listę dozwolonych sprzedawców i konfiguracja aukcji sprzedawcy zawierająca listę dozwolonych kupujących, pomogą wykluczyć nieoczekiwane dane z pliku danych.

Inne środki uwzględniające rozmiar, np. zezwalanie SSP na określanie priorytetów kupujących, umieszczanie w generowanym ładunku limitów dla poszczególnych kupujących i ustalanie maksymalnego rozmiaru ładunku na aukcję, mogą też pomóc w ograniczeniu wpływu złośliwego ładunku. Te środki mają umożliwić dostawcom technologii reklamowych określenie, z którymi dostawcami technologii reklamowych współpracują, oraz ustawienie dopuszczalnych limitów dotyczących ładunku, który muszą przetwarzać.

Jak wspomnieliśmy wcześniej, wszystkie środki zapobiegawcze wprowadzone w celu ochrony przed nadużywaniem i ograniczenia rozmiaru muszą być zgodne z zasadami ochrony prywatności.

identyfikowanie szkodliwych elementów;

Chociaż wspomniane powyżej środki zaradcze chronią generowanie adSelectionData w przypadku aukcji na serwerze, nie pomagają w identyfikowaniu złośliwych podmiotów ani nie chronią platformy przed nadużyciami, takimi jak tworzenie przez kupującego niespotykanej liczby niestandardowych list odbiorców.

Aby zapewnić stabilność i prawidłowe działanie platformy, musimy znaleźć mechanizm umożliwiający identyfikację szkodliwych podmiotów, wektorów nadużyć oraz motywacji stojących za konkretnymi atakami. W kolejnych wersjach udostępnimy materiały wyjaśniające, w których omówimy potencjalne sposoby nadużyć i środki ochrony przed nimi.