Oferta podlega procesowi rejestracji w Piaskownicy prywatności oraz zaświadczeń. Więcej informacji na temat atestów znajdziesz tutaj: klikając podany link do atestu. Kolejne aktualizacje tej oferty pakietowej opisują wymagania dotyczące dostępu do tego systemu.
Reklamy promujące instalacje aplikacji mobilnej, znane też jako reklamy pozyskiwania użytkowników, to rodzaj reklam, reklamy mobilnej, których celem jest zachęcenie użytkowników do pobrania aplikacji mobilnej. Te reklamy są zwykle wyświetlane użytkownikom na podstawie ich zainteresowań i danych demograficznych. często pojawiają się w innych aplikacjach mobilnych, takich jak gry, media społecznościowe i wiadomości. aplikacji. Gdy użytkownik kliknie reklamę promującą instalacje aplikacji, zostanie przekierowany bezpośrednio na stronę sklepu z aplikacjami, aby ją pobrać.
Przykład: reklamodawca, który chce zwiększyć liczbę instalacji na nowym urządzeniu mobilnym którzy oferują zamawianie jedzenia w Stanach Zjednoczonych, może kierować reklamy na użytkowników, lokalizacja znajduje się w Stanach Zjednoczonych i wcześniej świadczyła inne usługi dostawy jedzenia aplikacji.
Jest to zazwyczaj implementowane przez uwzględnienie kontekstowych, własnych i zewnętrznych sygnałów pochodzących od innych dostawców technologii reklamowych do tworzenia profili użytkowników na podstawie identyfikatorów wyświetlania reklam. Modele systemów uczących się związane z technologią reklamową wykorzystują te informacje jako dane wejściowe przy wyborze reklam które są trafne w odniesieniu do użytkownika i przy największym prawdopodobieństwie uzyskania konwersji.
Zaproponowaliśmy poniższe interfejsy API do obsługi skutecznych reklam promujących instalacje aplikacji, popraw prywatność użytkowników dzięki wyeliminowaniu zależności od takich identyfikatorów:
- Protected App Signals API: koncentruje się na pamięci masowej Opracowane z myślą o technologiach reklamowych funkcje, które odzwierciedlają potencjał użytkownika Twoich zainteresowań. Techniki reklamowe przechowują samodzielnie zdefiniowane sygnały zdarzeń w poszczególnych aplikacjach, np. dotyczące aplikacji instalacje, pierwsze uruchomienia, działania użytkowników (poziomy w grze, osiągnięcia) zakupów czy czasu spędzonego w aplikacji. Sygnały są zapisywane i przechowywane w celu ochrony przed wyciekiem danych. Są one dostępne tylko dla logika technologii reklamowych, która zapisała dany sygnał podczas aukcji chronionej działające w bezpiecznym środowisku.
- Ad Selection API: udostępnia interfejs API do konfigurowania i wykonywania Aukcja chroniona działająca w zaufanym środowisku wykonawczym (TEE) w którym specjaliści od technologii reklamowych pobierają kandydatów, przeprowadzają wnioskowanie, obliczają stawki punktację, aby wybrać „zwycięską” używająca chronionych sygnałów aplikacji informacjami kontekstowymi podawanymi przez wydawcę w czasie rzeczywistym.
Oto ogólne omówienie sposobu, w jaki chronione sygnały aplikacji trafne reklamy promujące instalacje aplikacji. W poniższych sekcjach tego dokumentu znajdziesz więcej o każdym z tych kroków.
- Selekcjonowanie sygnałów: gdy użytkownicy korzystają z aplikacji mobilnych, technologie reklamowe wybierają sygnały zapisując zdarzenia w aplikacji związane z technologią reklamową, aby wyświetlać odpowiednie reklamy za pomocą Interfejs Protected App Signals API. Te zdarzenia są przechowywane w chronionej pamięci na urządzeniu pamięci, podobnie jak w przypadku niestandardowych odbiorców, i są szyfrowane przed wysyłane z urządzenia w taki sposób, że tylko usługi określania stawek i usług aukcyjnych w zaufanych środowiskach wykonawczych z odpowiednimi zabezpieczeniami i ustawienia prywatności mogą odszyfrowywać je na potrzeby określania stawek i oceniania reklam.
- Kodowanie sygnałów: sygnały są przygotowywane w zaplanowanym tempie przez niestandardowe technologie reklamowe. Zadanie w tle na Androidzie wykonuje tę logikę, aby wykonywać kodowanie na urządzeniu, aby wygenerować ładunek chronionych sygnałów aplikacji. których można później używać w czasie rzeczywistym do wyboru reklamy w środowisku chronionym Aukcja. Ładunek jest bezpiecznie przechowywany na urządzeniu do czasu wysłania aukcji.
- Wybór reklamy: aby wybrać reklamy odpowiednie dla użytkownika, pakiety SDK sprzedawcy
wysyła zaszyfrowany ładunek Protected App Signals i konfiguruje
aukcja chroniona. Niestandardowa logika kupującego przygotowuje na aukcji element Protected
Sygnały aplikacji wraz z danymi kontekstowymi dostarczonymi przez wydawcę (danymi)
zwykle udostępniane w żądaniu reklamy z otwartym ustalaniem stawek w czasie rzeczywistym),
funkcje służące do wyboru reklamy (pobieranie reklam, wnioskowanie i stawka,
generacja). Podobnie jak w przypadku Protected Audience API, kupujący przesyłają reklamy do:
sprzedawcy do ostatecznej oceny w aukcji chronionej.
- Pobieranie reklam: kupujący używają chronionych sygnałów aplikacji oraz dane kontekstowe dostarczone przez wydawcę do inżynierii funkcji zgodnie z zainteresowaniami użytkownika. Te funkcje służą do dopasowywania reklam spełniających kryteria kierowania. Reklamy spoza budżetu są odfiltrowywane. Następnie do ustalania stawek wybiera się tys. pierwszych reklam.
- Określanie stawek: kupujący logika ustalania stawek niestandardowych przygotowuje dane kontekstowe przekazywane przez wydawcę i chronione sygnały aplikacji do opracowania; które są wykorzystywane jako dane wejściowe dla nabywców modeli systemów uczących się wnioskowania i ustalania stawek dla reklam kandydatów w ramach zaufanej ochrony prywatności granic. Następnie kupujący zwraca wybraną reklamę sprzedawcy.
- Ocena sprzedawcy: ocena sprzedawcy reklamy oparte na niestandardowej punktacji wyników przesłane przez kupujących biorących udział w programie i wybiorą do wysłania zwycięską reklamę. do aplikacji do renderowania.
- Raportowanie: uczestnicy aukcji otrzymują odpowiednie raporty o wygranych aukcjach. raportów strat. Badamy mechanizmy chroniące prywatność, aby uwzględniały dane do trenowania modelu w raporcie wygranej.
Oś czasu
| wersja przedpremierowa dla programistów | Beta | |||
|---|---|---|---|---|
| Funkcja | IV kw. 2023 r. | I kw. 2024 r. | II kw. 2024 r. | III kw. 2024 r. |
| Interfejsy API do selekcji sygnałów | Interfejsy API do przechowywania danych na urządzeniu |
Logika limitu miejsca na dane na urządzeniu Dzienne aktualizacje niestandardowej logiki na urządzeniu |
Nie dotyczy | Dostępne dla 1% urządzeń w wersji T+ |
| Serwer pobierania reklam w TEE | Najbardziej wartościowy zawodnik |
Dostępne w GCP Pomoc dotycząca Top K Produkcja UDF |
Dostępne w AWS Debugowanie, wskaźniki i monitorowanie na podstawie zgody użytkownika |
|
|
Usługa wnioskowania w TEE Obsługa uruchamiania modeli ML i używania ich do określania stawek w TEE |
W trakcie opracowywania |
Dostępne w GCP Możliwość wdrażania prototypowanie statycznych modeli ML przy użyciu Tensorflow i PyTorch |
Dostępne w AWS Opracowane wdrożenie modelu dla modeli Tensorflow i PyTorch Dane telemetryczne, debugowanie i monitorowanie na podstawie zgody |
|
|
Określanie stawek i obsługa aukcji w TEE |
Dostępne w GCP |
Integracja pobierania reklam z technologii PAS-B&A i TEE (z szyfrowaniem gRPC i TEE<>TEE) Obsługa pobierania reklam za pomocą ścieżki kontekstowej (obejmuje obsługę B&A<>K/V w TEE) |
Dostępne w AWS Raportowanie debugowania Debugowanie, wskaźniki i monitorowanie na podstawie zgody użytkownika |
|
Wybór chronionych sygnałów aplikacji
Sygnał to reprezentacja różnych interakcji użytkownika w aplikacji, które uznane przez technologie reklamowe za 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 otwarcie aplikacji, osiągnięcia, aktywność związana z zakupami lub w aplikacji. Chronione sygnały aplikacji są bezpiecznie przechowywane na urządzeniu i są są szyfrowane przed wysłaniem ich poza urządzenie, tak aby mogły działać tylko usługi działające w zaufanych środowiskach wykonawczych z odpowiednimi zabezpieczeniami a ustawienia prywatności mogą go odszyfrować na potrzeby określania stawek i oceniania reklam. Podobne do Custom Audience API, nie można odczytywać ani sprawdzać sygnałów przechowywanych na urządzeniu. przez aplikacje lub pakiety SDK, nie ma interfejsu API do odczytu wartości sygnałów, a interfejsy API są opracowane w taki sposób, aby uniknąć ujawniania obecności sygnałów. Niestandardowa logika technologii reklamowych ma i chroniony dostęp do wybranych sygnałów w celu rozwijania funkcji, które służą na podstawie wyboru reklamy w aukcji chronionej.
Interfejs Protected App Signals API
Interfejs Protected App Signals API obsługuje zarządzanie sygnałami za pomocą mechanizmu przekazywania podobnego do używanego w przypadku list niestandardowych odbiorców. Interfejs Protected App Signals API umożliwia przechowywanie sygnałów w postaci pojedynczego obiektu skalarnego jako ciąg czasowy. Sygnały ciągu czasowego mogą być wykorzystywane do przechowywania takich danych jak czas trwania sesji użytkownika. Sygnały ciągu czasowego służą do egzekwowania danego długości ruchu. Typ danych skalarnego czyli każdy element sygnału ciągu czasowego, jest tablicą bajtów. Każdy jest uzupełniana o nazwę pakietu aplikacji, w której zapisano oraz sygnaturę czasową utworzenia wywołania interfejsu API sygnału sklepu. Ten dodatek informacje są dostępne w kodzie JavaScript do kodowania sygnałów. Ten przykład pokazuje strukturę sygnałów należących do danej technologii reklamowej:
Ten przykład przedstawia sygnał skalarny i powiązany sygnał ciągu czasowego
z użytkownikiem adtech1.com:
- Sygnał skalarny z kluczem wartości w formacie base64 „
A1c” i wartość „c12Z”. Sygnał sklep został wywołany przez użytkownikacom.google.android.game_app1 czerwca 2023 r. - Lista sygnałów z kluczem „
dDE” które zostały stworzone przez dwa różne aplikacji.
Technologie reklamowe mają określoną ilość miejsca do przechowywania sygnałów na urządzeniu. Sygnały będą miały maksymalny czas TTL, który nie zostanie ustalony.
Chronione sygnały aplikacji są usuwane z pamięci, jeśli aplikacja generująca dane zostanie odinstalowana, nie może korzystać z interfejsu Protected App Signals API lub jeśli dane aplikacji jest usuwana przez użytkownika.
Interfejs Protected App Signals API składa się z tych części:
- interfejs API Java i JavaScript API do dodawania, aktualizowania i usuwania sygnałów.
- interfejsu JavaScript API do przetwarzania trwałych sygnałów w celu ich przygotowania. dalszy rozwój funkcji w czasie rzeczywistym podczas aukcji chronionej. w zaufanym środowisku wykonawczym (TEE).
Dodawanie, aktualizowanie i usuwanie sygnałów
Technologie reklamowe mogą dodawać, aktualizować i usuwać sygnały za pomocą interfejsu API fetchSignalUpdates().
Ten interfejs API obsługuje przekazywanie dostępu podobnie jak w przypadku niestandardowych list odbiorców z Protected Audience API
.
Aby dodać sygnał, reklamodawcy korzystający z technologii reklamowych kupującego, którzy nie mają pakietu SDK w aplikacjach, muszą:
współpracować z ekspertami ds. technologii reklamowych, którzy korzystają z urządzeń (np. z reklam mobilnych);
partnerów świadczących usługi pomiarowe (MMP) i platform dostawców (SSP). Aplikacja chroniona
Interfejs Signals API ma wspierać te technologie reklamowe przez dostarczanie elastycznych rozwiązań
Zarządzanie chronionymi sygnałami aplikacji przez włączenie na urządzeniu wywołań wywołujących
Tworzenie chronionego sygnału aplikacji w imieniu kupujących. Ten proces nazywa się
delegowanie zasobów i wykorzystuje interfejs fetchSignalUpdates() API. fetchSignalUpdates()
pobiera identyfikator URI i pobiera listę aktualizacji sygnałów. W ramach przykładu:
fetchSignalUpdates() wysyła żądanie GET do podanego identyfikatora URI, aby pobrać
listę aktualizacji, które mają zostać zastosowane do pamięci masowej sygnałów lokalnych. Punkt końcowy URL, który należy do
w odpowiedzi przesyła listę poleceń w formacie JSON.
Obsługiwane polecenia JSON:
- put: wstawia lub zastępuje wartość skalarną danego klucza.
- put_if_not_present: wstawia wartość skalarną dla danego klucza, jeśli nie ma podanej wartości przechowywanej wartości. Ta opcja może być przydatna na przykład do skonfigurowania eksperymentu dla danego użytkownika i nie zastępuj go, jeśli już był. ustawiony przez inną aplikację.
- dołączać: dodaje element do ciągu czasowego powiązanego z danym kluczem. Parametr maxSignals określa maksymalną liczbę sygnałów w czasie serii. Jeśli rozmiar zostanie przekroczony, wcześniejsze elementy zostaną usunięte. Jeśli klucz zawiera wartość skalarną, jest automatycznie przekształcana w ciąg czasowy.
- remove: usuwa treść powiązaną z danym kluczem.
{
"put": {
"A1c": "c12Z",
"dDE": "d23d",
},
"put_if_not_present": {
"aA9": "a1zfC3"
}
"append": {
"bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
},
"remove": ["c0D"]
}
Wszystkie klucze i wartości są wyrażone w Base64.
Wymienione powyżej polecenia umożliwiają wstawianie, zastępowanie i usuwanie semantyki sygnałów skalarnych oraz wstawiania, dołączania i zastępowania całych serii dla jako sygnały ciągu czasowego. Usuwanie i zastępowanie semantyki określonych elementów w atrybucie Podczas kodowania i kompresowania sygnał ciągu czasowego musi być zarządzany. np. podczas kodowania ignorowania wartości w ciągach czasowych, które są zastąpione lub skorygowane przez nowsze i usunięte w okresie kompresowania.
Przechowywane sygnały są automatycznie powiązane z aplikacją wykonującą żądania pobierania oraz respondenta żądania („site” lub „origin” usługi zarejestrowanych technologii reklamowych) oraz czas utworzenia żądania. Wszystkie sygnały są są przechowywane w imieniu technologii reklamowej zarejestrowanej w Piaskownicy prywatności, identyfikator URI „site”/„origin”, muszą być zgodne z danymi zarejestrowanych technologii reklamowych. Jeśli żądanie technologii reklamowych nie jest zarejestrowane, żądanie zostało odrzucone.
Limit miejsca na dane i jego usuwanie
Każda technologia reklamowa ma ograniczoną ilość miejsca na urządzeniu użytkownika do przechowywania sygnałów. Ten limit jest określany w przypadku danej technologii reklamowej, więc sygnały pochodzące z różnych aplikacji limit miejsca na dane. Jeśli limit zostanie przekroczony, system zwolni miejsce, usuwając wcześniejsze wartości sygnałów w pierwszej kolejności. Aby zapobiec usunięciu jest wykonywany zbyt często, system stosuje logikę grupowania, aby umożliwić w ograniczonej części limitu i aby zwolnić trochę miejsca, jest uruchamiana logika usunięcia.
Kodowanie na urządzeniu na potrzeby przesyłania danych
Aby przygotować sygnały do wyboru reklamy, na kupującego została zabezpieczona logika niestandardowa na kupującego z zapisanymi sygnałami i zdarzeniami związanymi z poszczególnymi aplikacjami. Uruchomione w tle zadanie systemu Android co godzinę na wykonanie logiki kodowania niestandardowego na kupującego, która jest pobierana do urządzenia. Kodowanie niestandardowe dla poszczególnych kupujących koduje sygnały dla poszczególnych aplikacji. kompresuje sygnały poszczególnych aplikacji do ładunku zgodnego z na kupującego. Następnie ładunek jest szyfrowany w granicach z chronioną pamięcią urządzenia, a potem do usług ustalania stawek i aukcji.
Specjaliści ds. technologii reklamowych określają poziom przetwarzania sygnałów przez własne logikę logiczną. Możesz na przykład dostosować rozwiązanie do wcześniejszego odrzucenia. oraz agregować podobne lub wzmacniające sygnały z różnych źródeł, w nowych sygnałach, które wykorzystują mniej miejsca.
Jeśli kupujący nie zarejestrował kodera sygnałów, sygnały nie są przygotowane. a do ustalania stawek i aukcji nie są przesyłane żadne sygnały wybrane na urządzeniu. usług Google.
Więcej informacji o limitach miejsca na dane, ładunku i żądań znajdziesz w przyszła aktualizacja. Przekażemy również dodatkowe informacje na temat udostępniać niestandardowe funkcje.
Proces wyboru reklamy
W przypadku tej oferty niestandardowy kod technologii reklamowych będzie miał dostęp tylko do aplikacji chronionej Sygnały w ramach aukcji chronionej (Ad Selection API) uruchomionej w TEE. Do są dostosowane do potrzeb konkretnego przypadku użycia, a reklamy kandydujące pobieranych w czasie rzeczywistym podczas aukcji chronionej. Kontrastuje to z remarketing, w którym reklamy kandydujące są znane przed aukcją.
Proces wyboru reklamy w tej ofercie pakietowej jest podobny jak w sekcji Protected Audience API oferty pakietowej wraz z aktualizacjami, które będą obsługiwać ten przypadek użycia. Wsparcie wymagania obliczeniowe związane z inżynierią cech i wyborem reklam w czasie rzeczywistym, aukcje reklam promujących instalacje aplikacji muszą być prowadzone w ramach określania stawek i aukcji działające w TEE. Dostęp do chronionych sygnałów aplikacji w trakcie ochrony Aukcje nie są obsługiwane w przypadku aukcji na urządzeniu.
Proces wyboru reklamy wygląda tak:
- Pakiet SDK sprzedawcy wysyła na urządzeniu zaszyfrowany ładunek plików chronionych Sygnały z aplikacji.
- Serwer sprzedawcy tworzy konfigurację aukcji i wysyła ją do zaufanego ustalania stawek i usługi aukcyjnej sprzedawcy, a także ładunek, by zainicjować przepływ pracy wyboru reklamy.
- System aukcji sprzedawcy przekazuje ładunek do z serwerów frontendowych dla zaufanych kupujących biorących udział w programie.
- Usługa określania stawek kupującego wykorzystuje logikę wyboru reklamy po stronie kupującego
- Zasada dotycząca punktacji SSP jest realizowana.
- Reklama jest renderowana, a rozpoczęte jest raportowanie.
Rozpocznij proces wyboru reklamy
Gdy aplikacja jest gotowa do wyświetlenia reklamy, pakiet SDK technologii reklamowych (zwykle SSP)
rozpoczyna proces wyboru reklamy, wysyłając wszelkie odpowiednie dane kontekstowe z:
wydawca i zaszyfrowane ładunki dla poszczególnych kupujących, które mają zostać uwzględnione w żądaniu;
zostanie przesłana na aukcję Protected za pomocą wywołania getAdSelectionData. To jest
tego samego interfejsu API, który został użyty do remarketingu i został opisany w sekcji Określanie stawek i
Oferta pakietowa integracji aukcji na urządzeniach z Androidem.
Aby rozpocząć wybór reklamy, sprzedawca przekazuje listę kupujących biorących udział w programie
i zaszyfrowany ładunek chronionych sygnałów aplikacji na urządzeniu. W związku z tym
informacji, serwer reklam po stronie sprzedającej przygotowuje SelectAdRequest dla
zaufanej usługi SellerFrontEnd.
Sprzedawca ustawia te informacje:
- Ładunek otrzymany z instancji
getAdSelectionData, która zawiera Chronione sygnały aplikacji. Sygnały kontekstowe wykorzystujące:
auction_config.auction_signals(dla informacje o aukcji)auction_config.seller_signals(w przypadku sygnałów sprzedawcy)auction_config.per_buyer_config["buyer"].buyer_signals(dla nabywców sygnały)
Listę kupujących uwzględnionych w aukcjach z zastosowaniem parametru
buyer_list.
Realizacja logiki wyboru reklamy po stronie kupującego
Ogólnie logika kupującego korzysta z danych kontekstowych dostarczanych przez wydawcy i chronionych sygnałów aplikacji w celu wyboru i zastosowania stawki do odpowiednich reklam. dla żądania reklamy. Platforma ta umożliwia kupującym zawężenie dużej puli do najtrafniejszych z nich (górne k), dla których obliczane są stawki zanim reklamy zostaną zwrócone sprzedawcy w celu ostatecznego wyboru.
Przed ustaleniem stawki kupujący zaczynają od dużej puli reklam. Jest za wolne do Obliczają stawkę dla każdej reklamy, więc kupujący muszą najpierw wybrać k najlepszych kandydatów z dużego basenu. Następnie kupujący muszą obliczyć stawki dla każdego kandydaci. Następnie te reklamy i stawki są zwracane sprzedawcy, by uzyskać ostateczną wyboru.
- Usługa BuyerFrontEnd otrzymuje żądanie reklamy.
- Usługa BuyerFrontEnd wysyła żądanie do usługi określania stawek kupującego.
Usługa określania stawek kupującego wykorzystuje funkcję UDF o nazwie
prepareDataForAdRetrieval(), tworząc prośbę o wystawienie tys. najlepszych kandydatów z Wyszukiwania reklam posprzedażna. Usługa określania stawek wysyła to żądanie do skonfigurowanego pobierania danych punktu końcowego serwera. - Usługa pobierania reklam uruchamia funkcję UDF
getCandidateAds(), która filtruje do zestawu 10 najpopularniejszych reklam kandydatów, które są wysyłane do usługę określania stawek. - Usługa ustalania stawek kupującego uruchamia funkcję UDF
generateBid(), która wybiera najlepszy kandydat, oblicza stawkę, a następnie zwraca ją do BuyerFrontEnd. posprzedażna. - Usługa BuyerFrontEnd zwraca reklamy i stawki sprzedawcy.
Jest kilka ważnych szczegółów dotyczących tego procesu, szczególnie jeśli chodzi o oraz jak platforma komunikuje się ze sobą i jak platforma zapewnia funkcje takie jak Możliwość tworzenia prognoz przez systemy uczące się do pobierania tys. najpopularniejszych reklam i obliczania ich stawek.
Zanim dokładnie przeanalizujemy niektóre kwestie, zauważymy kilka ważnych kwestii. uwagi architektoniczne dotyczące TEE na schemacie powyżej.
Usługa ustalania stawek kupującego zawiera wewnętrznie usługę wnioskowania. Technologie reklamowe Może przesyłać modele systemów uczących się do usługi ustalania stawek kupującego. Będziemy udostępnić interfejsy API JavaScript dla techników reklamowych do prognozowania lub generowania wektorów dystrybucyjnych z tych modeli z funkcji UDF działających w usłudze określania stawek kupującego. W przeciwieństwie do usługi pobierania reklam usługa określania stawek kupującego nie ma podanego parametru do przechowywania metadanych reklam.
Usługa Ad Retrieval Service zawiera wewnętrznie usługę par klucz-wartość. Technologie reklamowe powielania par klucz-wartość do tej usługi z własnych serwerów, poza do granicy prywatności. Udostępnimy interfejs API JavaScript, z którego mogą odczytywać się specjaliści ds. technologii reklamowych tę usługę klucz-wartość z funkcji UDF działających w usłudze Ad Retrieval Service. W przeciwieństwie do usługi określania stawek oferowanej przez kupującego usługa pobierania reklam nie zawiera usługę wnioskowania.
Jedną z głównych kwestii związanych z projektem jest to, jak skrócić czas pobierania i szacuje czas ustalania stawek. Odpowiedź może brzmieć w ramach rozwiązania rozkładania modelu na czynniki pierwsze.
Rozkład danych modelu na czynniki
Rozłożenie na czynniki modelu to technika, która umożliwia podział na model na kilka części, a następnie łączy je w prognozę. W w przypadku instalacji aplikacji, modele często korzystają z 3 rodzajów danych: danych, danych kontekstowych i danych o reklamach.
W przypadku bez rozkładu na czynniki pojedynczy model jest trenowany na wszystkich 3 rodzajach i skalowalnych danych. W przypadku rozkładu na czynniki dzielimy model na kilka części. Tylko element zawierający dane użytkownika jest wrażliwy. Oznacza to, że tylko model z element użytkownika musi być uruchamiany w granicach zaufania i w ramach ustalania stawek kupującego w usłudze wnioskowania.
Dzięki temu możliwe jest następujący projekt:
- Podziel model na element prywatny (dane użytkownika) i co najmniej jeden elementów nieprywatnych (danych kontekstowych i reklam).
- Opcjonalnie możesz przekazać niektóre lub wszystkie elementy, które nie są prywatne, jako argumenty do funkcji UDF.
którzy mają generować prognozy. Na przykład wektory dystrybucyjne kontekstowe są
przekazywane do funkcji UDF w
per_buyer_signals. - Opcjonalnie technologie reklamowe mogą tworzyć modele dla elementów, które nie są prywatne, a potem wektorów dystrybucyjnych z tych modeli do funkcji pobierania reklam w magazynie par klucz-wartość. UDF w usłudze pobierania reklam mogą pobierać te wektory dystrybucyjne w czasie działania aplikacji.
- Aby utworzyć prognozę podczas korzystania z funkcji UDF, połącz prywatne wektory dystrybucyjne z usługa wnioskowania z nieprywatnymi wektorami dystrybucyjnymi z argumentów funkcji UDF lub do magazynu z parami klucz-wartość przy użyciu operacji podobnej do iloczynu skalarnego. To już koniec z prognozą.
Dzięki temu możemy bardziej szczegółowo przyjrzeć się każdej funkcji UDF. Wyjaśnimy, jak robią, jak integrują się i jak mogą generować prognozy niezbędne wybrać k najlepszych reklam i obliczyć ich stawki.
Funkcja UDF prepareDataForAdRetrieval()
Obecny stan „prepareDataForAdRetrieval()” w usłudze określania stawek kupującego
odpowiada za utworzenie ładunku żądania, który zostanie wysłany do reklamy
usługa pobierania danych w celu pobrania tysięcy najpopularniejszych propozycji reklam.
prepareDataForAdRetrieval() pobiera te informacje:
- Ładunek na kupującego odebrany z
getAdSelectionData. Ten ładunek zawiera chronione sygnały aplikacji. - Sygnały kontekstowe
auction_signals(w przypadku informacji o aukcji) orazbuyer_signals(dla nabywców sygnały).
prepareDataForAdRetrieval() wykonuje 2 czynności:
- Nasycenie: jeśli wymagane jest wnioskowanie w czasie pobierania, przekształca się sygnały przychodzące do funkcji na potrzeby połączeń z usługą wnioskowania aby pobrać prywatne wektory dystrybucyjne do pobrania.
- Oblicza wektory dystrybucyjne do pobrania: jeśli prognozy pobierania są potrzebne, wywołuje usługę wnioskowania z użyciem powyższego i otrzymuje prywatny wektor dystrybucyjny na potrzeby prognoz czasu pobierania.
prepareDataForAdRetrieval() zwraca:
- Protected App Signals (Zabezpieczone sygnały aplikacji): ładunek sygnałów wybranych technicznie przez reklamy.
- Sygnały dotyczące aukcji: sygnały dotyczące konkretnej platformy.
informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym wektory dystrybucyjne kontekstowe) zSelectAdRequest. Jest to podobne do Protected Audience API. - Dodatkowe sygnały: dodatkowe informacje, takie jak pobrane wektory dystrybucyjne prywatne. z usługi wnioskowania.
To żądanie jest wysyłane do usługi pobierania reklam, która dopasowuje kandydatów
a następnie uruchamia funkcję UDF getCandidateAds().
Funkcja UDF getCandidateAds()
getCandidateAds() korzysta z usługi pobierania reklam. Otrzymuje żądanie
utworzone przez: prepareDataForAdRetrieval() w usłudze określania stawek kupującego.
usługa wykonuje polecenie getCandidateAds(), które pobiera najlepsze tys. kandydatów na
do określania stawek przez przekształcenie żądania w serię zestawów zapytań, pobrania danych
oraz wykonywanie niestandardowej logiki biznesowej i innych procesów pobierania.
getCandidateAds() pobiera te informacje:
- Protected App Signals (Zabezpieczone sygnały aplikacji): ładunek sygnałów wybranych technicznie przez reklamy.
- Sygnały dotyczące aukcji: sygnały dotyczące konkretnej platformy.
informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym wektory dystrybucyjne kontekstowe) zSelectAdRequest. Jest to podobne do Protected Audience API. - Dodatkowe sygnały: dodatkowe informacje, takie jak pobrane wektory dystrybucyjne prywatne. z usługi wnioskowania.
getCandidateAds() wykonuje te czynności:
- Pobierz początkowy zestaw propozycji reklam: pobrane na podstawie kryteriów kierowania. np. język, dane geograficzne, typ reklamy, rozmiar reklamy lub budżet, aby filtrować kandydatów i reklamy.
- Pobieranie wektorów dystrybucyjnych z pobierania: jeśli reprezentacje właściwościowe z usługi par klucz-wartość są które są niezbędne do prognozowania czasu pobierania dla najlepszych k wybranych osób, muszą one pobranych z usługi par klucz-wartość.
- Dobór najlepszych kandydatów (K): oblicz wynik podstawowy dla przefiltrowanego zbiór kandydatów na podstawie metadanych reklamy pobranych z magazynu par klucz-wartość, i informacjach wysyłanych z usługi określania stawek kupującego, aby wybrać na podstawie tego wyniku. Na przykład wynik może wskazywać na możliwość instaluje aplikację wyświetlaną w reklamie.
- Pobieranie wektorów dystrybucyjnych z określaniem stawek: jeśli wektory dystrybucyjne z usługi par klucz-wartość są potrzebne do wygenerowania prognoz czasu ustalania stawek, mogą być pobranych z usługi par klucz-wartość.
Pamiętaj, że wynikem reklamy może być wynik modelu prognozującego, który w przypadku
prognozuje prawdopodobieństwo zainstalowania aplikacji przez użytkownika. Tego rodzaju wynik
generowania wymaga pewnego rodzaju rozdzielania modelu na czynniki pierwsze:
getCandidateAds() korzysta z usługi pobierania reklam, a proces pobierania reklam
usługa nie ma usługi wnioskowania, prognozy mogą być generowane przez
kombinacja:
- wektory dystrybucyjne kontekstowe przekazywane z wykorzystaniem sygnałów związanych z aukcjami, dane wejściowe.
- Wektory dystrybucyjne prywatne przekazywane za pomocą danych wejściowych dodatkowych sygnałów.
- wszelkie technologie reklamowe w obszarach reklamowych, które nie są prywatne, pojawiły się na ich serwerach; do usługi Ad Retrieval Service.
Pamiętaj, że funkcja UDF generateBid() działająca w usłudze określania stawek kupującego może
stosują też własny sposób rozkładania modelu na potrzeby określania stawek.
i generowanie prognoz. Jeśli do tego potrzebne są wektory dystrybucyjne usługi klucz-wartość,
trzeba je pobrać teraz.
getCandidateAds() zwraca:
- Reklamy kandydatów: tys. najlepszych reklam do przekazania do organizacji
generateBid(). Każda reklama złożony:- URL renderowania: punkt końcowy renderowania kreacji reklamy.
- Metadane: metadane reklam związanych z zakupem i konkretnych technologii reklamowych. Na przykład to może zawierać informacje o kampanii reklamowej i kryteriach kierowania; np. lokalizacji i języka. Metadane te mogą zawierać opcjonalne informacje, wektory dystrybucyjne używane, gdy do uruchomienia wymagana jest składnia modelu wnioskowania podczas ustalania stawek.
- Dodatkowe sygnały: opcjonalnie usługa Ad Retrieval Service może zawierać
dodatkowe informacje, takie jak wektory dystrybucyjne lub sygnały spamu.
w aplikacji
generateBid().
Pracujemy nad innymi metodami dostarczania ocen reklam, w tym:
udostępnianie go w ramach wywołania funkcji SelectAdRequest. Takie reklamy mogą być
pobrane za pomocą pytania o stawkę RTB. Należy pamiętać, że w takich przypadkach reklamy muszą być
pobrane bez chronionych sygnałów aplikacji. Przewidujemy, że technologie reklamowe
Ocena kompromisów w przypadku wyboru najlepszej opcji, w tym ładunku odpowiedzi
rozmiaru, czasu oczekiwania, kosztów i dostępności sygnałów.
Funkcja UDF generateBid()
Po pobraniu zestawu reklam kandydujących oraz wektorów dystrybucyjnych podczas
pobieranie danych, możesz przejść do określania stawek, które będzie
wykorzystywane do określania stawek kupującego.
posprzedażna. Ta usługa korzysta z dostarczanego przez kupującego komponentu generateBid()
UDF, aby wybrać reklamę, dla której chcesz ustalić stawkę, spośród górnego k, a następnie zwrócić ją ze stawką.
generateBid() pobiera te informacje:
- Reklamy kandydatów: tys. najlepszych reklam zwróconych w wyniku pobierania reklam posprzedażna.
- Sygnały dotyczące aukcji: sygnały dotyczące konkretnej platformy.
informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym wektory dystrybucyjne kontekstowe) zSelectAdRequest. - Dodatkowe sygnały: dodatkowe informacje używane podczas ustalania stawek.
Implementacja generateBid() kupującego robi 3 czynności:
- Featuryzacja: przekształca sygnały w funkcje przeznaczone do użytku podczas wnioskowania.
- Wnioskowanie: generuje prognozy za pomocą modeli systemów uczących się, aby: obliczać wartości takie jak prognozowany współczynnik klikalności i współczynniki konwersji.
- Określanie stawek: połączenie wywnioskowanych wartości z innymi danymi wejściowymi, aby obliczyć wartość stawki dla danej reklamy.
generateBid() zwraca:
- Reklama kandydująca.
- Obliczona wysokość stawki.
Zwróć uwagę, że tag generateBid() używany w przypadku reklam promujących instalacje aplikacji oraz tag używany do
Reklamy remarketingowe są inne.
W sekcjach poniżej bardziej szczegółowo opisujemy featuryzację, wnioskowanie i określanie stawek szczegóły.
Featuryzacja
generateBid() może przygotować sygnały aukcji do funkcji. Funkcje te
mogą być używane podczas wnioskowania do prognozowania kliknięć
współczynnikach konwersji. Badamy też mechanizmy chroniące prywatność,
prześlij niektóre z nich w raporcie o wygranej do wykorzystania w trenowaniu modelu.
Wnioskowanie
Podczas obliczania stawki często następuje wnioskowanie na podstawie co najmniej jednego i modele systemów uczących się. Na przykład w obliczeniach efektywnego eCPM aby prognozować współczynniki klikalności i konwersji.
Klienci mogą udostępniać wiele modeli systemów uczących się
Implementacja generateBid(). W ramach platformy
generateBid(), aby klienty mogły wnioskować w czasie działania.
Proces wnioskowania odbywa się w usłudze ustalania stawek kupującego. Może to mieć wpływ na wnioskowanie czas oczekiwania i koszty, zwłaszcza że akceleratory nie są jeszcze dostępne w TEE. Niektórzy klienci spełnią ich potrzeby dzięki indywidualnym modelom działającym na do ustalania stawek przez kupującego. Niektórzy klienci – na przykład bardzo duże firmy modeli – warto rozważyć takie opcje jak rozkładanie na czynniki, aby zminimalizować koszt wnioskowania i czas oczekiwania w czasie ustalania stawki.
Więcej informacji o możliwościach wnioskowania, takich jak obsługiwane formaty modeli maksymalne rozmiary zostaną podane w przyszłej aktualizacji.
Wdrażanie rozkładu na czynniki w modelu
Wcześniej wyjaśniliśmy, na czym polega rozkładanie modelu na czynniki pierwsze. W momencie określania stawek określony podejście jest takie:
- Podziel pojedynczy model na prywatny fragment (dane użytkownika) i jeden lub bardziej nieprywatnych elementów (danych kontekstowych i danych reklamy).
- Przekaż elementy, które nie są prywatne, na urządzeniu
generateBid(). Mogą to byćper_buyer_signalslub z reprezentacji właściwościowych obliczonych na zewnątrz przez technologie reklamowe. powielać w magazynie par klucz-wartość usługi pobierania, pobierać przy pobieraniu i zwrotu w ramach dodatkowych sygnałów. Nie obejmuje to: wektory dystrybucyjne prywatne, ponieważ nie można ich pozyskiwać spoza prywatności i nie tylko. - W aplikacji
generateBid():- Przeprowadź wnioskowanie na podstawie modeli, aby uzyskać prywatne wektory dystrybucyjne użytkowników.
- Połącz wektory dystrybucyjne prywatnych z wektorami kontekstowymi z
per_buyer_signalslub nieprywatnych reklam i umieszczonych kontekstowo wektorów dystrybucyjnych z usługi pobierania przy użyciu operacji podobnej do iloczynu skalarnego. To jest ostateczna prognoza, która może służyć do obliczania stawek.
Dzięki tej metodzie można wnioskować w czasie ustalania stawek modele, które w innym przypadku byłyby zbyt duże lub zbyt wolne, by zrealizować je usługę określania stawek.
Logika oceny sprzedawcy
Na tym etapie reklamy ze stawkami otrzymanymi od wszystkich kupujących
. Dane wyjściowe funkcji generateBid() są przekazywane do usługi aukcyjnej sprzedawcy
wyświetlanie scoreAd(), które scoreAd() uwzględnia tylko jedną reklamę naraz. Siedziba
na podstawie oceny sprzedawca wybiera zwycięską reklamę i wróci do urządzenia
jak renderowanie.
Logika punktacji jest taka sama jak w przypadku remarketingu w ramach Protected Audience API i wybierać zwycięskie podejście w przypadku remarketingu i instalacji aplikacji. kandydatów.Funkcja jest wywoływana raz dla każdej przesłanej reklamy kandydata w funkcji aukcja chroniona. Przeczytaj wyjaśnienia dotyczące określania stawek i aukcji w przypadku .
Środowisko wykonawcze kodu wyboru reklamy
W ofercie pakietowej kod wyboru reklamy promującej instalację aplikacji jest określony w tej samej w procesie remarketingu w ramach Protected Audience API. Więcej informacji: Konfiguracja ustalania stawek i aukcji. Kod określania stawek zostanie dostępne w tej samej lokalizacji w chmurze co miejsce, w którym jest używane do remarketingu.
Raportowanie
Ta oferta pakietowa korzysta z tych samych interfejsów API do raportowania co raportowanie w ramach Protected Audience API
oferty pakietowej (np. reportImpression(), która powoduje, że platforma
wysyłania raportów o sprzedawcach i kupujących).
Jednym z typowych zastosowań raportów po stronie kupującego jest pobieranie danych treningowych. w przypadku modeli użytych podczas wyboru reklamy. Oprócz istniejących interfejsów API platforma udostępni specjalny mechanizm ruchu wychodzącego danych na poziomie zdarzenia z z serwerów technologii reklamowych. Te ładunki ruchu wychodzącego mogą zawierać określonych użytkowników i skalowalnych danych.
W dłuższej perspektywie szukamy rozwiązań chroniących prywatność, aby rozwiązać trenowanie modelu z użyciem danych używanych w aukcjach chronionych bez wysyłania danych na poziomie zdarzenia danych użytkowników spoza usług działających w TEE. Podamy dodatkowe informacje w późniejszej aktualizacji.
W najbliższym czasie zapewnimy tymczasowy sposób wychodzący zaszumionych danych
generateBid() Wstępną propozycję w tym zakresie znajdziesz poniżej, ale będziemy ją rozwijać.
(w tym możliwe zmiany powodujące brak zgodności wstecznej) w odpowiedzi na zmiany
opinie.
Technicznie to działa tak:
- Technologie reklamowe definiują schemat danych, które chcą przesyłać.
- W
generateBid()tworzy odpowiedni ładunek ruchu wychodzącego. - Platforma weryfikuje ładunek ruchu wychodzącego pod kątem schematu i egzekwuje i rozmiarów.
- Platforma dodaje szum do ładunku ruchu wychodzącego.
- Ładunek ruchu wychodzącego jest uwzględniony w raporcie wygranej w formacie przewodu otrzymanym z serwerów technologii reklamowych, zdekodowanych i używanych do trenowania modeli.
Definiowanie schematu ładunków ruchu wychodzącego
Aby platforma mogła egzekwować zmieniające się wymagania dotyczące prywatności, ładunki ruchu wychodzącego muszą być uporządkowane w sposób zrozumiały dla platformy. Technologie reklamowe zdefiniują struktury ładunków ruchu wychodzącego za pomocą pliku JSON schematu. Ten schemat będą przetwarzane przez platformę i będą traktowane jako poufne przez Określanie stawek i usługi aukcyjne korzystające z tych samych mechanizmów co inne zasoby technologii reklamowych. takich jak UDF i modele.
Udostępnimy plik CDDL, który określa strukturę tego kodu JSON. Plik CDDL będzie zawierał zestaw obsługiwanych typów funkcji (np. funkcji które są logiczne, liczby całkowite, zasobniki itd.). Zarówno plik CDDL, jak i plik podany schemat będzie miał wersję.
Na przykład ładunek ruchu wychodzącego składający się z jednej funkcji logicznej z dopiskiem funkcji zasobnika o 2 rozmiarze wyglądałaby np. 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 są dostępne na GitHubie.
Utwórz ładunki ruchu wychodzącego w regionie generateBid()
Wszystkie chronione sygnały aplikacji w przypadku danego kupującego są dostępne
Funkcja UDF generateBid(). Następnie specjaliści z branży technologii reklamowych tworzą ładunek
Format JSON. Ten ładunek wychodzący zostanie uwzględniony w raporcie o wygranym kupującego dotyczącym
na serwery technologii reklamowych.
Alternatywą dla tego projektu jest obliczanie wektora ruchu wychodzącego
reportWin() zamiast generateBid(). Każdy z nich wymaga kompromisów.
a my podejmiemy ostateczną decyzję na podstawie opinii użytkowników.
Zweryfikuj ładunek ruchu wychodzącego
Platforma zweryfikuje każdy ładunek ruchu wychodzącego utworzony przez technologię reklamową. Weryfikacja gwarantuje, że wartości cech są prawidłowe dla ich typów, spełnione są ograniczenia rozmiaru; oraz że hakerzy nie próbują ominąć ustawień prywatności podczas pakowania dodatkowych informacji w ładunkach ruchu wychodzącego.
Jeśli ładunek ruchu wychodzącego jest nieprawidłowy, zostanie dyskretnie odrzucony z danych wejściowych które trafią do raportu wygranych. Powodem jest to, że nie chcemy udostępniać funkcji debugowania informacje przekazywane niewłaściwemu podmiotowi, które próbują zweryfikować dane.
Udostępnimy interfejs JavaScript API dla techników reklamowych, aby zapewnić obsługę ładunku wychodzącego
Utwórz w generateBid() przejdzie weryfikację platformy:
validate(payload, schema)
Ten interfejs JavaScript API jest w pełni przeznaczony dla elementów wywołujących do określenia, czy określony ładunek
przejdzie weryfikację platformy. Trzeba przeprowadzić rzeczywistą weryfikację na platformie,
i chronić przed złośliwymi funkcjami UDF generateBid().
Szum ładunku wychodzącego
Platforma zaszumuje ładunki wychodzące przed uwzględnieniem ich w raporcie wygranej. Początkowy próg szumu wyniesie 1% i z czasem może się zmieniać. platforma nie wskaże, czy określony ładunek ruchu wychodzącego Zaszumiono.
Metoda szumu to:
- Platforma wczytuje definicję schematu dla ładunku ruchu wychodzącego.
- Do szumu zostanie wybrany 1% ładunków ruchu wychodzącego.
- Jeśli ładunek ruchu wychodzącego nie zostanie wybrany, cała pierwotna wartość zostanie zachowana.
- Jeśli wybierzesz ładunek ruchu wychodzącego, wartość każdej cechy zostanie zastąpiona
losową prawidłową wartość dla tego typu cechy (na przykład
0lub1w przypadku funkcja logiczna).
Wysyłanie, odbieranie i dekodowanie ładunku wychodzącego na potrzeby trenowania modelu
Zweryfikowany, zaszumiony ładunek ruchu wychodzącego zostanie uwzględniony w argumentach
reportWin() i przekazywane na serwery technologii reklamowych kupującego poza ustawieniami prywatności
granicę trenowania modelu. Ładunek ruchu wychodzącego będzie miał format przewodu.
Szczegółowe informacje o formacie przewodu dla wszystkich typów cech i ładunku wychodzącego są dostępne na GitHubie.
Określ rozmiar ładunku wychodzącego
Rozmiar ładunku wychodzącego w bitach odpowiada za narzędzia i minimalizację danych. Wspólnie z branżą określimy odpowiedni rozmiar za pomocą z eksperymentami. W trakcie tych eksperymentów będziemy tymczasowo danych ruchu wychodzącego bez ograniczeń rozmiaru w bitach. Te dodatkowe dane ruchu wychodzącego bez bitów ograniczenie rozmiaru zostanie usunięte po zakończeniu eksperymentów.
Metoda określania rozmiaru:
- Na początku w
generateBid()będziemy obsługiwać 2 ładunki ruchu wychodzącego:egressPayload: opisany do tej pory ładunek wychodzący o ograniczonym rozmiarze w tym dokumencie. Początkowo rozmiar tego ładunku wychodzącego wyniesie 0 bitów (co oznacza, że są one zawsze usuwane podczas weryfikacji).temporaryUnlimitedEgressPayload: tymczasowy ruch wychodzący o nieograniczonym rozmiarze do eksperymentów związanych z rozmiarem. Formatowanie, tworzenie i przetwarzanie tego ładunku ruchu wychodzącego używa tych samych mechanizmów coegressPayload.
- Każdy z tych ładunków ruchu wychodzącego będzie miał własny plik JSON schematu:
egress_payload_schema.jsonitemporary_egress_payload_schema.json. - Udostępniamy protokół eksperymentu i zestaw wskaźników do określania modelu narzędzie dla ładunków o różnych rozmiarach ruchu wychodzącego (na przykład 5, 10, ... bitów).
- Na podstawie wyników eksperymentu określamy rozmiar ładunku wychodzącego z kompromisów między użytecznością i prywatnością.
- Ustawiamy nowy rozmiar pliku
egressPayloadz 0 bitów. - Po upływie ustawionego okresu migracji usuwamy adresy
temporaryUnlimitedEgressPayload, pozostawiając jedynieegressPayloadw nowym rozmiarze.
Pracujemy nad dodatkowymi wymaganiami technicznymi dotyczącymi zarządzania tą zmianą.
(na przykład w celu szyfrowania pliku egressPayload, gdy zwiększymy jego rozmiar z 0 bitów).
Szczegóły, takie jak czas trwania eksperymentu i usunięcie
temporaryUnlimitedEgressPayload – zostanie uwzględniona w późniejszej aktualizacji.
Następnie objaśnimy możliwy protokół eksperymentu, który pozwoli określić
egressPayload Naszym celem jest współpraca z branżą nad znalezieniem rozmiaru, który będzie zrównoważony
i minimalizacji danych. Artefakt wytworzony przez te eksperymenty jest
na wykresie, na którym oś X to rozmiar ładunku treningowego w bitach, a
oś Y to odsetek przychodów wygenerowanych przez model w tej wielkości w porównaniu z
do punktu odniesienia
nieograniczonego rozmiaru.
Zakładamy, że trenujemy model pInstall, a nasze źródła danych treningowych
są nasze dzienniki i zawartość temporaryUnlimitedegressPayload,
które otrzymujemy,
gdy wygrywamy aukcje. Protokół dla technologii reklamowych najpierw wymaga obecności offline
eksperymenty:
- określić architekturę modeli, których będą używać z zabezpieczoną aplikacją; Sygnały. Będą musieli na przykład określić, czy użyj rozkładania modelu na czynniki pierwsze.
- Zdefiniuj wskaźnik do pomiaru jakości modelu. Sugerowane dane to strata AUC i logarytmiczna funkcja straty.
- Zdefiniuj zestaw funkcji, których będą używać podczas trenowania modelu.
- Korzystając z takiej architektury modelu, wskaźnika jakości i zestawu funkcji trenowania,
przeprowadź badania abulacji, aby określić wkład w użycie narzędzia na bit
model, którego chcą używać w PAS. Zalecany protokół badania ablacji
to:
- Wytrenuj model z wykorzystaniem wszystkich funkcji i zmierz użyteczność. to dla porównania.
- Dla każdej cechy użytej do utworzenia punktu odniesienia wytrenuj model, używając wszystkich funkcje oprócz tej funkcji.
- Mierz wynikową użyteczność. Podziel delta przez rozmiar obiektu w bitach; to oczekiwane narzędzie na bit dla tej funkcji.
- Określ rozmiary ładunków treningowych, które chcesz wykorzystać w eksperymentach. Śr
zaproponować [5, 10, 15, ...,
size_of_all_training_features_for_baseline] bity. Każdy z nich reprezentuje możliwy rozmiar elementuegressPayload, jaki oceniona część eksperymentu. - Dla każdego możliwego rozmiaru wybierz zestaw cech mniejszy lub równy mu który maksymalizuje użyteczność na bit, na podstawie wyników badania ablacji.
- Wytrenuj model dla każdego możliwego rozmiaru i oceń jego użyteczność procent przydatności modelu bazowego wytrenowanego na wszystkich cechach.
- Przedstawienie wyników na wykresie, na którym oś X to rozmiar trenowania ładunek w bitach, a oś Y to procent przychodów wygenerowanych przez w porównaniu z wartością bazową.
Następnie specjaliści ds. technologii reklamowych mogą powtórzyć kroki 5–8 w eksperymentach z ruchem w sieci,
dane wysłane przez temporaryUnlimitedEgressPayload. Technologie reklamowe mogą udostępniać
wyniki eksperymentów z ruchem w trybie offline i na żywo za pomocą Piaskownicy prywatności
aby poinformować o decyzji w sprawie rozmiaru pliku egressPayload.
Oś czasu tych eksperymentów oraz oś czasu ustawiania rozmiaru
egressPayload do wynikowej wartości, wykracza poza zakres tego dokumentu
a wkrótce wprowadzimy zmiany.
Środki ochrony danych
Stosujemy szereg zabezpieczeń do danych wychodzących, takich jak:
- Zarówno
egressPayload, jak itemporaryUnlimitedEgressPayloadbędą wyciszone. - Do minimalizacji i ochrony danych
temporaryUnlimitedEgressPayloadbędzie tylko na czas trwania eksperymentów z rozmiarem, podczas których określić prawidłowy rozmiar dla:egressPayload.
Uprawnienia
Kontrola użytkowników
- Propozycja ma na celu zapewnienie użytkownikom widoczności listy zainstalowanych aplikacji z co najmniej 1 chronionym sygnałem aplikacji lub niestandardową listą odbiorców.
- Użytkownicy mogą blokować aplikacje z tej listy i je z niej usuwać. Blokowanie i usuwanie
:
- Usuwa wszystkie chronione sygnały aplikacji i niestandardowe listy odbiorców powiązane z kontem aplikację.
- Uniemożliwia aplikacjom zapisywanie nowych chronionych i niestandardowych sygnałów aplikacji odbiorcy
- Użytkownicy mogą resetować chronione sygnały aplikacji i chronione sygnały Audience API. W takim przypadku każda dotychczasowa aplikacja chroniona Sygnały i niestandardowe listy odbiorców na urządzeniu zostaną usunięte.
- Użytkownicy mogą całkowicie zrezygnować z Piaskownicy prywatności na
Androida, w tym interfejsu Protected App Signals API i Protected Audience API.
API. W takim przypadku funkcje Protected Audience i Protected App Signals
Interfejsy API zwracają standardowy komunikat wyjątku:
SECURITY_EXCEPTION.
Uprawnienia aplikacji i kontrola nad nimi
Oferta ma na celu umożliwienie aplikacjom kontroli nad chronionymi sygnałami aplikacji:
- Aplikacja może zarządzać powiązaniami z chronionymi sygnałami aplikacji.
- Aplikacja może przyznawać zewnętrznym platformom technologii reklamowych uprawnienia do zarządzania Chronione sygnały aplikacji w jej imieniu.
Kontrola platformy technologii reklamowych
Przedstawiamy w nim sposoby, w jakie technologie reklamowe mogą kontrolować chronione sygnały aplikacji:
- Wszystkie technologie reklamowe muszą zarejestrować się w Piaskownicy prywatności i wskazać „witrynę” lub „origin” , która pasuje do wszystkich adresów URL w Protected App Signals.
- Techniki reklamowe mogą współpracować z aplikacjami lub pakietami SDK, aby dostarczać tokeny weryfikacyjne, służą do weryfikacji tworzenia chronionych sygnałów aplikacji. W trakcie tego procesu przekazanym partnerowi, tworzenie chronionego sygnału aplikacji można skonfigurować tak, wymagają potwierdzenia ze strony zespołu technicznego.