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 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 z tego 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ą zdefiniowane 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ę.

Oto ogólny przegląd sposobu działania wskaźników Protected App Signals w reklamach promujących 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, dostawcy technologii reklamowych wybierają sygnały, przechowując zdarzenia aplikacji zdefiniowane przez dostawcę technologii reklamowych, aby wyświetlać trafne reklamy za pomocą interfejsu Protected App Signals API. Te zdarzenia są przechowywane w chronionym miejscu na urządzeniu, podobnie jak w przypadku odbiorców niestandardowych, i przed wysłaniem z urządzenia są szyfrowane, aby mogły być odszyfrowywane tylko przez usługi licytacji i aukcji działające w środowiskach zaufanej realizacji z odpowiednimi zabezpieczeniami i kontrolą prywatności na potrzeby licytacji i oceny reklam.
• Kodowanie sygnałów: sygnały są przygotowywane zgodnie z harmonogramem przez niestandardową logikę technologiczną reklam. 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 momentu wysłania na aukcję.
• Wybór reklam: aby wybrać odpowiednie reklamy dla użytkownika, sprzedawca przesyła zaszyfrowany ładunek za pomocą chronionych sygnałów aplikacji i konfiguruje chronioną aukcję. W aukcji logika niestandardowa kupującego przygotowuje sygnały z aplikacji chronionej wraz z danymi kontekstowymi dostarczanymi przez wydawcę (dane te są zwykle udostępniane w żądaniu reklamy OpenRTB), 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 z zabezpieczonej aplikacji i danych kontekstowych dostarczanych przez wydawcę, aby projektować funkcje dostosowane 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 k reklam do ustalania stawek.
  • Określanie stawek: logika określania stawek przez kupujących przygotowuje dane kontekstowe dostarczane przez wydawcę i sygnały z aplikacji chronionej, aby opracować funkcje, które są używane jako dane wejściowe do modeli uczenia maszynowego kupujących w celu wnioskowania i określania stawek za reklamy kandydujące w ramach zaufanych granic zapewniających ochronę prywatności. Kupujący zwróci wybraną reklamę sprzedawcy.
  • Ocena sprzedawcy: sprzedawcy używają niestandardowej logiki oceny do oceny reklam przesłanych przez kupujących biorących udział w programie i wybierają reklamę, która zostanie przesłana z powrotem do aplikacji w celu jej renderowania.
• Raporty: uczestnicy aukcji otrzymują odpowiednie raporty o zwycięstwach i porażkach. Badamy mechanizmy ochrony prywatności, które umożliwiłyby uwzględnienie 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 tylko usługi ustalania stawek i aukcji działające w zaufanym środowisku wykonania z odpowiednimi zabezpieczeniami i kontrolą prywatności mogły je odszyfrować na potrzeby ustalania stawek i oceny reklam. 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 obecności sygnałów. Logika niestandardowa technologii reklamowej ma chroniony dostęp do swoich sygnałów, aby tworzyć funkcje, które służą do wyboru reklam w ramach chronionej aukcji.

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 niestandardowych list odbiorców. 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 danych 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ę technologią reklamową:

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 zakodowanym w standardzie 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, zablokowano jej korzystanie z interfejsu Protected App Signals API lub użytkownik usunął 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 poprzez zapewnienie 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.

Te 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.

Przechowywane sygnały są automatycznie powiązane z aplikacją wykonującą żądanie pobierania oraz z odbiorcą żądania (czyli „witryną” lub „źródłem” zarejestrowanej technologii reklamowej) oraz z czasem utworzenia żądania. Wszystkie sygnały są przechowywane w imieniu zakwalifikowanej do Piaskownicy prywatności technologii reklamowych, a adres URI „site”/„origin” musi być zgodny z danymi takiej technologii. Jeśli zażądanie wysyłane przez technologię reklamową nie jest zakwalifikowane, żądanie jest odrzucane.

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 wejść, pierwsze wyjść”. 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 przechowywanych sygnałów i zdarzeń dotyczących poszczególnych aplikacji. 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 następnie kompresuje je w ramach limitu na kupującego. Następnie ładunek jest szyfrowany w ograniczonych granicach pamięci urządzenia chronionego, 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 aukcji chronionej (interfejs Ad Selection API) prowadzonej w enklawie Trusted Execution Environment (TEE). 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 korzysta z podobnego procesu wyboru reklam do tego, który jest używany w propozycji 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 w usługach określania stawek i aukcji działających w TEE. W aukcjach na urządzeniu dostęp do sygnałów z chronionych aplikacji nie jest obsługiwany.

