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

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

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

Reklamy promujące instalację aplikacji mobilnej, zwane też reklamami na potrzeby pozyskiwania użytkowników, to rodzaj reklam mobilnych zachęcających użytkowników do pobrania aplikacji mobilnej. Reklamy te są zwykle wyświetlane użytkownikom na podstawie ich zainteresowań i danych demograficznych. Często pojawiają się w innych aplikacjach mobilnych, np. w aplikacjach do gier, mediów społecznościowych i wiadomości. Gdy użytkownik kliknie reklamę promującą instalację aplikacji, zostanie przekierowany bezpośrednio do sklepu z aplikacjami, aby ją pobrać.

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

Zwykle jest to realizowane przez uwzględnianie sygnałów kontekstowych, własnych i innych firm w technologiach reklamowych w celu tworzenia profili użytkowników na podstawie identyfikatorów reklamowych. Modele systemów uczących się w technologii reklamowej wykorzystują te informacje jako dane wejściowe do wybierania reklam, które są trafne dla użytkownika i mają najwyższe prawdopodobieństwo doprowadzenia do konwersji.

Proponujemy stosowanie tych interfejsów API do obsługi skutecznych reklam aplikacji, które zapewniają większą ochronę prywatności użytkowników dzięki wyeliminowaniu zależności od identyfikatorów użytkowników należących do innych firm:

1. Protected App Signals API: interfejs ten służy do przechowywania i tworzenia funkcji opartych na technologii reklamowej, które odzwierciedlają potencjalne zainteresowania użytkownika. Technologie reklamowe przechowują definiowane przez siebie sygnały zdarzeń w aplikacji, np. instalacje aplikacji, pierwsze uruchomienia, działania użytkownika (poziomowanie w grze, osiągnięcia), czynności związane z zakupami lub czas spędzony w aplikacji. Sygnały są zapisywane i przechowywane na urządzeniu, aby zapobiec wyciekowi danych. Są one dostępne tylko dla logiki technologii reklamowej, która zapisała dany sygnał podczas licytacji chronionej, która działa w bezpiecznym środowisku.
2. Ad Selection API: interfejs API umożliwiający konfigurowanie i wykonywanie chronionej aukcji w zaufanym środowisku wykonywania (TEE), w którym technologie reklamowe pobierają reklamy kandydujące, przeprowadzają wnioskowanie, obliczają stawki i wyznaczają wynik, aby wybrać „zwycięską” reklamę, korzystając zarówno z chronionych sygnałów aplikacji, jak i z informacji kontekstowych w czasie rzeczywistym udostępnianych przez wydawcę.

Poniżej znajdziesz ogólny opis tego, jak sygnały chronionych aplikacji pomagają wyświetlać trafne reklamy promujące instalację aplikacji. W następnych sekcjach tego dokumentu znajdziesz więcej informacji o każdym z tych kroków.

• Wybieranie sygnałów: gdy użytkownicy korzystają z aplikacji mobilnych, firmy technologiczne zajmujące się reklamami wybierają sygnały, przechowując zdarzenia z aplikacji zdefiniowane przez technologię reklamową, aby wyświetlać trafne reklamy za pomocą interfejsu Protected App Signals API. Są one przechowywane w chronionym miejscu na urządzeniu, podobnie jak audycje niestandardowe, i przed wysłaniem są szyfrowane, aby tylko usługi ustalania stawek i aukcji działające w zaufanym środowisku wykonawczym z odpowiednimi zabezpieczeniami i kontrolą prywatności mogły je odszyfrować na potrzeby ustalania stawek i oceny reklam.
• Kodowanie sygnałów: sygnały są przygotowywane zgodnie z harmonogramem za pomocą niestandardowej logiki technologii reklamowej. Ta logika jest wykonywana przez zadanie działające w tle na urządzeniu z Androidem. Polega ono na kodowaniu na urządzeniu, aby wygenerować ładunek sygnałów chronionych aplikacji, który można później wykorzystać w czasie rzeczywistym do wyboru reklamy podczas chronionej aukcji. Dane są bezpiecznie przechowywane na urządzeniu do czasu wysłania na aukcję.
• Wybór reklam: aby wybrać odpowiednie reklamy dla użytkownika, sprzedawca wysyła zaszyfrowany ładunek za pomocą bezpiecznych sygnałów aplikacji i konfiguruje bezpieczną aukcję. W aukcji logika klienta kupującego przygotowuje chronione sygnały z aplikacji wraz z danymi kontekstowymi dostarczanymi przez wydawcę (zwykle udostępnianymi w żądaniu reklamy Open-RTB), aby tworzyć funkcje przeznaczone do wyboru reklam (pobieranie reklam, wnioskowanie i generowanie stawek). Podobnie jak w przypadku Protected Audience, kupujący przesyłają reklamy do sprzedawcy na potrzeby końcowego oceniania w ramach aukcji chronionej.
  • Pobieranie reklam: kupujący korzystają z sygnałów chronionych aplikacji oraz danych kontekstowych udostępnianych przez wydawcę, aby projektować funkcje dopasowane do zainteresowań użytkownika. Te funkcje służą do dopasowywania reklam do kryteriów kierowania. Reklamy, które nie mieszczą się w budżecie, są odfiltrowywane. Następnie wybierane są najlepsze reklamy do ustalania stawek.
  • Określanie stawek: logika określania stawek przez kupujących przygotowuje dane kontekstowe dostarczane przez wydawcę i sygnały z chronionych aplikacji w celu tworzenia funkcji, które są używane jako dane wejściowe do modeli uczenia maszynowego kupujących na potrzeby wnioskowania i określania stawek za reklamy kandydatów w ramach zaufanych granic zapewniających ochronę prywatności. Kupujący zwróci wybraną reklamę sprzedawcy.
  • Ocena sprzedawcy: logika oceny stosowana przez sprzedawcę ocenia reklamy przesłane przez kupujących i wybiera reklamę, która zostanie wysłana z powrotem do aplikacji w celu wyrenderowania.
• Raporty: uczestnicy aukcji otrzymują odpowiednie raporty o zwycięstwach i porażkach. Badamy mechanizmy ochrony prywatności, które umożliwiłyby uwzględnianie danych do treningu modelu w raporcie o wygrywalności.

