dzięki chronionych sygnałów aplikacji na potrzeby obsługi odpowiednich reklam promujących instalacje aplikacji;

Ta propozycja podlega procesowi rejestracji w Piaskownicy prywatności i atestom. Więcej informacji o atestach znajdziesz w podanym linku. W przyszłych aktualizacjach tej propozycji opisane zostaną wymagania dotyczące uzyskania dostępu do tego systemu.

Reklamy promujące instalację aplikacji mobilnej, zwane też reklamami zachęcającymi do pozyskiwania użytkowników, to rodzaj reklamy mobilnej, która ma zachęcać użytkowników do pobierania aplikacji mobilnych. Reklamy te są zwykle wyświetlane użytkownikom na podstawie ich zainteresowań i danych demograficznych, a często pojawiają się w innych aplikacjach mobilnych, takich jak gry, aplikacje społecznościowe i aplikacje z wiadomościami. Gdy użytkownik kliknie reklamę promującą instalację aplikacji, zostanie przekierowany bezpośrednio do sklepu z aplikacjami, w którym będzie mógł pobrać aplikację.

Na przykład reklamodawca, który chce zwiększyć liczbę nowych instalacji nowej aplikacji mobilnej do zamawiania jedzenia w Stanach Zjednoczonych, może kierować reklamy do użytkowników, którzy znajdują się w tym kraju i wcześniej korzystali z innych aplikacji do zamawiania jedzenia.

Zazwyczaj odbywa się to przez uwzględnianie sygnałów kontekstowych, własnych i pochodzących od innych firm w komunikacji między technologiami reklamowymi, aby tworzyć profile użytkowników na podstawie identyfikatorów reklamowych. Modele uczenia maszynowego w technologiach reklamowych wykorzystują te informacje jako dane wejściowe do wybierania reklam, które są trafne dla użytkownika i z największym prawdopodobieństwem doprowadzą do konwersji.

Aby obsługiwać skuteczne reklamy instalacji aplikacji, które zwiększają prywatność użytkowników dzięki wyeliminowaniu zależności od identyfikatorów użytkowników pochodzących od firm zewnętrznych, proponujemy te interfejsy API:

1. Protected App Signals API: ten interfejs API koncentruje się na przechowywaniu i tworzeniu funkcji opracowanych przez technologię reklamową, które reprezentują potencjalne zainteresowania użytkownika. Technologie reklamowe przechowują zdefiniowane przez siebie sygnały zdarzeń dotyczące poszczególnych aplikacji, takie jak instalacje aplikacji, pierwsze uruchomienia, działania użytkowników (poziomy w grze, osiągnięcia), aktywność związana z zakupami lub czas spędzony w aplikacji. Sygnały są zapisywane i przechowywane na urządzeniu, aby zapobiec wyciekowi danych. Są one udostępniane tylko logice technologii reklamowej, która zapisała dany sygnał podczas aukcji chronionej przeprowadzanej w bezpiecznym środowisku.
2. Ad Selection API: ten interfejs API umożliwia konfigurowanie i przeprowadzanie aukcji chronionej w zaufanym środowisku wykonawczym (TEE), w którym platformy reklamowe pobierają kandydatów na reklamy, przeprowadzają wnioskowanie, obliczają stawki i przypisują wyniki, aby wybrać „zwycięską” reklamę na podstawie chronionych sygnałów z aplikacji i dostarczonych przez wydawcę informacji kontekstowych w czasie rzeczywistym.

Oto ogólny przegląd działania sygnałów z chronionych aplikacji, które pomagają wyświetlać trafne reklamy promujące instalacje aplikacji. W kolejnych sekcjach tego dokumentu znajdziesz więcej szczegółów na temat każdego z tych kroków.

• Selekcja sygnałów: gdy użytkownicy korzystają z aplikacji mobilnych, dostawcy technologii reklamowych selekcjonują sygnały przez przechowywanie zdefiniowanych przez nich zdarzeń w aplikacji na potrzeby wyświetlania trafnych reklam za pomocą interfejsu Protected App Signals API. Te zdarzenia są przechowywane w chronionym miejscu na urządzeniu, podobnie jak listy odbiorców niestandardowych, i są szyfrowane przed wysłaniem z urządzenia. Tylko usługi określania stawek i aukcji działające w zaufanych środowiskach wykonawczych z odpowiednimi zabezpieczeniami i kontrolą prywatności mogą je odszyfrować na potrzeby określania stawek i oceniania reklam.
• Kodowanie sygnałów: sygnały są przygotowywane zgodnie z harmonogramem przez niestandardową logikę technologii reklamowej. Zadanie w tle na Androidzie wykonuje tę logikę, aby przeprowadzić kodowanie na urządzeniu i wygenerować ładunek sygnałów z chronionych aplikacji, które mogą być później używane w czasie rzeczywistym do wybierania reklam podczas chronionej aukcji. Ładunek jest bezpiecznie przechowywany na urządzeniu do momentu wysłania na aukcję.
• Wybór reklamy: aby wybrać odpowiednie reklamy dla użytkownika, pakiety SDK sprzedawcy wysyłają zaszyfrowany ładunek zawierający chronione sygnały z aplikacji i konfigurują chronioną aukcję. Podczas aukcji niestandardowa logika kupującego przygotowuje sygnały Protected App Signals wraz z danymi kontekstowymi dostarczonymi przez wydawcę (dane zwykle udostępniane w żądaniu reklamy Open-RTB), aby opracować funkcje przeznaczone do wyboru reklam (pobieranie reklam, wnioskowanie i generowanie stawek). Podobnie jak w przypadku Protected Audience kupujący przesyłają sprzedawcy reklamy do ostatecznej oceny w ramach aukcji chronionej.
  • Pobieranie reklam: kupujący używają sygnałów z aplikacji chronionych i dostarczonych przez wydawcę danych kontekstowych, aby opracowywać funkcje odpowiednie dla zainteresowań użytkownika. Te funkcje służą do dopasowywania reklam, które spełniają kryteria kierowania. Reklamy, które nie mieszczą się w budżecie, są odfiltrowywane. Następnie wybieranych jest k najlepszych reklam, które mogą brać udział w licytacji.
  • Określanie stawek: niestandardowa logika określania stawek kupujących przygotowuje dane kontekstowe dostarczone przez wydawcę i sygnały Protected App Signals, aby tworzyć funkcje, które są używane jako dane wejściowe w modelach uczenia maszynowego kupujących na potrzeby wnioskowania i określania stawek za reklamy kandydujące w zaufanych granicach ochrony prywatności. Kupujący zwróci sprzedawcy wybraną reklamę.
  • Ocena sprzedawcy: niestandardowa logika oceniania sprzedawcy ocenia reklamy przesłane przez uczestniczących kupujących i wybiera zwycięską reklamę, która ma zostać odesłana do aplikacji w celu renderowania.
