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

W propozycji dotyczącej usług określania stawek i usług aukcyjnych na Androida opisano szczegóły wykonywania aukcji na Androidzie za pomocą zaufanych serwerów określania stawek i aukcji. Aby zapewnić, że dane w trakcie przesyłania są przetwarzane tylko przez interfejsy API chroniące prywatność i usługujące na zaufanych serwerach, są one szyfrowane między klientem a serwerem za pomocą dwukierunkowego szyfrowania kluczem publicznym hybrydowym.

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 zespołu ds. nieuczciwych sprzedawców
4. Odszyfrowanie odpowiedzi z aukcji Protected Audience i uzyskanie wyniku aukcji

Aby obsługiwać aukcje 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.
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. Otrzymywanie 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 protected audience i uzyskanie wyniku aukcji: aby odszyfrować wynik aukcji protected audience, dostawca technologii reklamowej powinien wywołać interfejs API persistAdSelectionResult. Wynik zwracany przez funkcjępersistAdSelectionResult pomoże dostawcom technologii reklamowych określić, czy wygrała aukcję reklama kontekstowa czy reklama dla chronionej listy odbiorców, oraz (w odpowiednich przypadkach) URI reklamy dla chronionej listy odbiorców, która wygrała aukcję.

Funkcje obsługiwane w ramach aukcji serwera

Staramy się obsługiwać wszystkie funkcje, które są dostępne w ramach aukcji na urządzeniu. Harmonogram obsługi tych funkcji w aukcji serwera:

uruchamiać aukcje serwera 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ę pakietów SDK technologii reklamowych z serwerami określania stawek i aukcji.

Zbieranie i szyfrowanie danych na potrzeby aukcji na serwerze

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, a w pliku manifestu wywołującego musisz zdefiniować uprawnienieACCESS_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 ustawiony, powinien być równy 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 ładunku jest szyfrowany za pomocą dwukierunkowego hybrydowego szyfrowania kluczem publicznym.

GetAdSelectionDataOutcome

Wartość GetAdSelectionDataOutcome jest generowana jako wynik 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 ustalania stawek i aukcji do przeprowadzania aukcji. Ta metoda obejmuje:
   1. Odfiltrowane dane o listach odbiorców na podstawie ograniczania liczby wyświetleń, filtrów instalacji aplikacji i wymagań aukcji serwera dotyczących 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 tworzenie danych doboru reklam nie może zostać ukończone z powodu nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia zasobów, wywołanie zwrotne OutcomeReceiver.onError() przekazuje AdServicesException z tymi zachowaniami:

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

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 oszczędzającego miejsce, np. wysyłanie żądania do usługi reklamowej sprzedawcy w formie multipart/form-data.

Odbieranie odpowiedzi od nieuczciwego sprzedawcy

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

Usługa niesprawdzonego 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 użyć tylko reklamy kontekstowej w odpowiedzi 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, technologia reklamowa sprzedawcy 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

W żądaniu wywołujący musi podać:

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

1. adSelectionId: nieprzejrzysty 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 jest zwycięzca na liście Protected Audience, funkcja AdSelectionOutcome zwraca URI renderowania zwycięskiej reklamy.Gdy adSelectionResult zostanie odszyfrowany, dane raportowania są przechowywane 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 tworzenie danych doboru reklam nie może zostać ukończone z powodu nieprawidłowych argumentów, przekroczenia limitu czasu lub nadmiernego zużycia 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 mają kod AdServicesException z wartością IllegalStateException.

Uwagi dotyczące prywatności

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

Pomimo szyfrowania wyciek danych może wystąpić z powodu rozmiaru adSelectionData. adSelectionData Wymiary mogą się różnić ze względu na:

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 identyfikatorów międzyaplikacyjnym, jak wspomniano w dyskusji na temat wycieku 1-bitowych danych. Wiele metod ograniczania wycieków 1-bitowych 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 dane CustomAudiences na urządzeniu są używane do tworzenia adSelectionData, a zaszyfrowane dane są 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 ilości danych, które muszą być przesyłane w ramach każdego wywołania 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. Omówiliśmy te problemy w sekcjach Optymalizacja rozmiaru i Zwalczanie nadużyć.

Optymalizacja rozmiaru