Oś czasu

Tworzenie chronionych sygnałów aplikacji

Sygnał to reprezentacja różnych interakcji użytkownika z aplikacją, które według technologii reklamowych są przydatne do wyświetlania trafnych reklam. Aplikacja lub zintegrowany pakiet SDK może przechowywać lub usuwać chronione sygnały 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. Chronione sygnały aplikacji są bezpiecznie przechowywane na urządzeniu i szyfrowane przed wysłaniem z urządzenia, tak aby mogły je odszyfrowywać tylko usługi ustalania stawek i aukcji działające w zaufanych środowiskach wykonywania z odpowiednimi zabezpieczeniami i kontrolą prywatności. Podobnie jak w przypadku interfejsu Custom Audience API sygnały przechowywane na urządzeniu nie mogą być odczytywane ani sprawdzane przez aplikacje ani pakiety SDK. Nie ma interfejsu API do odczytywania wartości sygnałów, a interfejsy API zostały zaprojektowane tak, aby uniknąć wycieku informacji o ich obecności. Logika niestandardowa technologii reklamowej ma zabezpieczony dostęp do swoich sygnałów, aby tworzyć funkcje, które służą do wyboru reklam w ramach aukcji chronionej.

Interfejs Protected App Signals API

Interfejs Protected App Signals API umożliwia zarządzanie sygnałami za pomocą mechanizmu delegowania podobnego do tego używanego w przypadku list odbiorców niestandardowych. Interfejs Protected App Signals API umożliwia przechowywanie sygnałów w postaci pojedynczej wartości skalarnej lub szeregu czasowego. Sygnałów z danych porządkowanych czasowo można używać do przechowywania takich informacji jak czas trwania sesji użytkownika. Sygnały z serii czasowych umożliwiają wymuszenie określonej długości za pomocą reguły wyrzucania „pierwszy na wejściu, pierwszy na wyjściu”. Typ danych sygnału skalarnego lub każdego z elementów sygnału szeregu czasowego to tablica bajtów. Każda wartość jest wzbogacona o nazwę pakietu aplikacji, która przechowywała sygnał, oraz sygnaturę czasową utworzenia wywołania interfejsu API sygnału sklepu. Te dodatkowe informacje są dostępne w kodzie JavaScript służącym do kodowania sygnału. Ten przykład pokazuje strukturę sygnałów należących do danej firmy zajmującej się technologiami reklamowymi:

Ten przykład pokazuje sygnał skalarny i sygnał z ciągu czasowego powiązane z wartością adtech1.com:

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

Firmom technologicznym reklamowym przydziela się pewną ilość miejsca na przechowywanie sygnałów na urządzeniu. Sygnały będą miały maksymalną wartość TTL, która zostanie określona.

Chronione sygnały aplikacji są usuwane z magazynu, jeśli aplikacja, która je wygenerowała, została odinstalowana, zablokowana przed korzystaniem z interfejsu Protected App Signals API lub jeśli użytkownik wyczyścił dane aplikacji.

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

• interfejs API w języku Java i JavaScript do dodawania, aktualizowania i usuwania sygnałów.
• interfejs JavaScript API do przetwarzania utrwalonych sygnałów w celu przygotowania ich do dalszego tworzenia funkcji w czasie rzeczywistym podczas chronionej aukcji w zaufanym środowisku wykonawczym (TEE).

Dodawanie, aktualizowanie i usuwanie sygnałów

Firmy technologiczne zajmujące się reklamami 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.

Aby dodać sygnał, technologie reklamowe kupujących, które nie mają pakietu SDK w aplikacjach, muszą współpracować z technologiami reklamowymi, które są obecne na urządzeniu, np. z partnerami ds. pomiarów mobilnych i platformami dostawców (SSP). Interfejs Protected App Signals API ma na celu wspieranie tych technologii reklamowych przez udostępnianie elastycznych rozwiązań do zarządzania sygnałami Protected App Signal. Umożliwia on wywoływanie tworzenia sygnałów Protected App Signal przez wywołujących na urządzeniu w imieniu kupujących. Ten proces nazywa się delegowaniem i wykorzystuje interfejs API fetchSignalUpdates(). fetchSignalUpdates()pobiera identyfikator URI i pobiera listę aktualizacji sygnału. W tym celu fetchSignalUpdates() wysyła żądanie GET do podanego identyfikatora URI, aby pobrać listę aktualizacji do zastosowania w lokalnym magazynie sygnałów. Punkt końcowy adresu URL należący do kupującego zwraca 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 żadnej 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 serii czasowej powiązanej z danym kluczem. Parametr maxSignals określa maksymalną liczbę sygnałów w serii czasowej. Jeśli rozmiar zostanie przekroczony, wcześniejsze elementy zostaną usunięte. Jeśli klucz zawiera wartość skalarną, jest ona automatycznie przekształcana 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żane w formacie Base64.

Powyższe polecenia mają na celu zapewnienie możliwości wstawiania, zastępowania i usuwania sygnałów skalarnych oraz wstawiania, dołączania i zastępowania całej serii w przypadku sygnałów serii w czasie rzeczywistym. Usuwanie i zastępowanie semantyki w określonych elementach sygnału serii czasowej musi być zarządzane podczas kodowania i skompresowania. Przykładowo podczas kodowania można zignorować wartości w serii czasowej, które zostały zastąpione lub poprawione przez nowsze, i usunąć je podczas procesu kompresji.

Z przechowywanych sygnałów są automatycznie powiązane aplikacja wykonująca żądanie pobierania oraz odpowiadający na nie podmiot (czyli „witryna” lub „źródło” zarejestrowanej technologii reklamowej) oraz czas utworzenia żądania. Wszystkie sygnały są przechowywane w imieniu zakwalifikowanej do Piaskownicy prywatności technologii reklamowej, a adres URI „site”/„origin” musi być zgodny z danymi takiej technologii. Jeśli zażądana technologia reklamowa nie jest zakwalifikowana, prośba zostanie odrzucona.

Limit miejsca na dane i wyrzucanie