• Raportowanie: uczestnicy aukcji otrzymują odpowiednie raporty o wygranych i przegranych. Badamy mechanizmy ochrony prywatności, które pozwolą nam uwzględniać w raporcie o wygranych dane do trenowania modeli.

Oś czasu

Tworzenie sygnałów aplikacji chronionych

Sygnał to reprezentacja różnych interakcji użytkownika w aplikacji, które są uznawane przez technologię reklamową za przydatne do wyświetlania trafnych reklam. Aplikacja lub zintegrowany pakiet SDK mogą przechowywać lub usuwać sygnały chronione aplikacji zdefiniowane przez technologie reklamowe na podstawie aktywności użytkownika, takiej jak otwieranie aplikacji, osiągnięcia, aktywność związana z zakupami lub czas spędzony w aplikacji. Sygnały chronione aplikacji są bezpiecznie przechowywane na urządzeniu i są szyfrowane przed wysłaniem z urządzenia, tak aby tylko usługi ustalania stawek i aukcji działające w zaufanych środowiskach wykonawczych z odpowiednimi zabezpieczeniami i kontrolą prywatności mogły je odszyfrować na potrzeby ustalania stawek i oceniania reklam. Podobnie jak w przypadku interfejsu Custom Audience API sygnały przechowywane na urządzeniu nie mogą być odczytywane ani sprawdzane przez aplikacje lub pakiety SDK. Nie ma interfejsu API do odczytywania wartości sygnałów, a interfejsy API są zaprojektowane tak, aby nie ujawniać obecności sygnałów. Niestandardowa logika technologii reklamowych ma chroniony dostęp do wyselekcjonowanych sygnałów, aby tworzyć funkcje, które stanowią podstawę wyboru reklam w ramach aukcji chronionej.

Interfejs Protected App Signals API

Interfejs Protected App Signals API obsługuje zarządzanie sygnałami za pomocą mechanizmu delegowania podobnego do tego, który jest używany w przypadku niestandardowych list odbiorców. Interfejs Protected App Signals API umożliwia przechowywanie sygnałów w postaci pojedynczej wartości skalarnej lub szeregu czasowego. Sygnały szeregów czasowych mogą służyć do przechowywania informacji takich jak czas trwania sesji użytkownika. Sygnały szeregów czasowych umożliwiają wymuszanie określonej długości za pomocą reguły usuwania „pierwsze weszło, pierwsze wyszło”. Typem danych sygnału skalarnego lub każdego z elementów sygnału szeregu czasowego jest tablica bajtów. Każda wartość jest wzbogacana o nazwę pakietu aplikacji, która zapisała sygnał, oraz o sygnaturę czasową utworzenia wywołania interfejsu Store Signal API. Te dodatkowe informacje są dostępne w kodzie JavaScript do kodowania sygnałów. Ten przykład pokazuje strukturę sygnałów należących do danej platformy reklamowej:

Ten przykład pokazuje sygnał skalarny i sygnał szeregu czasowego powiązane z kampanią adtech1.com:

• Sygnał skalarny z kluczem wartości zakodowanym w Base64 „A1c” i wartością „c12Z”. Sygnał został wywołany przez com.google.android.game_app w dniu 1 czerwca 2023 r..
• Lista sygnałów z kluczem „dDE”, które zostały utworzone przez 2 różne aplikacje.

Technologie reklamowe mają do dyspozycji określoną ilość miejsca na urządzeniu, w którym mogą przechowywać sygnały. Sygnały będą miały maksymalny czas życia, który zostanie określony.

Sygnały aplikacji chronionych są usuwane z pamięci, jeśli aplikacja, która je generuje, zostanie odinstalowana lub zablokowana w zakresie korzystania z interfejsu Protected App Signals API albo jeśli użytkownik wyczyści dane aplikacji.

Interfejs Protected App Signals API składa się z tych elementów:

• interfejs API w językach Java i JavaScript do dodawania, aktualizowania i usuwania sygnałów;
• interfejs API JavaScript do przetwarzania zapisanych sygnałów w celu przygotowania ich do dalszego tworzenia funkcji w czasie rzeczywistym podczas aukcji chronionej, która jest przeprowadzana w zaufanym środowisku wykonawczym (TEE);

Dodawanie, aktualizowanie i usuwanie sygnałów

Technologie reklamowe mogą dodawać, aktualizować i usuwać sygnały za pomocą interfejsu fetchSignalUpdates() API. Ten interfejs API obsługuje delegowanie podobne do delegowania niestandardowych list odbiorców w Protected Audience API.

Aby dodać sygnał, dostawcy technologii reklamowych po stronie kupującego, którzy nie mają pakietu SDK w aplikacjach, muszą współpracować z dostawcami technologii reklamowych obecnymi na urządzeniu, takimi jak partnerzy ds. pomiarów mobilnych (MMP) i platformy dostawców (SSP). Interfejs Protected App Signals API ma wspierać te technologie reklamowe, zapewniając elastyczne rozwiązania do zarządzania chronionymi sygnałami aplikacji. Umożliwia on podmiotom wywołującym na urządzeniu tworzenie chronionych sygnałów aplikacji w imieniu kupujących. Ten proces nazywa się delegowaniem i wykorzystuje interfejs fetchSignalUpdates() API. fetchSignalUpdates() pobiera identyfikator URI i zwraca listę aktualizacji sygnałów. Na przykład fetchSignalUpdates() wysyła żądanie GET do podanego identyfikatora URI, aby pobrać listę aktualizacji do zastosowania w lokalnym magazynie sygnałów. Punkt końcowy URL należący do kupującego odpowiada listą poleceń w formacie JSON.

Obsługiwane polecenia JSON:

• put: wstawia lub zastępuje wartość skalarną dla danego klucza.
• put_if_not_present: wstawia wartość skalarną dla danego klucza, jeśli nie ma jeszcze zapisanej wartości. Ta opcja może być przydatna np. do ustawienia identyfikatora eksperymentu dla danego użytkownika i uniknięcia jego zastąpienia, jeśli został już ustawiony przez inną aplikację.
• append: dodaje element do szeregu czasowego powiązanego z danym kluczem. Parametr maxSignals określa maksymalną liczbę sygnałów w szeregu czasowym. Jeśli rozmiar zostanie przekroczony, wcześniejsze elementy zostaną usunięte. Jeśli klucz zawiera wartość skalarną, jest automatycznie przekształcany w ciąg czasowy.
• remove: usuwa treści powiązane z danym kluczem.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Wszystkie klucze i wartości są wyrażone w formacie Base64.

Wymienione polecenia mają na celu zapewnienie semantyki wstawiania, zastępowania i usuwania w przypadku sygnałów skalarnych oraz wstawiania, dołączania i pełnego zastępowania serii w przypadku sygnałów szeregów czasowych. Semantyka usuwania i nadpisywania w przypadku określonych elementów sygnału szeregu czasowego musi być zarządzana podczas procesu kodowania i kompresji, np. podczas kodowania ignorowanie wartości w szeregu czasowym, które zostały zastąpione lub poprawione przez nowsze wartości, oraz usuwanie ich podczas procesu kompresji.

