Raport kwartalny za I kwartał 2024 r. podsumowujący opinie ekosystemu na temat ofert pakietowych Piaskownicy prywatności i odpowiedzi Chrome.
W ramach swoich zobowiązań wobec CMA firma Google zobowiązała się do publicznego udostępniania kwartalnych raportów z procesu angażowania zainteresowanych osób w swoich propozycjach Piaskownicy prywatności (patrz art. 12 i 17(c)(ii) Zobowiązań). Raporty z podsumowaniem opinii w Piaskownicy prywatności są tworzone przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym między innymi z problemów na GitHubie, formularza opinii dostępnego na stronie privacysandbox.com, spotkań z osobami z branży i forów standardów internetowych. Chrome korzysta z opinii otrzymanych od ekosystemu i aktywnie bada sposoby wykorzystywania zdobytych informacji na potrzeby podejmowania decyzji projektowych.
Tematy opinii są uporządkowane według częstotliwości występowania w poszczególnych interfejsach API. W tym celu zbieramy opinie na temat danego motywu zebrane przez zespół Chrome i uporządkowaliśmy je w kolejności malejącej. Tematyka opinii została zidentyfikowana na podstawie tematów dyskusji ze spotkań publicznych (W3C, PatCG, IETF), opinii bezpośrednich, GitHuba oraz często zadawanych pytań pojawiających się w zespołach wewnętrznych Google i formularzach publicznych.
Dokładniej rzecz ujmując, sprawdzono protokoły ze spotkań zebrań organizacji zajmujących się standardami internetowymi, a w celu uzyskania bezpośredniej opinii rozważaliśmy indywidualne spotkania z zainteresowanymi osobami, e-maile otrzymane przez poszczególnych inżynierów, listę adresową interfejsu API oraz publiczny formularz opinii. Następnie zespół Google koordynował działania zespołów zaangażowanych w te działania informacyjne, aby określić względną powszechność tematów pojawiających się w porównaniu z poszczególnymi interfejsami API.
Wyjaśnienia reakcji Chrome na opinie opierają się na opublikowanych najczęstszych pytaniach, rzeczywistych odpowiedziach zgłaszanych przez zainteresowane osoby oraz określeniu stanowiska na potrzeby tego publicznego raportowania. Biorąc pod uwagę obecny cel programowania i testowania, otrzymaliśmy pytania i opinie w szczególności dotyczące interfejsów Topics, Protected Audience i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu raportowania mogą jeszcze nie mieć odpowiedzi Chrome.
Słowniczek akronimów
- interfejs ARA
- Attribution Reporting API
- CHIPS
- Pliki cookie o niezależnym stanie partycjonowania
- (procesor) DSP
- Platforma DSP
- FedCM
- Sfederowane zarządzanie danymi uwierzytelniającymi
- kl./s
- Zestawy własne
- IAB
- Interactive Advertising Bureau ,
- Dostawca tożsamości
- Dostawca tożsamości
- IETF
- Grupa zadaniowa ds. inżynierii internetu
- IP
- Adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Wersja próbna origin
- Interfejs API PAT
- Protected Audience API (wcześniej FLEDGE)
- PatCG
- Grupa społeczności Private Advertising Technology
- RP
- Strona uzależniona
- RWS
- Zestawy powiązanych witryn (wcześniej zestawy źródeł własnych)
- platforma SSP
- Platforma dostawców reklam
- TEE
- Zaufane środowisko wykonawcze
- UA
- Ciąg znaków klienta użytkownika
- UA-CH
- Wskazówki dotyczące klienta użytkownika
- W3C
- World Wide Web Consortium
- WIPB
- Samodzielna ślepota na adresy IP
Ogólna opinia, brak konkretnego interfejsu API lub technologii
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Zarządzanie | Zainteresowanie okresem komentowania aktualizacji zarządzania w Piaskownicy prywatności. | Jesteśmy otwarci na uzasadnione opinie zainteresowanych osób na temat ważnych zmian w Piaskownicy prywatności, w tym dotyczących przyszłego zarządzania Piaskownicą prywatności. |
Testowanie | Dodatkowe fazy testowania wersji 3PCD jako uzupełnienie obecnego 1% testów obsługiwanych przez Chrome. | Od początku stycznia nie planujemy prowadzić testów z wykorzystaniem Chrome powyżej obecnego 1% ruchu w Chrome. |
Przejście z aplikacji do aplikacji | Model 3PCD na urządzeniach mobilnych nie powinien nastąpić przed osiągnięciem pełnej interoperacyjności między stroną internetową a aplikacją. | Zgadzamy się, aby obsługiwała interoperacyjność aplikacji i stron internetowych. Wprowadziliśmy też pomiary atrybucji w różnych aplikacjach i internecie. Sprawdzamy też rozwiązania do kierowania reklam z witryny do aplikacji. Nie planujemy jednak opóźnić wdrożenia 3PCD w internecie mobilnym. Nie planujemy osiągnięcia 100% pokrycia po wdrożeniu 3PCD. Spodziewamy się raczej, że zgodność z Androidem w zakresie pomiarów w różnych aplikacjach i witrynach będzie dość wysoka w przypadku modeli 3PCD i z czasem będzie się zwiększać w miarę aktualizowania telefonów przez użytkowników. |
Rola przeglądarki | Wygląda na to, że Chrome przyjmuje rolę serwera reklam lub platformy SSP. | Chrome nie przyjmuje roli serwera reklam ani platformy SSP. Dzięki interfejsowi PA API Chrome udostępnia serwer reklam, platformy SSP, platformy DSP i inne technologie reklamowe, umożliwiając wprowadzenie ich własnych logiki w zakresie określania stawek i wyników. |
Wskazówki dotyczące przypadku użycia | bardziej przejrzyste wytyczne dotyczące przypadków użycia obsługiwanych przez interfejsy API Piaskownicy prywatności. | Na początku projektu Piaskownica prywatności przede wszystkim znajdowała się w dokumentacji dla deweloperów, która miała zachęcać deweloperów do udziału w procesie dyskusji i przekazywania opinii na temat wszystkich ofert. Oznaczało to zasadniczą strukturę treści pod kątem motywacji i koncepcji projektu oraz szczegółów na wczesnym etapie rozwoju i testowania każdej propozycji. Było to skuteczne w nawiązywaniu współpracy w rzeczywistym ekosystemie przy opracowywaniu propozycji. Jednak gdy interfejsy API stały się ogólnie dostępne, pojawiło się nowa grupa deweloperów, którzy głównie tworzą interfejsy API, zamiast pomagać w ich opracowywaniu. Niedawno zaktualizowaliśmy funkcję nawigacji na stronie Privacy Lab Sandbox. Będziemy nadal stosować takie podejście do dokumentacji oparte na konkretnych przypadkach użycia. |
Lokalne środowisko programistyczne | W jaki sposób możemy kontynuować programowanie i testowanie lokalnie naszego frontendu na serwerze lokalnym http://localhost, gdy plik cookie ma ustawienie SameSite=Secure, a backend ma front przez CDN? | Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie od członków ekosystemu. |
Łagodzenie 3PCD | Czy istnieje sposób automatycznego sprawdzania, że 3PC są zablokowane lub gdy włączona jest heurystyka? | W Chrome zarówno wykrywanie funkcji, jak i wywołanie metody document.hasStorageAccess w elemencie iframe pozwalają deweloperowi sprawdzić, czy źródło elementu iframe ma dostęp do aplikacji 3PC. |
Testowanie wideo | Obecnie nie można testować reklam wideo w Piaskownicy prywatności. | Chrome opublikował już dziś omówienie kilku możliwych sposobów na wykorzystanie tego filmu za pomocą interfejsu PA API (zobacz 242 i 254 w naszym repozytorium demonstracyjnym na GitHubie). Pamiętaj, że nie są to przykładowe fragmenty kodu, za pomocą których technicy reklam mogliby zastosować sprzedaż hurtową, ale raczej model koncepcyjny i zademonstrowanie technik, które mogłyby obsługiwać renderowanie wideo VAST z użyciem interfejsu PA API. W ramach tej dyskusji dało się też zauważyć, że chociaż renderowanie filmów jest już możliwe, Chrome może wprowadzić zmiany, które uprościłyby implementację za pomocą interfejsu PA API. Na przykład aktualizacje dotyczące zastępowania makr (omówione tutaj), które chcieliśmy rozwiązać na podstawie opinii o zastosowaniach zewnętrznych weryfikatorów reklam, dotyczą również opinii w przypadku użycia wideo, gdy kupujący szuka makr sprzedawcy do renderowania. Większość dotychczasowych dyskusji dotyczyła przede wszystkim renderowania reklam wideo VAST. Renderowanie reklam natywnych może wykorzystać ten sam efekt i jest pod wieloma względami łatwiejsze. Wygląda na to, że reklamy natywne przyciągają obecnie mniejszą uwagę niż reklamy wideo, ale chodzi o priorytet w branży technologii reklamowych, a nie o przeszkodę techniczną w implementacji. |
Pomiary niezwiązane z reklamami | Model 3PCD może wpływać na pomiary odbiorców, które nie są związane z reklamami. | Interfejsy API pomiarowe nie wymagają, aby przypadek użycia był związany z reklamami. ARA jest bardziej specyficzne dla typowej ścieżki reklamowej, agregacja prywatna ma charakter ogólny. Te 2 elementy składowe mogą być wykorzystywane do różnorodnych działań pomiarowych. |
Twórcy | Piaskownica prywatności ma zachęcać twórców do tworzenia większej ilości treści dla YouTube, a mniej na własnych stronach. | Inicjatywa Piaskownica prywatności koncentruje się na zachowaniu prywatności aktywności użytkowników w otwartym i bezpłatnym internecie. Wiemy, że wydawcy tworzą treści za pomocą reklam i udostępniają je najszersze grono. Reklamodawcy pomagają użytkownikom odkrywać nowe produkty lub oferty, które ich interesują. Funkcje Piaskownicy prywatności umożliwiają witrynom wszelkiego rodzaju, w tym współpracującym z twórcami treści, wyświetlanie użytkownikom przydatnych reklam na podstawie ich aktywności w różnych podmiotach bez ujawniania im tożsamości użytkowników. |
Bardziej przejrzyste harmonogramy | Bardziej przejrzyste i szczegółowe harmonogramy udostępniania technologii Piaskownicy prywatności. | Dokumentacja interfejsu API Piaskownicy prywatności zawiera informacje o stanie i dostępności interfejsu API. Na tych stronach znajdziesz listę funkcji, które pojawią się wkrótce, i ich harmonogram (np. PA API czy ARA). Tutaj znajdziesz centralny widok tych stanów. |
Systemy uczące się | Technologie reklamowe nie są w stanie prawidłowo trenować modeli systemów uczących się, dopóki wartość 3PCD nie przekroczy 1%. | Udostępnienie technologii 3PCD większej liczbie przeglądarek nie zagwarantuje, że interfejsy API będą częściej wykorzystywane do tego celu, a zapewne właśnie tego oczekują technicy reklamowi, aby dalej trenować modele systemów uczących się. Jeśli technologie reklamowe dążą do dalszego trenowania modeli systemów uczących się w szerszym zakresie, nie ma powodu rozszerzać 3PCD, ponieważ technologie reklamowe, które chcą trenować modele na większym ruchu, mogą to zrobić już teraz bez zwiększonego udziału w 3PCD. Dzięki temu przeglądarka Chrome nie będzie musiała przejść do przodu w trybie 3PCD przed zakończeniem przerwy w działaniu. |
Nieobsługiwane zastosowanie | Przypadki użycia samoobsługowej platformy DSP nie są obecnie uwzględniane. | Istnieje wiele samoobsługowych platform DSP, które regularnie publikują publiczne opinie na temat interfejsów API. Kilku z tych dostawców usług DSP, które regularnie przekazują publiczne opinie, również wskazało siebie jako testerów. Ponadto Chrome aktywnie korzysta z typowych samoobsługowych platform DSP, takich jak wideo czy serwery reklamowe firm zewnętrznych. Omówiliśmy te tematy w ostatnich cotygodniowych wywołaniach interfejsu API reklam spersonalizowanych. |
Wersja próbna Origin | Prośba o dołączenie do witryn w przypadku witryn wymagających bardziej agresywnego wzrostu i testowania zakresu 3PCD. | Chrome pracuje obecnie nad własną opcją dogrzania, aby umożliwić źródłom wyrażenie zgody na wycofywanie z serwerów 3PC. W przypadku źródeł najwyższego poziomu, które zarejestrowały się w ramach tego okresu próbnego i tokenów wdrażania, urządzenia 3PC będą blokowane tak, jakby na urządzeniu użytkownika była włączona ochrona przed śledzeniem. Umożliwi to witrynom przeprowadzenie szerszych testów długoterminowych alternatyw dla rozwiązań 3PC przed ich planowanym wycofaniem po konsultacji z CMA. Nadal pracujemy nad sfinalizowaniem harmonogramu wdrożenia OT. |
Raport IAB Tech Lab | Opinia na temat Piaskownicy prywatności z raportu IAB Tech Lab. | Szczegółowo odpowiedzieliśmy na raport IAB Tech Lab tutaj. Uznaliśmy też, że „w raporcie pojawiają się pytania dotyczące pofragmentowanej dokumentacji, wymagań handlowych, audytów przeprowadzanych przez firmy zewnętrzne, akredytacji branżowej, skalowalności, przejrzystości i przyszłego zarządzania, w związku z czym zaangażujemy się w ekosystem i odpowiednio zaktualizujemy odpowiedzi na najczęstsze pytania publiczne”. Wcześniej zajmujemy się fragmentami dokumentacji. Odpowiadamy na wymagania komercyjne w sekcji „Gwarancje danych” tutaj, a niektóre usługi reklamowe Google poinformowały o swoich działaniach. Zajmujemy się audytami przeprowadzanymi przez firmy zewnętrzne w ramach kategorii „Gwarancja integralności algorytmu” tutaj. W odniesieniu do akredytacji oczekujemy, że instytucje te będą nadal akredytować produkty, w tym również związane z wykorzystaniem technologii, zamiast samych technologii. Jeśli chodzi o skalowalność, wciąż jesteśmy otwarci na dane od deweloperów, które wykazują problemy. Jeśli chodzi o przejrzystość i zarządzanie, kontynuujemy prace na otwartej platformie GitHub i na forach takich jak W3C, jednocześnie nawiązując współpracę z CMA w ramach zobowiązań. |
Logowanie przez Google | Dane logowania w usługach Google wiążą się z użyciem przez Google danych logowania umożliwiających identyfikację w sposób niezgodny z zobowiązaniami. | Logowanie przez Google nie umożliwia Google używania danych sprzecznych z zobowiązaniami. |
Zgodność | Jakie są plany dotyczące obsługi interfejsów API Piaskownicy prywatności oraz zgodności w przyszłości i wstecz? | Kiedy funkcja Chrome stanie się ogólnodostępna, dołożymy wszelkich starań, aby kontynuować jej obsługę. Oczywiście nie zawsze jest to możliwe. W takich przypadkach mamy jasny proces wycofywania i usuwania istniejących funkcji, który jest opisany tutaj. Zamierzamy z czasem dodawać kolejne funkcje do interfejsów API Piaskownicy prywatności, w odpowiedzi na opinie ekosystemu dotyczące przypadków użycia, w przypadku których ulepszona obsługa będzie się rozwijać. W takich przypadkach stosujemy pewną metodę wykrywania funkcji, dzięki której przedstawiciel reklamowy zainteresowany eksperymentem może bezpośrednio zapytać przeglądarkę, czy funkcja jest obsługiwana. To lepsze niż proszenie deweloperów o sprawdzenie określonego numeru wersji Chrome, ponieważ niektóre funkcje mogą nie zostać udostępnione u wszystkich użytkowników Chrome w tym samym czasie. Na przykład o działaniach wykrywania funkcji na potrzeby interfejsu PA API dowiesz się tutaj. |
Implementacja serwera | Zamiast łączyć je z własną implementacją, Chrome powinna określać zachowania, które musi spełniać zadowalająca implementacja serwera zaufanych sygnałów, serwera agregacji i wszelkich innych wymaganych komponentów innych niż przeglądarka. Umożliwi to wprowadzanie innowacji w ramach dopuszczalnych granic prywatności. | Doceniamy chęć wprowadzania innowacji ze strony firm zewnętrznych. W przypadku wszystkich interfejsów API i usług chcemy zapewnić technikom reklamowym elastyczność w implementacji ich funkcji. Zezwalamy na przykład technikom reklamowym na wykorzystywanie poufnych informacji o firmie do projektowania logiki ustalania stawek na potrzeby aukcji. Co więcej, stale korzystamy z opinii od technologii reklamowych i w uzasadnionych przypadkach włączamy je do naszych projektów. Aby inne osoby mogły uruchamiać własny kod w zaufanych środowiskach wykonawczych, Piaskownica prywatności musi sprawdzić ten kod (i wszelkie zmiany), aby potwierdzić, że jest zgodny z gwarancjami prywatności. Wymaga to wiele wysiłku ze strony zespołu Piaskownicy prywatności. Dlatego chcemy zrozumieć, jakie korzyści chce osiągnąć zainteresowana osoba, a których obecnie nie znamy. |
Heurystyka | Jakie są długoterminowe plany dotyczące heurystyki? | Zgodnie z danymi innych przeglądarek planujemy wycofać te narzędzia heurystyczne, ponieważ alternatywne rozwiązania zaczną być powszechnie stosowane, co uzależnione jest od dalszej analizy wykonalności. Udostępniliśmy to tutaj. |
Liczba testów | Różne natężenie ruchu przy porównywaniu różnych wymiarów. | Eksperyment 1% ma kryteria wykluczania, które prowadzą do różnic w kwalifikowaniu się do niego wśród różnych populacji klientów Chrome. Na przykład eksperyment wyklucza użytkowników Chrome Enterprise, więc odsetek ruchu objęty etykietami eksperymentu będzie wyższy w weekendy. Należy się spodziewać różnych wartości procentowych ruchu w różnych kategoriach danych (takich jak dane geograficzne, daty i platforma) – odpowiada to danym z Chrome. |
Ręczne ponowne włączanie urządzeń 3PC | Czy witryny będą w stanie dowiedzieć się, ilu użytkowników (%) ponownie ręcznie włączyło pliki cookie po wymuszeniu 3PCD? | W przypadku awarii użytkownicy będą mogli ponownie włączyć dostęp do sieci 3PC na poziomie witryny za pomocą funkcji pomijania użytkownika. Urządzenia 3PC można też ponownie włączyć za pomocą innych metod, na przykład interfejsu Storage Access API. Istnieją środki techniczne, takie jak hasStorageAccess(), które pozwalają witrynom wykrywać, czy urządzenia 3PC są włączone czy wyłączone. Chrome nie umożliwia jednak witrynom uzyskiwania informacji o powodach ponownego włączenia aplikacji. |
Ochrona przed śledzeniem | Jak długo funkcja ochrony przed śledzeniem w Chrome będzie dostępna? | Przewidujemy, że interfejs ochrony przed śledzeniem na pasku adresu będzie nadal dostępny po wycofaniu technologii 3PC. |
(Również zgłaszane w poprzednich kwartałach) Obsługa w różnych przeglądarkach |
Inni dostawcy przeglądarek wdrażają interfejsy API Piaskownicy prywatności. | Inni dostawcy przeglądarek, np. Apple, Mozilla i Microsoft, są aktywnymi uczestnikami forów publicznych, na których omawiane są zasady ochrony prywatności i rozwiązania działające w różnych przeglądarkach. Zachęcamy do prowadzenia dyskusji na forach takich jak niedawne doroczne spotkanie W3C TPAC i trwające na forach W3C PATCG, na których widać oznaki zbieżności. Na przykład firma Microsoft Edge ogłosiła niedawno swój plan, który „ma na celu zmaksymalizowanie zgodności składni” z interfejsami PA API i ARA, a jednocześnie oferuje dodatkowe funkcje dla deweloperów. |
Opcja zastępcza dla niezgodnego umieszczenia posta 3PCD | Udostępnij punkty zaczepienia interfejsu API umożliwiające wykrywanie, czy zewnętrzny element iframe lub umieszczony element jest zgodny z 3PCD. | Rozmawiamy o tej prośbie tutaj. Czekamy na dodatkowe opinie od członków ekosystemu. |
Testowanie | Żądanie dodatkowych flag w zarządzanych instancjach Chrome, które tymczasowo wyłączają niestandardowe zachowania. | Rozpatrujemy prośbę o udostępnienie zarządzanych instancji Chrome i prosimy o dodatkowe dane z ekosystemu, jeśli taka flaga byłaby przydatna. |
Rejestracja i atest
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Weryfikacja atestu | W jaki sposób Google będzie dbać o autentyczność atestów? | Wszyscy subskrybenci muszą przechowywać plik atestu podczas korzystania z interfejsów API. Google sprawdza, czy plik jest dostępny, a składnia jest poprawna, ale nie weryfikujemy działania technologii reklamowej w odniesieniu do języka atestu. |
Proces rejestracji do interfejsu Private Aggregation API | Czy mogę sprawdzić stan rejestracji interfejsu Private Aggregation API? | Po potwierdzeniu rejestracji wszyscy zatwierdzeni uczestnicy otrzymają e-maila od zespołu pomocy ds. rejestracji. Jeśli abonent ma jakiekolwiek pytania na temat tego procesu, może skontaktować się z zespołem pomocy (z którym kontaktuje się po przesłaniu formularza rejestracyjnego). Zespół pomocy odpowie na Twoje pytania i udzieli wszelkich dodatkowych wskazówek. |
Pokaż trafne treści i reklamy
Tematy
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
(raporty również w poprzednich kwartałach) Oś czasu i dokumentacja klasyfikatorów |
Musi istnieć jakaś forma mechanizmu weryfikacji klasyfikacji lub przynajmniej dodatkowa przejrzystość sposobu wyznaczania kategorii przez tryb klasyfikacji. | Nasza odpowiedź nie zmieniła się w porównaniu z poprzednimi kwartałami: „Błędna klasyfikacja witryn może sprawić, że sygnał Topics będzie nieco mniej przydatny jako sygnał, ale nie jest to w żaden sposób szkodliwe w przypadku konkretnych witryn, które zostały błędnie sklasyfikowane. Jest to spowodowane tym, że informacje kontekstowe witryny będą zawsze dostępne dla aukcji w jej witrynie, dzięki czemu informacje będą porównywalne z prawidłowym tematem, nawet w przypadku błędnej klasyfikacji. Zachęcamy do przesyłania opinii na ten temat tutaj. |
Google Ad Manager | Google Ad Manager jest już umieszczony w większości witryn i zawiera znacznie szersze informacje o zagadnieniach dotyczących użytkowników niż konkurencja. | Wymóg obserwacji pozwala się upewnić, że interfejs Topics API nie powoduje udostępniania danych użytkownika większej liczbie elementów niż technologie, które ten interfejs zastępuje (w tym 3PC). Inne rozwiązania branżowe, takie jak Prebid, obsługują ponad 10 tysięcy witryn i umożliwiają uczestnikom rynku wywoływanie interfejsu Topics API za pomocą swojej technologii. Warto też pamiętać, że limit maksymalnie 5 najpopularniejszych tematów tygodniowo może dawać równomierny efekt, ponieważ uczestnicy rynku obecni w wielu witrynach, którzy mogą dzięki nim poznać więcej niż 5 równoważników tematycznych, są ograniczone do 5 osób. |
(Również zgłaszane w poprzednich kwartałach) Przydatność różnych rodzajów zainteresowanych osób |
obawy związane z korzyścią tworzenia i rozkładem treści w witrynach w zależności od poziomu ruchu w nich oraz tego, jak specjalistyczna jest treść witryny; | Zdajemy sobie sprawę, że wyspecjalizowane witryny często zamieszczają bardziej szczegółowe tematy niż domeny zainteresowań ogólnych. Jednak nie wszystkie wyspecjalizowane witryny zawierają tematy wartościowe pod względem handlowym. Dodatkowo dynamiczna reguła odzwierciedla status quo i jest całkowicie niezależna od zakończenia obsługi urządzeń 3PC w Chrome. W obecnym środowisku niektóre witryny zapewniają większą wartość niż inne w systemach trafności reklam opartych na technologii 3PC. Ponadto zagadnienia poruszane w różnych specjalistycznych witrynach mogą przynieść wzajemne korzyści, ponieważ różni reklamodawcy mogą prowadzić kampanie dotyczące różnych zestawów tematów, a mechanizmy określania stawek mogą oceniać wartość w szerokim zakresie tematów. |
Nazwy hostów a pełne adresy URL | Czy klasyfikacja na podstawie nazw hostów witryn jest wystarczająco skuteczna i czy zmniejsza ryzyko naruszenia prywatności w porównaniu z pełnymi adresami URL? | Zastanawialiśmy się nad używaniem oprócz nazw hostów adresów URL i tytułów stron z informacjami, i uznaliśmy, że potencjalne korzyści wyniosłyby ze względu na ryzyko dla prywatności i bezpieczeństwa użytkowników. Przykładem ryzyka dotyczącego prywatności użytkownika jest klasyfikacja informacji poufnych zawartych w adresie URL lub tytule strony w ramach tematów użytkownika. |
Tematy jako sygnał | Poproś o wskazówki dotyczące łączenia tematów z innymi sygnałami oraz o inne sygnały, które mogą być przydatne. | Rozwiązania z zakresu technologii reklamowych mogą uzyskać najlepsze wyniki dzięki połączeniu wszystkich dostępnych narzędzi, takich jak systemy uczące się i sygnały zapewniające ochronę prywatności pochodzące z interfejsów API chroniących prywatność, z danymi kontekstowymi, danymi kreacji i danymi własnymi. Dalsze wskazówki na ten temat znajdziesz tutaj. |
Protected Audience API (wcześniej FLEDGE)
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Przetestuj natężenie ruchu | Testerzy zgłaszają małą liczbę odpowiedzi na stawkę w aukcji interfejsu API PA. | 1. Gęstość stawek jest powiązana z udziałem ekosystemu w interfejsie API PA, który według naszych prognoz będzie się zwiększać w 2024 roku i później. To reklamodawcy, ich agencje i dostawcy technologii decydują, jak rozdysponować budżet kampanii. Spodziewamy się, że niektórzy uczestnicy ekosystemu mogą opóźnić swoją inwestycję w różne rozwiązania „bez plików cookie”, w tym interfejs API PA, aż do 3PCD. Spodziewamy się, że zwiększą one wówczas budżet kampanii na te rozwiązania. 2. Na liczbę pytań o stawkę w aukcjach interfejsu API z reklamami spersonalizowanymi może mieć wpływ (1) – wydawcy i ich dostawcy technologii reklamowych mogą zdecydować, że nie będą inicjować aukcji interfejsu API z reklamami spersonalizowanymi, jeśli uznają, że popyt jest niski. To wydawcy decydują, czy aktualizacja stron jest ich priorytetem, czy nie. Przewidujemy, że z tego powodu wydawcy mogą potrzebować czasu na testowanie i stopniowe zwiększanie ruchu. Raport ten zawiera też odpowiedź Google Ad Managera z informacjami o ustawieniach wydawcy dotyczących korzystania z interfejsu PA API. |
(Zgłoszono również w poprzednich kwartałach) Oszustwa / nadużycie |
W jaki sposób ekosystem może zmniejszyć ryzyko i powstrzymać nieuczciwe podmioty lub kupujący przed pozycjonowaniem ich jako pożądanych odbiorców? | Mechanizmy raportowania reklam z użyciem interfejsu API PA zachowują informacje używane do odróżniania obecnie ruchu generowanego przez użytkowników od ruchu generowanego przez boty. Ponadto w interfejsie PA API można stosować aktualne, oparte na domenie techniki włączania i wykluczania domen. Szczegółowo opisujemy to w naszej odpowiedzi na raport IAB Tech Lab na temat Piaskownicy prywatności. |
Ograniczenie dotyczące tego samego źródła w przypadku właściciela Instagrama i adresu URL logiki ustalania stawek | Przy wymaganiu tego samego pochodzenia punkty końcowe właściciela IG będą wymuszane przez ten sam system równoważenia obciążenia, co może doprowadzić do odrzucenia przekierowań. | Wymóg podania tej samej domeny przy wczytywaniu skryptu ma duże znaczenie dla bezpieczeństwa. Tutaj znajdziesz szczegółowe informacje na temat proponowanego rozwiązania, które uwzględnia opinie ekosystemu i inne kwestie. |
Aukcja prywatna z wieloma boksami | Jest sporo miejsca na dopuszczenie aukcji prywatnych z wieloma boksami w granicach prywatności dzięki zastosowaniu szumu i bliższej integracji z aktualnymi praktykami reklamowymi. | Bierzemy pod uwagę te opinie i oceniamy prośbę o przeprowadzenie aukcji z wieloma tagami pod kątem zwiększonej złożoności i zagrożenia dla prywatności związanego z tą funkcją. Ten problem został szczegółowo omówiony tutaj podczas wywołania PA API Web Incubator Community Group (WICG). |
Sprzedawcy najwyższego poziomu | Obecna struktura interfejsu API reklam spersonalizowanych zapewnia każdemu sprzedawcy najwyższego poziomu dostęp do znacznie większej ilości danych i wiedzy o względnej wartości wyświetleń niż w przypadku wydawców i sprzedawców komponentów. | W aukcji dla wielu sprzedawców każdy sprzedawca będzie miał najlepszą stawkę. Poza tym z ekosystemu wynika, że wydawcy mogą chcieć wziąć pod uwagę popyt na sprzedaż bezpośrednią, obok najlepszych stawek każdego sprzedawcy, z którym współpracują. Aby zdecydować, którą reklamę wyświetlić, trzeba wziąć pod uwagę wszystkie te możliwości zarabiania. W takiej sytuacji, gdy użytkownik musi zobaczyć pełny zestaw opcji, aby wybrać reklamę do wyświetlenia, jest wcześniejsza niż w przypadku interfejsu PA API. Interfejs PA API ma na celu obsługę aukcji z wieloma sprzedawcami, a wydawcy chcą brać pod uwagę najlepsze stawki każdego sprzedawcy obok kampanii reklamowych w sprzedaży bezpośredniej (tam, gdzie ta druga opcja ma zastosowanie). Oznacza to, że musi istnieć mechanizm wyboru spośród tych możliwości zarabiania, jakie obecnie istnieją. Sądziliśmy, że nie powinna być rolam przeglądarki w wyborze reklamy do wyświetlenia. Aby wybrać zwycięską reklamę z wielu możliwości, trzeba użyć pojęcia sprzedawcy najwyższego poziomu. Ta logika najwyższego poziomu musi uwzględniać najlepsze stawki od każdego sprzedawcy, z którym chce współpracować. Sprzedawca może również podać informacje o jego kampaniach w sprzedaży bezpośredniej, o ile takie dane są dostępne. Wszystkie te informacje można uwzględnić w logice najwyższego poziomu wyboru reklamy. Oznacza to, że logika najwyższego poziomu wybiera najlepsze stawki z aukcji interfejsu API reklam spersonalizowanych oraz, w stosownych przypadkach, wszelkie opcje reklam sprzedawanych bezpośrednio przez wydawcę w celu wyłonienia zwycięzcy. W sekcji „Dostęp do informacji” w raporcie Google Ad Manager można znaleźć szczegóły implementacji interfejsu API PA jako sprzedawcy najwyższego poziomu. |
Oddzielenie reklam konkurencyjnych | Zażądanie odseparowania reklam konkurencji, na przykład w celu uniemożliwienia wyświetlania reklam konkurencyjnych marek obok siebie. | Nie wiemy, jak sprawić, żeby w dzisiejszym ekosystemie reklamy cyfrowej wielu sprzedawców z automatyzacją, z ustalaniem stawek i poszczególnymi stawkami zagwarantowaliśmy odseparowanie konkurencji. Interfejs API PA umożliwia jednak sprzedawcom pobieranie dodatkowych sygnałów w czasie rzeczywistym na podstawie kombinacji adresu URL renderowania i nazwy hosta (reprezentującej domenę wydawcy), które można wykorzystać w ramach ScoreAd() podczas oceniania kreacji. Sprzedawcy mogą go używać, aby reklamy konkurujących marek nie wyświetlały się obok siebie, jeśli wydawca chce egzekwować tę regułę. |
Ograniczone informacje | Interfejs PA API ogranicza informacje dostępne dla wydawców, takie jak wartość reklamy, nazwa kupującego komponentu, nazwa reklamodawcy, URL strony docelowej, rozmiar kreacji, czas odpowiedzi i stawka, a także przegrywające stawki. | Zaproponowaliśmy kilka potencjalnych rozwiązań tutaj. Zachęcamy również do zapoznania się z opiniami od członków ekosystemu. |
Raporty na poziomie zdarzenia | Po wycofaniu interfejsu API raportowania na poziomie zdarzenia wydawcy nie będą w stanie uzyskać wystarczającej ilości informacji o wyświetlonej reklamie. | Zdajemy sobie sprawę z różnych przypadków użycia raportowania, które będziemy musieli obsługiwać po wycofaniu raportowania na poziomie zdarzenia. Dlatego zaplanowaliśmy datę wycofania raportów na poziomie zdarzenia nie wcześniej niż w 2026 r. W tym czasie zachęcamy do aktywnego udziału w pracy z ekosystemem w zakresie trwałych działań, które mogłyby obejmować nowe pomysły na pozyskiwanie informacji w sposób zapewniający ochronę prywatności. |
Wiele platform SSP | Wartość dodana z wielu platform SSP będzie zbyt niska dla wydawców. | Uważamy, że nie jest to słuszne. Chętnie poznamy prośbę o dodatkowe opinie z ekosystemu, aby lepiej zrozumieć uzasadnienie takiego stwierdzenia. |
Selekcjonowanie | W przypadku interfejsu PA API działania związane z selekcjonowaniem nie są możliwe. | Słyszeliśmy, że sprzedawcy mogą korzystać z interfejsu PA API do udostępniania kupującym w internecie informacji o odbiorcach (tzw. rozszerzenie liczby odbiorców). Uważamy, że jest to możliwe obecnie, wykorzystując funkcję przekazywania dostępu w ramach usług płatnych wraz z umowami biznesowymi. Jednocześnie aktywnie zastanawiamy się, czy i jak moglibyśmy lepiej dostosować się do tego typu przypadków użycia. |
Rezygnacja kupującego | Domyślna rezygnacja kupującego może przełożyć się na niższe wyniki w aukcjach składowych. | Niezależnie od tego, czy zdefiniujesz aukcję dla pojedynczego sprzedawcy czy wielu sprzedawców, sprzedawca musi jawnie wskazać kupujących w polu InterestGroupBuyers w konfiguracji aukcji. Uzyskane w ten sposób informacje potwierdzają, że sprzedawcy mają umowy z niektórymi kupującymi, dlatego potrzebują wyraźnej kontroli nad tym, którzy kupujący uwzględnią ich w aukcji. Zachęcamy do dalszych dyskusji na GitHubie. |
Adsize | Nie można wykonać filtra wstępnego na podstawie parametru adsize i adSlotSize. | Pracujemy nad dodaniem tej funkcji. Więcej informacji znajdziesz tutaj. |
Obsługa kierowania wykluczającego w sieci reklamowej | Interfejs API umożliwiający obsługę kierowania wykluczającego w sieci reklamowej, który umożliwia wyświetlanie reklam tylko wtedy, gdy użytkownik nie należy do IG. | W tym problemie z GitHub zaproponowano alternatywny sposób implementacji kierowania wykluczającego, w którym przeglądarka bezpośrednio informuje serwer reklam, które reguły kierowania wykluczającego powinny obowiązywać w przypadku konkretnego żądania reklamy. Choć takie podejście wydaje się atrakcyjne, wszystkie zbadane przez nas wersje umożliwiają serwerowi jednoznaczne zidentyfikowanie użytkownika. |
akt prawny o usługach cyfrowych | W jaki sposób wydawca może używać chronionych ramek, a jednocześnie zapobiegać renderowaniu odpowiedzi zawierających informacje podlegające aktowi o usługach cyfrowych? | Podobnie jak w przypadku każdej nowej technologii, każda firma jest odpowiedzialna za korzystanie z Piaskownicy prywatności zgodnie z prawem. Google nie może udzielać porad prawnych innym podmiotom. W przypadku każdego interfejsu API opublikowaliśmy obszerną dokumentację techniczną, która powinna stanowić podstawę do przeprowadzenia niezbędnych ocen prawnych. Chronione ramki nie są wymagane do użycia w interfejsie API PA wcześniej niż w 2026 roku. Da to zainteresowanym stronom więcej czasu na sprawdzenie, czy wykorzystują tę technologię zgodnie ze wszystkimi odpowiednimi przepisami. |
Dokumentacja | Czy funkcja updateAdInterestGroups() jest tymczasowa? | Nie ogłaszaliśmy żadnych planów wycofania funkcji updateAdInterestGroup. W przyszłości możemy stosować podobne środki ochrony prywatności, o których mówiliśmy publicznie w przypadku innych mechanizmów aktualizacji Instagrama, na przykład przez korzystanie z adresu IP również z serwerem proxy oraz dodanie pewnego opóźnienia przed aktualizacją. |
Metadane po stronie kupującego i obsługa własności logicznej w przypadku platform innych niż platformy DSP | Prośba o określenie sposobu działania jako serwer proxy dla platform DSP. | Zdajemy sobie sprawę z tych opinii od segmentów nienależących do DSP i rozpatrujemy je. Czekamy na dodatkowe opinie od członków ekosystemu. |
Raportowanie | Prośba o dodanie funkcji niestandardowego modułu obsługi dla zasobnika / wartości sygnałów w raportach agregacji prywatnej. | Wiemy, że ta prośba o dodanie funkcji oczekuje na sprawdzenie. Dodatkowe opinie z ekosystemu chętnie poznamy tutaj. |
Dokumentacja | Czy istnieje link, za pomocą którego można wyświetlić wszystkie nagłówki odpowiedzi, które muszą zostać ustawione przez reklamodawcę i domenę (wyznaczonego) właściciela? | Planujemy aktualizacje dokumentacji, aby wyjaśnić tę kwestię. Będziemy wdzięczni również po otrzymaniu opinii od członków ekosystemu. |
Określanie stawek za wiele wieży | Prośba o wyjaśnienie przepływu pracy (trenowanie i wnioskowanie) za pomocą schematu architektury / bloków obrazującego podejście z wieloma wieżami w kontekście interfejsu PA API. | Dziękujemy za opinię. Mamy pewne prezentacje na ten temat, dla których przewidujemy opracowanie dodatkowej dokumentacji. |
Kierowanie wykluczające | Możliwość Piaskownicy prywatności w celu ochrony wrażliwych odbiorców i nieletnich przed nieodpowiednimi reklamami, np. hazardem. | Interfejs PA API nie uwzględnia treści wyświetlanych reklam. Tu kontrolują deweloperzy technologii reklamowych, którzy korzystają z reklam spersonalizowanych. Ogólnie rzecz biorąc, wydawca i jego dostawcy technologii reklamowych mogą blokować kreacje w ramach aukcji Protected Audience API, korzystając z informacji kontekstowych ze strony i zestawów reguł wydawcy. Jest to odzwierciedlenie naszego obecnego podejścia ekosystemu do tych wyzwań. Funkcja kierowania wykluczającego może też być przydatna dla kupujących w pewnych przypadkach zgodności z przepisami. |
Projektowanie interfejsów API | Google sprzeciwia się temu i chce, aby technologie reklamowe wykorzystywały uniwersalne określanie stawek, co zwiększa czas oczekiwania, zamiast stosować różne metody określania stawek w różnych logicznych adresach URL, które są dozwolone. | Podczas dyskusji na temat opóźnienia aukcji podkreśliliśmy, że ponowne użycie tego samego skryptu na wszystkich stronach internetowych kupującego przyspieszy jego realizację. Szczegółowe informacje na ten temat znajdziesz tutaj oraz nasze inne zalecenia dotyczące skrócenia czasu oczekiwania w przypadku aukcji interfejsu API reklam spersonalizowanych. |
Marketing oparty na kontach | Interfejs PA API nie jest czystym interfejsem do marketingu na podstawie konta. | Chętnie poznamy opinie ekosystemu na temat wszelkich konkretnych przypadków użycia, które ich zdaniem nie są możliwe. Zachęcamy uczestników ekosystemu do kontynuowania tej dyskusji za pomocą naszego publicznego repozytorium GitHub lub cotygodniowych rozmów. |
Test A/B | Gdy interfejs PA API jest skonfigurowany w GAM dla wydawcy, musi być obecnie włączony dla wszystkich zasobów reklamowych albo dla żadnego z nich. Ogranicza to możliwość przeprowadzenia testów A/B. | Odpowiedź dostarczona przez Google Ad Managera: Ustawienia interfejsu API PA w usłudze Google Ad Manager (GAM) wpływają na możliwość korzystania przez GAM z tego interfejsu API, o ile ten interfejs API jest dostępny. Z tego powodu wydawcy mogą przeprowadzać testy A/B, korzystając z funkcji zasad uprawnień w Chrome, aby wyłączyć używanie interfejsu API w podzbiorze ruchu i używać go jako grupy kontrolnej w teście A/B. |
Systemy uczące się | Wydawcy potrzebują większej kontroli nad proponowanym przez GAM wykorzystaniem systemów uczących się. | Odpowiedź uzyskana przez Google Ad Managera: w styczniu 2024 r. wprowadziliśmy opcję, która umożliwia wydawcom wyłączenie ograniczenia na potrzeby systemów uczących się i włączenie aukcji interfejsu API reklam spersonalizowanych z udziałem sprzedawców spoza Google w przypadku całego ruchu. Więcej informacji o tym ustawieniu znajdziesz w Centrum pomocy. |
(Również raportowane w poprzednich kwartałach) Aukcje najwyższego poziomu |
Możliwość korzystania z serwera reklam wydawcy Google bez zapewnienia GAM kontroli nad aukcją interfejsów API najwyższego poziomu. | Odpowiedź podana przez Google Ad Managera: Z powodów opisanych w raporcie Google za III kwartał plany GAM dotyczące integracji interfejsu API reklam spersonalizowanych nie obejmują wydawców, którzy korzystają z GAM jako serwera reklam wydawcy bez kontroli nad aukcją najwyższego poziomu. |
Dostęp do informacji | GAM ma dostęp do cennych informacji od konkurencji, w tym do kontekstowych cen z aukcji, sygnałów dostarczanych przez kupujących platformom SSP na potrzeby aukcji interfejsu API PA i parametrów konfiguracji tych platform. | Odpowiedź od Google Ad Managera: Od lat koncentrujemy się na uczciwości aukcji i obiecujemy sobie, że żadne ceny z żadnych niegwarantowanych źródeł reklam wydawcy (w tym ceny niegwarantowanych elementów zamówienia) nie będą udostępniane innemu kupującemu przed podjęciem decyzji o udziale w aukcji. Następnie potwierdziliśmy to w naszych zobowiązaniach wobec francuskiego organu ds. konkurencji. W przypadku aukcji interfejsu API PA zamierzamy dotrzymać obietnicy i nie będziemy udostępniać stawki żadnego uczestnika aukcji innym uczestnikom aukcji przed zakończeniem aukcji wielu sprzedawców. Dla jasności – nie podajemy ceny aukcji kontekstowych z żadną aukcją cząstkową, w tym z naszą, zgodnie z opisem w tej aktualizacji. Ponadto w ramach naszych aukcji nie wykorzystujemy informacji o konfiguracjach składowych aukcji, w tym sygnałów dostarczanych przez kupujących platformom SSP. Chcielibyśmy również zaproponować zmiany w interfejsie API reklam spersonalizowanych, które pozwolą sprzedawcom komponentów określać ich konfiguracje aukcji komponentów w taki sposób, aby nie były one ujawniane przez sprzedawcę najwyższego poziomu. |
Aukcje składowe | W ramach aukcji najwyższego poziomu GAM będzie kontrolować, które platformy SSP przeprowadzają aukcje składowe poszczególnych możliwości reklamowych. | Odpowiedź dostarczana przez Google Ad Managera: GAM to serwer reklam wydawcy oferujący prostszy interfejs API dla platform SSP, z którymi wydawca może współpracować, aby określić konfiguracje aukcji za pomocą interfejsu API tagów wydawcy Google (GPT). Więcej informacji znajdziesz tutaj. Jeśli platforma SSP dostarcza składnikową konfigurację aukcji za pomocą tego interfejsu API, jest uwzględniana na liście aukcji składowych danej możliwości reklamowej. GAM nie nakłada żadnych ograniczeń na uwzględnione aukcje komponentów. Może to zrobić każda platforma SSP, która chce przeprowadzić aukcję komponentów, pod warunkiem że wydawca zezwolił jej na wykonanie wymaganego kodu na stronie wydawcy. |
Aukcje składowe | GAM może zastosować określoną, nieujawnioną cenę minimalną do każdej zwycięskiej stawki na aukcji składowej. | Odpowiedź przesłana przez Google Ad Managera: GAM od lat przykłada dużą wagę do uczciwości aukcji. Aby zapewnić uczciwą i przejrzystą aukcję, nie obsługujemy cen minimalnych, które mają zastosowanie tylko do określonych segmentów popytu. Jest to jedna z spójnych zasad obowiązujących w naszej usłudze i będzie tak samo obowiązywać w przypadku aukcji interfejsów API reklam spersonalizowanych. |
Serwery reklamowe firm zewnętrznych | Serwery reklamowe firm zewnętrznych nie będą miały dostępu do udziału Google w aukcji wyższego poziomu, co ograniczy możliwość korzystania z żądań SSP Google w kontekście interfejsu PA API. | Odpowiedź przesłana przez Google Ad Managera: Obecnie GAM obsługuje testowanie interfejsu PA API z udziałem wielu sprzedawców w GAM za pomocą interfejsu API opisanego tutaj. Udział GAM jako aukcji składowej w innych aukcjach najwyższego poziomu nie jest obecnie obsługiwany. |
(Również zgłaszane w poprzednich kwartałach) Skuteczność aukcji interfejsów API PA |
Raport od testerów o dużym czasie oczekiwania na aukcje interfejsów API z reklamami spersonalizowanymi. | Słyszeliśmy obawy o opóźnienia, co jest jednym z powodów, dla których opracowaliśmy szereg funkcji w ramach interfejsu PA API, które umożliwią platformom SSP ustawianie limitów czasu oczekiwania na DSP i wprowadzanie ulepszeń w celu zmniejszenia tych opóźnień. Niedawno zaktualizowaliśmy nasz przewodnik po sprawdzonych metodach dotyczących opóźnienia, który zawiera więcej informacji na temat korzystania z tych funkcji. Stale opracowujemy też nowe rozwiązania pozwalające skrócić czas oczekiwania. Niektóre z nich znajdziesz tutaj. |
(Również zgłaszane w poprzednich kwartałach) Renderowanie wideo |
Obsługa renderowania wideo przy użyciu interfejsu PA API i ramek Fenced Frame. | W styczniu opublikowaliśmy prezentację o tym, jak reklamy wideo typu In-Stream mogą działać w aukcjach PA, wraz z dodatkowymi informacjami o alternatywnych rozwiązaniach. Widzimy też, że podmioty działające w ekosystemie zaczynają proponować działanie renderowania wideo w przypadku partnerów, którzy się z nimi integrują, takie jak propozycje GAM dotyczące tworzenia URL-a zgodnego z wideo czy pełny proces E2E. Dodatkowo słuchamy opinii ekosystemu na temat zmian, które możemy wprowadzić w celu zwiększenia rozpowszechnienia, a informacje o takich zmianach są szczegółowo opisane na GitHubie. Aktywnie współpracujemy z ekosystemem w celu identyfikacji wszelkich innych przeszkód w ich wdrażaniu. |
(Również zaraportowano w poprzednich kwartałach) Zasady postępowania z danymi |
Jakie są zasady postępowania z danymi w przypadku interfejsów IG / PA API? | W ramach interfejsu API PA wszystkie dane przechowywane w tagach Instagram i informacje o tym, co użytkownicy są w tagach Instagram, (i) pozostają na urządzeniu lub (ii) są przetwarzane w ramach usług określania stawek i aukcji działających w zaufanym środowisku wykonawczym (TEE). W obu przypadkach dane nie mogą być odczytywane przez żadne inne osoby ani wykorzystywane w żaden inny sposób niż do generowania stawek podczas aukcji. Niektóre rozszerzenia ochrony prywatności, nad którymi testuje się Chrome, wymagają interakcji z zarządzanym przez Google serwerem k-anonimowości. Interakcja ta została starannie zaprojektowana tak, aby uniknąć udostępniania informacji o użytkownikach, a była przeprowadzona w TEE w celu zapewnienia spójności informacji w całym ekosystemie reklamowym. Google zobowiązało się do projektowania i wdrażania propozycji Piaskownicy prywatności w sposób, który nie zniekształca konkurencji przez samo traktowanie własnej firmy Google oraz uwzględnia wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców. W dalszym ciągu ściśle współpracujemy z CMA, aby zapewnić zgodność naszych działań z tymi zobowiązaniami. |
(raportowano także w poprzednich kwartałach) Czas trwania IG |
Poproś o wydłużenie okresu ważności Instagrama z 30 do 90 dni. | Taka zmiana wymaga dokładnej oceny korzyści dla branży w porównaniu z wpływem na użytkowników Chrome i inne zainteresowane osoby. Rozpatrujemy Twoją prośbę. Chętnie poznamy Twoją opinię tutaj. |
(raportowane również w poprzednich kwartałach) ModelingSignals |
Oprócz modelowania sygnałów, które mogą kodować tylko informacje o wyświetlaniu i kliknięciach, poproś o nowe pole. | W odpowiedzi na tę opinię przedstawiliśmy kontrofertę, która znajduje się tutaj. Aktywnie współpracujemy z przedstawicielami branży, aby poznać ich opinie na temat naszej propozycji. Rozważamy też korzyści dla branży w porównaniu z wpływem na użytkowników Chrome i inne zainteresowane osoby. |
Dodatkowe bity w funkcji reportWin() | Podaj dodatkowe bity w funkcji reportWin() od obecnego limitu wynoszącego 12 przed 3PCD. | Obecnie analizujemy różne podejścia do zastosowania tego rozwiązania. Potrzebujemy trochę czasu, ponieważ szukamy też rozwiązań, które mogłyby pomóc nam opracować długoterminowy plan ochrony prywatności. |
Projektowanie aukcji | Żądania pojedynczej aukcji, która zwraca renderowane adresy URL wraz z odpowiednim wynikiem. | Wzięliśmy pod uwagę udostępnianie wielu URL-i renderowania wraz z ich wynikami w ramach jednej aukcji reklam spersonalizowanych, ale nie wdrożyliśmy tej funkcji ze względu na kwestie dotyczące prywatności. Rozumiemy, że chcesz uniknąć wielokrotnego wyświetlania tej samej reklamy jednemu użytkownikowi na jednej stronie i zachęcamy do dalszych dyskusji na GitHubie. |
reportWin | rejestrować dowolne pola w funkcji reportWin(). | Dzieje się tak już teraz, przez cały okres testowania. Po zakończeniu obsługi technologii 3PC w Chrome zostanie przeniesiona wersja interfejsu API forDebuggingOnly, która będzie umożliwiać debugowanie w wersji niższej niż próbkowane. Więcej informacji znajdziesz tutaj. |
Sprzedawcy komponentów | mieć niezależny mechanizm liczenia własnych wyświetleń i innych zdarzeń, który nie musi polegać wyłącznie na raportach specjalistów reklamowych; | Tę prośbę o funkcję oczekujemy w kolejce do dalszego zbadania. W okresie testów przeprowadzanych w Chrome nie planujemy podejmować takich działań. |
Rozliczanie według kosztu kliknięcia | Zaimplementuj rozliczanie według kosztu kliknięcia w interfejsie PA API. | Rozpatrujemy tę prośbę tutaj. Przekazujemy ją obecnie jako prośbę o sugestie dotyczące wdrożenia jej w obecnej wersji interfejsu API. |
browserSignals | Dodano element przychodzące BidInSellerCurrency do raportowania specyfikacji BrowserSignals dla sprzedawcy. | Rozpatrujemy Twoją prośbę. Chętnie poznamy Twoją opinię tutaj. |
Metadane po stronie kupującego i obsługa własności logicznej w przypadku platform innych niż DSP | Obecny wygląd interfejsu API może spowodować znaczącą zmianę w kampaniach ponownego kierowania na poziomie produktów, w przypadku których konieczne może być przeniesienie kampanii na platformy działające zarówno jako platformy DSP, jak i dostawcy DCO. | Pracujemy nad tym problemem. Chętnie poznamy też dodatkowe opinie – tutaj . |
Metadane po stronie kupującego i obsługa własności logicznej w przypadku platform innych niż DSP | Podaj przykłady sytuacji, w których platforma DSP nie jest właścicielem Instagrama. | Zdajemy sobie sprawę, że osoby niebędące licytującymi chcą korzystać z niektórych funkcji Instagrama, ale nie z innych. Aktywnie oceniamy możliwości rozwiązania tych przypadków użycia i chętnie poznamy dodatkowe opinie tutaj. |
Opcje czasu oczekiwania | Wydawcy powinni mieć możliwość określenia, ilu użytkowników IG mogą używać, oraz określić limit czasu najwyższego poziomu / globalny limit czasu. | Rozumiemy, że istnieje zapotrzebowanie na większą kontrolę limitu czasu i widoczność między sprzedawcą najwyższego poziomu a sprzedawcą komponentów, dlatego rozważamy tę prośbę. |
Wiele rozmiarów reklam | Obsługa interfejsu PA API w przypadku korzystania z wielu rozmiarów reklam. | Rozpatrujemy tę prośbę i chętnie poznamy dodatkowe opinie od członków ekosystemu. |
Dokumentacja | Czy istnieje lista atrybutów IG, które są poddawane działaniu k-anon? | Odpowiedzieliśmy na to pytanie tutaj. |
Debugowanie | Ulepszone możliwości debugowania interfejsu PA API. | Zdajemy sobie sprawę, jak ważne są niezawodne narzędzia do debugowania dla programistów pracujących z interfejsem PA API. Staramy się, aby korzystanie z aplikacji było jak najprzyjemniejsze dla programistów, dlatego badamy sposoby lepszej integracji pobierania plików .well-known z narzędziami dla programistów. Naszym celem jest zapewnienie większej widoczności i możliwości rozwiązywania problemów w środowisku programistycznym. Omawiamy ten problem dokładniej tutaj. Zachęcamy do przesyłania opinii. |
Etykiety | Czy wszyscy użytkownicy korzystający z etykiet traktowania w trybie B mają włączone interfejsy API Piaskownicy prywatności? | Przypisania do grup eksperymentalnych Chrome są określane losowo i niezależne od skonfigurowanych przez użytkownika ustawień Chrome. Te interfejsy API mogą być dostępne dla użytkowników w określonych grupach eksperymentalnej (np. terapia_1.*), ale ich działanie można zmieniać lub wyłączać w ustawieniach Chrome. Grupa kontrolna B w trybie B: uwzględnienie w tej grupie powoduje wyłączenie interfejsów API Piaskownicy prywatności i trafności. Użytkownik nie może zastąpić tego ustawienia w ustawieniach Chrome. |
Używanie API | Czy wywołanie metody reportWin() i renderowania reklam odbywa się równolegle, czy jedno po drugim? | Funkcja reportWin() jest wywoływana bezpośrednio po zakończeniu działania runAdAuction(). Jednocześnie może rozpocząć się proces renderowania reklamy, gdy wynik aukcji zostanie umieszczony w elemencie iframe lub ramce ogrodzonej. Gdy funkcja reportWin() zakończy wykonywanie kodu i rozpocznie się renderowanie reklamy, zostaną pobrane adresy URL podane w funkcji sendReportTo(). |
(Również zaraportowane w poprzednich kwartałach) Obsługa testów A/B |
Poproś o pomoc dotyczącą testów A/B interfejsu PA API. | Rozmawiamy o tej prośbie tutaj. Chętnie poznamy też dodatkowe opinie. |
Kształtowanie natężenia ruchu | Propozycja od Google dotycząca zarządzania wymaganym procesem podejmowania decyzji przez serwer KV nie jest przydatna, ponieważ sprzedawcy nie mogą korzystać z backendu, co utrudnia kształtowanie natężenia ruchu. | Jak wspomnieliśmy w problemie z GitHubem, ujawnienie tego, czy dana platforma DSP jest na platformie DSP, może budzić wątpliwości użytkownika. Zasugerowaliśmy inne rozwiązania dotyczące tego problemu i przyjmujemy dalsze sugestie. |
Kształtowanie natężenia ruchu | Mechanizmy buforowania zwiększają złożoność i utrudniają platformom DSP poznawanie prawdziwego kształtu ruchu, dla którego będą ustalać stawki. | Mechanizm buforowania to sugerowana sugestia. Specjaliści ds. technologii reklamowych mogą korzystać z sugestii dopasowanych do ich potrzeb. Zachęcamy do dodatkowej dyskusji tutaj. |
Etykiety | Chrome powinien udostępniać tę etykietę jako parametr w żądaniach wysyłanych do zaufanych serwerów kupujących i sprzedawców. | Żądanie wygląda na uzasadnione, ponieważ wydaje się być w dużej mierze zgodne z celem odpowiedzialnego wykorzystania danych z Instagrama. Rozpatrzymy ją jednak i poddamy jej wewnętrznej analizie. W miarę postępów w dyskusjach opublikujemy publicznie informacje na ten temat. |
Używanie API | Wyjaśnienie jednoznacznej definicji grupy „control_1” w dokumencie „Dodatkowe wytyczne CMA dla osób trzecich dotyczące testowania”. W szczególności obawiamy się, że zmiana sformułowania może zostać błędnie zinterpretowana jako wymagająca wykluczenia wszystkich interfejsów API Piaskownicy prywatności z elementu Control_1. | Przedstawiliśmy nasze poglądy na ten temat w tym wątku na GitHubie. W związku z tym nie jesteśmy uprawnieni do wypowiadania się w imieniu CMA. Zalecamy zgłaszanie wszelkich problemów związanych z interpretacją wskazówek dotyczących testowania bezpośrednio w CMA. |
Używanie API | Czy Chrome pozwoli na wywołanie JoinAdInterestGroup() w przypadku pustej strony podczas przekierowania do innego zasobu? | Jeśli użytkownik odwiedza jakąś witrynę, jej właściciel może przekazać możliwość wywoływania funkcji JoinAdInterestGroup zewnętrznemu. To przekazanie umożliwia osobom trzecim tworzenie Instagrama bez konieczności dodawania jakiegokolwiek rodzaju przekierowania przez pustą stronę. Czekamy na opinie na temat konkretnych powodów, dla których warto utworzyć Instagram w trakcie przekierowania, zamiast korzystać z odpowiedniego mechanizmu przekazywania dostępu. |
Używanie API | Giełdy powinny mieć możliwość zapisu Instagrama na stronach należących do wydawców, z którymi współpracują, oraz przekazywania uprawnień do ustalania stawek na Instagramie dowolnym kupującym lub DSP. | Otrzymaliśmy Twoją opinię i zastanawiamy się, czy możemy ją zaakceptować. Czekamy na dodatkowe opinie od członków ekosystemu. |
Używanie API | Jeśli nikt nie wygra aukcji interfejsu API PA, nie jest wysyłane powiadomienie o stracie związanej z debugowaniem. | Funkcje reportWin i reportResult w Chrome są zaprojektowane do raportowania wygranych na poziomie zdarzenia w systemie aukcji prywatności. W sytuacji, gdy wszystkie stawki są odrzucane podczas aukcji reklam spersonalizowanych, funkcje te nie powinny być wywoływane, ponieważ nie zostaje wyłoniony zwycięzca. Niedawna aktualizacja Chrome może wyjaśniać rozbieżności, ponieważ adresy URL przekazywane do forDebuggingOnly.reportAdAuctionLoss() nie pojawiają się w panelu sieci DevTools. Zalecamy zweryfikowanie tej funkcji przy użyciu kompilacji Chrome w wersji Canary lub deweloperskiej. |
Używanie API | Czy parametr adCost zwracany z funkcji generatebid może mieć wartość ujemną (został już stochastycznie zaokrąglony do 2 bajtów)? | Koszt reklamy to koszt kliknięcia lub konwersji reklamodawcy przekazany z metody generatebid() do metody reportWin(). Ta wartość może mieć wartość Null lub być podwójną. Wartości ujemne będą ignorowane i nie będą przekazywane. Po przekazaniu wartość zostanie stochastycznie zaokrąglona. |
Ulepszenia interfejsu API | Czy do obsługi kierowania / kohort / atrybucji i aukcji mogą być używane zaufane i zaszyfrowane serwery wykonywania zamiast przeglądarki Chrome? | Zalecamy zapoznanie się z opartymi na TEE komponentami i opcjami w interfejsie PA API (np. serwerami KV i usługami B&A), a także opartymi na TEE komponentami funkcji Attribution Reporting i agregacji prywatnej (np. usługa agregacji), które odpowiadają na to pytanie. |
Ulepszenia interfejsu API | Czy odpowiedź na aukcję w Piaskownicy prywatności może być odpowiedzią na stawkę (np. określenie stawek przez kod w nagłówku), a nie na reklamę (np. w tagach reklamy)? | Ten typ zmiany zasadniczo zmienia właściwości prywatności interfejsu API PA, dlatego nie bierzemy pod uwagę. |
Kontrola wydawców | Czy wydawcy mogą blokować kreacje interfejsu PA API na swoich stronach? | Chrome oferuje propozycję skanowania kreacji w czasie rzeczywistym, która nie jest jeszcze dostępna do testów. Nie jest to jeszcze możliwe, ale zauważyliśmy, że większość platform SSP opracowała rozwiązania, które to umożliwia. |
Używanie API | Jaki jest limit rozmiaru w przypadku perBuyerSignals? | W klasycznej postaci perBuyerSignals nie wprowadza żadnych ograniczeń rozmiaru w Chrome. Główne ograniczenia polegają na tym, że dane pozostają poddane serializowaniu w formacie JSON i nie powodują nadmiernego zużycia pamięci. Należy jednak pamiętać, że bardzo duże i złożone sygnały perBuyerSignal mogą niekorzystnie wpływać na skuteczność. Istnieje alternatywna metoda przekazywania sygnałów perBuyerSignal za pomocą metody directFromSellerSignalsHeaderAdSlot. Ta metoda przesyła sygnały perBuyerSignals w nagłówku, przy czym maksymalny rozmiar całej odpowiedzi nagłówka nie może przekraczać 10 KB. Ponadto poszczególne serwery mogą nakładać własne ograniczenia maksymalnego rozmiaru nagłówka. |
Dokumentacja | Należy zmienić dokumentację dotyczącą wywołania recordAdBeacon z poziomu generatebid. | 17 lutego zaktualizowaliśmy te dokumenty . |
Używanie API | W jaki sposób reportEvent wybiera właściwy URL obrazu typu beacon spośród wielu zarejestrowanych opcji? | Każda aukcja generuje osobną konfigurację, co z kolei powoduje utworzenie osobnej mapy raportowania. Poszczególne aukcje (i ich ramki) są całkowicie oddzielone od siebie i nie udostępniają danych. Więcej informacji na ten temat znajdziesz w wyjaśnieniu „Raportowanie reklam w ramkach obok niego”. |
Interfejs Chrome | Dodaj filtr w Narzędziach deweloperskich w Chrome, „Aplikacja -> Grupy zainteresowań”, co umożliwia filtrowanie według właściciela Instagrama (lub nawet nazwy Instagrama). | Rozpatrujemy Twoją prośbę i chętnie poznamy dodatkowe opinie od członków ekosystemu. |
Chrome bez interfejsu graficznego | Obsługa interfejsu PA API w Chrome bez interfejsu graficznego. | Niektóre składniki interfejsu PA API są powiązane z Chrome, na przykład wywołania k-anon do serwerów Google, które mogą nie działać w „starej” przeglądarce Chrome bez interfejsu graficznego. Uważamy, że może to rozwiązać ten problem w „nowej” wersji Chrome bez interfejsu graficznego, która została udostępniona w Chrome 112. |
Używanie API | W przypadku raportowania strat za pomocą reportAdAuctionLoss widzimy w wielu przypadkach wartość „topLevelWinningbid=0”. Jak to interpretować? | Wartość topLevelWinningbid pochodzi z funkcji ScoreAd() w komponencie sprzedawcy najwyższego poziomu. Ta wartość odgrywa rolę przy ustalaniu wyniku aukcji najwyższego poziomu. Jak wynika z objaśnienia, wartość topLevelWinningStawki wynosząca 0 lub dowolna liczba ujemna oznacza, że dana reklama nie kwalifikuje się do wygrania aukcji. Mechanizm ten można np. odfiltrowywać reklamy kierowane na grupy zainteresowań, które nie są ważniejsze niż reklamy kierowane kontekstowo. Choć wartość najwyższego poziomu w wysokości zero-value może wskazywać, że wygrała aukcja kontekstowa, specyfikacja interfejsu API PA uznaje, że na taki wynik mogą mieć wpływ inne czynniki. |
Testowanie w trybie A/B | Wyjaśnienie dotyczące promptów w Trybach B i A dotyczących wyboru ruchu i rezygnacji z nich. | Kryteria uwzględnienia w Trybach A i B są takie same. Celem jest utworzenie grup reprezentatywnych dla normalnego ruchu Chrome, o ile obsługują one interfejsy API Piaskownicy prywatności i metodę oznaczania etykietami (np. niektóre konfiguracje klienta nie są zgodne). Na potrzeby eksperymentu ważne jest, aby porównywać tylko ruch oznaczony etykietą z innym ruchem oznaczonym etykietą. Użytkownicy Trybu B mają włączoną funkcję ochrony przed śledzeniem i otrzymują powiadomienie o tej funkcji. |
Ulepszenia interfejsu API | Czy właściwość „lifetimeMs” można dodać jako bezpośrednią właściwość w wywołaniu joinAdInterestGroup lub zarządzać nią jako oddzielnym argumentem? | Dokładnie analizujemy opinie społeczności programistów stron internetowych na temat funkcji „joinAdInterestGroup” w ofercie interfejsu API PA. Kluczowym punktem do dyskusji jest optymalna metoda zarządzania czasem aktywności IG. Sprawdzamy korzyści płynące z oddzielnego argumentu dotyczącego parametru „lifetimeMs”, ponieważ promuje on elastyczność i możliwość dostosowania do możliwych ulepszeń specyfikacji w przyszłości. Omawiamy ten problem tutaj. Chętnie poznamy Twoją opinię na ten temat . |
Używanie API | Potencjalny wzrost współczynników wyników fałszywie negatywnych w interfejsie PA API z powodu kolizji z identyfikatorami przeglądarek o niskiej entropii. | Zespół Chrome aktywnie pracuje nad ulepszaniem platformy interfejsu PA API. Dziękujemy za dyskusję na temat potencjalnych wskaźników fałszywie negatywnych wynikających z kolizji identyfikatorów przeglądarki. Dokładnie analizujemy te opinie i postaramy się, aby zaktualizowane analizy w pełni uwzględniają wszystkie istotne czynniki. Naszym celem jest znalezienie rozwiązania, które przynosi pożądane rezultaty w zakresie prywatności przy zachowaniu dokładności i niezawodności. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Czy identyfikator przeglądarki o niskiej entropii jest niezbędny, aby klienci nie powtarzali próśb o dołączenie do tego samego obiektu w systemie k-anonimowości? | Doceniamy i doceniamy toczącą się dyskusję na temat wykorzystywania identyfikatorów przeglądarek do wdrażania systemów k-anonimowości. Rozumiemy obawy związane z potencjalnymi konsekwencjami stosowania takich identyfikatorów na potrzeby prywatności. Mimo że na początku jako mechanizm zapobiegający nadużyciom korzystaliśmy z identyfikatora o niskiej entropii, aktywnie badamy też inne metody, takie jak anonimowe tokeny zliczające, które kładą nacisk na prywatność użytkowników przy zachowaniu integralności systemu. Zależy nam na szukaniu rozwiązań, które równoważą odpowiedzialne wykorzystanie danych z niezawodnymi mechanizmami ochrony prywatności. Jesteśmy otwarci na dalszy dialog ze społecznością badaczy. Omawiamy tę kwestię tutaj. Chętnie poznamy Twoją opinię na ten temat . |
Używanie API | Czy AMP (Accelerated Mobile Pages) obsługuje interfejs PA API? | Strony AMP nie obsługują obecnie natywnie interfejsu PA API. Jeśli obsługa standardu AMP jest dla nas priorytetem, chętnie zapoznamy się z dodatkowymi opiniami od ekosystemu. |
Ulepszenia interfejsu API | Rozważ usunięcie tego typu z kontroli k-anonimowości. | Starannie analizujemy opinie na temat potencjalnej optymalizacji struktur żądań k-anonimowości. Rozumiemy sugestie dotyczące konsolidacji parametrów i potencjalnie ujednolicenia typów w celu usprawnienia procesu. Naszym celem jest zapewnienie wydajności i łatwości obsługi. Analizujemy wszystkie opcje w trakcie opracowywania naszych rozwiązań w zakresie ochrony prywatności. Omawiamy ten problem tutaj. Chętnie poznamy Twoją opinię na ten temat . |
Interfejs Chrome | Poproś o mechanizmy dla mniej zaawansowanych użytkowników, którzy będą mogli łatwo przeglądać posiadane przez nich Instagramy i nimi zarządzać, w tym mechanizm rezygnacji z rezygnacji na poziomie witryny. | Zdajemy sobie sprawę, jak ważne jest oferowanie łatwych w użyciu narzędzi do interpretowania IG i zarządzania nimi. Dokładnie wzięliśmy pod uwagę różne metody i zauważyliśmy, że identyfikacja IG według witryny, w której są połączone, zapewnia największą równowagę między przejrzystość a ochroną prywatności. Obecnie globalne zarządzanie Instagramem odbywa się w ustawieniach Chrome. Stale szukamy nowych sposobów na ulepszenie tej funkcji dla użytkowników. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Bezpieczeństwo interfejsów API | Czy interfejs PA API jest podatny na wyciek danych osobowych w wyniku interakcji z reklamami, nawet w kontekście chronionych ramek? | Zdajemy sobie sprawę z możliwości wycieku informacji przez zaawansowane interakcje z reklamami. Aktywnie badamy współdziałanie między ramkami zabezpieczonymi, interfejsem PA API i potencjalnymi wektorami ataku. Eliminowanie ryzyka związanego z prywatnością jest naszym priorytetem, dlatego zależy nam na opracowywaniu niezawodnych rozwiązań, które równoważą innowacyjność z ochroną użytkowników. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Czas oczekiwania | Czy domyślny czas oczekiwania wynoszący 50 ms w przypadku logiki ustalania stawek przez kupującego jest realną wartością? | Rozumiemy obawy związane z potencjalnymi rozbieżnościami między specyfikacją a czasem wysyłania żądań sieciowych do logiki określania stawek. Aktywnie sprawdzamy specyfikacje, aby zapewnić ich dokładność i sprawdzamy optymalne domyślne ustawienia limitu czasu, aby zrównoważyć wydajność i wykonalność. Omawiamy ten problem tutaj. Chętnie poznamy Twoją opinię na ten temat . |
Dokumentacja | Potencjalny wyciek czasu w specyfikacji, w wyniku którego witryna może określić, czy reklama nie przekroczyła progu k-anonimowości, a także jakie konsekwencje ma śledzenie w witrynach. | Rozumiemy zgłoszony problem związany z potencjalnym wyciekiem informacji o czasie. Potwierdziliśmy rozbieżności w specyfikacji i podejmujemy działania, aby przed aukcją określić stan k-anonimowości reklam, aby zapobiec takim wyciekom informacji. Tego typu wątpliwości traktujemy poważnie i aktualizujemy specyfikację, aby odzwierciedlała te zmiany. Omawiamy ten problem tutaj. Chętnie poznamy Twoją opinię na ten temat . |
Używanie API | Sposoby implementacji listy zablokowanych SSP w interfejsie API PA. | Zdajemy sobie sprawę, że potrzebują mechanizmów umożliwiających zarządzanie ograniczeniami dotyczącymi reklam przez platformy SSP. Zachęcamy do zapoznania się z rozwiązaniami, które traktują priorytetowo ocenę na urządzeniu i wykorzystują istniejące metadane reklam, aby chronić prywatność użytkowników przy jednoczesnym zapewnianiu elastyczności. Współpracujemy z deweloperami, aby znaleźć optymalne metody w interfejsie API PA. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Czy ktoś może poprosić przeglądarkę, aby udawała, że korzysta z interfejsu PA API w sposób, którego witryny nie potrafią wykryć? | Zdajemy sobie sprawę, że w obecnej formie rezygnacja z korzystania z interfejsu PA API może być wykrywana przez witryny. Pracujemy nad takimi funkcjami jak dodatkowe stawki i kierowanie wykluczające, a także nad renderowaniem chronionych ramek, aby zwiększyć ochronę prywatności i udostępnić niewykrywalne opcje rezygnacji. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Testowanie w trybie A/B | Ruch w centrum danych, który prawdopodobnie ma być traktowany jako 1.1. | Zespół Chrome potwierdził z zespołem GAM, że ten ruch jest obecnie odfiltrowywany z eksperymentu. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Skuteczność i uczciwość implementacji interfejsu InterestGroupBuyers w interfejsie API PA. | Zdajemy sobie sprawę z toczącej się dyskusji na temat skuteczności i uczciwości pola „InterestGroupBuyers” w aukcjach interfejsów API PA. Zdajemy sobie sprawę z problemów związanych z wydajnością, prywatnością i uczciwością rynku. Chociaż sprzedawcy muszą zarządzać relacjami biznesowymi z kupującymi, pracujemy nad sposobami optymalizacji procesu dopasowywania. Mogą one obejmować dynamiczne korekty oparte na danych w czasie rzeczywistym i modele hybrydowe. Nadal dokładamy wszelkich starań, aby szukać rozwiązań, które traktują priorytetowo prywatność użytkowników i są zgodne z konkurencyjnym ekosystemem reklamowym. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Interfejs Chrome | Potencjalne problemy z pamięcią i przejrzystość interfejsu związane z IG w Chrome. | Rozumiemy obawy związane z wyświetlaniem IG w Narzędziach deweloperskich. Chociaż obecny widok obejmuje wszystkie zdarzenia IG w ramach śledzenia historycznego, doceniamy tę wartość, ponieważ zapewniamy lepszy wgląd w bieżący stan przechowywanych internetowych grup dyskusyjnych. Przeanalizujemy optymalizacje i ewentualne ulepszenia interfejsu, aby ulepszyć statystyki dla deweloperów. Jeśli chodzi o zarządzanie pamięcią, implementacja IG została zaprojektowana tak, aby zapobiegać wyciekom pamięci, ale stale monitorujemy i optymalizujemy wykorzystanie zasobów. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Dokumentacja | Podczas próby użycia nazwanych rozmiarów reklam bezpośrednio w polu „sizeGroup” funkcji „joinAdInterestGroup” wystąpił błąd. Chce się dowiedzieć, czy jest to zamierzone działanie. | Doceniamy wartość usprawnienia konfiguracji reklam w ramach funkcji „joinAdInterestGroup”. Pracujemy nad rozwiązaniem tego problemu i planujemy włączyć tę funkcję w kolejnych aktualizacjach. Ta zmiana jest wyrazem naszego zobowiązania do zapewnienia deweloperom elastycznych i skutecznych narzędzi do zarządzania reklamami. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Etykieta testowania obsługiwanego przez Chrome | Poproś o bezpośrednie dane dotyczące Trybów A i B oraz dokładne etykiety w SendReportTo, aby umożliwić nam spójne śledzenie eksperymentu. | Rozmawiamy o tej prośbie tutaj. Chętnie poznamy też dodatkowe opinie. |
Dokumentacja | Czy nazwa domeny sprzedawcy jest uwzględniana w żądaniach wysyłanych do zaufanego serwera sprzedawcy w celu weryfikacji? | Zdajemy sobie sprawę, że w dokumentacji interfejsu Protected Audience API Server API został on pominięty. Chcemy zapewnić programistów, że nazwa domeny sprzedawcy jest automatycznie uwzględniana w żądaniach wysyłanych do zaufanego serwera sprzedawcy. Ta funkcja jest niezbędna do skutecznego sprawdzania poprawności reklam. Zaktualizowaliśmy dokumentację w odpowiedzi na tę sytuację. Nadal będziemy traktować priorytetowo jej przejrzystość i przejrzystość dla społeczności deweloperów. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Potencjalne metody dodawania nazwy tagu witryny do wywołań śledzenia wyświetleń reklam na potrzeby raportowania. | Dokładamy wszelkich starań, aby znaleźć równowagę między potrzebą stosowania niezawodnych mechanizmów raportowania a podstawową zasadą ochrony prywatności użytkowników. Uwzględnienie nazw z Instagrama w śledzeniu wyświetleń reklam podlega środkom ochrony k-anonimowości, które mają na celu uniemożliwienie identyfikacji poszczególnych osób. Będziemy w dalszym ciągu badać innowacyjne rozwiązania w zakresie raportowania uwzględniające ograniczenia związane z prywatnością. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Funkcja interfejsu API | Żądanie, aby zaufany serwer kupującego odbierał nagłówki HTTP z podpowiedziami klienta. | Tę prośbę o dodanie funkcji śledzimy tutaj. |
Używanie API | Czy plik przekazywania dostępu powinien wymagać nagłówka „Access-Control-Allow-Origin” do wczytania, ponieważ określa on zachowanie członkostwa IG w przeglądarce? | Stosujemy się do sprawdzonych metod zapewniania bezpieczeństwa w sieci. Wymóg używania nagłówka „Access-Control-Allow-Origin” w przypadku plików przekazywania dostępu zapewnia spójność z zasadami CORS i zapobiega niezamierzonemu ujawnieniu informacji poufnych. Sprawdzamy, jak zoptymalizować ten proces przy zachowaniu silnego stanu zabezpieczeń. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Włącz obsługę personalizacji kreacji w serwerach reklam w ramach platformy PA API. | Zdajemy sobie sprawę z roli, jaką serwery reklam mogą odgrywać w personalizacji kreacji. Aktywnie poszukujemy rozwiązań wspierających serwery reklam w interfejsie API reklam spersonalizowanych, takich jak „połączony model IG”, w którym można by było łączyć logikę określania stawek i wyboru kreacji. Naszym celem jest znalezienie równowagi między tworzeniem wydajnych kreacji reklamowych a ochroną prywatności użytkownika. Zachęcamy do dalszej współpracy i przesyłania opinii na temat ulepszania interfejsu API, tak aby spełniał potrzeby wszystkich zainteresowanych osób. Kliknij tutaj. |
Kwestie dotyczące prywatności | Dostępność alternatywnych identyfikatorów (np. RampID, ID5) w pytaniach o stawkę kontekstową może zagrażać celom dotyczącym prywatności interfejsu PA API, ułatwiając zbieranie danych z różnych witryn. | Zdajemy sobie sprawę z potencjalnego napięcia między identyfikatorami pochodzącymi z różnych witryn a celami interfejsu PA API w zakresie ochrony prywatności. Wydawcy mogą zdecydować się na udostępnianie takich identyfikatorów, ale zasadniczo projekt interfejsu API PA ma na celu odseparowanie wyboru reklam od konieczności śledzenia w wielu witrynach. Dokładamy wszelkich starań, aby rozwijać ekosystem reklam nastawiony na prywatność i zachęcamy deweloperów do priorytetowego traktowania podejścia do interfejsu PA API. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Zapisywanie w pamięci podręcznej | Czy mogę zapobiec wykorzystywaniu skryptów ustalania stawek w wielu aukcjach? | Zdajemy sobie sprawę z zaobserwowanego zachowania buforowania skryptów ustalania stawek w ramach platformy PA API. Chociaż obsługiwane są standardowe mechanizmy buforowania HTTP, możliwe jest ponowne wykorzystanie skryptu w różnych aukcjach ze względu na zachowanie zawieszania urządzeń i projekt wykonawców określania stawek. Zespół analizuje rozwiązania, które zapewnią kupującym większą kontrolę nad przechowywaniem skryptów w celu efektywnego zarządzania strategiami ustalania stawek. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Scentralizuj raportowanie aktywności związanej z ustalaniem stawek we wszystkich Instagramach na potrzeby platformy DSP, szanując prywatność użytkowników. | Projektując interfejs PA API, priorytetowo traktujemy prywatność użytkowników. Bezpośrednie raportowanie poszczególnych zdarzeń określania stawek nie jest możliwe z powodu ryzyka śledzenia w witrynach, ale oferujemy mechanizmy takie jak pamięć współdzielona i agregacja prywatna. Dzięki nim platformy DSP mogą uzyskiwać zbiorcze statystyki aktywności związanej z określaniem stawek w sposób zapewniający ochronę prywatności użytkowników. |
Używanie API | Pobieranie z funkcji sendReportTo() w funkcji reportResult() odbywa się tylko przez 94% czasu w porównaniu z pobieraniem zarejestrowanym za pomocą funkcji forDebuggingOnly.reportAdAuctionWin(). | Oba adresy URL mogą być pobierane w różnym czasie w tym samym czasie. W niektórych przypadkach worklet sprzedawcy komponentu został usunięty i trzeba go ponownie załadować, aby można było uruchomić funkcję reportResult(). Jednak ani czas potrzebny na pobranie logiki punktacji, ani czas na ponowne załadowanie zadanialetu nie mają wpływu na 50-ms czasu oczekiwania dla funkcji reportResult(). Pamiętaj, że Chrome użyje nagłówków buforowania do określenia sposobu pobierania w przypadkach, gdy zbiór zadań trzeba ponownie załadować. Więcej informacji o fazach aukcji reklam spersonalizowanych znajdziesz tutaj. |
K-anonimowość | Prośba o potwierdzenie, że nazwa grupy zainteresowań nie wpływa na k-anonimowość wyświetlania reklam. | Aby można było uznać kreację za k-anonimową, krotka adresu URL właściciela tagu witryny, adresu URL skryptu ustalania stawek, adresu URL kreacji i rozmiaru reklamy musi w przeszłości osiągnąć określony próg (k). Stan k-anonimowości jest okresowo aktualizowany (p). |
Interfejs Chrome | Propozycja udostępnienia typu „widoczności wewnętrznej”, który oferuje wiele platform MVC, ORM itp. Możesz np.zacząć od prostego rejestrowania wybranych zdarzeń wewnętrznych w nowym panelu w sekcji Narzędzia dla deweloperów --> Aplikacja --> Aplikacja. | Omawiamy tę propozycję tutaj. Chętnie poznamy też dodatkowe opinie. |
Interfejs Chrome | Łączenie z indywidualnymi elementami interfejsu w Narzędziach deweloperskich nie pokazuje elementów powiązanych z priorytetem. | Rozwiązaliśmy ten problem tutaj. |
Ulepszenia interfejsu API | Najlepiej zezwolić serwerowi reklam na śledzenie własnych zdarzeń. Czy można konfigurować listę dozwolonych domen śledzenia? | Opublikowaliśmy naszą propozycję tutaj. Zachęcamy do przekazywania opinii od członków ekosystemu. |
Prośba o dodanie funkcji interfejsu API | Czy interfejs PA API może zostać rozszerzony do obsługi transakcji multimedialnych nie RTB i utrzymania kluczowych przypadków użycia, takich jak wyświetlanie reklam i DCO? | Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Limit czasu aukcji wydawcy | Wydawcy potrzebują kontroli nad czasem trwania aukcji, by zapobiec utracie wyświetleń, zwłaszcza w przypadku konfiguracji określania stawek przez kod w nagłówku, w których reklamy są wybierane w sposób sekwencyjny. | Zdajemy sobie sprawę, jak ważne jest zapewnienie wydawcom szczegółowej kontroli nad limitami czasu oczekiwania na reklamy w ramach aukcji reklam. Aktywnie badamy, jak wdrożyć mechanizm globalnego limitu czasu aukcji (potencjalnie w obiekcie „auctionConfig”), jednocześnie dokładnie analizując przypadki skrajne. Ta funkcja ma na celu optymalizację współczynników wypełnienia wyświetleń dla wydawców. Będziemy nadal współpracować ze społecznością w celu znalezienia najlepszego rozwiązania. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Ulepszenia interfejsu API | Obecny wygląd IG w interfejsie API PA prowadzi do dużych rozmiarów metadanych z powodu długich adresów URL renderowania. Testerzy chcieliby skompresować te adresy URL, aby zwiększyć wydajność. | Zdajemy sobie sprawę, jak ważna jest optymalizacja rozmiaru metadanych w przypadku Instagrama, zwłaszcza w przypadku aukcji reklam, w których liczy się efektywność. Naszym zdaniem rozwiązanie oparte na szablonach do kompresowania URL-i renderowania ma istotny potencjał. Starannie ocenimy proponowane projekty szablonów i upewnimy się, że każde wdrożone rozwiązanie zawiera niezawodne mechanizmy zapobiegające nadużyciom, które zapewniają stabilność przeglądarki. Najważniejsza jest współpraca ze społecznością ds. standardów internetowych w celu opracowania optymalnego podejścia, biorąc pod uwagę te kwestie. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Testerzy, którzy obsługują formaty reklam natywnych, chcą zoptymalizować proces aukcji w Piaskownicy prywatności, pobierając wiele wyników reklam w jednym wywołaniu, co pozwoli ograniczyć obciążenie sieci i przyspieszyć renderowanie reklam. | Zdajemy sobie sprawę z zastrzeżeń dotyczących skuteczności renderowania reklam natywnych w Piaskownicy prywatności. Dbamy o zachowanie równowagi między skutecznością a dobrą ochroną prywatności użytkowników. Chociaż zwracanie wielu reklam z pełnym wynikiem narusza prywatność, szukamy nowych sposobów optymalizacji procesu aukcji. Dokładamy wszelkich starań, aby poprawić obsługę formatów reklam natywnych przez interfejs API reklam natywnych i badać alternatywne mechanizmy, które pozwolą zwiększyć wydajność w ramach Piaskownicy prywatności. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Elastyczność w sposobie oceniania i sortowania stawek za reklamy w Piaskownicy prywatności, zwłaszcza jeśli chodzi o poziomy priorytetów i reguły rynku prywatnego. | Zdajemy sobie sprawę, że w Piaskownicy prywatności trzeba mieć szczegółową kontrolę nad oceną i sortowaniem reklam, zwłaszcza w złożonych scenariuszach ustalania stawek. Doceniamy proponowane rozwiązania wykorzystujące krotki i funkcje matematyczne, które pozwalają uzyskać wielowymiarową punktację bez negatywnego wpływu na prywatność użytkowników. Takie rozwiązania mogą utrudniać pracę programistom, ale dają niezbędną ekspresję. Dokładamy wszelkich starań, aby usprawnić te procesy, potencjalnie za pomocą funkcji pomocniczych lub wytycznych, aby zapewnić optymalne wykorzystanie funkcji Piaskownicy prywatności na potrzeby zaawansowanej logiki aukcji. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
reportEvent() | Dodaj nowe zarezerwowane zdarzenie (np. automatyczny obraz typu beacon), które jest wywoływane przez przeglądarkę po zainicjowaniu ramki z kreacją z reklamą. | Rozmawiamy o tej prośbie tutaj. Chętnie poznamy też dodatkowe opinie. |
adCost | Umożliwiają zestawienie kosztu reklamy. | Każda wartość kosztu umożliwia wysłanie ograniczonej ilości informacji z aukcji. Dopuszczenie całej listy N tych kosztów wystarczyłoby do wysłania całego identyfikatora użytkownika, co umożliwiłoby śledzenie w witrynach. Rozmawiamy o tym tutaj. Chętnie poznamy Twoją opinię. |
resolveToConfig | Czy parametr resolveToConfig powinien być dziedziczony z najwyższego poziomu i udostępniany w mechanizmie BrowserSignals? | Rozmawiamy o tej prośbie tutaj. Chętnie poznamy też dodatkowe opinie. |
Lepsze narzędzia | Czy jest coś podobnego do chrome://topics-internals, ale dla interfejsu PA API? | Nic nie jest dokładnie takie samo. Istnieje jednak obszerne narzędzia programistyczne dla interfejsu PA API. |
Etykiety | Czy Chrome może wykorzystać etykiety do zidentyfikowania 20% populacji k-anon? | Rozpatrujemy tę prośbę i chętnie poznamy dodatkowe opinie od członków ekosystemu. |
Dokumentacja | Czy Worklety aukcji Piaskownicy prywatności staną się standardowymi typami Workletów? | Ze względu na unikalne wymagania związane z prywatnością i bezpieczeństwem te worklety znacznie różnią się od standardowych typów Workletów przeglądarki, dlatego nie przewidujemy, aby wkrótce staną się standardowymi typami Workletów w specyfikacji HTML. Staramy się rozbudować nasze zasoby dla programistów, dodając jasne wyjaśnienia dotyczące środowiska wdrażania i środowiska wykonywania zadań aukcyjnych, aby informacje te były bardziej dostępne dla uczestników Piaskownicy prywatności. Więcej informacji na ten temat znajdziesz tutaj. |
Serwer klucz-wartość (KV) – własny serwer (BYOS) | Strony mogą być w stanie nauczyć się wielu kluczy IG (od tego samego właściciela) połączonych przez użytkownika za pomocą zapytań usług KV w konfiguracji usługi BYOS KV. | Nie będzie to już możliwe, gdy serwery KV działają w TEE. Możemy też zapewnić zgodność tych serwerów z opublikowanym modelem zaufania. |
userBiddingSignals | aktualizować część elementu „userWyznaczenia stawek”, jednocześnie zachowując pozostałe. | Jest to już możliwe bez wprowadzania zmian w interfejsie API. |
Używanie API | Zaimplementuj ograniczenie liczby wyświetleń w wielu Instagramach w ramach Piaskownicy prywatności, potencjalnie korzystając z serwera KV lub zmodyfikowanych danych „prevWinsMs”. | Doceniamy potrzebę zaawansowanych funkcji ograniczania liczby wyświetleń w ramach Piaskownicy prywatności. Zdajemy sobie sprawę, że obecne ograniczenia w zakresie udostępniania danych między IG mogą stanowić wyzwanie przy wdrażaniu tych strategii. Serwer KV zapewnia potencjalny mechanizm z odpowiednimi zabezpieczeniami prywatności, ale zachęcamy deweloperów do poszukiwania rozwiązań w ramach jednego modelu IG. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Używanie API | Sprzedawcy komponentów (którzy biorą udział w zagnieżdżonych aukcjach w ramach Piaskownicy prywatności) muszą mieć wgląd w limity czasu aukcji najwyższego poziomu, aby zoptymalizować własne konfiguracje i uniknąć niepotrzebnych opóźnień. | Zdajemy sobie sprawę, że zachodzi potrzeba lepszej koordynacji czasu oczekiwania między sprzedawcami najwyższego poziomu a sprzedawcami komponentów w Piaskownicy prywatności. Aktywnie badamy dodawanie nowych mechanizmów limitów czasu oczekiwania, w tym potencjalnego limitu czasu całej aukcji i sposobów stosowania limitów czasu najwyższego poziomu do aukcji komponentów. Naszym celem jest zwiększenie skuteczności i przewidywalności dla wszystkich uczestników procesu aukcji w Piaskownicy prywatności. Omawiamy ten problem tutaj. Chętnie poznamy też dodatkowe opinie. |
Usługi Protected Audience API
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Trusted Execution Environments (TEE) | Wdrażanie TEE w chmurze publicznej jest droższe niż w lokalnych centrach danych reklamowych? | Nasza reakcja jest podobna do wyników z poprzednich kwartałów: nasz obecny model zabezpieczeń TEE korzysta z praktyki wdrożeń w chmurze publicznej. W szczególności obecnie TEE oparte na sprzęcie nie chronią przed wszystkimi atakami fizycznymi. Nasi obecni obsługiwani dostawcy chmury publicznej (AWS i GCP) zaprojektowali i wdrożyli rozwiązania ograniczające ryzyko związane z dostępem fizycznym, m.in. ze strony pracowników. Poniżej znajdziesz więcej informacji na temat lokalnej pomocy. Specjaliści ds. technologii reklamowych zauważyli, że korzystanie z usług w chmurze jest droższe niż w lokalnych centrach danych. Nie jesteśmy w stanie ocenić tych stwierdzeń, ale chętnie poznamy dodatkowe opinie na temat kosztów i nieustannie analizujemy możliwości rozszerzenia obsługi TEE. |
T-shirty | Obsługa TEE w niepublicznych środowiskach chmurowych | Nasza reakcja jest podobna jak w poprzednich kwartałach: chociaż nadal pracujemy nad wsparciem innych opcji niż publiczne rozwiązania działające w chmurze, nie mamy obecnie planów dotyczących obsługi lokalnych TEE. Biorąc pod uwagę wymagania dotyczące bezpieczeństwa Piaskownicy prywatności i poważne wyzwania, jakie stwarzają wdrożenia lokalne, uważamy, że dalsze rozwijanie i ulepszanie wdrożeń działających w chmurze (np. wspieranie Google Cloud oprócz AWS) jest najkorzystniejsze dla ekosystemu. Chętnie poznamy jednak dodatkowe opinie na temat tego, dlaczego takie wymaganie jest niezbędne i wykonalne w świetle ograniczeń związanych z prywatnością i bezpieczeństwem. |
Inni dostawcy chmury | Pomoc dla innych dostawców chmury | Zawsze jesteśmy otwarci na sugestie dotyczące innych dostawców chmury, ale obecnie planujemy przynajmniej zapewnić obsługę GCP i AWS, gdy wprowadzimy model 3PCD. Więcej informacji znajdziesz w tym wyjaśnieniu. |
Interfejs API usług B&A | Jaki jest kierunek Google w sprawie interfejsu B&A Services API? Czy w aukcjach urządzeń będzie miały priorytet wyższy czy niższy niż chroniona grupa odbiorców w przeglądarce Chrome? | Reakcja jest podobna jak w poprzednich kwartałach: Niezmiennie przestrzegamy obecnego sposobu określania stawek w ramach Protected Audience API na urządzeniu. Zaproponowano usługi B&A w celu zbadania możliwych rozwiązań wspomagających podzbiór przypadków użycia, w których moc obliczeniowa lub szybkość sieci urządzenia mogą być ograniczone. |
Standaryzacja | Usługi B&A nie przeszły procesu standaryzacji. | Propozycja usług B&A jest w trakcie jednego etapu procesu standaryzacji. Cieszymy się, że możemy pomóc w jego realizacji. Zaczęło się od opracowania propozycji (na podstawie poprzednich propozycji). Jest ona publicznie udostępniana w ramach szeroko zakrojonej dyskusji w W3C, a zainteresowani deweloperzy mogą zacząć z nimi eksperymentować i przekazywać opinie. Jest to typowy wzorzec tworzenia funkcji internetowych, opisany na przykład w tym poście na naszym blogu. |
Serwer KV | Udostępnij pełny adres URL serwerowi KV kupującego na potrzeby kierowania na treść / kontekstowy / witryny. | Rozmawiamy o tej prośbie tutaj. Chętnie poznamy też dodatkowe opinie od zespołu. |
Dokumentacja | Dokumentacja na stronie GitHub dotycząca „Zaufane/Wymuszone komponenty i opcjonalne” powoduje niejasność dla niektórych techników reklam, którzy mają własny zestaw obrazów wdrożenia i infrastrukturę. | Pracujemy nad ulepszeniem dokumentacji dotyczącej „zaufanych/wymuszanych komponentów a elementów opcjonalnych”. Chcemy dowiedzieć się od ekosystemu, czy takie działania powinny zostać potraktowane priorytetowo. |
Ulepszenia interfejsu API | Kod stanu HTTP wywołania serwera KV powinien być również dostępny jako parametr dla funkcji ScoreAd(). | Rozpatrujemy Twoją prośbę i chętnie poznamy dodatkowe opinie od członków ekosystemu. |
Dokumentacja | Podaj więcej informacji o tym, jak zadania JS i WASM będą obsługiwane dokładnie podczas wykonywania UDF. | Postaramy się przesłać te informacje. Zachęcamy do przekazywania opinii tutaj. |
Dokumentacja | Poproś o zaktualizowanie nazwy repozytorium. | Zmieniliśmy nazwę repozytorium na „Protected-auction-key-value-service”. Jest to zgodne z terminem dotyczącym zbierania usług, do których należy, który obejmuje też inne repozytoria, takie jak dyskusja na temat usług Protected Audience Services i repozytorium dokumentacji dotyczącej usług chronionych aukcji. |
Dokumentacja | Usunięto odniesienie do interfejsu Cloud debugger API w pliku bid_auction_services_gcp_guide.md. | Zaktualizowaliśmy dokumentację i usunęliśmy plik referencyjny. |
Używanie API | Czas oczekiwania wywoływany przez wyszukiwanie KV trwa ponad 50 ms. Zajmie to prawie 100 ms. Czy możecie wskazać, co się sprawdziło u innych sprzedawców? Czy masz jakieś sugestie dotyczące mierzenia czasu oczekiwania i czasu oczekiwania? |
Wywołanie serwera KV odbywa się w kontekście uruchamianych skryptów, czyli w specjalnym chronionym środowisku przeglądarki Chrome. Ma to na celu ochronę informacji w tych elementach uruchamiających skrypty przed dostępem spoza interfejsu API. Szczegółowe wyjaśnienie znajdziesz tutaj. |
Używanie API | Czy jest określony czas oczekiwania na odpowiedź serwera KV w określonym czasie? | Sprzedawcy mogą określić pole „perBuyerCumulativeTimeouts” w konfiguracji aukcji. Ten limit czasu obejmuje czas potrzebny na pobranie zaufanych sygnałów ustalania stawek. |
Czas oczekiwania | W jaki sposób zespół Piaskownicy prywatności pracuje nad rozwiązaniem problemu z czasem oczekiwania? | Informacje o strategiach, które chcemy, aby opóźnienia nie przekroczyły akceptowalnego limitu, znajdziesz tutaj. |
Pomiary reklam internetowych
Attribution Reporting (i inne interfejsy API)
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Ręczna optymalizacja kampanii | Interfejs ARA nie obsługuje ręcznej optymalizacji kampanii. | Omówiliśmy ten scenariusz z technologią reklamową i pokazaliśmy sposoby wykorzystania interfejsu ARA do ręcznej optymalizacji kampanii. Technologia ARA została stworzona w sposób, który zapewnia elastyczność i elastyczność technologii reklamowych, która sprawdza się w różnych przypadkach użycia technologii reklamowych. Przedstawiliśmy kilka sugestii z wykorzystaniem różnych elastycznych konfiguracji na poziomie zdarzenia oraz wykorzystania raportów na poziomie zdarzenia z raportami podsumowującymi, aby zmniejszyć wpływ szumu i osiągnąć potrzeby ręcznej i automatycznej optymalizacji. Jesteśmy otwarci na dodatkowe opinie z ekosystemu dotyczące możliwości dostosowywania i elastyczności konfiguracji interfejsu ARA. |
Typ konwersji | Google zezwala na maksymalnie 8 typów konwersji, co jest ograniczone. | Wdrożyliśmy większość elastycznych raportów na poziomie zdarzenia, które dają technikom reklamowym dodatkową elastyczność w zakresie liczby okien raportowania, liczby raportów atrybucji i fragmentów danych reguły, z których mogą korzystać. Technicy reklamowi mogą wybrać konfigurację, która umożliwia pomiar nawet 32 różnych typów konwersji. |
Limit zdarzeń w raporcie zbiorczym | Minimalna liczba 20 zdarzeń konwersji w 1 zbiorczym raporcie jest niemożliwa w przypadku mniejszych reklamodawców z ograniczonym budżetem. | Nie ma minimalnej liczby zdarzeń konwersji potrzebnych w zbiorczym raporcie. Dodatkowo można podjąć różne decyzje projektowe w celu zoptymalizowania raportów zbiorczych dla mniejszych reklamodawców. Mogą to być na przykład zmiana kluczowej struktury lub śledzonych wymiarów, testowanie różnych poziomów epsilonu, testowanie dłuższych częstotliwości grupowania i testowanie różnych przydziałów budżetu między celami pomiarowych i łączenie raportów podsumowujących na poziomie zdarzenia. |
Dane w czasie rzeczywistym | Brak platform DSP danych w czasie rzeczywistym (np. o kliknięciach, sesjach i konwersjach), z których platformy te korzystają, by dostosować swoją strategię ustalania stawek i zwiększyć skuteczność kampanii, jest sprzeczne z wymogiem utrzymania dotychczasowych funkcji. | Nawet w przypadku interfejsu ARA kliknięcia i sesje są rejestrowane w czasie rzeczywistym, a konwersje są realizowane w czasie rzeczywistym – nawet w przypadku 3PC. |
Brakujące pola | Nie spełniasz wymagań związanych z wdrażaniem zdarzeń w pełni elastycznym: i) waluta oraz ii) pole orderID lub TransactionID. | Nie planujemy obsługiwania pola Waluta ani Identyfikator zamówienia / Identyfikator transakcji w ramach pełnego elastycznego poziomu zdarzenia, ponieważ można to już zrobić w bieżącym raportowaniu na poziomie zdarzenia. Jesteśmy otwarci na dodatkowe opinie dotyczące tych pól. Rozważymy je ponownie, jeśli pojawią się dodatkowe przypadki użycia, które ich wymagają. Sposoby wykorzystania obecnego interfejsu platformy ARA do mierzenia informacji o walucie i typie identyfikatora zamówienia: 1. Na podstawie opinii waluta jest określana na podstawie lokalizacji geograficznej użytkownika. Można ją dodać jako część parametru source_event_id, aby określić używaną walutę. 2. Z naszych informacji wynika, że pole identyfikatora zamówienia jest potrzebne, aby konwersje i wartości nie były zliczane podwójnie przez pomyłkę. Można to zrobić, korzystając z kluczy do usuwania duplikatów. |
Budżet na prywatność | Budżet ochrony prywatności w ARA ogranicza możliwość przeprowadzania pomiarów w wielu wymiarach | Interfejs ARA zaprojektowano w taki sposób, aby umożliwiać technikom reklamowym dostosowywanie własnych konfiguracji interfejsu ARA do różnych scenariuszy atrybucji. Obecna technologia ARA musi uwzględniać kompromis między pomiarami wymiarów a wpływem szumu na dane. Dodawanie szumu do danych w zależności od szczegółowości wymiarów objętych pomiarem jest kluczowe dla ochrony prywatności. Jesteśmy otwarci na dodatkowe opinie z ekosystemu dotyczące możliwości dokonywania pomiarów w różnych wymiarach, ale musimy poznać konkretne przypadki użycia, które tego wymagają. |
Zaktualizuj specyfikację | Poinformowaliśmy, że przeszliśmy ze stałego okna raportowania na elastyczne, ale nie zostało to odzwierciedlone w specyfikacjach technicznych Google, które obecnie obowiązują na minimalnym przedziale czasu wynoszącym jedną godzinę. | Elastyczne raportowanie na poziomie zdarzenia umożliwia obecnie technikom reklamowym zmianę liczby raportów atrybucji na zdarzenie źródłowe, bitów danych reguły oraz liczby i długości okien raportowania. Interfejs ARA nadal ma minimalny 1-godzinny okres raportowania w przypadku raportów na poziomie zdarzenia, co jest niezbędne do zachowania prywatności i zminimalizowania ryzyka związanego z odtworzeniem niektórych rodzajów ataków polegających na odtwarzaniu historii. Ponieważ raporty podsumowujące zawierają informacje zbiorcze, technologie reklamowe mogą od razu włączyć otrzymywanie raportów zbiorczych bez opóźnień. |
Projektowanie interfejsów API | Martwi się, że ograniczenie informacji w raportach dotyczących konwersji i dodanie szumu może mieć większy wpływ na ekosystem niż Google. | Firma Google zobowiązała się do opracowania i wdrożenia propozycji Piaskownicy prywatności w taki sposób, aby nie zniekształcać konkurencji przez samo traktowanie własnej firmy przez Google i uwzględniać wpływ na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców niezależnie od skali działalności. |
Korekta atrybucji | ARA nie pozwala dostawcy technologii kontrolować i weryfikować prawidłowego źródła danych. | W interfejsie ARA dostępnych jest wiele rozwiązań zapewniających możliwości weryfikacji: 1. Technologie reklamowe mogą sprawdzić, czy działanie interfejsu ARA odpowiada ich oczekiwaniom: – kod po stronie klienta interfejsu ARA jest oprogramowaniem typu open source, – kod po stronie serwera ARA również jest dostępny na licencji open source, a koordynatorzy dbają o to, aby tylko dozwolone wersje usługi agregacji mogły odszyfrowywać i przetwarzać raporty zbiorcze. 2. Technologie reklam w Chrome udostępniają bibliotekę symulacji do weryfikacji zachowania atrybucji, w której technologie reklamowe mogą przetestować, jak ARA przeprowadza atrybucję w symulowanym środowisku. 3. ARA obsługuje wiele sygnałów debugowania, które pomagają sprawdzić, czy i dlaczego oczekiwane przetwarzanie mogło nie wystąpić. |
(Również zaraportowane w poprzednich kwartałach) Szum |
opinie, że poziom szumu jest zbyt wysoki i ma wpływ na przydatność raportu. | Porozmawialiśmy z technikami reklam o tych samych spostrzeżeniach i ustaliliśmy, jak można dostosować interfejs ARA do ich zastosowań, nawet w przypadku szumu. Opracowaliśmy dokumentację dla programistów, która obejmuje większość decyzji projektowych i dostosowań, o których rozmawialiśmy ze specjalistami ds. technologii reklamowych. ARA została zaprojektowana w taki sposób, aby umożliwić technikom reklamowym dostosowywanie własnych konfiguracji interfejsu ARA na potrzeby różnych scenariuszy atrybucji. Technologie reklamowe będą jednak musiały zastanowić się nad kompromisem między wymiarami, które są dla nich najważniejsze, a wpływem szumu na ich dane. Jesteśmy otwarci na dodatkowe opinie z ekosystemu na temat wpływu szumu i możemy podać dodatkowe wskazówki na temat narzędzi ARA, które można wykorzystać do zmiany oddziaływania szumu. |
Atrybucja w wielu domenach | Jak śledzić atrybucje w wielu domenach? | Technologie reklamowe mogą w tym celu przekierowywać użytkowników na różne adresy URL do raportowania. Czekamy na dodatkowe opinie z ekosystemu dotyczące tego aspektu projektowania interfejsu ARA. |
Ulepszenia interfejsu API | Regularnie zmieniaj współczynnik skalowania używany przy rejestrowaniu atrybucji w raportach podsumowujących ARA. | Z dyskusji na GitHubie wynika, że obsługa wielu czynników skalowania w usłudze agregacji prawdopodobnie spowoduje większą ilość szumu dodawaną do raportów podsumowujących w porównaniu z obecną funkcją. Jesteśmy otwarci na dodatkowe uwagi dotyczące potrzeby stosowania współczynników skalowania w ramach raportów zbiorczych, ale chcemy zwrócić uwagę na potencjalny kompromis związany ze wzrostem szumu. Sprawdzamy też, czy inne przyszłe funkcje interfejsu ARA mogą pomóc w rozwiązaniu tego problemu. |
Używanie API | Możliwość ujednolicenia sposobu udostępniania zdarzeń atrybucji dla wszystkich uczestników, co jest korzystne dla SSP, DSP itp. | Zamierzamy skoordynować działania z technologiami reklamowymi, aby lepiej zrozumieć ich opinie i ewentualne ograniczenia. |
Przetestuj natężenie ruchu | Czy ruch testowy w Trybie B jest stabilny w przypadku wszystkich aplikacji Chrome? | Ustawienia Chrome nie mają wpływu na dołączenie do grupy eksperymentalnej. |
Dokumentacja | Obsługa interfejsu ARA dla pikseli. | Opublikowaliśmy opublikowane informacje na temat pomocy w tym przypadku użycia. Chętnie poznamy też dodatkowe opinie od członków ekosystemu. |
Używanie API | Zdarzenia ARA mogą nie zostać przypisane do właściwego źródła w przypadku sprzedawców zewnętrznych na platformach e-commerce, jeśli konwersja nie została dokonana przez ostatni kontakt. | Firmy mogą korzystać z filtrów, aby zapobiegać nieprawidłowej atrybucji (ponieważ w przeciwnym razie nie będą generowane raporty o konwersjach). Pracujemy też nad propozycją filtrowania przed atrybucji, aby ułatwić ten przypadek użycia. |
Obsługa przeglądarek | Czy interfejs ARA będzie obsługiwany w różnych przeglądarkach? | Zachęcamy inne przeglądarki do wdrożenia interfejsów API Piaskownicy prywatności. Nadal poświęcamy czas na dyskusję na temat naszego podejścia na otwartej konferencji W3C. Wyraźnie wskazaliśmy interoperacyjność jako cel związany z interfejsem ARA, a projekt ARA jest z założenia niezależny od przeglądarki i ma elastyczne wartości określone przez dostawcę w przypadku dostawców o odmiennych ustawieniach prywatności i w ramach innych przeglądarek, które umożliwiają wybór usług cyfrowych w różnych witrynach. Inne przeglądarki mogą samodzielnie wybierać usługi do obsługi treści cyfrowych w różnych witrynach. Zachęcamy do tego, że Microsoft Edge wskazał, że będzie obsługiwać RA. |
Używanie API | Jaki jest oczekiwany rodzaj źródła w przypadku rejestracji źródeł ARA dla przypadku signAdBeacon/reportEvent (i nawigacji Navigation_start/commit automatycznych beaconów)? | Zależy to od tego, czy te beacony są automatyczne czy ręczne: – zarezerwowane*. Zdarzenia (tj. automatyczne) będą typu „źródło nawigacji”. – zdarzenia wywoływane ręcznie muszą być typu źródła zdarzeń; |
Używanie API | Czy dla każdego zdarzenia źródłowego obowiązuje limit 20 zbiorczych raportów na źródło? Czy limit jest globalny czy dzienny? Czy jest planowane zwiększenie limitu? | Limit 20 raportów zbiorczych na źródło to limit globalny, podczas którego dla każdego źródła można utworzyć 20 raportów zbiorczych. Limit jest ustawiany przez przeglądarkę i nie można go skonfigurować. Ten limit ma na celu uniknięcie nadużywania ochrony rzeczywistych raportów atrybucji zawierających puste raporty. Więcej informacji na ten temat znajdziesz tutaj. |
Używanie API | Pomoc w zakresie marketingu e-mailowego z wykorzystaniem interfejsu ARA. | Obecnie nie ma bezpośredniej pomocy w przypadku tego przypadku użycia w interfejsie ARA (jeśli nie kontrolujesz witryny obsługującej pocztę e-mail). Rozmawiamy o tym tutaj. Chętnie poznamy Twoją opinię. |
Epsilon | Kiedy zostanie określona wartość epsilon dla interfejsu Aggregate API? | Technologie reklamowe mogą skonfigurować bieżącą wartość epsilonu do wstępnie ustalonego progu określonego przez Piaskownicę prywatności (obecnie 64). Zalecamy testowanie różnych wartości epsilonów i identyfikowanie punktów przebojowych na potrzeby własnych zastosowań, a także przesłanie opinii. Poinformujemy o tym specjalistów z branży technologii reklamowych przed wprowadzeniem jakichkolwiek zmian w zakresie wartości epsilonów. |
Ulepszenia interfejsu API | zawierać przypadek użycia, w którym reklamodawca może wstawić identyfikator w polu aktywator_data, aby dopasować go do zewnętrznych danych CRM i umożliwić reklamodawcom sprawdzanie jakości konwersji. | Rozpatrujemy tę prośbę. Chętnie poznamy też dodatkowe opinie tutaj. |
Używanie API | Obsługa przekierowań jako docelowych adresów URL. | Technologie reklamowe mogą wykonać jedną z tych czynności: 1. W polu docelowego wpisz ostateczny docelowy adres URL: 2. Pole docelowe pozwala na maksymalnie 3 adresy URL, co pozwala umieścić w tym polu większą liczbę adresów. Obie opcje wymagają znajomości końcowego docelowego adresu URL. Więcej informacji na ten temat znajdziesz tutaj . |
Usługa do agregacji
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Kluczowy mechanizm odkrywania | Żądanie mechanizmu wykrywania kluczy | Przygotowaliśmy propozycję dotyczącą kluczowego odkrycia i chętnie poznamy opinie na temat tej propozycji. |
Używanie API | Plan dostrzegalności w usłudze agregacji | Sprawdzamy opcje zwiększające dostrzegalność. Zachęcamy do wyrażania opinii od ekosystemu. Kliknij tutaj. |
Ulepszenia interfejsu API | Wysyłam prośbę o możliwość ponownego wysyłania zapytań dotyczących raportów. | Usługa agregacji pracuje nad propozycją ponownego wysyłania zapytań, w ramach której technicy reklamowi mogą podzielić epsilon na potrzeby każdego raportu. Może to spowodować zwiększenie ilości szumu w poszczególnych zapytaniach, ale umożliwi technikom reklamowym ponowne wysyłanie zapytań i zachowanie prywatności. |
Ulepszenia interfejsu API | Chcesz mieć możliwość powiązania wielu źródeł z tym samym identyfikatorem AWS. | Usługa agregacji umożliwi teraz rejestrowanie wielu witryn na tym samym koncie w chmurze (GCP lub AWS). Dzięki temu technologie reklamowe będą mogły używać tej samej enklawy usługi agregacji do przetwarzania raportów z różnych witryn i wielu źródeł z tych samych witryn. |
Używanie API | Jeśli zbiorcze pliki wsadowe nie działają, nie wiadomo, czy zostały zużyte budżet, i czy można je ponownie przetworzyć. Gdy w usłudze agregacji wystąpi błąd dotyczący budżetu zduplikowanych raportów, pozostałe raporty zostaną utracone. Jak zminimalizować tę stratę? | W typowym scenariuszu, jeśli całe zadanie się nie powiedzie, budżet nie zostanie wykorzystany. W rzadkich przypadkach awarii związanych z wyczerpywaniem budżetu technologie reklamowe mogą poprosić o przywrócenie budżetu. Jeśli technologie reklamowe napotkają częste błędy w zadaniach powodujące błąd wyczerpania budżetu, powinni potwierdzić swoją strategię grupowania. Instrukcje dotyczące prawidłowego tworzenia grupy oraz unikania zduplikowanych raportów i błędów znajdziesz tutaj. Opinie na temat odzyskiwania budżetu znajdziesz tutaj. |
Używanie API | Użycie interfejsu Private Aggregation API z regułą opisaną tutaj wygeneruje raport zbiorczy o każdej aukcji. Jakie są możliwości skalowania usługi agregacji? | Sama usługa agregacji nie nakłada górnego limitu na liczbę kluczy lub raportów w jednej grupie, ale skala 10^14 raportów i 10^12 kluczy nie jest obecnie obsługiwana ze względu na ilość wymaganej pamięci. Nasze wskazówki dotyczące rozmiaru wskazują zakresy, które przetestowaliśmy i rekomendujemy w celu uzyskania optymalnej wydajności przy oczekiwanym obciążeniu i obsługiwanych typach instancji maszyn wirtualnych Cloud. |
Przetwarzanie danych | Jeśli zaszyfrowane dane zawierają dane osobowe, jaki jest prawny sposób udostępniania zaszyfrowanych danych usłudze agregacji? Czy możesz dać znać, czy jest gwarantowane, że koordynator nie będzie miał dostępu do zaszyfrowanych danych? |
Usługa agregacji nie udostępnia koordynatorowi zaszyfrowanych danych użytkownika. Usługa agregacji korzysta z koordynatora do zarządzania kluczami i księgowości. Niektóre informacje o koordynatorze znajdziesz tutaj. Na potrzeby księgowości usługa agregacji udostępnia tylko identyfikator wspólny i źródło raportowania PBS na potrzeby wykorzystania budżetu. Po uruchomieniu wielu witryn zastąpimy punkt początkowy witryną. Pamiętaj, że usługa agregacji działa w TEE, czyli jedynym miejscu, w którym można odszyfrowywać raporty od klientów. Kod działający w TEE jest oprogramowaniem typu open source i podlega audytom zewnętrznym, zgodnie z opisem tutaj. |
Interfejs Private Aggregation API
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Używanie API | Możliwość wysyłania raportów do wielu serwerów agregacji w TEE przez sprzedawców komponentów. | Obecny stan interfejsu Private Aggregation API nie obsługuje tej funkcji. Ten problem został szczegółowo omówiony tutaj. |
Dokumentacja | Jaka jest wartość epsilonu używana w próbach Google? | W przypadku interfejsu Private Aggregation API wartość SEC określona w zapytaniu usługi agregacji odpowiada budżetowi darowizn L1 2^16, który jest egzekwowany w kolejnych 10 minutach. Jest też „backstop” budżet darowizn L1 o wysokości 2^20, który jest egzekwowany cyklicznie co 24 godziny. Zasadniczo parametr prywatności jest sieci na 10 minut. Jego wartość maleje z dokładnością do 16 sekund (a nie 144 sekund). Usługa agregacji obsługuje obecnie szereg wartości na potrzeby testowania (do 64), co umożliwia eksperymentowanie z różnymi strategiami agregacji i dostarczanie opinii o użyteczności systemu z różnymi parametrami prywatności na potrzeby prywatnej agregacji i innych parametrów prywatności. Planujemy z czasem sprawdzać maksymalną dozwoloną wartość epsilonu, gdy uzyskamy opinie od testerów i dodamy funkcje pozwalające efektywniej wykorzystywać budżet na potrzeby prywatności. |
Ogranicz tajne śledzenie
Redukcja klienta użytkownika/wskazówki klienta użytkownika
W tym kwartale nie otrzymaliśmy żadnych opinii.
Ochrona IP (dawniej Gnatcatcher)
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Identyfikator rozwiązania | Piaskownica prywatności musi bardziej rzucać się w oczy, że identyfikatory rozwiązań, które są często oparte na własności intelektualnej, nie są odpowiednie dla reklamodawców. | Z Piaskownicy prywatności jasno wynika, że naszym celem jest ograniczenie śledzenia w witrynach. Nasze inicjatywy publiczne, które wykraczają poza pliki cookie, są publikowane zarówno na stronie privacysandbox.com, jak i na GitHubie. Dokładamy wszelkich starań, aby ograniczyć śledzenie w witrynach, także na podstawie adresów IP. Jednak ostateczna decyzja, czy włączyć śledzenie w witrynach, należy do poszczególnych witryn. W erze zwiększonej kontroli zgodności z przepisami rozsądne jest, aby firmy rozumieły praktyki stosowane przez ich dostawców usług. |
Chromecast | Czy Ochrona IP ma wpływ na Chromecasta lub inne urządzenia z Chrome? | Obecnie nie ma planów stosowania ochrony IP na Chromecastach. |
Lista zabezpieczeń adresów IP | Czy zostanie opublikowana lista firm zewnętrznych zidentyfikowanych jako potencjalnie korzystające z adresów IP do śledzenia w całej sieci? | Lista zostanie opublikowana po sfinalizowaniu, zgodnie z tym artykułem. |
Łagodzenie śledzenia przekierowań
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Zwolnienie z logowania jednokrotnego | W jaki sposób łagodzenie śledzenia przekierowań (BTM) będzie weryfikować przypadki użycia logowania jednokrotnego na potrzeby wykluczenia? | System BTM zostanie wyłączony przez heurystyki Chrome. Szczegółowe informacje znajdziesz tutaj. |
Próba wycofania | Czy BTM jest włączone w witrynach w trakcie okresu próbnego wycofywania wersji 3PC? | Nie, BTM uwzględnia wyjątki dotyczące plików cookie utworzone w ramach okresu próbnego wycofywania, co zostało omówione tutaj. |
Budżet na prywatność
Zgodnie z wyjaśnieniem na GitHubie i w witrynie dla deweloperów budżet prywatności nie jest już aktywnie uwzględniany w ofertach pakietowych Piaskownicy prywatności.
Wzmacnianie granic prywatności w witrynach
Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Propozycja nowej funkcji | Dostęp do CHIP lub partycjonowania pamięci masowej jest automatycznie dozwolony w RWS, bez konieczności korzystania z interfejsu Storage Access API ani interakcji użytkownika. | Rozważamy zalety i wykonalność funkcji, która może wykonywać tę funkcję. Jednym z nich jest potencjalna luka we interoperacyjności między przeglądarkami, którą RWS eliminuje, wykorzystując interfejs Storage Access API. Obecnie nie ma odpowiednika tej żądanej funkcji obsługiwanej w innych przeglądarkach. Zachęcamy deweloperów do przesyłania przypadków użycia w tej kwestii, aby ułatwić dyskusję tutaj. |
Usuwanie niezgodnych zestawów | Jak wygląda proces usuwania z repozytorium zbiorów, które stają się niezgodne? | Pracujemy nad zdefiniowaniem procesu, który będzie miał zastosowanie w tym zakresie. Poinformujemy Cię, gdy tylko będą dostępne. |
Proces egzekwowania zasad | Brak jasności co do subiektywnej roli Google w procesie egzekwowania RWS. | RWS to projekt, który cały czas otrzymujemy. Dlatego też pewne aspekty tego procesu i nasze kryteria wciąż są doprecyzowywane. Zgadzam się, że wytyczne dotyczące przesyłania powinny zawierać szczegółowe informacje na ten temat. W przyszłości będziemy dodawać bardziej szczegółowe informacje, aby uniknąć niejasności i nieporozumień. Naszym celem jest jak najbardziej techniczne przedstawienie procesu przesyłania zgłoszeń, dzięki czemu uwolnimy się od udziału człowieka i będziemy całkowicie polegać na automatycznym sprawdzaniu. Agencje PR takie jak ten wymagają interakcji z ludźmi, ponieważ uwzględniają nieprzewidziane zachowania, ale pozwalają nam zidentyfikować kolejne obszary automatyzacji oraz sposoby poprawy naszych wytycznych, które pozwolą uniknąć takich problemów w przyszłości. |
Udostępnianie danych | Poproś właścicieli domen o udostępnienie danych RWS za zgodą użytkownika. | Żądana funkcja jest już dostępna przez interfejsy API, takie jak FedCM, i interfejsy Storage Access API, które dają dostęp do uwierzytelnionej tożsamości po zaakceptowaniu przez użytkownika prośby o przyznanie uprawnień. Chętnie poznamy opinie członków ekosystemu na temat konkretnych przypadków użycia, które ich zdaniem nie są możliwe. |
Inne metody przechowywania | Czy informacje zapisane w pamięci lokalnej lub pamięci sesji również będą interpretowane jako dane 3PC? | Pamięć lokalna, pamięć sesji i inne rodzaje pamięci masowej poza plikami cookie, które są używane w kontekstach innych firm, są podzielone na partycje w Chrome od wersji 115. Więcej informacji znajdziesz w tym poście na blogu. |
Limit powiązanych zestawów | Co się stanie z organizacjami, które przesyłają więcej niż 5 domen, mimo że ten limit jest „ograniczony do 5 powiązanych witryn”? | Zbiory te będą akceptowane przez proces GitHuba, ale przeglądarka (Chrome) zastosuje reguły automatycznego przyznawania dostępu przez interfejs Storage Access API tylko do pierwszych 5 domen i zignoruje pozostałe domeny w sposób opisany tutaj. |
find_robots_txt | Sprawdzanie pliku find_robots_txt nie działa w przypadku przekierowań. | Prośba o poprawkę została przesłana tutaj, aby rozwiązać ten problem. |
Gest użytkownika | W przypadku accessStorage() usunięto wymóg korzystania z gestów użytkownika. | To wymaganie powstało na podstawie podobnego projektu stosowanego we wszystkich popularnych przeglądarkach dla interfejsu requestStorageAccess API. Zachęcamy do dodatkowych opinii i przypadków użycia w tym problemie na GitHubie, aby pomóc nam nadać priorytet temu żądaniu i umożliwić prowadzenie dyskusji w różnych przeglądarkach. |
Gest użytkownika | Czy po ponownym uruchomieniu Chrome lub systemu operacyjnego do przyznania dostępu aplikacji innej firmy do pamięci masowej wymagany jest gest użytkownika? | Tak, ale zachęcamy do przesyłania opinii od ekosystemu na temat zmiany tego sposobu działania tutaj. |
Interfejs API Fenced Frames
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
adComponent | Brak dokumentacji i elastyczności podczas korzystania z komponentów reklam z zabezpieczonymi ramkami. | Chcemy udostępnić więcej dokumentacji na temat tego przypadku użycia. Dodatkowo komponenty reklam są obsługiwane w obramowanych ramkach za pomocą metody getNestedConfigs(), która jest udokumentowana tutaj. |
(Również zgłaszane w poprzednich kwartałach) Renderowanie komponentu adKomponent |
Żądanie przykładowych kodów renderowania komponentów adKomponenty w chronionej ramce. | Kilka przykładowych kodów udostępniamy tutaj. |
Weryfikacja reklam firm zewnętrznych | Rola weryfikacji reklam firm zewnętrznych w kontekście Chronionych ramek wymaga więcej szczegółów, zwłaszcza w zakresie bezpieczeństwa kontekstu i bezpieczeństwa marki. | Obecnie raporty dotyczące reklam w ramach Fenced Frames umożliwiają platformom DSP wysyłanie danych na poziomie zdarzenia o wyświetleniach i aukcji do zewnętrznych weryfikatorów reklam na potrzeby kontroli bezpieczeństwa marki i płatności po wyrenderowaniu. |
Reklamy rozwijane | Prośba o włączenie obsługi reklam rozwijanych. | Jeśli reklama musi się przełączać między 2 rozmiarami o tym samym współczynniku proporcji i nie ma między nimi działającej różnicy (sam rozmiar), mechanizm umieszczania może zmienić rozmiar ogrodzonej ramki z drugim rozmiarem reklamy, a przeglądarka odpowiednio skaluje element ramki ogrodzonej. |
(Również raportowane w poprzednich kwartałach) Obsługa zasobów reklamowych wideo i natywnych |
Czy chronione ramki obsługują zasoby reklamowe wideo i natywne? | Nasza odpowiedź jest podobna do poprzednich: PA API obsługuje renderowanie filmów za pomocą mechanizmu opartego na elementach iframe. Nie opracowaliśmy jednak jeszcze rozwiązania do renderowania reklam wideo i reklam natywnych, które było zgodne z ramkami chronionymi. Jest to jeden z powodów, dla których zdecydowaliśmy się wycofać egzekwowanie zasad związanych z chronionymi ramkami na rok 2026. Oznacza to, że jeśli partner zdecyduje się teraz wyegzekwować Fenced Frames, nie będzie on obsługiwał reklam wideo i reklam natywnych. |
Rada ekspertów | Prosi o utworzenie zespołu doradczego obejmującego dostawców reklam natywnych, aby zapewnić, że implementacje chronionych ramek są zgodne ze standardami branżowymi. | Chronione ramki nie są wymagane do użycia w interfejsie PA API wcześniej niż w 2026 roku. Dodatkowy czas pozwala nam kontynuować współpracę z branżą przy opracowywaniu i wdrażaniu pomocy dla szerszego zakresu najważniejszych przypadków użycia. Wspomnieliśmy wcześniej, że będziemy rozwijać ramki ogrodzone jeszcze przed wprowadzeniem w nich wymagań, aby utrzymać obsługę reklam wideo i reklam natywnych z użyciem interfejsu PA API. Zgodnie z naszymi zobowiązaniami będziemy informować CMA o wszelkich takich zmianach. Będziemy też nadal korzystać z opinii od ekosystemu, zanim będzie wymagać stosowania chronionych ramek. Nasz model zaangażowania w ekosystem opracowany przez W3C oraz organizacje zajmujące się standardami reklamowymi, takie jak IAB Tech Lab, pozwalają ekspertom branżowym z całego świata zarządzać projektami, zanim będą one potrzebne. |
(Również zaraportowano w poprzednich kwartałach) Różnica rozmiaru na poszczególnych platformach |
Raportuje, że rozmiar treści wyświetlanej w ramce ogrodzonej wygląda inaczej na komputerach i na smartfonach. | Jest to znany problem z Chromium, który badamy. Dodatkową opinię możesz przesłać tutaj. |
Ulepszenia interfejsu API | Czy wymagania dotyczące chronionych ramek zostały wycofane w 2025 r., tak aby reklamy natywne były obsługiwane w Piaskownicy prywatności? | Jak wspominaliśmy w naszym publicznym ogłoszeniu w związku z wprowadzeniem egzekwowania zasad dotyczących chronionych ramek, nie wcześniej niż w 2026 roku dowiedzieliśmy się o dużej „znacznej wysiłku w związku z uwzględnieniem” zabezpieczonych ramek. Oczywiście jednym z nich była reklama natywna, ale nie była jedynym czynnikiem. Chodziło o to, aby dać więcej czasu na przygotowanie ekosystemu do obsługi kluczowych przypadków użycia, w tym m.in. reklam natywnych. |
Interfejs Shared Storage API
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Wydajność | Czasy zwracania pamięci współdzielonej poza workletem zależą od aktywności w worku. | Wynik testu omawiamy tutaj. |
Szersze rozpowszechnienie | Pamięć współdzielona powinna być standardem branżowym dostępnym dla różnych przeglądarek. | Akceptujemy i doceniamy tę opinię. Chrome aktywnie uczestniczy w organizacjach W3C, w tym w WICG, aby realizować propozycje, szukać opinii i wspierać wdrażanie tych rozwiązań. |
Worklety określania stawek | Czy można odczytać dane z pamięci współdzielonej w ramach funkcji generatebid (które już działa w panelu), aby podjąć decyzje dotyczące reklam lub logikę biznesową (np. ograniczenie liczby wyświetleń) na podstawie informacji z różnych witryn i wybrać podzbiór reklam? | Nie, w ramach Workletów określania stawek odczyt z pamięci współdzielonej jest niemożliwa. |
CHIPS
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Pojemność partycji | Wyjaśnij działanie w przypadku przekroczenia pojemności partycji. | Po osiągnięciu limitu najstarsze pliki cookie są usuwane z najmniej ostatnio używanych, aby zwolnić pamięć, dopóki limit nie zostanie przekroczony. W kolejnych żądaniach deweloperzy zobaczą zaktualizowany nagłówek Cookie. |
Dostęp do elementów iframe innych firm | Umieszczony element iframe innej firmy, który otwiera nową kartę lub nowe okno z tą samą stroną, powinien mieć dostęp do tych samych partycjonowanych plików cookie co element otwierający. | Omawiamy ten przypadek użycia. Zachęcamy do przekazywania opinii z ekosystemu tutaj. |
Zduplikowane pliki cookie | Jeśli istnieje partycjonowany plik cookie i nieparty na partycji plik cookie o tej samej nazwie, którą parę klucz-wartość decyduje przeglądarka? | Jeśli masz 2 pliki cookie o tej samej nazwie (jeden partycjonowany, a drugi nie), otrzymasz oba pliki – niestety nie da się rozróżnić, który jest który. Specyfikacja RFC na ten temat jest dostępna tutaj, która wyjaśnia, że nie należy polegać na kolejności wysyłania plików cookie. |
Propozycja nowej funkcji | Włącz pliki cookie partycjonowane według źródła. | Rozpatrujemy tę prośbę. Zachęcamy do przekazywania opinii z ekosystemu tutaj. |
FedCM
W tym kwartale nie otrzymaliśmy żadnych opinii.
Zwalczanie spamu i oszustw
Private State Token API (i inne interfejsy API)
Motyw opinii | Podsumowanie | Odpowiedź Chrome |
---|---|---|
Komponent WebView | Czy tokeny prywatności prywatności (PST) są przechowywane w wielu widokach WebView na tym samym urządzeniu mobilnym (w profilu)? | Każda aplikacja, która korzysta z WebView, ma inną pamięć lokalną, co oznacza, że wydawcy plików PST nie mogą wystawiać tokenów w komponencie WebView jednej aplikacji, a później w osobnej aplikacji, umożliwiając wykorzystywanie tokenów. Dotyczy to też innych rodzajów danych przechowywanych lokalnie w komponentach WebView, np. plików cookie. Pliki PST nie są jeszcze w pełni dostępne w komponencie WebView. Spodziewamy się, że pod koniec II kwartału przekażemy Ci nowe informacje. |
Nowy typ tokena | Propozycja nowego typu tokena. | Dziękujemy za tę propozycję oraz za kontynuowanie badania zastosowań i adaptacji plików PST. Z niecierpliwością czekamy na więcej informacji na temat tej propozycji podczas nadchodzących spotkań grupy walczącej z oszustwami, które odbędą się w II kwartale 2024 roku. |
Identyfikacja użytkownika | Jak zapobiec identyfikowaniu użytkowników na podstawie konkretnych plików PST, które mają? | Obecnie zmniejsza się to przez ograniczenie prób wykorzystania karty w witrynie do 2 wydawców niezależnie od tego, czy dany wydawca udostępnia tokeny. Musisz uwzględnić wydawcę w limicie, nawet jeśli nie ma dostępnych tokenów. W przeciwnym razie witryna może iterować ją przez wszystkich wydawców, dopóki nie znajdzie dopasowania do dodatniej wartości. |
Rejestracja | Jak długo będzie wymagana rejestracja w przypadku plików PST? | W najbliższej przyszłości rejestracja będzie wymagana, zgodnie z tym artykułem. |
Obsługa innych przeglądarek Chromium | Czy rejestracja wydawcy pliku PST w innych przeglądarkach opartych na Chromium będzie obsługiwana przez repozytorium rejestracji wystawców Chrome? | Chrome pobiera najważniejsze zobowiązania i rozpowszechnia je wśród klientów Chrome za pomocą mechanizmu o nazwie Aktualizator składników. W miarę jak inne przeglądarki będą w pełni obsługiwać ten interfejs API, będą musiały opracować proces przekazywania kluczowych zobowiązań wobec klienta stosownie do metody aktualizatora komponentów lub innej metody. Szczegółowo omawiamy to tutaj. |