Każda technologia reklamowa ma ograniczoną ilość miejsca na urządzeniu użytkownika na przechowywanie sygnałów. Ta pula jest określana dla każdej technologii reklamowej, więc sygnały pochodzące z różnych aplikacji dzielą się na tę pulę. Jeśli limit zostanie przekroczony, system zwolni miejsce, usuwając wcześniejsze wartości sygnału według zasady „pierwsze weszło, pierwsze wyszło”. Aby zapobiec zbyt częstemu usuwaniu, system stosuje logikę grupowania, która umożliwia ograniczenie przekroczenia limitu i zwolnienie dodatkowej ilości miejsca po uruchomieniu logiki usuwania.

Kodowanie na urządzeniu na potrzeby przesyłania danych

Aby przygotować sygnały do wyboru reklam, logika niestandardowa dla poszczególnych kupujących ma chroniony dostęp do zapisanych sygnałów i zdarzeń w poszczególnych aplikacjach. Zadaniem wykonywanym w tle w systemie Android jest zadanie wykonywane co godzinę, które wykonuje logikę kodowania niestandardowego dla poszczególnych kupujących. Jest ona pobierana na urządzenie. Logika kodowania niestandardowego na poziomie kupującego koduje sygnały na poziomie aplikacji, a potem kompresuje je w taki sposób, aby pasowały do limitu na poziomie kupującego. Ładunek jest następnie szyfrowany w ograniczonych granicach pamięci chronionego urządzenia, a następnie przesyłany do usług licytowania i aukcji.

Dostawcy technologii reklamowych określają poziom przetwarzania sygnałów za pomocą własnej logiki niestandardowej. Możesz na przykład skonfigurować rozwiązanie tak, aby odrzucało wcześniejsze sygnały i zbierało podobne lub wzmacniające 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 i żadne sygnały z urządzenia nie są wysyłane do usług określania stawek i aukcji.

Więcej informacji o limitach miejsca na dane, ładunku i zapytań znajdziesz w przyszłej aktualizacji. Dodatkowo podamy Ci więcej informacji o tym, jak udostępniać funkcje niestandardowe.

Proces wyboru reklamy

W ramach tej propozycji kod niestandardowy technologii reklamowej może uzyskiwać dostęp tylko do sygnałów Protected App Signals w ramach chronionej aukcji (interfejs Ad Selection API) prowadzonej w enklawie Trusted Execution Environment. Aby jeszcze lepiej spełniać potrzeby związane z instalacją aplikacji, reklamy docelowe są pobierane w czasie rzeczywistym podczas aukcji chronionej. Jest to odmienne podejście niż w przypadku remarketingu, gdzie reklamy docelowe są znane przed aukcją.

Ta propozycja wykorzystuje podobny proces wyboru reklam do oferty Protected Audience, z aktualizacjami umożliwiającymi obsługę przypadku użycia polegającego na instalowaniu aplikacji. Aby spełnić wymagania dotyczące przetwarzania danych związane z rozwojem funkcji i wybieraniem reklam w czasie rzeczywistym, aukcje reklam nastawionych na instalowanie aplikacji muszą być przeprowadzane przez usługi określania stawek i aukcje działające w TEE. W przypadku aukcji na urządzeniu dostęp do sygnałów z chronionej aplikacji podczas chronionej aukcji nie jest obsługiwany.

Proces wyboru reklamy wygląda tak:

1. Pakiet SDK sprzedawcy wysyła na urządzenie zaszyfrowany ładunek sygnałów z chronionej aplikacji.
2. Serwer sprzedawcy tworzy konfigurację aukcji i wysyła ją do usługi wiarygodnego określania stawek i aukcji sprzedawcy wraz z zaszyfrowanym ładunkiem, aby rozpocząć proces wyboru reklam.
3. Usługa ustalania stawek i aukcji sprzedawcy przekazuje ładunek do serwerów frontendowych zaufanych kupujących, którzy biorą udział w aukcji.
4. Usługa ustalania stawek kupującego wykonuje logikę wyboru reklam po stronie kupującego.
   1. Wykonywanie logiki pobierania reklam po stronie kupującego.
   2. Wykonywanie logiki określania stawek po stronie kupującego.
5. Wykonana zostaje logika punktacji po stronie sprzedaży.
6. Reklama jest renderowana i inicjowane jest raportowanie.

Uruchamianie 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 dane dotyczące poszczególnych kupujących, które mają zostać uwzględnione w żądaniu wysłanym do chronionej aukcji za pomocą wywołania getAdSelectionData. Jest to ten sam interfejs API, który jest używany w ramach procesu remarketingu i opisany w propozycji Integracja określania stawek i integracji z aukcją na Androida.

Aby zainicjować wybór reklamy, sprzedawca przekazuje listę kupujących, którzy biorą udział w programie, oraz zaszyfrowany ładunek z ochronnymi sygnałami aplikacji na urządzeniu. Na podstawie tych informacji serwer reklam po stronie sprzedawcy przygotowuje SelectAdRequest dla zaufanej usługi SellerFrontEnd.

Sprzedawca określa:

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