Przechowywane sygnały są automatycznie powiązane z aplikacją, która wysyła żądanie pobierania, oraz z odpowiadającym na to żądanie „miejscem” lub „źródłem” zarejestrowanej technologii reklamowej, a także z czasem utworzenia żądania. Wszystkie sygnały mogą być przechowywane w imieniu dostawcy technologii reklamowych zarejestrowanego w Piaskownicy prywatności. Adres URI „site” lub „origin” musi być zgodny z danymi zarejestrowanego dostawcy technologii reklamowych. Jeśli dostawca technologii reklamowych wysyłający żądanie nie jest zarejestrowany, żądanie jest odrzucane.

Limit miejsca na dane i usuwanie

Każda platforma reklamowa ma ograniczoną ilość miejsca na urządzeniu użytkownika do przechowywania sygnałów. Ten limit jest określany dla każdej technologii reklamowej, więc sygnały zbierane z różnych aplikacji mają wspólny limit. Jeśli limit zostanie przekroczony, system zwolni miejsce, usuwając wcześniejsze wartości sygnałów w kolejności ich otrzymania. Aby zapobiec zbyt częstemu usuwaniu danych, system stosuje logikę przetwarzania wsadowego, która umożliwia przekroczenie limitu miejsca na dane w ograniczonym zakresie i zwolnienie dodatkowego miejsca po uruchomieniu logiki usuwania.

Szyfrowanie danych na urządzeniu podczas transmisji

Aby przygotować sygnały do wyboru reklam, logika niestandardowa każdego kupującego ma chroniony dostęp do przechowywanych sygnałów i zdarzeń dotyczących poszczególnych aplikacji. Zadanie w tle systemu Android jest uruchamiane co godzinę, aby wykonywać niestandardową logikę kodowania dla każdego kupującego, która jest pobierana na urządzenie. Logika niestandardowego kodowania dla każdego kupującego koduje sygnały dotyczące poszczególnych aplikacji, a następnie kompresuje je do postaci ładunku zgodnego z limitem dla danego kupującego. Ładunek jest następnie szyfrowany w obrębie chronionego miejsca na dane na urządzeniu, a potem przesyłany do usług licytacji i aukcji.

Dostawcy technologii reklamowych określają poziom przetwarzania sygnałów obsługiwany przez ich własną logikę niestandardową. Możesz na przykład skonfigurować rozwiązanie tak, aby odrzucało wcześniejsze sygnały i agregowało podobne lub wzmacniające się sygnały z różnych aplikacji w nowe sygnały, które zajmują mniej miejsca.

Jeśli kupujący nie zarejestrował kodera sygnałów, sygnały nie są przygotowywane, a żadne wyselekcjonowane sygnały na urządzeniu nie są wysyłane do usług określania stawek i aukcji.

Więcej informacji o limitach miejsca na dane, ładunku i żądań podamy w przyszłej aktualizacji. Podamy też więcej informacji o tym, jak udostępniać funkcje niestandardowe.

Proces wyboru reklamy

Zgodnie z tą propozycją niestandardowy kod technologii reklamowej może uzyskiwać dostęp do chronionych sygnałów aplikacji tylko w ramach chronionej aukcji (interfejs Ad Selection API) uruchomionej w TEE. Aby jeszcze lepiej zaspokajać potrzeby związane z instalowaniem aplikacji, reklamy kandydujące są pobierane w czasie rzeczywistym podczas aukcji chronionej. Różni się to od przypadku użycia remarketingu, w którym reklamy kandydujące są znane przed aukcją.

Ta propozycja wykorzystuje podobny proces wyboru reklam jak Protected Audience, ale zawiera aktualizacje, które obsługują przypadek użycia związany z instalacją aplikacji. Aby spełnić wymagania obliczeniowe dotyczące tworzenia funkcji i wybierania reklam w czasie rzeczywistym, aukcje reklam promujących instalację aplikacji muszą być przeprowadzane w ramach usług określania stawek i aukcji działających w środowiskach TEE. Dostęp do sygnałów z chronionych aplikacji podczas chronionej aukcji nie jest obsługiwany w przypadku aukcji na urządzeniu.

Proces wyboru reklamy wygląda następująco:

1. Pakiet SDK sprzedawcy wysyła na urządzeniu zaszyfrowany ładunek sygnałów z chronionych aplikacji.
2. Serwer sprzedawcy tworzy konfigurację aukcji i wysyła ją do usługi Trusted Bidding and Auction sprzedawcy wraz z zaszyfrowanym ładunkiem, aby rozpocząć proces wyboru reklamy.
3. Usługa ustalania stawek i aukcji sprzedawcy przekazuje ładunek do serwerów frontendu zaufanych kupujących.
4. Usługa ustalania stawek kupującego wykonuje logikę wyboru reklam po stronie kupującego.
   1. Wykonanie logiki pobierania reklam po stronie kupującego.
   2. Wykonanie logiki określania stawek po stronie kupującego.
5. Wykonana zostaje logika oceny po stronie sprzedaży.
6. Reklama jest renderowana i rozpoczyna się raportowanie.

Inicjowanie procesu wyboru reklamy

Gdy aplikacja jest gotowa do wyświetlenia reklamy, pakiet SDK technologii reklamowej (zwykle platformy SSP) inicjuje proces wyboru reklamy, wysyłając odpowiednie dane kontekstowe od wydawcy i zaszyfrowane ładunki dla poszczególnych kupujących, które mają zostać uwzględnione w żądaniu wysyłanym do aukcji chronionej za pomocą wywołania getAdSelectionData. Jest to ten sam interfejs API, który jest używany w przepływie pracy remarketingu i opisany w propozycji Integracja licytowania i aukcji na Androidzie.

Aby rozpocząć wybieranie reklam, sprzedawca przekazuje listę uczestniczących kupujących i zaszyfrowany ładunek sygnałów z chronionych aplikacji na urządzeniu. Na podstawie tych informacji serwer reklamowy po stronie sprzedaży przygotowuje SelectAdRequest dla zaufanej usługi SellerFrontEnd.

Sprzedawca określa te kwestie:

• Ładunek otrzymany z getAdSelectionData, który zawiera chronione sygnały z aplikacji.