Pakiet SDK klienta adtecha powinien zawierać zaszyfrowane bajty adSelectionData w ramach wywołania kontekstowego HTTP PUT/POST wysyłanego do serwera adtecha. Aby zmniejszyć opóźnienie i koszty związane z czasem okrężnym, 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 puli, np. 7, spowoduje, że na każde wywołanie funkcji getAdSelectionData przypadnie mniej niż 3 bity ulatującej entropii.

   Jeśli dane na urządzeniu przekroczą maksymalny rozmiar zasobnika, do podjęcia decyzji, które dane mają zostać odrzucone, zostaną użyte strategie takie jak 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 ładunku kupującego pozwoli 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ę znajdującego się na liście dozwolonych. Konfigurację ładunku pobieramy 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, 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 przetwarzanych przez serwer określania stawek i serwer aukcji BuyerFrontendService 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 kupującego: zezwala sprzedawcom na ustawianie priorytetu dla kupującego. 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 pliku danych: różni sprzedawcy mogą mieć różne przydziały zasobów i mogą chcieć ustawić maksymalny rozmiar pliku danych aukcji na żądanie. Maksymalny rozmiar będzie zgodny z blokami o stałym rozmiarze określonymi 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 wysył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 o ustalaniu stawek przez użytkowników i sygnały z Androida. Większe ładunki mogą być zmniejszone przez:
      1. Klient wysyła identyfikatory renderowania reklamy (zamiast obiektów reklamy) w danych ładunku.
      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 te umożliwiają dostawcom technologii reklamowych definiowanie konfiguracji służących do zarządzania składem i limitami adSelectionData, ale mogą też stać się czynnikiem wpływającym na rozmiar adSelectionData poprzez 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 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 te strategie:

1. Wstępna generacja danych Protected Audience dla każdego sprzedawcy: konfiguracja aukcji sprzedawcy i konfiguracja ładunku kupującego będą stabilne przez długi czas (codziennie), więc platforma może wstępnie obliczyć i zapisać odpowiednie dane Protected Audience.

   Wymagałoby to stworzenia mechanizmu monitorowania aktualizacji list odbiorców niestandardowych i modyfikowania na jego 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 przetwarzania ograniczonych zasobów z różnymi priorytetami procesów, zdajemy sobie sprawę, że udostępnienie tej funkcji wstępnej generacji musi być powiązane z wysoką niezawodnością i gwarancjami SLA.

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

   1. Sprzedawca zgadza się na wstępną generację danych Protected Audience.
   2. Kupujący kwalifikujący się do udziału w aukcji zainicjowanej przez konkretnego sprzedawcę.
   3. Określanie na podstawie danych o kliencie grup odbiorców niestandardowych, które będą częścią ładunku:
      1. limity rozmiarów na kupującego, priorytety na kupującego i maksymalne limity rozmiarów zdefiniowane w konfiguracji sprzedawcy,
      2. Limit wielkości na sprzedawcę, priorytet niestandardowych odbiorców określony 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ótkim 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ń getAdSelectionData dzwoniący może podać odwołanie do wstępnie obliczonego ładunku, który ma być użyty do wygenerowania adSelectionData.

Te 3 strategie są na etapie wstępnej eksploracji i mają na celu opisanie kierunku, w którym 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żyto wszystkich danych kupującego na urządzeniu, osoba o złośliwych zamiarach może udawać kupującego i tworzyć fałszywe dane kupującego, aby obniżyć wydajność Androida, zwiększyć objętość ładunku, aby zwiększyć koszty dla technologii reklamowych, aby prowadzić aukcje lub licytacje itp.

Łagodzenie

Niektóre z wymienionych w sekcji dotyczącej rozmiaru środków, np. konfiguracja pliku danych kupującego zawierająca autoryzowanych sprzedawców i konfiguracja aukcji sprzedawcy zawierająca autoryzowanych 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 już wspomnieliśmy, wszystkie środki zapobiegające nadużyciom i ograniczenia rozmiaru muszą być zgodne z zasadami ochrony prywatności.

identyfikowanie szkodliwych elementów;

Chociaż te środki zaradcze chronią generowanie adSelectionData w ramach aukcji na serwerze, nie pomagają w identyfikacji 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 omawiamy potencjalne sposoby nadużyć i środki ochrony przed nimi.