• Sygnały kontekstowe, które wykorzystują:

  • auction_config.auction_signals (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 za pomocą pola buyer_list.

Wykonywanie zasad wyboru reklam po stronie kupującego

Ogólnie rzecz biorąc, logika niestandardowa kupującego korzysta z danych kontekstowych dostarczonych przez wydawcę i sygnałów z chronionych aplikacji, aby wybrać stawkę i zastosować ją do odpowiednich reklam w ramach żądania reklamy. Platforma umożliwia kupującym zawężenie dużej puli dostępnych reklam do najbardziej trafnych (najlepszych k), dla których obliczane są stawki, zanim reklamy zostaną zwrócone sprzedawcy w celu ostatecznego wyboru.

Zanim określą stawki, kupujący zaczynają od dużej puli reklam. Obliczanie stawki za każdą reklamę jest zbyt czasochłonne, dlatego kupujący muszą najpierw wybrać z dużej puli najlepszych kandydatów. Następnie kupujący muszą obliczyć stawki dla każdego z tych kandydatów z najlepszych k. Następnie reklamy i stawki są zwracane do sprzedawcy w celu ostatecznego wyboru.

1. Usługa BuyerFrontEnd otrzymuje żądanie reklamy.
2. Usługa BuyerFrontEnd wysyła żądanie do usługi licytowania kupującego. Usługa ustalania stawek kupującego uruchamia UDF o nazwie prepareDataForAdRetrieval(), która tworzy żądanie, aby uzyskać najlepszych kandydatów z usługi pobierania reklam. Usługa ustalania stawek wysyła to żądanie do skonfigurowanego punktu końcowego serwera wyszukiwania.
3. Usługa pobierania reklam uruchamia UDF getCandidateAds(), który filtruje zbiór najlepszych k reklam kandydujących, które są wysyłane do usługi określania stawek kupującego.
4. Usługa określania stawek kupującego uruchamia funkcję generateBid() UDF, która wybiera najlepszego kandydata, oblicza jego stawkę, a następnie zwraca ją do usługi BuyerFrontEnd.
5. Usługa BuyerFrontEnd zwraca reklamy i oferty do sprzedawcy.

W tym procesie występuje 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ść korzystania z systemów uczących się do przewidywania wyników wyszukiwania najlepszych reklam i obliczania ich stawek.

Zanim przyjrzymy się bliżej niektórym z tych elementów, na diagramie powyżej znajdziesz kilka ważnych informacji o architekturze TEE.

Usługa określania stawek przez kupującego zawiera wewnętrznie usługę wnioskowania. Firmy technologiczne zajmujące się reklamami mogą przesyłać modele systemów uczących się do usługi określania stawek przez kupującego. Udostępnimy interfejsy JavaScript, aby firmy zajmujące się technologiami reklamowymi mogły dokonywać prognoz lub generować elementy embeddingu z tych modeli w ramach UDF działających w usłudze określania stawek przez kupującego. W przeciwieństwie do usługi pobierania reklam usługa ustalania stawek kupującego nie ma usługi klucz-wartość do przechowywania metadanych reklam.

Usługa pobierania reklam zawiera wewnętrznie usługę par klucz-wartość. Technologia reklamowa może tworzyć pary klucz-wartość w tej usłudze na własnych serwerach, poza granicą prywatności. Udostępnimy interfejs JavaScript API, który pozwoli specjalistom ds. technologii reklamowych odczytywać dane z tej usługi par klucz-wartość z ramy danych UDF działających w ramach usługi pobierania reklam. W przeciwieństwie do usługi ustalania stawek przez kupującego usługa pobierania reklam nie zawiera usługi wnioskowania.

Jednym z kluczowych pytań, na które odpowiada ta konstrukcja, jest to, jak tworzyć prognozy na czas wyszukiwania i okresu określania stawek. Odpowiedź na oba te pytania może polegać na zastosowaniu rozwiązania zwanego faktoryzacją modelu.

Rozkład modelu

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

W przypadku niesfaktoryzowanym pojedynczy model jest trenowany na podstawie wszystkich 3 rodzajów danych. W przypadku modelu czynnikowego dzielimy go na kilka części. Tylko część zawierająca dane użytkownika jest poufna. Oznacza to, że tylko model z elementem dotyczącym użytkownika musi być uruchamiany w ramach granicy zaufania w usłudze ustalania stawek kupującego.

Umożliwia to zastosowanie takiej struktury:

1. Podziel model na element prywatny (dane użytkownika) i jeden lub więcej elementów nieprywatnych (dane kontekstowe i dane reklam).
2. Opcjonalnie możesz przekazać niektóre lub wszystkie elementy nieprywatne jako argumenty funkcji niestandardowej, która ma generować prognozy. Na przykład w per_buyer_signals funkcje UDF otrzymują kontekstowe zanurzone dane.
3. Opcjonalnie specjaliści ds. technologii reklamowych mogą tworzyć modele dla elementów nieprywatnych, a potem materializować wbudowane elementy z tych modeli w usługach klucz-wartość usługi wyszukiwania reklam. UDF w usłudze pobierania reklam mogą pobierać te elementy w czasie wykonywania.
4. Aby dokonać prognozy podczas wykonywania funkcji niestandardowej, połącz prywatne ukryte reprezentacje z usługi wnioskowania z nieprywatnymi ukrytymi reprezentacjami z argumentów funkcji niestandardowej lub z magazynu klucz-wartość za pomocą operacji takiej jak iloczyn skalarny. To jest ostateczna prognoza.

Po wyjaśnieniu tego możemy przyjrzeć się każdemu z tych pól bardziej szczegółowo. Wyjaśnimy, do czego służą, jak się integrują i jak mogą dokonywać prognoz niezbędnych do wyboru najlepszych reklam i obliczenia ich stawek.

Funkcja UDF prepareDataForAdRetrieval()

prepareDataForAdRetrieval() działająca w usłudze ustalania stawek przez kupującego jest odpowiedzialna za tworzenie ładunku żądania, który zostanie wysłany do usługi pobierania reklam w celu pobrania najlepszych k reklam kandydujących.

prepareDataForAdRetrieval() pobiera te informacje:

• Dane o kupującym otrzymane z getAdSelectionData. Ten ładunek zawiera sygnały chronionych aplikacji.
• Sygnały kontekstowe auction_signals (w przypadku informacji o aukcji) i buyer_signals (w przypadku pól sygnałów kupujących).

prepareDataForAdRetrieval() wykonuje 2 działania:

• Featurization: jeśli potrzebne jest wnioskowanie na etapie wyszukiwania, usługa przekształca przychodzące sygnały w cechy, które są używane podczas wywołań usługi wnioskowania w celu uzyskania prywatnych wektorów zastępczych do wyszukiwania.
• Oblicza prywatne embeddingi do wyszukiwania: jeśli potrzebne są prognozy wyszukiwania, wywołuje usługę wnioskowania, korzystając z wymienionych powyżej funkcji, i otrzymuje prywatny embedding do prognozowania w czasie wyszukiwania.

prepareDataForAdRetrieval() zwrotów:

• Protected App Signals: dane sygnałów wybrane przez dostawcę technologii reklamowych.
• Sygnały dotyczące aukcji: sygnały po stronie sprzedawcy związane z konkretną platformą oraz informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym kontekstowe embeddingi) z SelectAdRequest. Jest to podobne do list odbiorców chronionych.
• Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne embeddingi pobrane z usługi wnioskowania.