• Sygnały kontekstowe wykorzystują:

  • auction_config.auction_signals (aby uzyskać informacje o aukcji)

  • auction_config.seller_signals (w przypadku sygnałów sprzedawcy

  • auction_config.per_buyer_config["buyer"].buyer_signals (w przypadku sygnałów kupujących)

• Lista kupujących uwzględnionych w aukcjach korzystających z polabuyer_list.

Wykonanie logiki wyboru reklam po stronie kupującego

Ogólnie rzecz biorąc, niestandardowa logika kupującego używa danych kontekstowych dostarczonych przez wydawcę i sygnałów z chronionych aplikacji do wybierania i stosowania stawki w przypadku odpowiednich reklam w odpowiedzi na żądanie reklamy. Platforma umożliwia kupującym zawężenie dużej puli dostępnych reklam do najbardziej trafnych (k najlepszych), dla których obliczane są stawki, zanim reklamy zostaną zwrócone sprzedawcy w celu ostatecznego wyboru.

Przed rozpoczęciem określania stawek kupujący mają do dyspozycji dużą pulę reklam. Jest zbyt wolny, aby obliczyć stawkę dla każdej reklamy, więc kupujący muszą najpierw wybrać z dużej puli k najlepszych kandydatów. Następnie kupujący muszą obliczyć stawki dla każdego z tych k najlepszych kandydatów. Następnie te reklamy i stawki są zwracane sprzedawcy w celu ostatecznego wyboru.

1. Usługa BuyerFrontEnd otrzymuje żądanie reklamy.
2. Usługa BuyerFrontEnd wysyła żądanie do usługi ustalania stawek kupującego. Usługa ustalania stawek kupującego uruchamia funkcję UDF o nazwie prepareDataForAdRetrieval(), która tworzy żądanie pobrania k najlepszych kandydatów z usługi pobierania reklam. Usługa ustalania stawek wysyła to żądanie do skonfigurowanego punktu końcowego serwera pobierania.
3. Usługa pobierania reklam uruchamia getCandidateAds()funkcję zdefiniowaną przez użytkownika, która filtruje reklamy, aby wybrać z nich k najlepszych kandydatów. Zostają oni wysłani do usługi określania stawek kupującego.
4. Usługa określania stawek kupującego uruchamia generateBid() funkcję UDF, która wybiera najlepszego kandydata, oblicza jego stawkę, a następnie zwraca ją do usługi BuyerFrontEnd.
5. Usługa BuyerFrontEnd zwraca sprzedawcy reklamy i stawki.

W tym procesie jest kilka ważnych szczegółów, zwłaszcza w odniesieniu do tego, jak poszczególne elementy komunikują się ze sobą i jak platforma udostępnia funkcje takie jak możliwość tworzenia prognoz uczenia maszynowego na potrzeby pobierania k najlepszych reklam i obliczania ich stawek.

Zanim przyjrzymy się poszczególnym częściom tego diagramu, warto zwrócić uwagę na kilka ważnych kwestii dotyczących architektury środowisk TEE.

Usługa określania stawek kupującego zawiera wewnętrzną usługę wnioskowania. Dostawcy technologii reklamowych mogą przesyłać modele uczenia maszynowego do usługi określania stawek kupującego. Udostępnimy interfejsy API JavaScript dla platform reklamowych, aby umożliwić im tworzenie prognoz lub generowanie osadzeń na podstawie tych modeli w ramach funkcji zdefiniowanych przez użytkownika działających w usłudze określania stawek kupującego. W przeciwieństwie do usługi pobierania reklam usługa ustalania stawek kupującego nie ma usługi wartości klucza do przechowywania metadanych reklam.

Usługa pobierania reklam wewnętrznie zawiera usługę par klucz-wartość. Technologie reklamowe mogą przekształcać pary klucz-wartość w tej usłudze na swoich serwerach, poza granicą prywatności. Udostępnimy interfejs JavaScript API, który umożliwi platformom reklamowym odczytywanie danych z tej usługi par klucz-wartość w ramach funkcji zdefiniowanych przez użytkownika działających w usłudze pobierania reklam. W przeciwieństwie do usługi ustalania stawek kupującego usługa pobierania reklam nie zawiera usługi wnioskowania.

Jednym z głównych problemów, które rozwiązuje ten projekt, jest sposób tworzenia prognoz w czasie pobierania i w czasie określania stawek. Odpowiedzią na oba te pytania może być rozwiązanie o nazwie faktoryzacja modelu.

Rozkład modelu

Faktoryzacja modelu to technika, która umożliwia podzielenie pojedynczego modelu na wiele części, a następnie połączenie ich w prognozę. W przypadku instalacji aplikacji modele często korzystają z 3 rodzajów danych: danych o użytkownikach, danych kontekstowych i danych o reklamach.

W przypadku modelu bez faktoryzacji jeden model jest trenowany na wszystkich 3 rodzajach danych. W przypadku faktoryzacji dzielimy model na kilka części. Tylko część zawierająca dane użytkownika jest wrażliwa. Oznacza to, że w ramach granicy zaufania, w usłudze wnioskowania usługi licytacyjnej kupującego, musi być uruchomiony tylko model z częścią użytkownika.

Umożliwia to zastosowanie takiego projektu:

1. Podziel model na prywatną część (dane użytkownika) i co najmniej jedną nieprywatną część (dane kontekstowe i dane reklam).
2. Opcjonalnie możesz przekazać niektóre lub wszystkie nieprywatne elementy jako argumenty do funkcji zdefiniowanej przez użytkownika, która musi dokonywać prognoz. Na przykład osadzenia kontekstowe są przekazywane do funkcji UDF w per_buyer_signals.
3. Opcjonalnie dostawcy technologii reklamowych mogą tworzyć modele dla elementów nieprywatnych, a następnie przekształcać osadzenia z tych modeli w pamięci klucz-wartość usługi pobierania reklam. Funkcje zdefiniowane przez użytkownika w usłudze pobierania reklam mogą pobierać te osadzania w czasie działania.
4. Aby dokonać prognozy podczas działania funkcji zdefiniowanej przez użytkownika, połącz prywatne osadzanie z usługi wnioskowania z nieprywatnym osadzaniem z argumentów funkcji zdefiniowanej przez użytkownika lub z magazynu klucz-wartość za pomocą operacji takiej jak iloczyn skalarny. To ostateczna prognoza.

Gdy już to wiesz, możemy przyjrzeć się każdej funkcji zdefiniowanej przez użytkownika bardziej szczegółowo. Wyjaśnimy, jak działają, jak są zintegrowane i jak mogą tworzyć prognozy niezbędne do wyboru k najskuteczniejszych reklam i obliczania ich stawek.

Funkcja prepareDataForAdRetrieval() UDF

prepareDataForAdRetrieval() działający w usłudze określania stawek kupującego jest odpowiedzialny za utworzenie ładunku żądania, który zostanie wysłany do usługi pobierania reklam w celu uzyskania k najlepszych reklam.

prepareDataForAdRetrieval() pobiera te informacje:

• Ładunek na kupującego otrzymany od getAdSelectionData. Ten ładunek zawiera chronione sygnały aplikacji.
• Sygnały kontekstowe auction_signals(w przypadku informacji o aukcji) i buyer_signals (w przypadku pól sygnałów kupujących).

prepareDataForAdRetrieval() robi 2 rzeczy:

• Tworzenie cech: jeśli potrzebne jest wnioskowanie w czasie pobierania, przekształca sygnały przychodzące w cechy, które są używane podczas wywołań usługi wnioskowania w celu uzyskania prywatnych wektorów osadzania na potrzeby pobierania.
• Oblicza prywatne wektory osadzania na potrzeby wyszukiwania: jeśli potrzebne są prognozy wyszukiwania, wywołuje usługę wnioskowania za pomocą tych funkcji i uzyskuje prywatny wektor osadzania na potrzeby prognozowania w czasie wyszukiwania.

prepareDataForAdRetrieval() za możliwość zwrotu:

• Protected App Signals: ładunek sygnałów wyselekcjonowanych przez dostawców technologii reklamowych.
• Sygnały dotyczące aukcji: sygnały platformy po stronie sprzedawcy i informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym osadzenia kontekstowe) z SelectAdRequest. Jest to podobne do odbiorców chronionych.
• Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne osadzanie pobrane z usługi wnioskowania.