Proces wyboru reklamy wygląda tak:

1. Pakiet SDK sprzedawcy wysyła na urządzenie zaszyfrowany ładunek sygnałów z ochrony 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 programie.
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 inicjowany jest raport.

Rozpoczynanie 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 licytowania i aukcji na urządzeniach z Androidem.

Aby rozpocząć wybór reklam, 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 dostarczanych przez wydawcę i sygnałów z aplikacji chronionej, aby wybrać stawkę i zastosować ją do odpowiednich reklam dla żą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 kandydatów najlepszych k 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 ustalania stawek 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 ustalania stawek kupującego.
4. Usługa określania stawek kupującego uruchamia UDF generateBid(), który 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 k reklam i obliczania ich stawek.

Zanim przyjrzymy się bliżej niektórym elementom, warto zwrócić uwagę na ważne informacje o architekturze TEE podane na tym diagramie.

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 przez 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 umożliwi technicznym specjalistom ds. reklam odczytywanie danych z tej usługi par klucz-wartość w ramach 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 architektura, 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 następującą strukturę:

1. Podziel model na element prywatny (dane użytkownika) i jeden lub więcej elementów nieprywatnych (dane kontekstowe i dane reklamy).
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 od technologii reklamowych mogą tworzyć modele dla elementów nieprywatnych, a potem materializować wbudowane elementy z tych modeli w usługach klucz-wartość usługi Ad Retrieval Service. 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 parametrów 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 określania stawek przez kupującego jest odpowiedzialna za tworzenie danych żądania, które zostaną wysłane do usługi pobierania reklam w celu pobrania najlepszych k reklam kandydatów.

prepareDataForAdRetrieval() pobiera te informacje:

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

prepareDataForAdRetrieval() wykonuje 2 działania:

• Featuryzacja: jeśli potrzebne jest wnioskowanie na etapie wyszukiwania, usługa przekształca sygnały wejściowe 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 na potrzeby wyszukiwania: jeśli potrzebne są prognozy wyszukiwania, wywołuje usługę wnioskowania, używając tych funkcji, i otrzymuje prywatny embedding na potrzeby prognozowania wyszukiwania.

prepareDataForAdRetrieval() zwrotów:

• Protected App Signals: dane sygnałów wybrane przez firmę zajmującą się technologią reklamową.
• Sygnały dotyczące aukcji: sygnały po stronie sprzedawcy, które są specyficzne dla danej platformy, 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 wstępnie przetworzone dane, 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 uniwersalny ciąg znaków getCandidateAds().

Funkcja UDF getCandidateAds()

getCandidateAds() działa w ramach usługi pobierania reklam. Otrzymuje ono żądanie utworzone przez prepareDataForAdRetrieval() w usłudze określania stawek kupującego. Usługa wykonuje getCandidateAds(), która pobiera kandydatów na najlepsze 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 firmę zajmującą się technologią reklamową.
• Sygnały dotyczące aukcji: sygnały po stronie sprzedawcy, które są specyficzne dla danej platformy, 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 wstępnie przetworzone dane, pobrane z usługi wnioskowania.

getCandidateAds():