To żądanie jest wysyłane do usługi pobierania reklam, która przeprowadza dopasowanie kandydatów, a następnie uruchamia niestandardową funkcję danych getCandidateAds().

Funkcja UDF getCandidateAds()

getCandidateAds() działa w ramach usługi pobierania reklam. Otrzymuje żądanie utworzone przez prepareDataForAdRetrieval() w usłudze określania stawek kupującego. Usługa wykonuje funkcję getCandidateAds(), która pobiera kandydatów na najwyższe k do określania stawek, przekształcając żądanie w serię zapytań zbiorczych, pobiera dane i wykonuje niestandardową logikę biznesową oraz inną niestandardową logikę wyszukiwania.

getCandidateAds() pobiera te informacje:

• Protected App Signals: dane sygnałów wybrane przez dostawcę technologii reklamowych.
• Sygnały dotyczące aukcji: sygnały po stronie sprzedawcy związane z konkretną platformą oraz informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym kontekstowe embeddingi) z SelectAdRequest. Jest to podobne do list odbiorców chronionych.
• Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne embeddingi pobrane z usługi wnioskowania.

getCandidateAds():

1. Pobierz początkowy zestaw reklam kandydujących: do filtrowania reklam kandydujących użyj kryteriów kierowania, takich jak język, lokalizacja, typ reklamy, rozmiar reklamy lub budżet.
2. Pobieranie zaszyfrowanych danych: jeśli zaszyfrowane dane z usługi klucz-wartość są potrzebne do prognozowania w czasie pobierania w celu wybrania najlepszych k wartości, muszą zostać pobrane z usługi klucz-wartość.
3. Wybór najlepszych kandydatów (k najlepszych): obliczanie lekkiej punktacji dla przefiltrowanego zbioru reklam kandydatów na podstawie metadanych reklam pobieranych z magazynu klucz-wartość oraz informacji wysyłanych z usługi określania stawek przez kupującego, a następnie wybieranie najlepszych kandydatów na podstawie tej punktacji. Może to być np. prawdopodobieństwo zainstalowania aplikacji po obejrzeniu reklamy.
4. Pobieranie danych z elementu embeddingu w ramach określania stawek: jeśli kod określania stawek potrzebuje danych z elementu embeddingu z usługi klucz-wartość do prognozowania w czasie określania stawek, może pobrać je z tej usługi.

Pamiętaj, że wynik reklamy może być wynikiem działania modelu predykcyjnego, który na przykład przewiduje prawdopodobieństwo zainstalowania aplikacji przez użytkownika. Generowanie tego typu wyników polega na faktoryzacji modelu: usługa getCandidateAds() korzysta z usługi pobierania reklam, która nie ma usługi wnioskowania, więc prognozy mogą być generowane przez połączenie:

• Ukryte reprezentacje kontekstu przekazywane za pomocą danych wejściowych sygnałów dotyczących aukcji.
• Prywatne zaszyfrowane reprezentacje wejść przekazywane za pomocą parametru additional_signals.
• Wszystkie nieprywatne technologie reklamowe z wbudowanymi funkcjami zostały zmaterializowane z ich serwerów do usługi klucz-wartość usługi Ad Retrieval Service.

Pamiętaj, że generateBid() UDF, który działa w usłudze określania stawek kupującego, może też stosować własny rodzaj faktoryzacji modelu, aby dokonywać prognoz stawek. Jeśli do tego celu potrzebne są jakiekolwiek zaszyfrowane reprezentacje z usługi klucz-wartość, muszą zostać pobrane.

getCandidateAds() zwrotów:

• Reklamy kandydujące: k najlepszych reklam, które zostaną przekazane do generateBid(). Każda reklama składa się z:
  • URL renderowania: punkt końcowy do renderowania kreacji reklamy.
  • Metadane: metadane reklam po stronie kupującego dotyczące technologii reklamowych. Mogą to być na przykład informacje o kampanii reklamowej i kryteriach kierowania, takie jak lokalizacja i język. Metadane mogą zawierać opcjonalne uczenie się z wykorzystaniem ukrytych modeli, które jest potrzebne do przeprowadzania wnioskowania podczas ustalania stawek.
• Dodatkowe sygnały: usługa pobierania reklam może opcjonalnie zawierać dodatkowe informacje, takie jak dodatkowe elementy lub sygnały spamu, które mają być używane w generateBid().

Badamy inne metody udostępniania reklam do oceny, w tym udostępnianie ich w ramach wywołania SelectAdRequest. Takie reklamy można pobrać za pomocą pytania o stawkę RTB. Pamiętaj, że w takich przypadkach reklamy muszą być pobierane bez korzystania z sygnałów chronionych aplikacji. Spodziewamy się, że firmy technologiczne zajmujące się reklamami przed wybraniem najlepszej opcji przeanalizują kompromisy, w tym rozmiar odpowiedzi, opóźnienie, koszt i dostępność sygnałów.

Funkcja UDF generateBid()

Gdy pobierzesz zestaw reklam kandydujących i wstawki podczas pobierania, możesz przejść do ustalania stawek, które odbywa się w usłudze ustalania stawek kupującego. Usługa ta uruchamia UDF generateBid() dostarczony przez kupującego, aby wybrać reklamę, na którą ma być ustalona stawka, spośród reklam z najlepszej grupy k, a następnie zwraca ją wraz ze stawką.

generateBid() pobiera te informacje:

• Reklamy kandydujące: najlepsze k reklam zwrócone przez usługę wyszukiwania reklam.
• Sygnały dotyczące aukcji: sygnały po stronie sprzedawcy związane z konkretną platformą oraz informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym kontekstowe embeddingi) z SelectAdRequest.
• Dodatkowe sygnały: dodatkowe informacje, które są używane podczas określania stawek.

Implementacja generateBid() kupującego umożliwia:

• Featuryzacja: polega na przekształcaniu sygnałów w cechy do wykorzystania podczas wnioskowania.
• Wnioskowanie: generuje prognozy za pomocą modeli uczenia maszynowego, aby obliczać wartości takie jak przewidywany współczynnik klikalności i współczynnik konwersji.
• Ustalanie stawek: łączenie wartości wywnioskowanych z innymi danymi wejściowymi w celu obliczenia stawki dla reklamy kandydata.

generateBid() zwrotów:

• Reklama kandydata.
• Obliczona kwota stawki.

Pamiętaj, że generateBid() używane w reklamach promujących instalacje aplikacji i w reklamach remarketingowych to różne wartości.

W następnych sekcjach znajdziesz więcej informacji o funkcjach, wnioskowaniu i ustalaniu stawek.

Wyróżnianie

Sygnały aukcji mogą być przygotowywane przez generateBid() do funkcji. Te funkcje mogą być używane podczas wyciągania wniosków, aby przewidywać takie wartości jak współczynniki klikalności i konwersji. Badamy też mechanizmy ochrony prywatności, aby przesyłać niektóre z nich w raporcie o wyniku wyszukiwania, który służy do trenowania modeli.

Wnioskowanie

Podczas obliczania stawki często wykonuje się wnioskowanie na podstawie co najmniej jednego modelu uczenia maszynowego. Na przykład do obliczenia efektywnego eCPM często używa się modeli służących do przewidywania współczynników klikalności i konwersji.

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

Uogólnienie jest wykonywane w usłudze określania stawek kupującego. Może to wpływać na opóźnienie i koszt wnioskowania, zwłaszcza że akceleratory nie są jeszcze dostępne w procesorach TEE. Niektórzy klienci mogą stwierdzić, ż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 korzystają z bardzo dużych modeli, mogą rozważyć opcje takie jak czynniki modelu, aby zminimalizować koszty wnioskowania i opóźnienia w określaniu stawek.

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

Wdrażanie czynników modelu

Wcześniej omawialiśmy faktoryzację modelu. W momencie ustalania stawki stosuje się następujące podejście:

1. Podziel pojedynczy model na część prywatną (dane użytkownika) i jedną lub więcej części nieprywatnych (dane kontekstowe i dane reklamy).
2. Przesyłanie elementów nieprywatnych do generateBid(). Mogą one pochodzić z per_buyer_signals lub z elementów zaimplementowanych przez zespoły ds. technologii reklamowych na zewnątrz, które są przechowywane w usługach odzyskiwania danych w formie klucz-wartość, pobierane w momencie odzyskiwania i zwracane jako część dodatkowych sygnałów. Nie dotyczy to prywatnych elementów, ponieważ nie można ich pobrać spoza granicy prywatności.
3. W generateBid():
   1. Przeprowadzanie wnioskowania na modelach w celu uzyskania prywatnych wektorów użytkowników.
   2. Połącz prywatne zaszyfrowane reprezentacje użytkowników z reprezentacjami kontekstowymi z per_buyer_signals lub z nieprywatnymi reprezentacjami reklam i reprezentacjami kontekstowymi z usługi wyszukiwania, używając operacji takiej jak iloczyn punktowy. Jest to ostateczna prognoza, która może służyć do obliczania stawek.

Dzięki temu podejściu można wykonywać 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 stawkami otrzymanymi od wszystkich aktywnych kupujących są oceniane. Dane wyjściowe funkcji generateBid() są przekazywane do usługi aukcji sprzedawcy w celu uruchomienia funkcji scoreAd(), która uwzględnia tylko jedną reklamę naraz.scoreAd() Na podstawie wyniku sprzedawca wybiera zwycięską reklamę, którą zwraca do urządzenia w celu jej wyrenderowania.

Logika punktacji jest taka sama jak w procesie remarketingu Protected Audience i umożliwia wybranie zwycięzcy spośród kandydatów do remarketingu i instalacji aplikacji.Funkcja jest wywoływana raz dla każdej przesłanej reklamy kandydata w ramach aukcji Protected Audience. Więcej informacji znajdziesz w artykule Ustalanie stawek i aukcja.

Czas wykonywania kodu wyboru reklam

W propozycji kod wyboru reklamy w przypadku instalacji aplikacji jest określony w taki sam sposób jak w przypadku ścieżki remarketingu Protected Audience. Więcej informacji znajdziesz w artykule Konfigurowanie ustalania stawek i aukcji. Kod ustalania stawek będzie dostępny w tym samym miejscu w chmurze, które jest używane do remarketingu.

Raportowanie

Ta propozycja korzysta z tych samych interfejsów API do raportowania co propozycja raportowania Protected Audience (np. reportImpression(), która powoduje wysyłanie raportów o sprzedawcy i kupującym).

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

Na dłuższą metę badamy rozwiązania zapewniające ochronę prywatności, aby umożliwić trenowanie modeli na podstawie danych używanych w aukcjach chronionych bez wysyłania danych o użytkownikach na poziomie zdarzenia poza usługi działające na platformach TEE. Więcej informacji znajdziesz w jednym z naszych kolejnych wpisów.

W krótce udostępnimy tymczasowy sposób na wyeksportowanie danych z generateBid(). Poniżej przedstawiamy naszą wstępną propozycję, którą będziemy rozwijać (w tym wprowadzać w niej zmiany powodujące brak zgodności wstecznej) w odpowiedzi na opinie branży.

Oto jak to działa:

1. Firmy technologiczne zajmujące się reklamami definiują schemat danych, które chcą przesyłać.
2. W generateBid() tworzy on żądany ładunek wyjściowy.
3. Platforma sprawdza zgodność ładunku wyjściowego ze schematem i egzekwuje limity rozmiaru.
4. Platforma dodaje szum do danych wyjściowych.
5. Ładunek wyjściowy jest uwzględniany w raporcie o wynikach w formacie sieciowym, odbierany na serwerach dostawców usług reklamowych, dekodowany i używany do trenowania modelu.

Definiowanie schematu danych wyjściowych

Aby platforma mogła egzekwować zmieniające się wymagania dotyczące prywatności, dane wyjściowe muszą być ustrukturyzowane w sposób zrozumiały dla platformy. Firmy zajmujące się technologiami reklamowymi określą strukturę swoich danych wyjściowych, podając plik schematu JSON. Schemat ten będzie przetwarzany przez platformę i będzie traktowany jako poufny przez usługi określania stawek i aukcji, które korzystają z tych samych mechanizmów co inne zasoby technologii reklamowej, np. UDF-y i modele.