To żądanie jest wysyłane do usługi pobierania reklam, która dopasowuje kandydatów, a następnie uruchamia getCandidateAds() funkcję zdefiniowaną przez użytkownika.

Funkcja getCandidateAds() UDF

getCandidateAds() działa w usłudze pobierania reklam. Otrzymuje żądanie utworzone przez prepareDataForAdRetrieval() w usłudze określania stawek kupującego. Usługa wykonuje getCandidateAds(), która pobiera k najlepszych kandydatów do licytowania, przekształcając żądanie w serię zapytań o zbiory, pobrań danych i wykonywania niestandardowej logiki biznesowej oraz innej niestandardowej logiki pobierania.

getCandidateAds() pobiera te informacje:

• Protected App Signals: ładunek sygnałów wyselekcjonowanych przez dostawców technologii reklamowych.
• Sygnały dotyczące aukcji: sygnały platformy po stronie sprzedawcy i informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym osadzenia kontekstowe) z SelectAdRequest. Jest to podobne do odbiorców chronionych.
• Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne osadzanie pobrane z usługi wnioskowania.

getCandidateAds() wykonuje te czynności:

1. Pobieranie wstępnego zestawu potencjalnych reklam: pobieranie za pomocą kryteriów kierowania, takich jak język, lokalizacja geograficzna, typ reklamy, rozmiar reklamy lub budżet, w celu filtrowania potencjalnych reklam.
2. Pobieranie osadzania na potrzeby wyszukiwania: jeśli osadzanie z usługi klucz-wartość jest potrzebne do prognozowania w czasie wyszukiwania na potrzeby wyboru k najlepszych wyników, musi zostać pobrane z tej usługi.
3. Wybór k najlepszych kandydatów: obliczanie uproszczonego wyniku dla przefiltrowanego zbioru kandydatów do wyświetlenia reklam na podstawie metadanych reklam pobranych z pamięci klucz-wartość oraz informacji przesłanych z usługi określania stawek kupującego, a także wybieranie k najlepszych kandydatów na podstawie tego wyniku. Może to być np. prawdopodobieństwo zainstalowania aplikacji po wyświetleniu reklamy.
4. Pobieranie danych do określania stawek: jeśli kod określania stawek potrzebuje danych z usługi klucz-wartość do prognozowania w czasie określania stawek, może je pobrać z tej usługi.

Pamiętaj, że wynik reklamy może być wynikiem modelu predykcyjnego, który np. przewiduje prawdopodobieństwo zainstalowania aplikacji przez użytkownika. Ten rodzaj generowania wyników obejmuje rodzaj faktoryzacji modelu: ponieważ getCandidateAds() działa w usłudze pobierania reklam, a usługa pobierania reklam nie ma usługi wnioskowania, prognozy mogą być generowane przez połączenie:

• Osadzenia kontekstowe przekazywane za pomocą sygnałów z poszczególnych aukcji.
• Prywatne osadzanie przekazywane za pomocą danych wejściowych dodatkowych sygnałów.
• Wszystkie technologie reklamowe, które nie korzystają z prywatnych umieszczeń, zostały zmaterializowane z ich serwerów w usłudze klucz-wartość usługi pobierania reklam.

Pamiętaj, że generateBid()funkcja zdefiniowana przez użytkownika, która działa w usłudze określania stawek kupującego, może też stosować własny rodzaj faktoryzacji modelu, aby tworzyć prognozy stawek. Jeśli do tego celu potrzebne są jakiekolwiek osadzania z usługi par klucz-wartość, muszą one zostać pobrane teraz.

getCandidateAds() za możliwość zwrotu:

• Reklamy kandydujące: k najlepszych reklam do przekazania do generateBid(). Każda reklama składa się z:
  • URL renderowania: punkt końcowy renderowania kreacji reklamy.
  • Metadane: metadane reklam dotyczące platformy kupującej i technologii reklamowych. Może to obejmować na przykład informacje o kampanii reklamowej i kryteriach kierowania, takich jak lokalizacja i język. Metadane mogą zawierać opcjonalne osadzanie używane, gdy do przeprowadzenia wnioskowania podczas ustalania stawek potrzebne jest rozkładanie modelu na czynniki.
• Dodatkowe sygnały: opcjonalnie usługa pobierania reklam może zawierać dodatkowe informacje, takie jak dodatkowe osadzanie lub sygnały spamu, które będą używane w generateBid().

Analizujemy inne metody dostarczania reklam do oceny, w tym udostępnianie ich w ramach wywołania SelectAdRequest. Te reklamy można pobierać za pomocą pytania o stawkę RTB. Pamiętaj, że w takich przypadkach reklamy muszą być pobierane bez bezpiecznych sygnałów z aplikacji. Zakładamy, że przed wyborem najlepszej opcji dostawcy technologii reklamowych ocenią kompromisy, w tym rozmiar ładunku odpowiedzi, opóźnienie, koszt i dostępność sygnałów.

Funkcja generateBid() UDF

Po pobraniu podczas pobierania zestawu reklam kandydujących i ich osadzeń możesz przejść do określania stawek, które odbywa się w usłudze określania stawek kupującego. Ta usługa uruchamia dostarczoną przez kupującego generateBid()funkcję zdefiniowaną przez użytkownika, aby wybrać z k najlepszych reklam tę, za którą ma złożyć ofertę, a następnie zwrócić ją wraz z ofertą.

generateBid() pobiera te informacje:

• Reklamy kandydujące: k reklam o najwyższym rankingu zwróconych przez usługę pobierania reklam.
• Sygnały dotyczące aukcji: sygnały platformy po stronie sprzedawcy i informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym osadzenia kontekstowe) z SelectAdRequest.
• Dodatkowe sygnały: dodatkowe informacje, które mają być używane podczas określania stawek.

Implementacja generateBid() kupującego wykonuje 3 czynności:

