Odpowiedzi na najczęstsze pytania dotyczące interfejsów API Piaskownicy prywatności z trafnością i pomiarów.
Czym różni się interfejs Topics od listy odbiorców zdefiniowanych przez sprzedawcę (SDA)?
Topics i SDA dostarczają informacji uzupełniających się pod kontrolą wydawcy. Nie uważamy, że one ze sobą rywalizują. Zamiast tego pracują obok siebie lub w różnych kontekstach, aby zmaksymalizować możliwości zakupu. Kupujący biorą pod uwagę wiele sygnałów i korzystają z nich podczas zautomatyzowanej oceny wyświetleń. Oczekujemy, że jednym z tych aspektów będą Topics API. W przeszłości sprzedawcy nie uwzględniali segmentów odbiorców w aukcjach na otwartym rynku, ponieważ w ich przypadku może być używany interfejs Topics. Zamiast tego sprzedawcy udostępniają swoje listy odbiorców do automatyzacji zakupu w ramach umów zawieranych z reklamodawcami, agencjami i platformami DSP. W takich przypadkach sprzedawca i kupujący dokonują transakcji celowo w ramach SDA. Jeśli tematy są używane w takich przypadkach, może to oznaczać, że:
- Sprzedawca rozszerzający definicję listy odbiorców za pomocą Topics
- Kupujący korzystający z Topics jako sygnału wskazującego wysokość stawki
- Kupujący korzystający z Topics w celu sprawdzenia, czy SDA jest prawidłowa
Czy Protected Audience daje Google kontrolę nad tworzeniem list odbiorców?
Nie. Witryny mogą nadal tworzyć własne grupy odbiorców zarówno w ramach Piaskownicy prywatności, jak i poza nią. Podczas tworzenia list odbiorców w ramach Piaskownicy prywatności właściciel witryny lub wybrany serwer proxy ustala, kto może tworzyć listy odbiorców, kim są odbiorcy, w jaki sposób są one aktualizowane, jak będą ustalane stawki oraz czy użytkownicy mają być z nich usuwani.
Czy funkcja Protected Audience obsługuje grupy zainteresowań utworzone przez wydawców?
Tak. Rozumiemy, że wydawcy obawiają się, że obecnie dołączają swoich odbiorców do aukcji opartych na OpenRTB. Obecnie w sekcji Chroniona lista odbiorców wydawcy mogą tworzyć listy odbiorców, które nie zapewniają systemowi licytującemu wglądu w dane konkretnego użytkownika wydawcy z różnych witryn. Z przyjemnością będziemy dalej badać sposoby, w jakie wydawcy mogą skorzystać ze ograniczonego wycieku danych w usłudze Protected Audience.
Jak są egzekwowane reguły dotyczące jakości reklam w aukcjach Protected Audience API?
Istnieje kilka sposobów egzekwowania reguł dotyczących jakości reklam w aukcjach Protected Audience API. Każdy z nich przypomina sposób egzekwowania reguł dotyczących jakości reklam obecnie przez platformy SSP. Jednym ze sposobów jest dopuszczenie jej do wyświetlenia w kolejce
do skanowania. Słyszeliśmy od opinii, że platformy tego typu oczekują lepszej obsługi tego przypadku użycia i opracowują mechanizm umożliwiający utworzenie pliku danych typu renderUrls, którego platforma SSP może kontrolować poza zakresem i przechowywać informacje na swoim serwerze par klucz-wartość. Innym sposobem jest wprowadzenie wymogu wcześniejszej rejestracji reklam. Podobnie jak w poprzednim przypadku, gdy kreacja zostanie przeskanowana, wyniki mogą być powiązane z serwerem par klucz-wartość. Następnie, gdy kupujący ustala stawkę za tę kreację (zgodnie z identyfikatorem kreacji prawdopodobnie w tym samym formacie co OpenRTB), logika sprzedawcy może wyszukać ten element na serwerze par klucz-wartość i określić sposób jego oceny.
Czy program Protected Audience API obsługuje reklamy wideo?
Tak. Adresy URL VAST można przekazywać do chronionych odbiorców i z nich wycofywać. Gdy pojawia się adres URL VAST, technika sprzedająca może koordynować sposób opakowania adresu URL VAST kupującego, zanim zostanie on wysłany do odtwarzacza. Spodziewamy się, że w ramach wymogu przejścia na zabezpieczone ramki (nie wcześniej niż w 2026 r.) i jeszcze bardziej wzmocnienia ochrony prywatności użytkowników ekosystem zaangażuje się w dyskusja na temat projektowania, która z pewnością obejmie również filmy.
Czy funkcja Protected Audience API obsługuje reklamy natywne?
Tak. Adresy URL w formacie JSON można przekazywać do Protected Audience API i z niego. Po pojawieniu się adresu URL w formacie JSON technologia sprzedająca może skoordynować sposób dodawania odpowiednich zdarzeń przed przekazaniem końcowego JSON do kodu renderowania. Spodziewamy się, że w ramach wymogu przejścia na ramki osłonięte (nie wcześniej niż w 2026 r.) w celu dalszego wzmocnienia ochrony prywatności użytkowników oczekujemy, że ekosystem weźmie udział w dyskusjach na temat projektowania, które prawdopodobnie będą obejmowały rozwiązania natywne.
Czy renderowanie reklam w ramach Protected Audience API ogranicza innowacyjność?
Nie. Renderowanie reklam zawsze polegało na technologiach przeglądarek. To się nie zmieni. Może to wynikać z planów, które w przyszłości wymagają stosowania opartych na ramkach ramek w połączeniu z funkcją Protected Audience API. Jedną z powodów, dla których plany są „w przyszłości”, jest to, że technologia Fenced Frames ułatwia obsługę innowacji i różnicowania w ekosystemie w zakresie renderowania reklam. Deweloperzy i firmy mogą się zastanawiać, czy warto postawić na ogrodzone ramki i zastanowić się nad tym, jak wspierać reklamy natywne.
Czy w ramach Protected Audience API stosowane są zaawansowane metody ustalania tempa i oceny stawek, które występują obecnie w tradycyjnych aukcjach?
Funkcja Protected Audience API umożliwia kupującym poznanie tempa kampanii i budżetów w czasie rzeczywistym. Z punktu widzenia zasobów reklamowych sprzedawca może dostarczać kupującemu sygnały z aukcji dotyczące kontekstu strony i innych informacji. Jeśli sprzedawca zdecyduje się wysłać pytanie o stawkę kontekstową, kupujący również może za pomocą tego mechanizmu uzyskać informacje o zasobach reklamowych, a potem otrzymać sygnały kontekstowe (za pomocą funkcji perBuyerSignals), które można wykorzystać do generowania stawek w ramach Protected Audience API. Użytkownicy wczesnej wersji łączą już systemy uczące się z Protected Audience API. Zdajemy sobie sprawę, że dostosowanie tych systemów do określania stawek w środowiskach Protected Audience może zająć trochę czasu, ale trzeba pamiętać, że dostrajanie jest możliwe i już trwa.
Czy standard OpenRTB będzie działać w Protected Audience?
Tak. W IAB Tech Lab pracujemy nad tą pracą z pomocą grupy starannie nadzorowanych przedstawicieli platform DSP i SSP. Wygląda na to, że celem będzie wykorzystanie fragmentów protokołu OpenRTB jako standardu komunikacyjnego w aukcjach Protected Audience API. Wiemy, że użytkownicy wczesnej wersji już takie stosują.
Czy w ramach ochrony odbiorców firmy muszą stosować 2 oddzielne architektury do wyświetlania reklam?
Nie. Protected Audience API nie wymaga 2 osobnych architektur. Wybór architektury zależy od Ciebie. Wraz z rozwojem reklamy online z czasem rośnie złożoność systemów, na których opiera się reklama. Zapewnienie użytkownikom większej prywatności w internecie jest bardziej złożone i wymaga pracy. Firmy z branży technologii reklamowych mogą zachować 2 oddzielne architektury lub utworzyć Protected Audience w ramach połączonej architektury z tradycyjnymi aukcjach.
Co się stanie z tradycyjnymi aukcje, gdy więcej firm z branży technologii reklamowych zacznie obsługiwać Protected Audience?
Spodziewamy się, że aukcje kontekstowe pozostaną trafne z wielu różnych powodów, m.in. z umów, kampanii kierowanych na odbiorców innych niż własne i wielu innych scenariuszy kontekstowych. Są też cenne, gdy nie ma żadnych grup zainteresowań lub stawki w sekcji Chronione grupy odbiorców nie osiągną wartości minimalnych lub nie będą przestrzegane przez reguły dotyczące jakości reklam.
Czy aukcja w ramach Protected Audience API jest równoznaczna z działaniami w ramach optymalizacji ścieżki dostawców ekosystemu (SPO) w celu zmniejszenia całkowitej liczby pośredników między reklamodawcą a wydawcą lub powielaniu danej możliwości reklamowej?
Nie. Zwycięska reklama w ramach Protected Audience API będzie przechodziła przez maksymalnie 2 jednostki sprzedawcy (np. platformę dostawców reklam (SSP) i serwer reklam wydawcy) i jak najmniej żadna (jeśli kupujący nawiąże bezpośrednią integrację z wydawcą).
Wybór wydawcy zależy od tego, czy powielanie tego samego żądania przez wielu pośredników. Ochrona odbiorców nie powinna wpływać w żaden sposób.
Aby nie doszło do wycieku danych użytkowników z różnych witryn, aukcje w ramach Protected Audience API odbywają się poza dzisiejszym systemem czasu rzeczywistego między serwerami. Niektórzy mogą powiedzieć, że duplikuje to żądanie reklamy. Osiągnięcie technicznie zrozumiałej ochrony prywatności wymaga pewnych kompromisów. W dłuższej perspektywie może się jednak zdarzyć, że system zdecyduje się korzystać z Protected Audience bez tradycyjnych aukcji po stronie serwera. Ten wybór może prowadzić do jeszcze bardziej zoptymalizowanych ścieżek dostawców.
Czy program Protected Audience obniża wartość istniejącej infrastruktury do kształtowania natężenia ruchu?
Jak rozumiemy, zmienia się to, że wiele platform SSP używa identyfikatorów z innych witryn do określania, czy wysłać żądanie do platformy DSP. Mniejsza liczba identyfikatorów z innych witryn wpływa więc na obecne techniki kształtowania natężenia ruchu. Dzieje się tak niezależnie od tego, czy wydawca chce przeprowadzić aukcję w ramach Protected Audience API, czy nie.
Przeanalizowaliśmy kształtowanie ruchu przy użyciu wielu platform SSP i znaleźliśmy rozwiązania takie jak pamięć podręczna i filtrowanie kontekstowe. Oczekujemy, że z czasem deweloperzy będą korzystać z agregacji prywatnej, aby lepiej rozumieć preferencje określania stawek przez DSP i odpowiednio filtrować dane.
W ostatecznym rozrachunku starsza infrastruktura zbudowana na bazie identyfikatorów z innych witryn nie będzie już przydatna.
Czy nowe żądania wynikające z aukcji Protected Audience API spowodują ograniczenie możliwości platformy SSP?
Z niektórych platform SSP dowiedzieliśmy się, że pojemność nie jest problemem ani ważnym elementem propozycji wartości tej platformy z punktu widzenia integracji. Dostawców SSP, którzy obawiają się o nowe połączenia w procesie aukcji, znamy firmy, które już pomagają tym platformom w związku z problemami z pojemnością, i planują rozszerzyć zakres tych usług, aby obsługiwały Protected Audience API. Daj nam znać, czy chcesz, abyśmy połączyli Cię z jedną z tych firm.
Jak jest określany priorytet w Protected Audience API, gdy w przeglądarce są konkurujące zasoby?
Funkcja Protected Audience API działa zwykle zgodnie ze standardowym wzorcem tworzenia ustawień, które pozwala sprzedawcom decydować, ile czasu i zasobów mogą wykorzystać licytujący, a także tworzyć narzędzia, które pozwalają kupującym decydować, jak najlepiej wykorzystać dostępne dla nich zasoby. Te opcje i narzędzia są dostępne już teraz, ale po ich wprowadzeniu przez kupujących i sprzedawców będą w pełni dostępne. Oprócz tego Chrome pracuje nad różnymi ulepszeniami infrastruktury zwiększającymi szybkość aukcji (np.crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev3323).
W jaki sposób Protected Audience radzi sobie z opóźnieniami?
W przeszłości, zanim w ramach funkcji Ochrona odbiorców stosowane było określanie stawek w czasie rzeczywistym na serwerach, sprzedawcy określali rygorystyczne limity czasu oczekiwania na odpowiedzi kupujących, aby kontrolować opóźnienia. Dodaliśmy wiele podobnych ustawień czasu oczekiwania określonych przez sprzedawców (zobacz dokumentację dotyczącą usług w zakresie perBuyerCumulativeTimeouts, perBuyerTimeouts i sellerTimeout) w ramach Protected Audience API, aby osiągnąć ten sam cel, jakim jest kontrola czasu oczekiwania. Narzędzia te zachęcają też uczestników aukcji do optymalizowania logiki w celu jak najefektywniejszego wykorzystywania zasobów na potrzeby ekosystemu technologii reklamowych i zapewnienia wysokiej jakości wrażeń użytkowników.
Chrome pracuje też nad różnymi ulepszeniami w infrastrukturze, które zwiększają szybkość aukcji (np. crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Zapraszamy do przesyłania opinii na temat obu tych aspektów: dodatkowych narzędzi, które mogą być przydatne dla kupujących i sprzedawców, oraz raportów o zaobserwowanych wąskich gardłach, które powinni zbadać inżynierowie Chrome.
Czy tworzenie treści z myślą o chronionej grupie odbiorców na urządzeniu jest zmarnowanym wysiłkiem w przypadku ustalania stawek i usług aukcyjnych?
Nie. W przypadku technologii reklamowych ustawienie „Na urządzeniu” wystarcza. Określanie stawek i usługi aukcyjne to opcjonalne rozwiązanie w skali poziomej, gdy technologie reklamowe chcą zainwestować więcej w obliczanie stawek, niż pozwala na to przeglądarka. Programowanie na urządzeniu to dobra inwestycja, bo większość zadań nadaje się do wielokrotnego wykorzystania, nawet jeśli deweloperzy zdecydują się później korzystać z usług określania stawek i aukcji. Większość zbudowanych rur i infrastruktury nadal będzie działać podobnie.
Czy wymagania dotyczące zaufanych środowisk wykonawczych działających w chmurze w zakresie Protected Audience API zachęcą firmy do korzystania z Google Cloud?
Interfejsy API w Piaskownicy prywatności zaprojektowano tak, aby zapewniać solidną ochronę prywatności i bezpieczeństwo. Nie podjęliśmy żadnych decyzji projektowych z korzyścią dla Google Cloud. Nasze wsparcie dla dostawców chmury zaczęło się od AWS, ponieważ wiemy, ilu dostawców technologii reklamowych wybiera Amazon. Oprócz AWS i Google Cloud planujemy w przyszłości obsługę innych dostawców chmury. Jesteśmy też otwarci na sugestie dotyczące innych dostawców chmury. Jeśli obawiasz się o czas oczekiwania, chmura umożliwia klientom wybór lokalizacji, co pozwala skrócić odległość od innych dostawców usług w chmurze.
Czy Piaskownica prywatności pozwoli zaufanym środowiskom wykonawczym (TEE) działać w niepublicznych centrach danych w chmurze?
Zaufane środowiska wykonawcze, które można kontrolować, stanowią część naszego modelu prywatności i bezpieczeństwa. Zaczęliśmy od technologii TEE oferowanych przez dostawców chmury publicznej ze względu na rygorystyczne środki bezpieczeństwa. Dla jasności – jedynymi interfejsami API, które będą w najbliższym czasie wymagać korzystania z zaufanych środowisk wykonawczych, to Attribution Reporting API i Private Aggregation API. żaden z nich nie wymaga wywoływania TEE w czasie rzeczywistym w ramach aukcji. Nadal pracujemy nad możliwością obsługi innych rozwiązań poza publicznymi rozwiązaniami działającymi w chmurze.
Czy działanie zaufanych środowisk wykonawczych w chmurach publicznych nie będzie droższe niż w lokalnych centrach danych reklamowych?
Nasz obecny model prywatności TEE korzysta z procedur związanych z bezpieczeństwem wdrożeń w chmurze publicznej i kwestionujemy wszelkie założenia, że prowadzenie lokalnego zaufanego środowiska wykonawczego jest tańsze. Oto kilka kwestii związanych z kosztami:
Dostawcy chmury publicznej muszą trzymać się bardzo wysokiej poprzeczki w zakresie bezpieczeństwa. Na przykład AWS to renomowany dostawca chmury z ugruntowanymi praktykami w zakresie zabezpieczeń. W szczególności AWS Nitro ma udokumentowany model zabezpieczeń, który sprawia, że enklawy Nitro uniemożliwiają operatorom dostęp do danych przetwarzanych w enklawie, a chronione zasoby (takie jak klucze odszyfrowywania) są dostępne tylko dla autoryzowanego kodu uruchomionego w enklawie. Trzeba też wziąć pod uwagę dostęp fizyczny. AWS zaprojektowała i wdrożyła środki ograniczające ryzyko zagrożeń dostępu fizycznego, w tym ze strony pracowników Amazon. Istniejące już sprzętowe TEE mogą nie obronić się przed wszystkimi atakami fizycznymi, które mają za zadanie chronić chmury publiczne. Ponadto firma Amazon ostatnio zaangażowała niezależną firmę badawczą NCC do weryfikacji projektów Nitro w kontekście zabezpieczeń związanych z dostępem dla pracowników wewnętrznych. Raport publiczny wskazuje, że projekty AWS spełniają ich deklaracje.
Wprowadzenie takich rozwiązań oraz ich wsparcie i ulepszanie z upływem czasu wiąże się z kosztami. Przy rozproszonych globalnie i powszechnie dostępnych chmurach publicznych koszty te rozkładają się na szeroką grupę klientów.
Czy Piaskownica prywatności zmienia płatności?
Nie. Firmy z branży technologii reklamowych i inne osoby wywołujące interfejs API mogą nadal sprawdzać, czy coś jest renderowane na stronie i za jaką cenę.
Czy w Piaskownicy prywatności można ograniczyć liczbę wyświetleń?
Funkcja Protected Audience API obsługuje ograniczenie liczby wyświetleń w różnych witrynach w ramach tej samej grupy zainteresowań za pomocą obiektu prevWinsMs. Funkcja generateBid() kupującego w aukcji chronionych odbiorców może utworzyć logikę, która może pomóc w określaniu strategii ustalania stawek na podstawie wyniku wcześniejszych ekspozycji reklam w tej samej przeglądarce.
Poza zabezpieczoną grupą odbiorców można stosować kilka rozwiązań do ograniczania liczby wyświetleń, ale nie są one w pełni mapowane na techniki działające w różnych witrynach stosowane przez technologie reklamowe w przypadku plików cookie innych firm.
- Własne pliki cookie: technologie reklamowe mogą używać własnych danych do ograniczania liczby wyświetleń w witrynie
- Fragmenty CHIP: technologie reklamowe mogą zarządzać limitami wyświetleń na użytkownika na poziomie witryny za pomocą partycjonowanego pliku cookie
- Pamięć współdzielona
SelectURL(): gdy technologia reklamowa wygra aukcję, a przed wyrenderowaniem kreacji, może wywołać pamięć współdzieloną, aby uzyskać dostęp do danych z różnych witryn, i wybrać odpowiednią kreację na podstawie częstotliwości za pomocą bramki wyjściowej wyboru adresu URL.
Rozwiązanie, które zapewnia ochronę prywatności i ogranicza liczbę wyświetleń na użytkownika, a które pozwala efektywnie korzystać z technologii reklamowych, jest trudne z tych powodów:
- Na podstawie opinii technologii reklamowych nie jest obecnie jasne, czy sygnał częstotliwości może tolerować szum.
- Słyszeliśmy, że w czasie aukcji trzeba udostępniać niezakłócone sygnały z różnych witryn, aby w każdej aukcji reklamowej można było korzystać z sygnałów dotyczących częstotliwości występowania w różnych witrynach. Mogłoby to ujawnić dużą ilość informacji o aktywności użytkownika na różnych stronach, co naruszyło cele Piaskownicy prywatności związane z prywatnością.
- Zwracamy uwagę na opóźnienia, a rozwiązanie na urządzeniu, które może dostarczać ten sygnał, może powodować opóźnienia i zakłócić środowisko aukcji
- Rozwiązaniem będzie prawdopodobnie nowy interfejs API, który musi przejść przez proces składania propozycji W3C.
W związku z tym opracowanie rozwiązania do ograniczania liczby wyświetleń poza usługą Protected Audience nie uwzględnia się w naszych najbliższych planach, ale chętnie poznamy opinie na temat potencjalnych sposobów rozwiązania tego problemu.
Co z przypadkami użycia, których nie obejmuje Piaskownica prywatności?
Interfejsy API Piaskownicy prywatności stanowią kluczowe elementy składowe reklam chroniących prywatność, dzięki którym deweloperzy mogą sami określić, w jaki sposób są one ze sobą powiązane. Podejście oparte na elementach składowych umożliwia firmom wprowadzanie innowacji i opracowywania rozwiązań, które zapewniają wartość klientom. Celem Piaskownicy prywatności nie jest kompleksowe rozwiązanie do wszystkich zastosowań. Naszym zdaniem byłby to zły wynik. Zamiast tego deweloperzy i firmy będą nadal realizować swoje pomysły za pomocą różnych technologii, w tym interfejsów API Piaskownicy prywatności, które integrują ze swoimi rozwiązaniami.