Udostępnimy plik CDDL, który definiuje strukturę pliku JSON. Plik CDDL będzie zawierać zestaw obsługiwanych typów cech (np. cech logicznych, liczb całkowitych, zbiorników itp.). Wersje będą przypisywane zarówno do pliku CDDL, jak i do dostarczonego schematu.

Na przykład ładunek wyjściowy, który składa się z pojedynczej cechy logicznej, a następnie z cechy zbiornika o rozmiarze 2, może wyglądać tak:

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

Szczegółowe informacje o obsługiwanych typach funkcji znajdziesz na GitHubie.

Tworzenie danych wyjściowych w generateBid()

Wszystkie sygnały chronionych aplikacji dla danego kupującego są dostępne dla jego generateBid() UDF. Po zdefiniowaniu funkcji technologie reklamowe tworzą ładunek w formacie JSON. Ten strumień danych będzie uwzględniony w raporcie o wynikach kupującego przesyłanym na serwery dostawców technologii reklamowych.

Alternatywą dla tego rozwiązania jest obliczenie wektora wyjściowego w funkcji reportWin() zamiast generateBid(). Każde podejście ma swoje wady i zalety. Ostateczną decyzję podejmiemy w odpowiedzi na opinie branży.

Weryfikowanie danych wyjściowych

Platforma zweryfikuje wszystkie dane wyjściowe utworzone przez technologię reklamową. Dzięki temu można mieć pewność, że wartości funkcji są prawidłowe dla swoich typów, że są spełnione ograniczenia rozmiaru oraz że osoby o złośliwych zamiarach nie próbują obejść ustawień prywatności przez umieszczenie dodatkowych informacji w danych wyjściowych.

Jeśli ładunek wyjściowy jest nieprawidłowy, zostanie po cichu odrzucony z danych wysyłanych do raportu o wygranach. Nie chcemy udostępniać informacji dotyczących debugowania osobom, które próbują obejść weryfikację.

Udostępnimy interfejs JavaScript API dla specjalistów ds. technologii reklamowych, aby zapewnić, że dane wyjściowe utworzone przez nich w generateBid() przejdą weryfikację na platformie:

validate(payload, schema)

Ten interfejs JavaScript API jest przeznaczony wyłącznie dla wywołujących, którzy chcą sprawdzić, czy określony ładunek danych przejdzie weryfikację platformy. Aby chronić się przed złośliwymi generateBid(), należy przeprowadzić rzeczywistą weryfikację na platformie.

Zanieczyszczenie ładunku wychodzącego

Platforma będzie wyciszać dane wyjściowe, zanim uwzględni je w raporcie o wygraniu. Początkowy próg szumu wynosi 1% i może się zmieniać z czasem. Platforma nie poda, czy konkretny ładunek wyjściowy został zafałszowany.

Metoda dodawania szumu:

1. Platforma wczytuje definicję schematu dla ładunku wyjściowego.
2. 1% z wyjściowych ładunków danych zostanie wybranych do zafałszowania.
3. Jeśli nie wybierzesz ładunku wyjściowego, zachowana zostanie cała wartość oryginalna.
4. Jeśli wybrano dane wyjściowe, wartość każdej cechy zostanie zastąpiona losową prawidłową wartością dla tego typu cechy (na przykład 0 lub 1 w przypadku cechy logicznej).

Przesyłanie, odbieranie i dekodowanie ładunku wyjściowego na potrzeby trenowania modelu

Walidowany, zafałszowany ładunek danych wyjściowych zostanie uwzględniony w argumentach funkcji reportWin() i przesłany na serwery technologii reklamowych kupującego poza granicą prywatności w celu trenowania modelu. Dane wyjściowe będą w formacie skompresowanym.

Szczegółowe informacje o formacie przesyłania danych dla wszystkich typów funkcji i samego ładunku wyjściowego znajdziesz na GitHubie.

Określanie rozmiaru ładunku wychodzącego

Rozmiar ładunku danych wychodzących w bitach zapewnia równowagę między użytecznością a minimalizacją danych. Wspólnie z branżą określimy odpowiedni rozmiar za pomocą eksperymentów. Podczas tych eksperymentów będziemy tymczasowo przekazywać dane bez ograniczeń rozmiaru bitów. Te dodatkowe dane wyjściowe 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: ograniczony rozmiarem pakiet danych wychodzących, który opisaliśmy do tej pory w tym dokumencie. Początkowo rozmiar tego ładunku wyjściowego będzie wynosił 0 bitów (co oznacza, że zawsze zostanie usunięty podczas weryfikacji).
   2. temporaryUnlimitedEgressPayload: tymczasowy pakiet danych wyjściowych o dowolnym rozmiarze na potrzeby eksperymentów dotyczących rozmiaru. Formatowanie, tworzenie i przetwarzanie tego ładunku wyjściowego odbywa się za pomocą tych samych mechanizmów co w przypadku egressPayload.
2. Każdy z tych ładunków wyjściowych będzie miał własny plik schematu JSON:egress_payload_schema.json i temporary_egress_payload_schema.json.
3. Udostępniamy protokół eksperymentu i zbiór danych do określania przydatności modelu przy różnych rozmiarach danych wyjściowych (np. 5, 10 i inne bity).
4. Na podstawie wyników eksperymentu określamy rozmiar danych wyjściowych z odpowiednim kompromisem między użytecznością a prywatnością.
5. Ustawiliśmy rozmiar egressPayload z 0 bitów na nowy rozmiar.
6. Po określonym okresie migracji usuwamy temporaryUnlimitedEgressPayload, pozostawiając tylko egressPayload w nowej wielkości.

Analizujemy dodatkowe zabezpieczenia techniczne, które pomogą w zarządzaniu tą zmianą (np. szyfrowanie egressPayload, gdy zwiększymy jego rozmiar z 0 bitów). Te informacje, wraz z harmonogramem eksperymentu i usunięciem temporaryUnlimitedEgressPayload, zostaną uwzględnione w późniejszej aktualizacji.