• Ekstrakcja cech: przekształca sygnały w cechy, które są używane podczas wnioskowania.
• Wnioskowanie: generuje prognozy przy użyciu modeli uczenia maszynowego, aby obliczać wartości takie jak przewidywane współczynniki klikalności i konwersji.
• Ustalanie stawek: łączenie wywnioskowanych wartości z innymi danymi wejściowymi w celu obliczenia stawki za reklamę kandydującą.

generateBid() za możliwość zwrotu:

• Reklama kandydata.
• Jest to obliczona kwota stawki.

Pamiętaj, że symbol generateBid() używany w przypadku reklam promujących instalację aplikacji różni się od tego, który jest używany w przypadku reklam remarketingowych.

W sekcjach poniżej znajdziesz więcej informacji o tworzeniu cech, wnioskowaniu i ustalaniu stawek.

Featurization

Sygnały aukcji mogą być przekształcane przez generateBid() w funkcje. Te funkcje mogą być używane podczas wnioskowania do prognozowania takich wartości jak współczynnik klikalności i współczynnik konwersji. Badamy też mechanizmy ochrony prywatności, aby przesyłać niektóre z nich w raporcie o wygranej na potrzeby trenowania modeli.

Wnioskowanie

Podczas obliczania stawki często przeprowadza się wnioskowanie na podstawie co najmniej jednego modelu uczenia maszynowego. Na przykład obliczenia efektywnego eCPM często wykorzystują modele do prognozowania współczynników klikalności i konwersji.

Klienci mogą dostarczyć kilka modeli uczenia maszynowego wraz z ich generateBid()wdrożeniem. W generateBid() udostępnimy też interfejs API JavaScript, aby klienci mogli przeprowadzać wnioskowanie w czasie działania.

Wnioskowanie jest wykonywane w usłudze składania ofert kupującego. Może to wpływać na opóźnienia i koszty wnioskowania, zwłaszcza że akceleratory nie są jeszcze dostępne w środowiskach TEE. Niektórzy klienci stwierdzą, że ich potrzeby są zaspokajane przez poszczególne modele działające w usłudze określania stawek kupującego. Niektórzy klienci, np. ci, którzy mają bardzo duże modele, mogą rozważyć opcje takie jak faktoryzacja modelu, aby zminimalizować koszt wnioskowania i opóźnienie w momencie składania oferty.

Więcej informacji o możliwościach wnioskowania, takich jak obsługiwane formaty modeli i maksymalne rozmiary, podamy w przyszłej aktualizacji.

Wdrażanie faktoryzacji modelu

Wcześniej wyjaśniliśmy, czym jest faktoryzacja modelu. W momencie ustalania stawek stosuje się to podejście:

1. Podziel pojedynczy model na część prywatną (dane użytkownika) i co najmniej jedną część nieprywatną (dane kontekstowe i dane reklam).
2. Przekaż elementy nieprywatne do generateBid(). Mogą one pochodzić z per_buyer_signals lub z osadzonych danych obliczanych zewnętrznie przez technologie reklamowe, zapisywanych w pamięci klucz-wartość usługi pobierania, pobieranych w momencie pobierania i zwracanych jako część dodatkowych sygnałów. Nie obejmuje to prywatnych osadzeń, ponieważ nie można ich pozyskać spoza granicy prywatności.
3. W przypadku generateBid():
   1. przeprowadzać wnioskowanie na podstawie modeli, aby uzyskiwać prywatne osadzanie użytkowników;
   2. Połącz prywatne osadzenia użytkowników z osadzeniami kontekstowymi z per_buyer_signals lub osadzeniami kontekstowymi i osadzeniami reklam niespersonalizowanych z usługi pobierania za pomocą operacji takiej jak iloczyn skalarny. Jest to ostateczna prognoza, która może być używana do obliczania stawek.

Dzięki temu można przeprowadzać wnioskowanie w momencie określania stawek na podstawie modeli, które w innym przypadku byłyby zbyt duże lub zbyt wolne, aby można je było uruchomić w usłudze określania stawek kupującego.

Logika oceniania po stronie sprzedawcy

Na tym etapie reklamy z ofertami otrzymanymi od wszystkich uczestniczących kupujących są oceniane. Dane wyjściowe funkcji generateBid() są przekazywane do usługi aukcyjnej sprzedawcy, aby uruchomić funkcję scoreAd(), która uwzględnia tylko jedną reklamę naraz.scoreAd() Na podstawie oceny sprzedawca wybiera zwycięską reklamę, która ma zostać zwrócona na urządzenie w celu renderowania.

Logika oceniania jest taka sama jak w przypadku remarketingu Protected Audience i umożliwia wybór zwycięzcy spośród kandydatów do remarketingu i instalacji aplikacji.Funkcja jest wywoływana raz dla każdej przesłanej reklamy kandydującej w aukcji chronionej. Więcej informacji znajdziesz w wyjaśnieniu licytowania i aukcji.

Czas działania kodu wyboru reklamy

W propozycji kod wyboru reklamy do instalacji aplikacji jest określony w taki sam sposób jak w przypadku remarketingu w ramach Protected Audience. Szczegółowe informacje znajdziesz w sekcji Konfiguracja określania stawek i aukcji. Kod określania stawek będzie dostępny w tym samym miejscu w Cloud Storage, które zostało użyte na potrzeby remarketingu.

Raportowanie

Ta propozycja korzysta z tych samych interfejsów API raportowania co propozycja raportowania w ramach Protected Audience (np. reportImpression(), który powoduje, że platforma wysyła raporty sprzedawcy i kupującego).

Jednym z częstych zastosowań raportowania po stronie kupującego jest uzyskiwanie danych treningowych dla modeli używanych podczas wybierania reklam. Oprócz dotychczasowych interfejsów API platforma będzie udostępniać specjalny mechanizm eksportowania danych na poziomie zdarzenia z platformy na serwery technologii reklamowych. Te ładunki wyjściowe mogą zawierać określone dane użytkownika.

W dłuższej perspektywie badamy rozwiązania chroniące prywatność, które pozwolą trenować modele na podstawie danych używanych w aukcjach chronionych bez wysyłania danych użytkowników na poziomie zdarzenia poza usługi działające w środowiskach TEE. Więcej szczegółów podamy w późniejszej aktualizacji.

W najbliższym czasie udostępnimy tymczasowy sposób eksportowania zaszumionych danych z generateBid(). Poniżej przedstawiamy naszą wstępną propozycję. Będziemy ją rozwijać (w tym wprowadzać zmiany, które mogą powodować brak zgodności wstecznej) w odpowiedzi na opinie branży.

Technicznie wygląda to tak:

1. Dostawcy technologii reklamowych określają schemat danych, które chcą przesyłać.
2. W generateBid() tworzą wybrany ładunek wyjściowy.
3. Platforma weryfikuje ładunek wychodzący pod kątem zgodności ze schematem i egzekwuje limity rozmiaru.
4. Platforma dodaje szum do ładunku wychodzącego.
5. Ładunek wychodzący jest uwzględniany w raporcie o wygranej w formacie przewodowym, odbieranym na serwerach technologii reklamowych, dekodowanym i używanym do trenowania modelu.

Określanie schematu ładunków wychodzących

Aby platforma mogła egzekwować zmieniające się wymagania dotyczące ochrony prywatności, ładunki wychodzące muszą być ustrukturyzowane w sposób zrozumiały dla platformy. Dostawcy technologii reklamowych określają strukturę ładunków wychodzących, przesyłając plik JSON ze schematem. Ten schemat będzie przetwarzany przez platformę i zachowywany w poufności przez usługi określania stawek i aukcji przy użyciu tych samych mechanizmów co inne zasoby technologii reklamowych, takie jak funkcje zdefiniowane przez użytkownika i modele.

Udostępnimy plik CDDL, który określa strukturę tego pliku JSON. Plik CDDL będzie zawierać zestaw obsługiwanych typów cech (np. cechy, które są wartościami logicznymi, liczbami całkowitymi, przedziałami itp.). Zarówno plik CDDL, jak i podany schemat będą wersjonowane.

Na przykład ładunek wychodzący, który składa się z 1 cechy logicznej, a następnie z cechy koszyka o rozmiarze 2, będzie wyglądać tak:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Szczegółowe informacje o zestawie obsługiwanych typów funkcji są dostępne w GitHubie.

Tworzenie ładunków wychodzących w usłudze generateBid()

Wszystkie sygnały z aplikacji chronionych dotyczące danego kupującego są dostępne w jego generateBid()funkcji zdefiniowanej przez użytkownika. Po przekształceniu tych danych w funkcje platformy reklamowe tworzą ładunek w formacie JSON. Ten ładunek wyjściowy zostanie uwzględniony w raporcie o wygranej kupującego, który zostanie przesłany na serwery dostawców technologii reklamowej.

Alternatywą dla tego rozwiązania jest obliczanie wektora wyjścia w reportWin() zamiast w generateBid(). Każde z tych podejść ma swoje wady i zalety. Ostateczną decyzję podejmiemy na podstawie opinii branży.

Weryfikowanie ładunku wychodzącego

Platforma będzie weryfikować wszystkie ładunki wychodzące utworzone przez technologię reklamową. Weryfikacja sprawdza, czy wartości funkcji są prawidłowe dla ich typów, czy spełnione są ograniczenia rozmiaru oraz czy złośliwi użytkownicy nie próbują obejść kontroli prywatności, pakując dodatkowe informacje do ładunków wychodzących.

Jeśli ładunek wychodzący jest nieprawidłowy, zostanie bez powiadomienia odrzucony z danych wejściowych wysyłanych do raportu o wygranej. Nie chcemy bowiem udostępniać informacji o debugowaniu osobom, które próbują obejść weryfikację.

Udostępnimy interfejs API JavaScript, który umożliwi dostawcom technologii reklamowych weryfikowanie, czy utworzony przez nich w generateBid() ładunek wychodzący przejdzie weryfikację platformy:

validate(payload, schema)

Ten interfejs API JavaScript służy wyłącznie do określania, czy dany ładunek przejdzie weryfikację platformy. Prawidłowa weryfikacja musi być przeprowadzana na platformie, aby chronić przed złośliwymi generateBid()funkcjami zdefiniowanymi przez użytkownika.

Dodawanie szumu do ładunku wychodzącego

Platforma będzie dodawać szum do wychodzących pakietów danych przed uwzględnieniem ich w raporcie o wygranej. Początkowy próg szumu wyniesie 1%, a z czasem może się zmienić. Platforma nie będzie informować, czy dany ładunek wychodzący został zaszumiony.

Metoda dodawania szumu to:

1. Platforma wczytuje definicję schematu ładunku wychodzącego.
2. Do szumienia zostanie wybrany 1% ładunków wychodzących.
3. Jeśli nie wybierzesz ładunku wychodzącego, zachowana zostanie cała pierwotna wartość.
4. Jeśli zostanie wybrany ładunek wychodzący, wartość każdej cechy zostanie zastąpiona losową prawidłową wartością dla tego typu cechy (np. 0 lub 1 w przypadku cechy logicznej).

Przesyłanie, odbieranie i dekodowanie ładunku wychodzącego na potrzeby trenowania modelu

Zweryfikowany, zaszumiony ładunek wychodzący zostanie uwzględniony w argumentach funkcji reportWin() i przesłany na serwery technologii reklamowych kupującego poza granicą ochrony prywatności na potrzeby trenowania modelu. Ładunek wychodzący będzie miał format transmisji.

Szczegółowe informacje o formacie przesyłania wszystkich typów funkcji i samym ładunku wychodzącym są dostępne w serwisie GitHub.

Określanie rozmiaru ładunku wychodzącego

Rozmiar ładunku wychodzącego w bitach zapewnia równowagę między użytecznością a minimalizacją danych. Wspólnie z przedstawicielami branży określimy odpowiedni rozmiar za pomocą eksperymentów. Podczas przeprowadzania tych eksperymentów będziemy tymczasowo przesyłać dane bez ograniczeń dotyczących rozmiaru bitów. Te dodatkowe dane wychodzące bez ograniczeń rozmiaru bitów zostaną usunięte po zakończeniu eksperymentów.

Metoda określania rozmiaru:

1. Początkowo w generateBid() będziemy obsługiwać 2 rodzaje danych wyjściowych:
   1. egressPayload: opisany do tej pory w tym dokumencie ładunek wychodzący o ograniczonej wielkości. Początkowo rozmiar tego pakietu danych wychodzących będzie wynosić 0 bitów (co oznacza, że będzie on zawsze usuwany podczas weryfikacji).
   2. temporaryUnlimitedEgressPayload: tymczasowy pakiet danych wychodzących o nieograniczonym rozmiarze na potrzeby eksperymentów dotyczących rozmiaru. Formatowanie, tworzenie i przetwarzanie tego ładunku wychodzącego odbywa się przy użyciu tych samych mechanizmów co w przypadku egressPayload.
2. Każdy z tych ładunków wyjściowych będzie miał własny plik JSON schematu:egress_payload_schema.json i temporary_egress_payload_schema.json.
3. Udostępniamy protokół eksperymentu i zestaw danych do określania przydatności modelu przy różnych rozmiarach ładunku wychodzącego (np. 5, 10 bitów …).
4. Na podstawie wyników eksperymentu określamy rozmiar pakietu danych wychodzących, uwzględniając odpowiednie kompromisy między użytecznością a prywatnością.
5. Ustawiamy rozmiar egressPayload od 0 bitów do nowego rozmiaru.
6. Po określonym czasie migracji usuniemy temporaryUnlimitedEgressPayload, pozostawiając tylko egressPayload w nowym rozmiarze.

