Ta oferta podlega procesowi rejestracji w Piaskownicy prywatności i poświadczeniom. Więcej informacji o atestach znajdziesz pod tym linkiem. Kolejne aktualizacje tej oferty opisują wymagania dotyczące dostępu do tego systemu.
Reklamy promujące instalacje aplikacji mobilnych, znane też jako reklamy mające na celu pozyskiwanie użytkowników, to typ reklamy mobilnej, który ma zachęcić użytkowników do pobrania aplikacji. Zwykle są one wyświetlane użytkownikom na podstawie ich zainteresowań i danych demograficznych, a często pojawiają się w innych aplikacjach mobilnych, takich jak gry, media społecznościowe i aplikacje z wiadomościami. Gdy użytkownik kliknie reklamę promującą instalacje aplikacji, zostanie przekierowany bezpośrednio do sklepu, z którego będzie mógł pobrać aplikację.
Na przykład reklamodawca, który chce zwiększyć liczbę instalacji nowej, mobilnej aplikacji do zamawiania jedzenia w Polsce, może kierować reklamy na użytkowników, którzy znajdują się w Polsce i którzy wcześniej korzystali z innych aplikacji umożliwiających zamawianie jedzenia.
Zwykle jest to realizowane przez uwzględnianie sygnałów kontekstowych, własnych i zewnętrznych technik reklamowych w celu utworzenia profili użytkowników na podstawie identyfikatorów wyświetlania reklam. Modele systemów uczących się działające w reklamach korzystają z tych informacji jako danych wejściowych, aby wybierać reklamy, które są trafne dla użytkownika i które mają największe szanse na doprowadzenie do konwersji.
Zaproponowaliśmy te interfejsy API, które wspierają skuteczne reklamy promujące instalacje aplikacji, które poprawiają prywatność użytkowników przez wyeliminowanie zależności od takich identyfikatorów użytkowników:
- Protected App Signals API: koncentruje się na przechowywaniu i tworzeniu funkcji za pomocą technologii reklamowych, które reprezentują potencjalne interesy użytkownika. Technologie reklam przechowują zdefiniowane samodzielnie sygnały zdarzeń w poszczególnych aplikacjach, np. instalacje aplikacji, pierwsze uruchomienia, działania użytkowników (poziomy w grze, osiągnięcia), aktywności związane z zakupami lub czas w aplikacji. Sygnały są zapisywane i przechowywane na urządzeniu, aby chronić przed wyciekiem danych, i są dostępne tylko w ramach logiki reklamowej, która przechowuje dany sygnał podczas aukcji chronionej w bezpiecznym środowisku.
- Ad Selection API: interfejs API do konfigurowania i przeprowadzania aukcji chronionej w Trusted Execution Environment (TEE), w którym technologie reklamowe pobierają kandydatów reklam, przeprowadzają wnioskowanie, obliczają stawki i oceniają, aby wybrać „zwycięską” reklamę przy użyciu chronionych sygnałów aplikacji oraz informacji kontekstowych dostarczanych w czasie rzeczywistym przez wydawcę.
Oto ogólne omówienie tego, jak chronione sygnały aplikacji pomagają w obsłudze trafnych reklam promujących instalacje aplikacji. Więcej informacji o każdym z tych kroków znajdziesz w poniższych sekcjach.
- Wybór sygnałów: gdy użytkownicy korzystają z aplikacji mobilnych, technologie reklamowe wybierają sygnały, przechowując zdefiniowane przez technologie reklamowe zdarzenia w aplikacji na potrzeby wyświetlania odpowiednich reklam za pomocą interfejsu Protected App Signals API. Zdarzenia te są przechowywane w chronionej pamięci na urządzeniu, podobnie jak niestandardowi odbiorcy. Przed wysłaniem tych zdarzeń są szyfrowane. Dzięki temu tylko usługi określania stawek i aukcji działające w zaufanych środowiskach wykonawczych z odpowiednimi ustawieniami zabezpieczeń i prywatności mogą odszyfrowywać je na potrzeby określania stawek i oceniania reklam.
- Kodowanie sygnałów: sygnały są przygotowywane z zaplanowaną częstotliwością za pomocą niestandardowej logiki technicznej reklam. Zadanie Androida w tle wykonuje tę logikę w celu wykonania kodowania na urządzeniu w celu wygenerowania ładunku chronionych sygnałów aplikacji, które można później wykorzystać w czasie rzeczywistym do wyboru reklamy podczas aukcji chronionej. Ładunek jest bezpiecznie przechowywany na urządzeniu do momentu wysłania do aukcji.
- Wybór reklamy: aby wybrać reklamy odpowiednie dla użytkownika, pakiety SDK sprzedawców wysyłają zaszyfrowany ładunek chronionych sygnałów aplikacji i konfigurują aukcję chronioną. Na aukcji niestandardowa logika kupującego przygotowuje chronione sygnały aplikacji wraz z dostarczonymi przez wydawcę danymi kontekstowymi (danymi, które zwykle są udostępniane w żądaniu reklamy Open-RTB) na potrzeby funkcji technicznych, które umożliwiają wybór reklamy (pobieranie reklam, wnioskowanie i generowanie stawek). Podobnie jak w przypadku chronionych odbiorców kupujący przesyłają reklamy do sprzedawcy, aby uzyskać ostateczną ocenę na aukcji chronionej.
- Pobieranie reklam: kupujący używają chronionych sygnałów aplikacji i danych kontekstowych dostarczanych przez wydawcę do funkcji technicznych związanych z zainteresowaniami użytkownika. Te funkcje służą do dopasowywania reklam spełniających kryteria kierowania. Reklamy spoza budżetu są odfiltrowywane. Następnie zostaje wybrane do ustalania stawek k najlepszych reklam.
- Ustalanie stawek: zasady ustalania stawek niestandardowych kupujących przygotowują dostarczone przez wydawcę dane kontekstowe i chronione sygnały aplikacji do opracowywania funkcji, które służą jako dane wejściowe dla modeli systemów uczących się kupujących do wnioskowania i określania stawek za reklamy kandydujące w ramach zaufanych granic chroniących prywatność. Kupujący zwraca wtedy wybraną reklamę sprzedawcy.
- Ocena sprzedawcy: reklamy z niestandardową oceną sprzedawcy przesłane przez kupujących biorących udział w programie i wybierają zwycięską reklamę, która ma być odesłana do aplikacji do renderowania.
- Raportowanie – uczestnicy aukcji otrzymują odpowiednie raporty o wygranych i stratach. Badamy mechanizmy chroniące prywatność, które umożliwią uwzględnianie danych na potrzeby trenowania modeli w raporcie o wygranych.
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 selekcji sygnałów | Interfejsy API pamięci masowej na urządzeniu |
Logika limitu miejsca na dane na urządzeniu Dzienne aktualizacje logiczne na urządzeniu |
Nie dotyczy | Dostępne dla urządzeń 1% T+ |
| Serwer pobierania reklam w TEE | Najbardziej wartościowy zawodnik (MVP) |
Dostępne w GCP Pomoc w zakresie produkcji najwyższego poziomu K UDF |
Dostępne w AWS Consented Debugging, Metrics, and Monitoring |
|
|
Usługa inferencyjna w TEE Obsługa modeli ML i używania ich do określania stawek w TEE |
W trakcie opracowywania |
Dostępne w GCP Możliwość wdrażania i tworzenia prototypów statycznych modeli ML za pomocą Tensorflow i PyTorch |
Dostępne w AWS Wdrożenie produkcyjnych modeli dla modeli Tensorflow i PyTorch Telemetria, debugowanie na podstawie zgody użytkownika i monitorowanie |
|
|
Określanie stawek i obsługa aukcji w TEE |
Dostępne w GCP |
Integracja pobierania reklam PAS-B&A i TEE (z gRPC i TEE<>szyfrowaniem TEE) Obsługa pobierania reklam za pomocą ścieżki kontekstowej (w tym B&A<>obsługa K/V w TEE) |
Dostępne w AWS Raportowanie debugowania Debugowanie z zgodą użytkownika, wskaźniki i monitorowanie |
|
Dobieranie chronionych sygnałów aplikacji
Sygnał to reprezentacja różnych interakcji użytkowników w aplikacji, które zostały określone przez technologię reklamową jako przydatne do wyświetlania trafnych reklam. Aplikacja i zintegrowany pakiet SDK mogą przechowywać lub usuwać chronione sygnały aplikacji zdefiniowane przez technologie reklamowe na podstawie aktywności użytkownika, np. otwarcia aplikacji, osiągnięcia, aktywności związanej z zakupami lub czasu w aplikacji. Chronione sygnały aplikacji są bezpiecznie przechowywane na urządzeniu i szyfrowane przed wysłaniem ich poza urządzenie. W ten sposób tylko usługi określania stawek i aukcji działające w zaufanych środowiskach wykonawczych z odpowiednimi zabezpieczeniami i ustawieniami prywatności mogą odszyfrowywać je na potrzeby określania stawek i oceniania. Podobnie jak w przypadku interfejsu Custom Audience API, aplikacje i pakiety SDK nie mogą odczytywać ani badać sygnałów przechowywanych na urządzeniu. Nie ma interfejsu API do odczytu wartości sygnałów, a interfejsy API zostały zaprojektowane tak, aby nie ujawniały obecności sygnałów. Niestandardowa logika technologii reklamowych zapewniła dostęp do wybranych sygnałów inżynierom funkcji, które służą jako podstawę do wyboru reklamy w ramach aukcji chronionej.
Interfejs Protected App Signals API
Interfejs Protected App Signals API obsługuje zarządzanie sygnałami za pomocą mechanizmu przekazywania dostępu podobnego do tego, który jest używany w przypadku list niestandardowych odbiorców. Interfejs Protected App Signals API umożliwia przechowywanie sygnałów w postaci pojedynczej wartości skalarnej lub ciągu czasowego. Sygnały ciągów czasowych mogą służyć do przechowywania takich danych jak czas trwania sesji użytkownika. Sygnały ciągów czasowych pozwalają egzekwować określoną długość za pomocą reguły „pierwsze wejście”, „pierwsze miejsce”. Typ danych sygnału skalarnego lub każdego elementu sygnału ciągu czasowego jest tablicą bajtów. Każda wartość jest wzbogacana o nazwę pakietu aplikacji, która zapisała sygnał, oraz sygnaturę czasową utworzenia wywołania interfejsu API sygnału magazynu. Te dodatkowe informacje są dostępne w kodzie JavaScriptu do kodowania sygnałów. Ten przykład pokazuje strukturę sygnałów należących do danej technologii reklamowej:
W tym przykładzie pokazano sygnał skalarny i sygnał ciągu czasowego powiązany z funkcją adtech1.com:
- Sygnał skalarny z kluczem wartości base64 „
A1c” i wartością „c12Z”. Magazyn sygnałów został aktywowany przez usługęcom.google.android.game_app1 czerwca 2023 r.. - Lista sygnałów z kluczem „
dDE”, które zostały utworzone przez 2 różne aplikacje.
Technologie reklamowe mają 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 pamięci, jeśli aplikacja generująca jest odinstalowana, zablokowano możliwość korzystania z interfejsu Protected App Signals API lub użytkownik wyczyścił dane aplikacji.
Interfejs Protected App Signals API składa się z tych elementów:
- interfejs API w języku Java i JavaScript – do dodawania, aktualizowania i usuwania sygnałów.
- JavaScript API do przetwarzania trwałych sygnałów w celu przygotowania ich do dalszej pracy w zakresie inżynierii 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 fetchSignalUpdates() API.
Ten interfejs API obsługuje przekazywanie dostępu podobne do przekazywania niestandardowych list odbiorców w ramach Protected Audience API.
Aby dodać sygnał, technologie reklamowe kupującego, które nie korzystają z pakietu SDK w aplikacjach, muszą współpracować z technikami reklamowymi, którzy są obecni na urządzeniu – takimi jak mobilni partnerzy świadczący usługi pomiarowe (MMP) i platformy dostawców reklam (SSP). Interfejs Protected AppSignals API ma na celu wspieranie tych technologii reklamowych, zapewniając elastyczne rozwiązania do zarządzania chronionymi sygnałami aplikacji przez umożliwienie osobom wywołującym urządzenia wywoływanie tworzenia chronionych sygnałów aplikacji w imieniu kupujących. Ten proces nazywany jest przekazywaniem dostępu i korzysta z interfejsu API fetchSignalUpdates(). 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 lokalnej pamięci sygnałów. Punkt końcowy URL, który należy do kupującego, odpowiada w odpowiedzi z listą poleceń w formacie JSON.
Obsługiwane polecenia JSON to:
- put: wstawia lub zastępuje wartość skalarną danego klucza.
- put_if_not_present: wstawia wartość skalarną do danego klucza, jeśli nie ma jeszcze żadnej wartości. Ta opcja może być przydatna, jeśli na przykład ustawisz identyfikator eksperymentu dla danego użytkownika i nie zastąpisz go, jeśli został już ustawiony przez inną aplikację.
- Join: dodaje element do ciągu czasowego powiązanego z danym kluczem. Parametr maxSignals określa maksymalną liczbę sygnałów w ciągu czasowym. Jeśli go przekroczy, wcześniejsze elementy zostaną usunięte. Jeśli klucz zawiera wartość skalarną, jest automatycznie przekształcany w ciąg czasowy.
- delete: 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 formacie Base64.
Wymienione powyżej polecenia umożliwiają wstawianie, zastępowanie i usuwanie semantyki sygnałów skalarnych oraz wstawianie, załączanie i zastępowanie pełnych ciągów czasowych w przypadku sygnałów ciągów czasowych. Semantykami usuwania i zastępowania określonych elementów ciągu czasowego należy zarządzać podczas procesu kodowania i kompresowania, na przykład podczas kodowania ignorowania wartości w ciągach czasowych, które zostały zastąpione lub poprawione przez nowsze, i usuwane podczas procesu kompresowania.
Zapisane sygnały są automatycznie powiązane z aplikacją, która wykonuje żądanie pobierania, oraz z użytkownikiem, który je wysyła (czyli z „witryną” lub „źródłową” zarejestrowanej technologii reklamowej) oraz z czasem utworzenia żądania. Wszystkie sygnały są przechowywane w imieniu technologii reklamowej zarejestrowanej w Piaskownicy prywatności. Identyfikator URI „witryna” i „źródło” musi być zgodny z danymi zarejestrowanych technologii reklamowych. Jeśli żądająca technologia reklamowa nie jest zarejestrowana, żądanie jest odrzucane.
Limit miejsca na dane i usuwanie
Każda technologia reklamowa ma ograniczoną ilość miejsca na urządzeniu użytkownika na przechowywanie sygnałów. Limit jest określany dla poszczególnych technologii reklamowych, więc sygnały pobierane z różnych aplikacji mają wspólny limit. Jeśli limit zostanie przekroczony, system zwalnia miejsce, usuwając wcześniejsze wartości sygnałów na podstawie pierwszego wejrzenia. Aby zapobiec zbyt częstemu przenoszeniu danych, system implementuje logikę grupowania, która umożliwia ograniczenie nadmiernej ilości limitu i zwolnienie dodatkowego miejsca po aktywowaniu logiki usuwania.
Kodowanie na urządzeniu na potrzeby transmisji danych
Aby przygotować sygnały do wyboru reklamy, logika niestandardowa kupującego zapewnia zabezpieczony dostęp do zapisanych sygnałów i zdarzeń w poszczególnych aplikacjach. Zadanie to jest uruchamiane w tle co godzinę w celu wykonania dla poszczególnych kupującego niestandardowego kodowania logiki pobranej na urządzenie. Logika niestandardowego kodowania konkretnego kupującego koduje sygnały dotyczące poszczególnych aplikacji, a następnie kompresuje sygnały dotyczące aplikacji do ładunku zgodnego z limitem na kupującego. Ładunek jest szyfrowany w granicach chronionej pamięci urządzenia, a następnie przesyłany do usług określania stawek i aukcji.
Technologie reklamowe definiują poziom przetwarzania sygnałów obsługiwany przez własne mechanizmy logiczne. Możesz na przykład dostosować rozwiązanie w taki sposób, aby odrzucało wcześniejsze sygnały i agregować 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, a żaden z selekcjonowanych sygnałów na urządzeniu nie jest wysyłany do usług określania stawek ani aukcji.
Więcej informacji o limitach miejsca na dane, ładunku i żądań udostępnimy w przyszłej aktualizacji. Przekażemy też dodatkowe informacje na temat udostępniania funkcji niestandardowych.
Proces wyboru reklamy
Dzięki tej ofercie niestandardowy kod technologii reklamowej ma dostęp do chronionych sygnałów aplikacji tylko w ramach interfejsu Protected aukcji (Ad Selection API) w teE. Aby jeszcze lepiej spełnić potrzeby związane z instalacją aplikacji, reklamy kandydujące są pobierane w ramach aukcji chronionej w czasie rzeczywistym. Odnosi się to do przypadków użycia remarketingu, w których reklamy kandydujące są znane jeszcze przed aukcją.
Ta oferta pakietowa korzysta z podobnego procesu wyboru reklamy co w przypadku propozycji Protected Audience (funkcja ochrony odbiorców) z aktualizacjami dostosowanymi do potrzeb zastosowania instalacji aplikacji. Ze względu na wymagania obliczeniowe związane z inżynierią cech i wyborem reklam w czasie rzeczywistym muszą być przeprowadzane aukcje reklam promujących instalacje aplikacji w przypadku usług określania stawek i aukcji działających w TEE. Dostęp do chronionych sygnałów aplikacji podczas aukcji zabezpieczonej nie jest obsługiwany w przypadku aukcji na urządzeniu.
Proces wyboru reklamy wygląda tak:
- Pakiet SDK sprzedawcy wysyła zaszyfrowany ładunek na urządzeniu w postaci chronionych sygnałów aplikacji.
- Serwer sprzedawcy tworzy konfigurację aukcji i wysyła ją wraz z zaszyfrowanym ładunkiem do usługi Zaufane określanie stawek i aukcji, aby zainicjować proces wyboru reklamy.
- Usługa określania stawek i aukcji sprzedawcy przekazuje ładunek do serwerów frontendowych zaufanych kupujących.
- Usługa określania stawek kupującego przeprowadza logikę wyboru reklamy po stronie kupującego.
- Systemy ocen po stronie sprzedaży są prowadzone.
- Reklama zostanie wyrenderowana i rozpocznie się raportowanie.
Rozpocznij proces wyboru reklamy
Gdy aplikacja jest gotowa do wyświetlenia reklamy, pakiet SDK technologii reklamowej (zwykle jest to platforma SSP) inicjuje proces wyboru reklamy, wysyłając od wydawcy odpowiednie dane kontekstowe oraz ładunki zaszyfrowane u kupujących, które mają być uwzględnione w żądaniu wysłania do aukcji chronionej za pomocą wywołania getAdSelectionData. Jest to ten sam interfejs API, który jest używany w remarketingu i opisany w ofercie pakietowej Integracja określania stawek i integracji aukcji na Androidzie.
Aby zainicjować wybór reklamy, sprzedawca przekazuje listę kupujących biorących udział w programie i zaszyfrowany ładunek chronionych sygnałów aplikacji na urządzeniu. Dzięki tym informacjom serwer reklam po stronie sprzedawcy przygotowuje SelectAdRequest dla swojej zaufanej usługiSellerFrontEnd.
Sprzedawca ustawia te ustawienia:
- Ładunek otrzymany z raportu
getAdSelectionData, który zawiera chronione sygnały aplikacji. Sygnały kontekstowe wykorzystują:
auction_config.auction_signals(informacje o aukcji)auction_config.seller_signals(na potrzeby sygnałów sprzedawcy)auction_config.per_buyer_config["buyer"].buyer_signals(na potrzeby sygnałów kupujących)
Lista kupujących uwzględnionych w aukcjach przy użyciu pola
buyer_list.
Wykonanie logiki wyboru reklamy po stronie kupującego
Ogólnie rzecz biorąc, niestandardowa logika kupującego korzysta z danych kontekstowych dostarczonych przez wydawcę i chronione sygnały aplikacji, aby wybierać i stosować stawkę do odpowiednich reklam w odpowiedzi na żądanie reklamy. Platforma umożliwia kupującym zawężenie dużej puli dostępnych reklam do tych najtrafniejszych (górne k), w przypadku których stawki są obliczane przed zwróceniem reklam sprzedawcy do ostatecznego wyboru.
Przed ustaleniem stawki kupujący zaczynają od dużej puli reklam. Obliczanie stawek za każdą reklamę jest zbyt wolne, więc kupujący najpierw muszą wybrać k najlepszych kandydatów z dużej puli. Następnie kupujący muszą obliczyć stawki dla każdego z tych k najlepszych kandydatów. Następnie te reklamy i stawki są zwracane sprzedawcy do ostatecznego 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 uruchamia funkcję UDF o nazwie
prepareDataForAdRetrieval(), która tworzy żądanie pobrania 10 najlepszych kandydatów z usługi pobierania reklam. Usługa określania stawek wysyła to żądanie do skonfigurowanego punktu końcowego serwera pobierania. - Usługa pobierania reklam korzysta z funkcji UDF
getCandidateAds(), która odfiltrowuje te reklamy do tylu reklam najczęściej wybieranych, które są przesyłane do usługi określania stawek kupującego. - Usługa określania stawek kupującego uruchamia funkcję UDF
generateBid(), która wybiera najlepszego kandydata, oblicza jej stawkę, a potem zwraca ją do usługi BuyerFrontEnd. - Usługa BuyerFrontEnd zwraca sprzedawcy reklamy i stawki.
Proces ten wymaga kilku ważnych szczegółów, zwłaszcza w odniesieniu do wzajemnych relacji między elementami oraz sposobu, w jaki platforma udostępnia takie funkcje jak możliwość generowania przez systemy uczące się prognoz dotyczących pobierania k najpopularniejszych reklam i obliczania ich stawek.
Zanim przyjrzymy się bliżej częściom tego zagadnienia, musimy pamiętać o kilku ważnych uwagach architektonicznych dotyczących TEE na diagramie powyżej.
Usługa określania stawek kupującego zawiera wewnętrznie usługę wnioskowania. Technologie reklamowe mogą przesyłać modele systemów uczących się do usługi określania stawek kupującego. Udostępnimy interfejsy API JavaScript dla technologii reklamowych, które umożliwią prognozowanie lub generowanie reprezentacji właściwościowych z tych modeli w ramach funkcji UDF działających w ramach usługi określania stawek kupującego. W odróżnieniu od usługi pobierania reklam usługa określania stawek przez kupującego nie oferuje usługi klucz-wartość, która służy do przechowywania metadanych reklam.
Usługa pobierania reklam obejmuje wewnętrznie usługę klucz-wartość. Technologie reklamowe mogą wykorzystywać w tej usłudze pary klucz-wartość z własnych serwerów spoza granic prywatności. Udostępnimy technikom reklamowym interfejs API JavaScript, który będzie odczytywać pary klucz-wartość z funkcji UDF w ramach usługi pobierania reklam. W przeciwieństwie do usługi określania stawek oferowanej przez kupującego usługa pobierania reklam nie zawiera usługi wnioskowania.
Jednym z głównych pytań jest to, jak prognozować czas pobierania i czas ustalania stawek. W obu przypadkach możesz zastosować rozwiązanie zwane rozkładaniem modelu na czynniki pierwsze.
Rozłożenie modelu na czynniki
Rozkład modeli to technika, która umożliwia rozbicie pojedynczego modelu na kilka części, a następnie łączenie ich w prognozę. W przypadku instalacji aplikacji modele często korzystają z 3 rodzajów danych: danych użytkownika, danych kontekstowych i danych reklam.
W przypadku nierozwiązanych na czynnikiach pojedynczy model jest trenowany na wszystkich 3 rodzajach danych. W tym przypadku dzielimy model na kilka części. Poufny jest tylko fragment danych użytkownika. Oznacza to, że tylko model z elementem użytkownika musi być uruchamiany w granicach zaufania w usłudze wnioskowania kupującego.
Umożliwia to następujący projekt:
- Podziel model na element prywatny (dane użytkownika) i co najmniej jeden element nieprywatny (dane kontekstowe i dane reklamy).
- Opcjonalnie możesz przekazać niektóre lub wszystkie elementy nieprywatne jako argumenty do funkcji UDF, która musi generować prognozy. Na przykład wektory dystrybucyjne kontekstowe są przekazywane do funkcji UDF w interfejsie
per_buyer_signals. - Opcjonalnie technologie reklamowe mogą tworzyć modele dla elementów nieprywatnych, a następnie materializować reprezentacje właściwościowe tych modeli w magazynie par klucz-wartość usługi Ad Retrieval Service. Funkcja UDF w usłudze pobierania reklam może pobierać te reprezentacje właściwości w czasie działania.
- Aby wygenerować prognozę w ramach funkcji UDF, połącz reprezentacje właściwościowe prywatne z usługi wnioskowania z reprezentacjami nieprywatnymi z argumentów funkcji UDF lub z magazynu par klucz-wartość z operacją taką jak iloczyn skalarny. To ostateczna prognoza.
Dzięki temu możemy bardziej szczegółowo przyjrzeć się każdej funkcji UDF. Wyjaśnimy, do czego służą, jak się wyświetlają i jak mogą generować prognozy niezbędne do wyboru k najlepszych reklam i obliczenia ich stawek.
Funkcja UDF prepareDataForAdRetrieval()
prepareDataForAdRetrieval() korzystający z usługi określania stawek kupującego odpowiada za utworzenie ładunku żądania, który będzie wysyłany do usługi pobierania reklam w celu pobrania k reklam kandydujących, które wygrały.
prepareDataForAdRetrieval() pobiera te informacje:
- Ładunek dla kupującego otrzymany z
getAdSelectionData. Ten ładunek zawiera chronione sygnały aplikacji. auction_signalssygnałów kontekstowych (informacje o aukcji) ibuyer_signals(na potrzeby pól sygnałów dla kupujących).
prepareDataForAdRetrieval() spełnia 2 czynności:
- Featuryzacja: jeśli potrzebne jest wnioskowanie na podstawie czasu pobierania, sygnały przychodzące są przekształcane w funkcje używane podczas wywoływania usługi wnioskowania w celu uzyskania prywatnych reprezentacji właściwościowych do pobierania.
- Oblicza prywatne reprezentacje właściwości na potrzeby pobierania: jeśli potrzebne są prognozy pobierania, wysyła wywołanie do usługi wnioskowania za pomocą powyższych funkcji i otrzymuje prywatny osadzanie na potrzeby prognoz czasu pobierania.
prepareDataForAdRetrieval() zwraca:
- Chronione sygnały aplikacji: ładunek sygnałów wybranych przez technologię reklamową.
- Sygnały związane z aukcjami: sygnały z platformy sprzedaży i informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym umiejscowienia kontekstowe) zSelectAdRequest. Funkcja działa podobnie do funkcji Protected Audience API. - Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne reprezentacje właściwościowe, pobierane z usługi wnioskowania.
To żądanie jest wysyłane do usługi pobierania reklam, która przeprowadza dopasowywanie kandydatów, a następnie uruchamia funkcję UDF getCandidateAds().
Funkcja UDF getCandidateAds()
getCandidateAds() korzysta z usługi pobierania reklam. Otrzymuje żądanie utworzone przez użytkownika prepareDataForAdRetrieval() w usłudze określania stawek kupującego. Usługa uruchamia polecenie getCandidateAds(), które pobiera tylu najlepszych kandydatów do ustalania stawek, konwertując żądanie na serię zapytań określonych w zestawie, pobieranie danych oraz wykonuje niestandardową logikę biznesową i inne niestandardowe reguły pobierania.
getCandidateAds() pobiera te informacje:
- Chronione sygnały aplikacji: ładunek sygnałów wybranych przez technologię reklamową.
- Sygnały związane z aukcjami: sygnały z platformy sprzedaży i informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym umiejscowienia kontekstowe) zSelectAdRequest. Funkcja działa podobnie do funkcji Protected Audience API. - Dodatkowe sygnały: dodatkowe informacje, takie jak prywatne reprezentacje właściwościowe, pobierane z usługi wnioskowania.
getCandidateAds() wykonuje te czynności:
- Pobranie początkowego zestawu kandydatów reklamy: pobieranie z uwzględnieniem kryteriów kierowania, takich jak język, region geograficzny, typ reklamy, rozmiar reklamy lub budżet, w celu odfiltrowania kandydatów reklamy.
- Pobieranie wektorów dystrybucyjnych: jeśli reprezentacje właściwościowe z usługi par klucz-wartość mają być potrzebne do utworzenia prognozy czasu pobierania dla wyboru górnego K, trzeba je pobrać z usługi par klucz-wartość.
- Wybór najlepszego kandydata: oblicza prosty wynik dla odfiltrowanego zestawu kandydatów reklam na podstawie metadanych reklamy pobranych ze sklepu par klucz-wartość oraz informacji wysłanych z usługi określania stawek kupującego, aby na podstawie tego wyniku wybrać k najlepszych kandydatów. Może to np. być szansa na zainstalowanie aplikacji dzięki reklamie.
- Pobieranie reprezentacji właściwościowych z określaniem stawek: jeśli w przypadku reprezentacji właściwościowych z usługi par klucz-wartość potrzebny jest kod określania stawek do generowania prognoz czasu ustalania stawek, dane te można pobrać z usługi par klucz-wartość.
Wynik reklamy może być wynikiem modelu prognostycznego, który na przykład prognozuje prawdopodobieństwo, że użytkownik zainstaluje aplikację. Taki sposób generowania wyników obejmuje rodzaj rozliczania modelu: getCandidateAds() działa w usłudze pobierania reklam, a usługa pobierania reklam nie ma usługi wnioskowania, dlatego prognozy mogą być generowane przez łączenie:
- Wektory dystrybucyjne kontekstowe przekazywane przy użyciu danych wejściowych sygnałów dotyczących aukcji.
- Wektory dystrybucyjne prywatne przekazywane za pomocą danych wejściowych dodatkowych sygnałów.
- Wszystkie technologie reklamowe umieszczone w umieszczaniu nieprywatnym zostały przetworzone ze swoich serwerów i przekształcone w usługę klucz-wartość usługi Ad Retrieval Service.
Pamiętaj, że funkcja UDF generateBid(), która korzysta z usługi określania stawek kupującego, może też stosować własny rodzaj rozkładu modelu na czynniki pierwsze do prognozowania stawek. Jeśli usługa par klucz-wartość potrzebuje do tego reprezentacji właściwościowych, musisz je pobrać teraz.
getCandidateAds() zwraca:
- Reklamy kandydujące: pierwsze k reklam do przesłania do:
generateBid(). Każda reklama składa się z tych elementów:- URL renderowania: punkt końcowy renderowania kreacji reklamy.
- Metadane: po stronie zakupu metadane reklam specyficznych dla technologii reklamowych. Dane te mogą np. obejmować informacje o kampanii reklamowej i kryteria kierowania, takie jak lokalizacja i język. Metadane mogą zawierać opcjonalne elementy osadzone używane, gdy do przeprowadzania wnioskowania podczas ustalania stawek potrzebna jest rozbicie modelu na czynniki pierwsze.
- Dodatkowe sygnały: opcjonalnie usługa pobierania reklam może zawierać dodatkowe informacje, takie jak dodatkowe reprezentacje właściwościowe czy sygnały spamowe do wykorzystania w usłudze
generateBid().
Szukamy innych metod dostarczania reklam do oceny, w tym udostępniania ich w ramach wywołania SelectAdRequest. Reklamy te można pobrać za pomocą pytania o stawkę RTB. W takich przypadkach reklamy należy pobierać bez chronionych sygnałów aplikacji. Przewidujemy, że technologie reklamowe będą analizować kompromisy, zanim wybierzą najlepszą opcję, w tym rozmiar ładunku odpowiedzi, czas oczekiwania, koszt i dostępność sygnałów.
Funkcja UDF generateBid()
Gdy podczas pobierania pobierzesz zestaw reklam kandydujących i reprezentacji właściwościowych, możesz przejść do określania stawek, które działa w usłudze kupującego. Ta usługa wykorzystuje dostarczony przez kupującego generateBid() UDF, aby wybrać z góry k reklamę, dla której zostanie określona stawka, a następnie zwrócić ją ze swoją stawką.
generateBid() pobiera te informacje:
- Reklamy kandydujące: pierwsze k reklam zwróconych przez usługę pobierania reklam do pobierania reklam.
- Sygnały związane z aukcjami: sygnały z platformy sprzedaży i informacje kontekstowe, takie jak
auction_signalsiper_buyer_signals(w tym umiejscowienia kontekstowe) zSelectAdRequest. - Dodatkowe sygnały: dodatkowe informacje używane podczas ustalania stawek.
Implementacja generateBid() kupującego spełnia 3 czynności:
- Featuryzacja: przekształca sygnały w cechy na potrzeby wnioskowania.
- Wnioskowanie: generuje prognozy za pomocą modeli systemów uczących się do obliczania wartości takich jak prognozowane współczynniki klikalności i konwersji.
- Ustalanie stawek: połączenie wywnioskowanych wartości z innymi danymi wejściowymi w celu obliczenia stawki dla reklamy kandydującej.
generateBid() zwraca:
- Reklama kandydująca.
- Kwota obliczonej stawki.
Pamiętaj, że generateBid() używane w reklamach promujących instalacje aplikacji i do reklam remarketingowych są różne.
Sekcje poniżej zawierają bardziej szczegółowe opisy funkcji, wnioskowania i ustalania stawek.
Funkcjonalizacja
generateBid() może przygotować sygnały z aukcji do wykorzystania w funkcjach. Funkcji tych można używać w trakcie wnioskowania do prognozowania współczynników klikalności i konwersji. Badamy też mechanizmy chroniące prywatność, które umożliwią przesyłanie niektórych z nich w raporcie o wygranych na potrzeby trenowania modeli.
Wnioskowanie
Przy obliczaniu stawki często wnioskowane jest zastosowanie danych z jednego lub kilku modeli systemów uczących się. Na przykład obliczenia efektywnego eCPM często wykorzystują modele do prognozowania współczynników klikalności i konwersji.
Klienci mogą dostarczyć wiele modeli systemów uczących się wraz z implementacją generateBid(). Udostępnimy też w obrębie generateBid() interfejs API JavaScript, który umożliwi klientom wnioskowanie w czasie działania.
Wnioskowanie jest wykonywane na usłudze określania stawek kupującego. Może to wpływać na czas oczekiwania na wnioskowanie i koszt, zwłaszcza że akceleratory nie są jeszcze dostępne w tych technologiach. Niektórzy klienci zauważą, że ich potrzeby spełniają poszczególne modele działające w ramach usługi określania stawek kupującego. Niektórzy klienci (na przykład klienci korzystający z bardzo dużych modeli) mogą rozważyć takie opcje jak rozkład na czynniki pierwsze, aby zminimalizować koszty wnioskowania i opóźnienia w czasie ustalania stawki.
Więcej informacji o możliwościach wnioskowania, takich jak obsługiwane formaty modelu i maksymalne rozmiary, przekażemy w kolejnej aktualizacji.
Wdrażanie rozkładu modelu na czynniki pierwsze
Wcześniej omówiliśmy rozłożenie modelu na czynniki pierwsze. Konkretna metoda podczas określania stawek:
- Podziel pojedynczy model na element prywatny (dane użytkownika) i co najmniej jeden element nieprywatny (dane kontekstowe i dane reklamy).
- Przekazuj utwory, które nie są prywatne, do
generateBid(). Mogą one pochodzić zper_buyer_signalslub z reprezentacji właściwościowych obliczonych na zewnątrz, z uwzględnieniem ich w magazynie par klucz-wartość usługi pobierania, pobierania w czasie pobierania i zwracanych jako część dodatkowych sygnałów. Nie dotyczy to prywatnych reprezentacji właściwościowych, ponieważ nie można ich pozyskiwać spoza granic prywatności. - W
generateBid():- Przeprowadzaj wnioskowanie na podstawie modeli w celu uzyskiwania prywatnych reprezentacji właściwościowych użytkowników.
- Łącz prywatnych reprezentacji właściwościowych użytkowników z reprezentacjami kontekstowymi z reklam
per_buyer_signalslub reklam nieprywatnych oraz reprezentacjami kontekstowymi z usługi pobierania, używając operacji takich jak iloczyn skalarny. To ostateczna prognoza, której można użyć do obliczenia stawek.
Dzięki temu można wnioskować podczas ustalania stawek z uwzględnieniem modeli, które w innym przypadku byłyby zbyt duże lub powolne do wykonania w ramach usługi określania stawek kupującego.
Logika punktowa po stronie sprzedawcy
Na tym etapie oceniane są reklamy ze stawkami otrzymanymi od wszystkich kupujących. Wynik działania generateBid() jest przekazywany do usługi aukcyjnej sprzedawcy
w celu uruchomienia scoreAd(), która scoreAd() uwzględnia tylko jedną reklamę naraz. Na podstawie wyniku sprzedawca wybiera zwycięską reklamę i zwraca na urządzenie, aby ją zrenderować.
Metoda oceniania jest taka sama jak w przypadku procesu remarketingu w ramach Protected Audience API i umożliwia wyłonienie zwycięzcy spośród użytkowników do kampanii remarketingowych i instalacji aplikacji.Funkcja jest wywoływana raz dla każdej przesłanej reklamy kandydującej w aukcji chronionych. Szczegółowe informacje znajdziesz w objaśnieniu dotyczącym określania stawek i aukcji.
Czas działania kodu wyboru reklamy
Kod wyboru reklamy promującej instalacje aplikacji jest określany w ofercie pakietowej w taki sam sposób jak w przypadku remarketingu w ramach Protected Audience API. Szczegółowe informacje znajdziesz w artykule Konfigurowanie określania stawek i aukcji. Kod ustalania stawek będzie dostępny w tej samej lokalizacji w chmurze, w której znajduje się miejsce używane do remarketingu.
Raportowanie
Oferta pakietowa korzysta z tych samych interfejsów API do raportowania co propozycja raportów na temat ochrony odbiorców (np. reportImpression(), która powoduje, że platforma wysyła raporty o sprzedawcach i kupujących).
Typowym przypadkiem użycia raportowania po stronie kupującego jest pobieranie danych treningowych dla modeli używanych podczas wyboru reklamy. Oprócz istniejących interfejsów API platforma będzie oferować specjalny mechanizm ruchu wychodzącego danych na poziomie zdarzenia z platformy do serwerów technologii reklamowych. Te ładunki ruchu wychodzącego mogą zawierać określone dane użytkownika.
W dłuższej perspektywie analizujemy rozwiązania chroniące prywatność, aby uwzględnić trenowanie modeli na danych używanych w aukcjach chronionych bez wysyłania danych użytkownika na poziomie zdarzenia poza usługi działające w TEE. Więcej szczegółów podamy w późniejszym czasie.
W najbliższym czasie zapewnimy tymczasowy sposób wysyłania zaszumionych danych wychodzących z generateBid(). Poniżej przedstawiliśmy wstępną propozycję dotyczącą tej funkcji. Będziemy ją rozwijać (również w odpowiedzi na opinie branży) (również w przypadku ewentualnych zmian niezgodnych wstecznie).
Technicznie to wygląda tak:
- Specjaliści ds. reklam definiują schemat danych, które chcą przesyłać.
- W usłudze
generateBid()tworzą odpowiedni ładunek ruchu wychodzącego. - Platforma weryfikuje ładunek ruchu wychodzącego w odniesieniu do schematu i egzekwuje limity rozmiaru.
- Platforma dodaje szum do ładunku ruchu wychodzącego.
- Ładunek ruchu wychodzącego jest uwzględniany w raporcie wygranych w formacie przewodowym, odbierany na serwerach technologii reklamowych, dekodowany i używany do trenowania modelu.
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ć zorganizowane w sposób zrozumiały dla platformy. Specjaliści reklamowi zdefiniują strukturę swoich ładunków ruchu wychodzącego, udostępniając plik JSON schematu. Schemat ten będzie przetwarzany przez platformę, a usługi określania stawek i usługi aukcyjne będą traktowane jako poufne za pomocą tych samych mechanizmów co inne zasoby technologii reklamowych, takie jak UDF i modele.
Udostępnimy plik CDDL definiujący strukturę tego kodu JSON. Plik CDDL będzie zawierał zestaw obsługiwanych typów cech (np. cechy będące wartościami logicznymi, liczbami całkowitymi, zasobnikami itd.). Zarówno plik CDDL, jak i udostępniony schemat będą miały różne wersje.
Na przykład ładunek ruchu wychodzącego, który składa się z 1 funkcji wartości logicznej, po której znajduje się funkcja zasobnika o rozmiarze 2, będzie wyglądać mniej więcej tak:
egressPayload = {
features : [
{
type: "boolean_feature",
value: false
},
{
type: "bucket_feature",
size: 2,
value: [
{
value: false
},
{
value: true
}
]
}
]
}
Szczegółowe informacje o zestawie obsługiwanych typów funkcji znajdziesz na GitHubie.
Kompilowanie ładunków ruchu wychodzącego w: generateBid()
Wszystkie chronione sygnały aplikacji w przypadku danego kupującego są dostępne w ramach funkcji UDF w usłudze generateBid(). Po ich wyposażeniu specjaliści ds. technologii reklamowych tworzą ładunek w formacie JSON. Ten ładunek ruchu wychodzącego zostanie uwzględniony w raporcie wygranych kupującego, który zostanie przesłany do serwerów technologii reklamowych.
Alternatywą dla tego projektu jest to, że obliczenia wektorów ruchu wychodzącego będą przeprowadzane w reportWin(), a nie w generateBid(). Każde podejście wiąże się z pewnymi kompromisami, a na podstawie opinii branży podejmiemy decyzję w tej sprawie.
Weryfikacja ładunku ruchu wychodzącego
Platforma zweryfikuje każdy ładunek ruchu wychodzącego utworzony przez technologię reklamową. Weryfikacja pozwala upewnić się, że wartości cech są prawidłowe w przypadku danego typu, spełnione są ograniczenia dotyczące rozmiaru i że złośliwe podmioty nie próbują ominąć ustawień prywatności, umieszczając dodatkowe informacje w swoich ładunkach ruchu wychodzącego.
Jeśli ładunek ruchu wychodzącego jest nieprawidłowy, zostanie dyskretnie odrzucony z danych wejściowych wysłanych do raportu wygranych. Wynika to z tego, że nie chcemy przekazywać informacji debugowania nieuczciwemu podmiotowi, który próbuje zaprzestać weryfikacji.
Udostępnimy technikom reklamowym interfejs API JavaScript, aby zapewnić, że ładunek ruchu wychodzącego, który utworzy w generateBid(), przejdzie weryfikację platformy:
validate(payload, schema)
Ten interfejs JavaScript API służy wyłącznie elementom wywołującym do określania, czy dany ładunek przejdzie weryfikację platformy. Aby chronić się przed złośliwymi funkcjami UDF generateBid(), należy przeprowadzić faktyczną weryfikację na platformie.
Szum ładunku ruchu wychodzącego
Platforma zaszumi ładunki wychodzące, zanim uwzględni je w raporcie wygranych. Początkowy próg szumu wyniesie 1% i z czasem może się zmienić. Platforma nie informuje, czy dany ładunek ruchu wychodzącego został zaszumiony.
Metoda szumu:
- Platforma wczytuje definicję schematu ładunku ruchu wychodzącego.
- Do szumu zostanie wybranych 1% ładunków ruchu wychodzącego.
- Jeśli ładunek ruchu wychodzącego nie zostanie wybrany, zachowana zostanie cała pierwotna wartość.
- Jeśli wybierzesz ładunek ruchu wychodzącego, wartość każdej cechy zostanie zastąpiona losową prawidłową wartością dla tego typu cechy (np.
0lub1w przypadku cechy logicznej).
Transmitowanie, odbieranie i dekodowanie ładunku wychodzącego na potrzeby trenowania modelu
Zweryfikowany, zaszumiony ładunek ruchu wychodzącego zostanie uwzględniony w argumentach funkcji reportWin() i przesłany do serwerów technologii reklamowych kupującego poza granicami prywatności na potrzeby trenowania modelu. Ładunek ruchu wychodzącego będzie miał format przewodu.
Szczegółowe informacje o formacie przewodu w przypadku wszystkich typów funkcji oraz samego ładunku wychodzącego znajdziesz na GitHubie.
Określ rozmiar ładunku ruchu wychodzącego
Rozmiar ładunku ruchu wychodzącego w bitach równoważy użyteczność i minimalizację danych. Wspólnie z branżą ustalimy odpowiednią wielkość w ramach eksperymentu. Podczas przeprowadzania tych eksperymentów będziemy tymczasowo wysyłać dane wychodzące bez ograniczeń. Te dodatkowe dane ruchu wychodzącego bez ograniczeń rozmiaru bitów zostaną usunięte po zakończeniu eksperymentów.
Metoda określania rozmiaru:
- Na początku w usłudze
generateBid()będziemy obsługiwać 2 ładunki ruchu wychodzącego:egressPayload: ładunek ruchu wychodzącego o ograniczonym rozmiarze, który został opisany w tym dokumencie. Początkowo rozmiar tego ładunku wychodzącego będzie wynosić 0 bitów (co oznacza, że będzie zawsze usuwany podczas weryfikacji).temporaryUnlimitedEgressPayload: tymczasowy ładunek ruchu wychodzącego o nieograniczonym rozmiarze na potrzeby eksperymentów dotyczących rozmiaru. Formatowanie, tworzenie i przetwarzanie tego ładunku ruchu wychodzącego korzysta z 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 przydatności modelu przy różnych rozmiarach ładunków ruchu wychodzącego (np. 5, 10, ...).
- Na podstawie wyników eksperymentu określamy rozmiar ładunku ruchu wychodzącego z uwzględnieniem odpowiedniej funkcjonalności i ochrony prywatności.
- Zmieniono rozmiar
egressPayloadz 0 bitów na nowy. - Po ustalonym okresie migracji usuwamy plik
temporaryUnlimitedEgressPayload, pozostawiając tylkoegressPayloadz nowym rozmiarem.
Szukamy dodatkowych barier technicznych, które mogą pomóc w zarządzaniu tą zmianą (np. szyfrowania egressPayload przy zwiększeniu jego rozmiaru z 0 bitów).
Te szczegóły – wraz z dodatkowymi informacjami, takimi jak protokół eksperymentu, czas trwania eksperymentu oraz czas usunięcia temporaryUnlimitedEgressPayload – zostaną uwzględnione w późniejszej aktualizacji.
Środki ochrony danych
Do wychodzących danych stosujemy szereg zabezpieczeń, w tym:
- Zarówno
egressPayload, jak itemporaryUnlimitedEgressPayloadbędą wyciszone. - Na potrzeby minimalizacji i ochrony danych funkcja
temporaryUnlimitedEgressPayloadbędzie dostępna tylko przez czas trwania eksperymentów dotyczących rozmiaru, w którym określimy właściwy rozmiar dla elementuegressPayload.
Uprawnienia
Kontrola użytkowników
- Ta oferta ma na celu zapewnienie użytkownikom wglądu w listę zainstalowanych aplikacji, które zawierają co najmniej 1 chroniony sygnał aplikacji lub niestandardową listę odbiorców.
- Użytkownicy mogą blokować aplikacje z tej listy i usuwać je z niej. Blokowanie i usuwanie sprawia, że:
- Usuwa wszystkie chronione sygnały aplikacji i niestandardowe listy odbiorców powiązane z aplikacją.
- Uniemożliwia przechowywanie przez aplikacje nowych chronionych sygnałów aplikacji i niestandardowych list odbiorców
- Użytkownicy mogą w pełni resetować sygnały Protected App Signals i Protected Audience API. W takim przypadku wszystkie istniejące sygnały chronionej aplikacji i niestandardowe listy odbiorców na urządzeniu zostaną wyczyszczone.
- Użytkownicy mogą całkowicie zrezygnować z Piaskownicy prywatności na Androidzie, co obejmuje interfejsy Protected App Signals API i Protected Audience API. W takim przypadku interfejsy Protected Audience API i Protected App Signals zwracają standardowy komunikat dotyczący wyjątku:
SECURITY_EXCEPTION.
Uprawnienia aplikacji i kontrola nad nimi
Celem tej oferty jest zapewnienie aplikacjom kontroli nad chronionymi sygnałami z aplikacji:
- Aplikacja może zarządzać swoimi powiązaniami z chronionymi sygnałami aplikacji.
- Aplikacja może przyznawać zewnętrznym platformom technologie reklamowe uprawnienia do zarządzania w jej imieniu chronionych sygnałów z aplikacji.
Kontrola platformy technologii reklamowych
Przedstawiamy tu sposoby, w jakie technologie reklamowe mogą kontrolować chronione sygnały aplikacji:
- Wszyscy specjaliści ds. technologii reklamowych muszą zarejestrować się w Piaskownicy prywatności i podać domenę „site” lub „origin”, która pasuje do wszystkich adresów URL na potrzeby chronionych sygnałów aplikacji.
- Technologie reklamowe mogą współpracować z aplikacjami lub pakietami SDK, aby dostarczać tokeny weryfikacyjne używane do weryfikowania tworzenia chronionych sygnałów aplikacji. Gdy ten proces zostanie przekazany partnerowi, utworzenie chronionego sygnału aplikacji można skonfigurować w taki sposób, aby wymagało potwierdzenia przez technologię reklamową.