Następnie wyjaśnimy, jak w ramach eksperymentu można ustalić rozmiar egressPayload. Naszym celem jest współpraca z branżą w celu znalezienia rozmiaru, który zapewni równowagę między użytecznością a minimalizacją danych. Wynikiem tych eksperymentów będzie wykres, na którego osi X będzie rozmiar ładunku danych na potrzeby trenowania w bitach, a na osi Y – odsetek przychodów wygenerowanych przez model o takim rozmiarze w porównaniu z modelem bez ograniczeń rozmiaru.

Załóżmy, że trenujemy model pInstall, a nasze dane do trenowania to nasze dzienniki i zawartość temporaryUnlimitedegressPayload, które otrzymujemy, gdy wygrywamy aukcje. Protokół dotyczący technologii reklamowych obejmuje najpierw eksperymenty offline:

1. Określ architekturę modeli, których będą używać w przypadku chronionych sygnałów aplikacji. Na przykład musisz określić, czy chcesz użyć faktoryzacji modelu.
2. Zdefiniuj dane służące do pomiaru jakości modelu. Sugerowane dane to utrata AUC i strata logarytmiczna.
3. Określ zestaw cech, których będą używać podczas trenowania modelu.
4. Korzystając z tej architektury modelu, metryki jakości i zbioru cech trenowania, przeprowadzają badania polegające na wykluczaniu, aby określić użyteczność na bit w przypadku każdego modelu, którego chcą używać w PAS. Zalecany protokół badania ablacyjnego:
   1. Wytrenuj model z użyciem wszystkich funkcji i zmierz jego przydatność. Będzie to punkt odniesienia do porównania.
   2. W przypadku każdej cechy użytej do wygenerowania wartości referencyjnej trenuj model z użyciem wszystkich cech z wyjątkiem tej cechy.
   3. Zmierz uzyskaną użyteczność. Podziel deltę przez rozmiar cechy w bitach. Jest to oczekiwana użyteczność na bit tej cechy.
5. Określ rozmiary danych treningowych, które mogą być przydatne do eksperymentowania. Sugerujemy użycie [5, 10, 15, ..., size_of_all_training_features_for_baseline] bitów. Każdy z nich reprezentuje możliwy rozmiar dla egressPayload, który eksperyment będzie oceniać.
6. W przypadku każdego możliwego rozmiaru wybierz zestaw funkcji o rozmiarze nieprzekraczającym tego rozmiaru, który maksymalizuje użyteczność na bit na podstawie wyników badania polegającego na usunięciu części modelu.
7. Trenuj model dla każdego możliwego rozmiaru i oceniaj jego przydatność jako procent przydatności modelu bazowego trenowanego na podstawie wszystkich cech.
8. Wyniki należy przedstawić na wykresie, na którym oś X to rozmiar danych treningowych w bitach, a oś Y to odsetek przychodów wygenerowanych przez ten model w porównaniu z modelem bazowym.

Następnie firmy technologiczne zajmujące się reklamami mogą powtórzyć kroki 5–8 w eksperymentach z ruchu na żywo, korzystając z danych funkcji przesyłanych za pomocą temporaryUnlimitedEgressPayload. Firmy z branży technologii reklamowych mogą udostępniać wyniki eksperymentów offline i z ruchu na żywo w Piaskownicy prywatności, aby ułatwić podjęcie decyzji o rozmiarze egressPayload.

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

środki ochrony danych;

Dane wychodzące będą chronione za pomocą wielu mechanizmów, w tym:

1. Zarówno egressPayload, jak i temporaryUnlimitedEgressPayload zostaną zastąpione szumem.
2. W celu minimalizacji i ochrony danych temporaryUnlimitedEgressPayload będzie dostępny tylko przez czas trwania eksperymentów dotyczących rozmiaru, w których określimy odpowiedni rozmiar dla egressPayload.

Uprawnienia

Kontrola użytkownika

• Proponujemy, aby użytkownicy widzieli listę zainstalowanych aplikacji, które przechowują co najmniej 1 ochronny sygnał aplikacji lub listę niestandardowych odbiorców.
• Użytkownicy mogą blokować aplikacje i usuwać je z tej listy. Blokowanie i usuwanie:
  • Usuwa wszystkie sygnały chronionych aplikacji i listy odbiorców powiązane z aplikacją.
  • Uniemożliwia aplikacjom przechowywanie nowych sygnałów chronionych aplikacji i list niestandardowych odbiorców
• Użytkownicy mogą całkowicie zresetować interfejs Protected App Signals API i Protected Audience API. W takim przypadku wszystkie istniejące sygnały chronionych aplikacji i listy odbiorców na urządzeniu zostaną usunięte.
• Użytkownicy mogą całkowicie zrezygnować z używania Piaskownicy prywatności na Androidzie, w tym 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ątkach: SECURITY_EXCEPTION.

Uprawnienia i kontrola aplikacji

Proponowane zmiany mają zapewnić aplikacjom kontrolę nad sygnałami chronionych aplikacji:

• Aplikacja może zarządzać powiązaniami za pomocą sygnałów chronionych aplikacji.
• Aplikacja może przyznać zewnętrznym platformom reklamowym uprawnienia do zarządzania sygnałami aplikacji chronionej w jej imieniu.

Ustawienia platformy reklamowej

W tej propozycji opisujemy sposoby, w jakie firmy technologiczne zajmujące się reklamami mogą kontrolować sygnały z chronionych aplikacji:

• Wszystkie technologie reklamowe muszą być zarejestrowane w Piaskownicy prywatności i mieć domenę „site” lub „origin” pasującą do wszystkich adresów URL sygnałów chronionych aplikacji.
• Firmy technologiczne zajmujące się reklamami mogą współpracować z aplikacją lub pakietem SDK, aby udostępniać tokeny weryfikacyjne, które są używane do weryfikacji tworzenia chronionych sygnałów aplikacji. Gdy ten proces jest delegowany do partnera, utworzenie sygnału chronionej aplikacji może zostać skonfigurowane tak, aby wymagało potwierdzenia przez technologię reklamową.