Badamy dodatkowe zabezpieczenia techniczne, które pomogą nam zarządzać tą zmianą (np. szyfrowanie egressPayload, gdy zwiększamy jego rozmiar z 0 bitów). Szczegóły te, a także harmonogram eksperymentu i usunięcia temporaryUnlimitedEgressPayload, zostaną podane w późniejszej aktualizacji.

Następnie wyjaśnimy możliwy protokół eksperymentu, który pozwoli ustalić ostateczny rozmiar egressPayload. Naszym celem jest współpraca z branżą w celu znalezienia rozmiaru, który będzie łączył użyteczność i minimalizację danych. Wynikiem tych eksperymentów będzie wykres, na którym oś X będzie przedstawiać rozmiar ładunku treningowego w bitach, a oś Y – odsetek przychodów generowanych przez model o danym rozmiarze w porównaniu z wartością bazową bez ograniczeń rozmiaru.

Załóżmy, że trenujemy model pInstall, a źródłami danych do trenowania są nasze logi i treści temporaryUnlimitedegressPayload, które otrzymujemy, gdy wygrywamy aukcje. Protokół dotyczący technologii reklamowych obejmuje najpierw eksperymenty offline:

1. określać architekturę modeli, których będą używać w przypadku sygnałów z aplikacji chronionych; Na przykład muszą określić, czy będą używać faktoryzacji modelu.
2. Określ dane do pomiaru jakości modelu. Sugerowane wskaźniki to strata AUC i strata logarytmiczna.
3. określić zestaw funkcji, których będą używać podczas trenowania modelu;
4. Korzystając z tej architektury modelu, wskaźnika jakości i zestawu cech trenowania, przeprowadź badania ablacyjne, aby określić użyteczność każdego bitu w przypadku każdego modelu, którego chcesz używać w PAS. Zalecany protokół badania ablacyjnego to:
   1. Wytrenuj model ze wszystkimi funkcjami i zbadaj jego przydatność. Będzie to punkt odniesienia do porównania.
   2. W przypadku każdej cechy użytej do utworzenia wartości bazowej wytrenuj model ze wszystkimi cechami z wyjątkiem tej cechy.
   3. Mierz wynikającą z tego użyteczność. Podziel różnicę przez rozmiar cechy w bitach. Otrzymasz oczekiwaną użyteczność na bit dla tej cechy.
5. Określ rozmiary ładunków treningowych, które Cię interesują w kontekście eksperymentowania. Sugerujemy [5, 10, 15, ..., size_of_all_training_features_for_baseline] bitów. Każdy z nich reprezentuje możliwy rozmiar egressPayload, który będzie oceniany w ramach eksperymentu.
6. W przypadku każdego możliwego rozmiaru wybierz zestaw funkcji o rozmiarze mniejszym lub równym danemu rozmiarowi, który maksymalizuje użyteczność na bit, korzystając z wyników badania ablacyjnego.
7. Wytrenuj model dla każdego możliwego rozmiaru i oceń jego przydatność jako odsetek przydatności modelu podstawowego wytrenowanego na podstawie wszystkich cech.
8. Wyniki przedstaw na wykresie, na którym oś X to rozmiar pakietu danych treningowych w bitach, a oś Y to odsetek przychodów wygenerowanych przez ten model w porównaniu z wartością bazową.

Następnie dostawcy technologii reklamowych mogą powtórzyć kroki 5–8 w eksperymentach z ruchem na żywo, używając danych o funkcjach wysyłanych za pomocą temporaryUnlimitedEgressPayload. Firmy z branży technologii reklamowych mogą udostępniać Piaskownicy prywatności wyniki eksperymentów dotyczących ruchu offline i ruchu na żywo, aby pomóc w określeniu rozmiaru egressPayload.

Harmonogram tych eksperymentów, a także harmonogram ustawiania rozmiaru egressPayload na wynikową wartość wykraczają poza zakres tego dokumentu i zostaną podane w późniejszej aktualizacji.

Środki ochrony danych

W przypadku danych wychodzących zastosujemy szereg zabezpieczeń, w tym:

1. Zarówno egressPayload, jak i temporaryUnlimitedEgressPayload zostaną zaszumione.
2. W celu minimalizacji i ochrony danych temporaryUnlimitedEgressPayload będzie dostępny tylko podczas eksperymentów dotyczących rozmiaru, w których określimy prawidłowy rozmiar egressPayload.

Uprawnienia

Kontrola sprawowana przez użytkowników

• Propozycja ma na celu udostępnienie użytkownikom listy zainstalowanych aplikacji, które przechowują co najmniej 1 sygnał aplikacji chronionej lub listę odbiorców niestandardowych.
• Użytkownicy mogą blokować i usuwać aplikacje z tej listy. Blokowanie i usuwanie powoduje:
  • Usuwa wszystkie sygnały z aplikacji chronionych i niestandardowe listy odbiorców powiązane z aplikacją.
  • Uniemożliwia aplikacjom przechowywanie nowych sygnałów chronionych aplikacji i niestandardowych list odbiorców.
• Użytkownicy mogą całkowicie zresetować sygnały chronione aplikacji i interfejs Protected Audience API. W takim przypadku wszystkie sygnały z chronionych aplikacji i niestandardowe listy odbiorców na urządzeniu zostaną wyczyszczone.
• Użytkownicy mogą całkowicie zrezygnować z Piaskownicy prywatności na Androidzie, w tym z interfejsów Protected App Signals API i Protected Audience API. W takim przypadku interfejsy Protected Audience API i Protected App Signals zwracają standardowy komunikat o wyjątku: SECURITY_EXCEPTION.

Uprawnienia aplikacji i kontrola

Propozycja ma na celu zapewnienie aplikacjom kontroli nad sygnałami aplikacji chronionych:

• Aplikacja może zarządzać powiązaniami z sygnałami aplikacji chronionych.
• Aplikacja może przyznawać platformom technologii reklamowych innych firm uprawnienia do zarządzania w jej imieniu sygnałami aplikacji chronionych.

Ustawienia platformy technologii reklamowych

Ta propozycja przedstawia sposoby, w jakie dostawcy technologii reklamowych mogą kontrolować chronione sygnały z aplikacji:

• Wszyscy dostawcy technologii reklamowych muszą zarejestrować się w Piaskownicy prywatności i podać domenę „site” lub „origin”, która pasuje do wszystkich adresów URL sygnałów z chronionych aplikacji.
• Technologie reklamowe mogą współpracować z aplikacjami lub pakietami SDK, aby udostępniać tokeny weryfikacyjne, które służą do weryfikowania tworzenia chronionych sygnałów z aplikacji. Gdy ten proces zostanie przekazany partnerowi, tworzenie sygnału aplikacji chronionej można skonfigurować tak, aby wymagało potwierdzenia przez technologię reklamową.