1. Pobierz początkowy zestaw reklam kandydujących: pobieranie za pomocą kryteriów kierowania, takich jak język, lokalizacja, typ reklamy, rozmiar reklamy czy budżet, aby odfiltrować reklamy kandydujące.
2. Pobieranie zaszyfrowanych danych: jeśli do prognozowania na czas pobierania danych w celu wybrania najlepszych k elementów potrzebne są zaszyfrowane dane z usługi klucz-wartość, muszą one zostać pobrane z tej usługi.
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 na potrzeby 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ściowe przekazywane za pomocą danych wejściowych dodatkowych sygnałów.
• Wszystkie nieprywatne technologie reklamowe z wbudowanymi funkcjami zostały zmaterializowane z ich serwerów do usługi klucz-wartość usługi wyszukiwania reklam.

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 dane z usługi klucz-wartość, należy je pobrać.

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, związane z technologią reklamową. 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 rozmowy telefonicznej 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 będą oceniać kompromisy przed wybraniem najlepszej opcji, biorąc pod uwagę m.in. 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, które są specyficzne dla danej platformy, oraz informacje kontekstowe, takie jak auction_signals i per_buyer_signals (w tym kontekstowe embeddingi) z SelectAdRequest.
• Dodatkowe sygnały: dodatkowe informacje używane podczas określania stawek.

Implementacja generateBid() kupującego umożliwia 3 rzeczy:

• Featuryzacja: przekształca sygnały 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 2 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 uogólniania do przewidywania takich 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, który będzie wykorzystywany 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 rzeczywistego 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.

Wyciąganie wniosków jest wykonywane w usłudze określania stawek kupującego. Może to wpływać na opóźnienia i koszty 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 przez 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. Przekaż elementy niebędące prywatne do generateBid(). Mogą one pochodzić z per_buyer_signals lub z elementów zaimplementowanych przez technologie reklamowe 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. Wykonywanie wnioskowania na podstawie modeli w celu uzyskania prywatnych wektorów osadzania 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órej można użyć do obliczenia stawek.

Dzięki temu podejściu można wykonywać wnioskowanie w momencie określania stawek na podstawie modeli, które 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 kupujących biorących udział w aukcji 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 obrębie procesu remarketingu Protected Audience. Więcej informacji znajdziesz w artykule Konfigurowanie określania 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 dotycząca raportowania Protected Audience (np. reportImpression(), która powoduje wysyłanie raportów o sprzedawcach i kupujących).

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 ad-tech. 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 danych używanych w licytacjach chronionych bez wysyłania danych użytkowników na poziomie zdarzenia poza usługi działające w kontenerach 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() użytkownik tworzy wybrany ł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 wyniku 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, ładunki 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 w formacie 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 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 ładunku wyjściowego

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. Rzeczywista weryfikacja musi być przeprowadzana na platformie, aby chronić przed złośliwymi generateBid() UDF.

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 danych wyjściowych.
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 i zaszyfrowany ł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 formatach transmisji danych dla wszystkich typów funkcji i dla samego ładunku wyjściowego znajdziesz na GitHubie.

Określanie rozmiaru ładunku wychodzącego

Rozmiar ładunku wyjściowego 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 ograniczenia 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: Payload wychodzący o ograniczonym rozmiarze, 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 nieograniczonym 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 może wyglądać protokół eksperymentu służący do określenia rozmiaru 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ół dla dostawców 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 wyłączeniu poszczególnych elementów, aby określić użyteczność na bit w przypadku każdego modelu, którego chcą użyć w PAS. Zalecany protokół badania ablacyjnego:
   1. Wytrenuj model z użyciem wszystkich funkcji i zmierz użyteczność. 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 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 zostanie oceniony w eksperymencie.
6. W przypadku każdego możliwego rozmiaru wybierz zestaw funkcji o rozmiarze równym temu rozmiarowi lub mniejszym, który maksymalizuje użyteczność na bit na podstawie wyników badania ablacjonalnego.
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 wartością bazową.

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 swoich eksperymentów z użyciem ruchu offline i w czasie rzeczywistym w Piaskownicy prywatności, aby ułatwić podjęcie decyzji o rozmarze 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ą różnych mechanizmów, w tym:

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

Uprawnienia

Kontrola użytkownika

• Proponujemy, aby użytkownicy mieli dostęp do listy 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 Protected App Signals i niestandardowe 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ą wyczyszczone.
• 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 chronionych aplikacji:

• Wszyscy dostawcy technologii reklamowych muszą zarejestrować się w Piaskownicy prywatności i podać domenę „site” lub „origin”, która jest zgodna ze wszystkimi adresami 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 dostawcę technologii reklamowych.