Czwarty raport kwartalny z 2024 r. podsumowujący opinie ekosystemu dotyczące propozycji Piaskownicy prywatności i odpowiedzi Chrome.
W ramach zobowiązań wobec CMA Google zgodziło się na publikowanie kwartalnych raportów na temat procesu zaangażowania interesariuszy w przypadku propozycji dotyczących Piaskownicy prywatności (patrz punkty 12 i 17(c)(ii) zobowiązań). Te raporty zbiorcze opinii na temat Piaskownicy prywatności są generowane przez agregację opinii otrzymanych przez Chrome z różnych źródeł wymienionych w omówieniu opinii, w tym m.in. z GitHub Issues, formularza opinii udostępnionego na privacysandbox.com, spotkań z osobami zainteresowanymi w branży oraz forów dotyczących standardów internetowych. Chrome z zadowoleniem przyjmuje opinie pochodzące z ekosystemu i aktywnie poszukuje sposobów na uwzględnienie wniosków w decyzji dotyczących projektowania.
Tematy opinii są klasyfikowane według częstotliwości występowania w przypadku poszczególnych interfejsów API. Polega to na zsumowaniu liczby opinii, które zespół Chrome otrzymał w danym temacie, i posortowaniu ich według malejącej się liczby. Najczęstsze tematy opinii zostały zidentyfikowane na podstawie przeglądu tematów dyskusji z publicznych spotkań (W3C, PatCG, IETF), bezpośrednich opinii, GitHuba oraz najczęściej zadawanych pytań, które pojawiają się w zespole wewnętrznym Google i w formularzach publicznych.
W szczególności zostały sprawdzone protokoły spotkań organizacji zajmujących się opracowywaniem standardów internetowych. W przypadku bezpośrednich opinii uwzględniono zapisy Google z indywidualnych spotkań z partnerami, e-maile otrzymane przez poszczególnych inżynierów, listę mailingową API oraz publiczny formularz opinii. Następnie Google skoordynowało działania zespołów biorących udział w różnych działaniach promocyjnych, aby określić względną częstotliwość występowania tematów związanych z poszczególnymi interfejsami API.
Wyjaśnienia dotyczące odpowiedzi Chrome na opinie zostały opracowane na podstawie opublikowanych najczęstszych pytań i odpowiedzi na nie, a także na podstawie rzeczywistych odpowiedzi na problemy zgłoszone przez zainteresowane strony i stanowiska przyjętego specjalnie na potrzeby tego publicznego raportu. W związku z obecnym celem rozwoju i testowania otrzymaliśmy pytania i opinie dotyczące głównie interfejsów API Topics, Protected Audience i Attribution Reporting.
Opinie otrzymane po zakończeniu bieżącego okresu sprawozdawczego mogą nie zostać jeszcze rozpatrzone przez zespół Chrome.
Słowniczek akronimów
- ARA
- Attribution Reporting API
- CHIPS
- Pliki cookie z niezależnym stanem partycji
- (procesor) DSP
- Platforma DSP
- FedCM
- Federated Credential Management
- FPS
- Zestawy źródeł własnych
- IAB
- Interactive Advertising Bureau
- IDP
- Dostawca tożsamości
- IETF
- Internet Engineering Task Force
- IP
- adres IP
- openRTB
- Określanie stawek w czasie rzeczywistym
- DOLICZONY CZAS
- Testowanie wersji Origin
- Interfejs PAT API
- Protected Audience API (dawniej FLEDGE)
- PatCG
- Grupa społeczności technologii reklamowych
- RP
- Jednostka zależna
- RWS
- Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)
- 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
- Celowe ignorowanie adresów IP
Ogólna opinia, nie dotyczy konkretnego interfejsu API ani technologii
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zarządzanie | zainteresowanie okresem składania publicznych komentarzy dotyczących wszelkich aktualizacji dotyczących zarządzania Piaskownicą prywatności; | Zapraszamy zainteresowane strony do przekazywania opinii na temat istotnych zmian dotyczących Piaskownicy prywatności, w tym przyszłego zarządzania nią. |
| Testowanie | dodatkowe fazy testowania 3PCD oprócz obecnego testowania wspomaganego przez Chrome z udziałem 1% użytkowników. | Nie zamierzamy oferować testów w Chrome poza 1% ruchu w Chrome, który jest dostępny od początku stycznia. |
| Web to App | 3PCD na urządzeniach mobilnych nie powinno się odbywać, dopóki nie osiągnie się pełnej interoperacyjności między stroną internetową a aplikacją. | Zgadzamy się, że warto wspierać interoperacyjność aplikacji i witryn internetowych. Wdrożyliśmy już pomiar atrybucji w aplikacjach i witrynach internetowych, a obecnie szukamy rozwiązań do kierowania reklam z witryn internetowych do aplikacji. Nie planujemy jednak opóźnienia wdrażania 3 PC na stronach mobilnych. Na koniec 3 cykli testów A/B nie mamy celu osiągnięcia 100% pokrycia. Spodziewamy się, że zgodność z Androidem w przypadku pomiarów w wielu aplikacjach i w internecie będzie na poziomie 3 PCD, a z czasem będzie się zwiększać, gdy użytkownicy będą aktualizować swoje telefony. |
| Rola przeglądarki | Wygląda na to, że Chrome pełni rolę serwera reklamowego lub SSP. | Chrome nie pełni roli serwera reklam ani SSP. Dzięki interfejsowi PA API Chrome udostępnia kontener dla serwerów reklam, platform SSP, platform DSP i innych technologii reklamowych, aby mogły one stosować własną logikę określania stawek i punktacji. |
| Wskazówki dotyczące zastosowania | bardziej przejrzyste wskazówki dotyczące tego, które przypadki użycia będą obsługiwane przez interfejsy API Piaskownicy prywatności; | Na początku projektu Piaskownica prywatności dokumentacja dla deweloperów była głównie ukierunkowana na zachęcanie deweloperów do dyskusji i procesów udzielania opinii dotyczących wszystkich propozycji. Oznacza to, że treści były ogólnie uporządkowane w sposób umożliwiający zrozumienie motywacji i koncepcji projektu, a następnie zawierały szczegóły wczesnych etapów rozwoju i testowania poszczególnych propozycji. Dzięki temu udało się zbudować prawdziwą współpracę w ramach ekosystemu podczas opracowywania propozycji, ale wraz z upowszechnieniem się interfejsów API pojawiła się nowa grupa deweloperów, którzy korzystają z tych interfejsów, a nie przyczyniają się do ich rozwoju. Niedawno zaktualizowaliśmy nawigację na stronie dla deweloperów w Piaskownicy prywatności, aby skupić się na zastosowaniach, stosując podobne kategorie jak IAB Tech Lab w niedawnym raporcie grupy roboczej ds. Piaskownicy prywatności. Będziemy nadal stosować podejście oparte na przypadkach użycia. |
| Lokalne środowisko programistyczne | Jak kontynuować tworzenie i testowanie front-endu lokalnie na stronie http://localhost, gdy plik cookie ma ustawioną opcję SameSite=Secure, a back-end jest obsługiwany przez CDN? | Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami na temat naszego ekosystemu. |
| 3PCD Mitigation | Czy istnieje programistyczny sposób na sprawdzenie, czy 3PC są zablokowane lub czy są aktywne heurystyki? | W Chrome zarówno wykrywanie funkcji, jak i wywołanie funkcji document.hasStorageAccess w ramce iframe umożliwiają deweloperowi sprawdzenie, czy pochodzenie w ramce iframe ma dostęp do 3PC. |
| Testowanie filmów | Obecnie nie można testować reklam wideo w Piaskownicy prywatności. | W Chrome opublikowaliśmy dyskusję i demonstrację kilku możliwych sposobów tworzenia filmów za pomocą interfejsu PA API (patrz 242 i 254 w repozytorium demonstracji na GitHubie). Pamiętaj, że te przykłady kodu nie są przeznaczone do bezpośredniego stosowania przez specjalistów ds. technologii reklamowych, ale raczej do weryfikacji koncepcji i demonstracji technik, które mogą obsługiwać renderowanie filmów VAST za pomocą interfejsu PA API. W trakcie tej dyskusji okazało się też, że chociaż renderowanie filmów jest już możliwe, w Chrome można wprowadzić zmiany, które uproszczą implementację za pomocą interfejsu PA API. Na przykład aktualizacje dotyczące zastępowania makro (omówione tutaj), które planowaliśmy już wprowadzić na podstawie opinii o używaniu zewnętrznych weryfikatorów bezpieczeństwa marki, będą też dotyczyć opinii o używaniu reklam wideo, w których przypadku kupujący chce wiedzieć, których makro sprzedawców użyć do renderowania. Do tej pory większość dyskusji koncentrowała się głównie na renderowaniu reklam wideo VAST. Renderowanie reklam natywnych może korzystać z tych samych metod i jest w wielu aspektach łatwiejsze. Wydaje się, że reklamy natywnych nie przyciągają obecnie tak dużej uwagi jak reklamy wideo, ale jest to tylko kwestia priorytetów branży technologii reklamowych, a nie technicznych barier w wdrożeniu. |
| Pomiar skuteczności reklam | 3PCD może wpływać na rozwiązania do pomiaru odbiorców niezwiązane z reklamami. | Interfejsy API do pomiarów nie wymagają, aby przypadek użycia był związany z reklamami. Chociaż ARA jest bardziej dopasowana do typowej ścieżki reklamowej, prywatna agregacja jest uniwersalna. Te 2 elementy można stosować do realizacji wielu różnych działań związanych z pomiarami. |
| Twórcy | Piaskownica prywatności została zaprojektowana tak, aby zachęcać twórców do tworzenia większej ilości treści dla YouTube i mniejszej dla własnych witryn. | Inicjatywa Piaskownica prywatności ma na celu zapewnienie prywatności w otwartym i wolnym internecie. Wiemy, że wydawcy polegają na reklamach, aby tworzyć treści i uzyskiwać jak największą ich oglądalność. Reklamodawcy pomagają użytkownikom odkrywać nowe produkty lub oferty, które mogą ich zainteresować. Funkcje piaskownicy prywatności umożliwiają witrynom wszelkiego rodzaju, w tym tym, które współpracują z twórcami treści, wyświetlanie użytkownikom przydatnych reklam na podstawie ich aktywności z różnymi podmiotami bez ujawniania tym podmiotom tożsamości użytkownika. |
| Bardziej przejrzyste osie czasu | bardziej przejrzyste i szczegółowe harmonogramy wprowadzania technologii Piaskownicy prywatności; | Dokumentacja interfejsu API Piaskownicy prywatności zawiera strony z informacjami o stanie i dostępności. Na tych stronach znajdziesz informacje o nadchodzących funkcjach i ich harmonogramie (np. PA API, ARA). Te stany możesz sprawdzić tutaj. |
| Systemy uczące się | Specjaliści od technologii reklamowych nie mogą prawidłowo trenować modeli systemów uczących się, dopóki współczynnik 3PCD nie przekroczy 1%. | Rozszerzenie testów 3PCD na inne przeglądarki nie gwarantuje, że interfejsy API będą częściej używane, co jest prawdopodobnie celem dostawców technologii reklamowych, którzy chcą dalej trenować modele systemów uczących się. Jeśli ekosystem reklam nie jest wykorzystywany do dalszego trenowania modeli uczenia maszynowego, nie ma powodu, aby zwiększać 3PCD, ponieważ firmy zajmujące się technologiami reklamowymi, które chcą trenować modele na większym ruchu, mogą to zrobić już teraz bez zwiększania 3PCD. Można to zrobić bez wyświetlania w Chrome 3PCD przed zakończeniem stania. |
| Nieobsługiwany przypadek użycia | Obecnie nie rozważamy możliwości użycia samoobsługowej platformy DSP. | Istnieje wiele samoobsługowych platform DSP, które regularnie publikują opinie na temat interfejsów API. Kilka z tych platform DSP, które regularnie udostępniają opinie, wyznaczyło się jako testerów. Chrome aktywnie angażuje się też w typowe tematy związane z platformami DSP samoobsługowych, np. serwery reklam wideo i serwery reklam zewnętrznych. Te tematy zostały omówione w ostatnich cotygodniowych wywołaniach interfejsu PA API. |
| Wersja próbna origin | Prośba o OT w przypadku witryn, które chcą szybciej zwiększyć pokrycie i testowanie 3PCD. | W Chrome pracujemy obecnie nad własnym trybem ochrony prywatności, który pozwoli witrynom na dołączenie do wycofywania obsługi plików cookie innych firm. Identyfikatory 3PC pochodzące z usług na najwyższym poziomie, które rejestrują się w ramach tego okresu próbnego i wdrażają tokeny, będą blokowane tak, jakby na urządzeniu użytkownika była włączona ochrona przed śledzeniem. Ta wersja testowa umożliwi witrynom przeprowadzenie szerszych testów długoterminowych alternatyw dla 3PC przed ich wycofaniem, które nastąpi po konsultacjach z CMA. Wciąż pracujemy nad ostatecznym harmonogramem wdrażania wersji testowej. |
| Raport IAB Tech Lab | Informacje zwrotne dotyczące Piaskownicy prywatności otrzymane z raportu IAB Tech Lab. | Szczegółową odpowiedź na raport IAB Tech Lab znajdziesz tutaj. Przyjęliśmy też do wiadomości, że „raport stawia pytania dotyczące fragmentarycznej dokumentacji, wymagań komercyjnych, audytów zewnętrznych, akredytacji branżowej, skalowalności, przejrzystości i przyszłego zarządzania, które omówimy z przedstawicielami ekosystemu i odpowiednio zaktualizujemy nasze publiczne odpowiedzi na najczęstsze pytania”. Rozwiązujemy problem rozdrobnionych informacji w dokumentacji. Wymagania komercyjne omawiamy w sekcji „Gwarancje dotyczące danych” tutaj, a niektóre usługi Google Ads opisały swoje podejście. Informacje o audytach zewnętrznych znajdziesz w sekcji „Gwarancja integralności algorytmu” tutaj. Jeśli chodzi o akredytację, oczekujemy, że te podmioty będą nadal akredytowały produkty, w tym ich wykorzystanie technologii, a nie same technologie. Jeśli chodzi o skalowalność, nadal zbieramy od deweloperów dane, które pomogą nam rozwiązać problemy. W zakresie przejrzystości i zarządzania nadal rozwijamy nasze rozwiązania w ramach GitHuba i na forach takich jak W3C, współpracując jednocześnie z CMA w ramach zobowiązań. |
| Logowanie przez Google | Logowanie się przez Google umożliwiłoby Google korzystanie z danych logowania z użyciem funkcji identyfikacji na różnych urządzeniach, co jest niezgodne z zobowiązaniami. | Funkcja Zaloguj się przez Google nie umożliwia Google korzystania z danych w sprzeczności z zobowiązaniami. |
| Zgodność | Jakie są plany dotyczące obsługi interfejsów API Piaskownicy prywatności i kompatybilności wstecznej / wstępnej? | Gdy funkcja zostanie udostępniona publicznie, będziemy ją wspierać. Oczywiście nie zawsze można zachować zgodność wsteczną, dlatego w takich przypadkach stosujemy jasny proces wycofywania i usuwania dotychczasowych funkcji, opisany tutaj. Z upływem czasu będziemy stopniowo dodawać do interfejsów API Piaskownicy prywatności kolejne funkcje, odpowiadając na opinie dotyczące zastosowań, które mogą skorzystać z ulepszonej obsługi. W takich przypadkach zwykle stosujemy jakąś technikę wykrywania funkcji, aby firmy technologiczne zainteresowane eksperymentowaniem z nową funkcją mogły bezpośrednio zapytać przeglądarkę, czy dana funkcja jest obsługiwana. Jest to lepsze rozwiązanie niż prosić deweloperów o sprawdzenie określonej wersji Chrome, ponieważ niektóre funkcje mogą nie być udostępniane wszystkim użytkownikom Chrome w tym samym czasie. Na przykład naszą pracę nad wykrywaniem funkcji w PA API znajdziesz tutaj. |
| Implementacja na serwerze | Zamiast wiązać się z własną implementacją, Chrome powinien określić zachowania, które musi spełniać prawidłowa implementacja serwera Trusted Signals, serwera agregacji i wszystkich innych wymaganych komponentów poza przeglądarką. Umożliwiłoby to innowacje w akceptowalnych granicach prywatności. | Doceniamy i przyjmujemy do wiadomości chęć wprowadzania innowacji przez osoby z zewnątrz. W przypadku wszystkich interfejsów API i usług staramy się zapewnić dostawcom technologii reklamowych elastyczność w wdrażaniu ich funkcji. Na przykład zezwalamy firmom zajmującym się technologiami reklamowymi na korzystanie z poufnych informacji biznesowych do projektowania logiki określania stawek na potrzeby aukcji. Ponadto stale zbieramy opinie od dostawców technologii reklamowych i w uzasadnionych przypadkach uwzględniamy je w naszych projektach. Aby umożliwić innym użytkownikom uruchamianie własnego kodu w zaufanych środowiskach wykonywania, Piaskownica prywatności musi sprawdzić ten kod (oraz wszelkie zmiany), aby potwierdzić, że spełnia on gwarancje dotyczące prywatności. Wymaga to znacznego nakładu pracy od zespołu Piaskownicy prywatności. Dlatego chcielibyśmy dowiedzieć się, jakie korzyści chce osiągnąć zainteresowana osoba, których obecnie nie oferujemy. |
| Heurystyka | Jakie są długoterminowe plany dotyczące heurystyk? | Zgodnie z tym, co podają inne przeglądarki, zamierzamy ostatecznie wycofać te heurystyki, gdy alternatywne rozwiązania staną się powszechnie stosowane, z zastrzeżeniem dalszej analizy wykonalności. Udostępniliśmy go tutaj. |
| Testowanie liczby konwersji | Różna wielkość ruchu podczas porównywania różnych wymiarów. | Eksperyment dotyczący 1% użytkowników ma kryteria wykluczenia, które prowadzą do różnic w kwalifikacji do eksperymentu w przypadku różnych grup użytkowników przeglądarki Chrome. Na przykład eksperyment wyklucza użytkowników Chrome Enterprise, więc można się spodziewać, że odsetek ruchu z etykietami eksperymentu będzie wyższy w weekendy. Różne odsetki ruchu w różnych przekrojach danych (np. według lokalizacji, daty i platformy) są czymś normalnym i zgodne z danymi w Chrome. |
| Ręczne ponowne włączanie 3 PC | Czy witryny będą mogły się dowiedzieć, ilu użytkowników (%) ponownie włączyło pliki cookie ręcznie po wprowadzeniu 3PCD? | W przypadku awarii użytkownicy będą mogli ponownie włączyć dostęp 3PC na poziomie witryny za pomocą funkcji obejścia przez użytkownika. 3PC mogą zostać ponownie włączone przez inne środki, takie jak interfejs Storage Access API. Istnieją środki techniczne, takie jak hasStorageAccess(), które umożliwiają witrynom wykrywanie, czy 3PC są włączone czy wyłączone. Chrome nie udostępni jednak witrynom informacji o przyczynach ponownego włączenia. |
| Ochrona przed śledzeniem | Jak długo będzie dostępna funkcja interfejsu ochrony przed śledzeniem w Chrome? | Interfejs ochrony przed śledzeniem na pasku adresu ma pozostać dostępny po wycofaniu 3 PC. |
| (zgłaszane również w poprzednich kwartałach) Obsługa w różnych przeglądarkach |
Inni dostawcy przeglądarek, którzy stosują interfejsy API Piaskownicy prywatności. | Inni dostawcy przeglądarek, tacy jak Apple, Mozilla i Microsoft, aktywnie uczestniczą w publicznych dyskusjach na temat zasad prywatności i podejść do przeglądarek. Zachęcają nas do tego wspólne dyskusje na forach, np. na niedawnym dorocznym spotkaniu TPAC w ramach W3C i obecnych forach PATCG w ramach W3C, gdzie widzimy oznaki konwergencji. Na przykład Microsoft Edge ogłosił niedawno plan, który ma na celu „maksymalizację zgodności składniowej” z interfejsem PA API i ARA, a zarazem oferuje dodatkowe funkcje dla deweloperów. |
| Opcja zastępcza dla nieobsługiwanych elementów osadzenia po 3PCD | Udostępnij elementy interfejsu API, które wykrywają, czy element iframe lub embed innej firmy jest zgodny z 3PCD. | Rozmawiamy o tej prośbie tutaj i zapraszamy do dzielenia się opiniami na temat tego ekosystemu. |
| Testowanie | Prośba o dodatkowe flagi w zarządzanych instancjach Chrome, które tymczasowo wyłączają dostosowywanie zachowań. | Rozważamy tę prośbę w przypadku zarządzanych instancji Chrome i zapraszamy do przesyłania dodatkowych informacji o tym ekosystemie, jeśli taka flaga byłaby przydatna. |
Rejestracja i potwierdzenie
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Weryfikacja atesta | Jak Google będzie weryfikować autentyczność zaświadczeń? | Wszyscy zarejestrowani użytkownicy muszą zachować plik oświadczenia na miejscu podczas korzystania z interfejsów API. Google sprawdza, czy plik jest dostępny i czy jego składnia jest poprawna, ale nie weryfikuje działania technologii reklamowej pod kątem języka oświadczenia. |
| Proces rejestracji w przypadku interfejsu Private Aggregation API | Czy istnieje sposób na sprawdzenie stanu rejestracji interfejsu Private Aggregation API? | Po zatwierdzeniu rejestracji wszyscy zatwierdzeni rejestrujący się użytkownicy otrzymują e-maila od zespołu pomocy ds. rejestracji. Jeśli w trakcie procesu rejestracji użytkownik ma pytania, może skontaktować się z zespołem pomocy (z którym łączy się po przesłaniu formularza rejestracyjnego). Zespół pomocy odpowie na pytania i dostarczy wszelkich potrzebnych wskazówek. |
Wyświetlanie odpowiednich treści i reklam
Tematy
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| (również w poprzednich kwartałach) Harmonogram i dokumentacja klasyfikatora |
Powinien istnieć jakiś mechanizm weryfikacji klasyfikacji lub przynajmniej dodatkowa przejrzystość dotycząca tego, jak tryb klasyfikacji określa kategorie. | Nasza odpowiedź nie zmieniła się od poprzednich kwartałów: „Niewłaściwe zaklasyfikowanie witryn może sprawić, że sygnał Topics będzie nieco mniej przydatny jako sygnał ogólny, ale konkretne witryny, które zostały nieprawidłowo zaklasyfikowane, nie są bardziej ani mniej poszkodzone niż inne witryny. Dzieje się tak, ponieważ informacje kontekstowe witryny będą zawsze dostępne w ramach aukcji w niej, co zapewni porównywalne informacje o właściwym temacie nawet w przypadku błędnej klasyfikacji. Zachęcamy do dzielenia się opiniami na ten temat tutaj. |
| Google Ad Manager | Google Ad Manager jest już wbudowany w większości witryn i będzie mieć znacznie więcej informacji o tematach interesujących użytkowników niż konkurenci, którzy są obecni w mniejszej liczbie witryn. | Wymaganie obserwacji ma na celu zapewnienie, że interfejs Topics API nie powoduje udostępniania danych użytkownika większej liczbie podmiotów niż technologie, które zastępuje (w tym pliki cookie innych firm). Inne rozwiązania branżowe, takie jak Prebid, działają na tysiącach stron i umożliwiają uczestnikom rynku wywoływanie interfejsu Topics API za pomocą swojej technologii. Warto też zauważyć, że limit 5 najpopularniejszych tematów w ciągu tygodnia może mieć efekt wyrównujący, ponieważ uczestnicy rynku obecni w wielu witrynach, którzy mogą się uczyć więcej niż 5 tematów za pomocą 3 PC, będą ograniczeni do 5 tematów. |
| (również w poprzednich kwartałach) Użyteczność dla różnych grup interesariuszy |
wątpliwości dotyczące wartości tworzonej i rozpowszechnianej przez witryny w zależności od ich poziomu ruchu lub stopnia specjalizacji treści; | Zdajemy sobie sprawę, że witryny wyspecjalizowane częściej zawierają szczegółowe tematy niż domeny o ogólnym charakterze. Nie wszystkie jednak witryny specjalistyczne zawierają tematy o wartości komercyjnej. Ta dynamika odzwierciedla obecną sytuację i jest całkowicie niezależna od zakończenia obsługi 3 PC w Chrome. W obecnej sytuacji niektóre witryny są bardziej wartościowe niż inne w systemach trafności reklam opartych na 3 PC. Dodatkowo tematy w specjalistycznych witrynach mogą być korzystne dla siebie nawzajem, ponieważ różni reklamodawcy mogą prowadzić kampanie w różnych zestawach tematów, a logika ustalania stawek może uwzględniać wartość w szerokim zakresie tematów. |
| Nazwy hostów a pełne adresy URL | Czy klasyfikacja oparta na nazwach hostów witryn jest wystarczająco skuteczna i czy zmniejsza ryzyko naruszenia prywatności w porównaniu z pełnymi adresami URL? | Rozważaliśmy użycie adresów URL informacji lub tytułów stron oprócz nazw hostów i stwierdziliśmy, że potencjalne korzyści będą mniejsze niż zagrożenia dla prywatności i bezpieczeństwa użytkowników. Przykładem zagrożeń dla prywatności użytkownika jest klasyfikacja informacji wrażliwych zawartych w adresie URL lub tytule strony do tematów użytkownika. |
| Tematy jako sygnał | prośba o wskazanie sposobu łączenia tematów z innymi sygnałami i o wskazanie innych przydatnych sygnałów; | Rozwiązania technologii reklamowych mogą zapewnić najlepsze wyniki dzięki połączeniu wszystkich dostępnych narzędzi, takich jak uczenie maszynowe i sygnały chroniące prywatność pochodzące z interfejsów API zapewniających ochronę prywatności, z danymi kontekstowymi, danymi kreacji i danymi własnymi. Więcej informacji na ten temat znajdziesz tutaj. |
Protected Audience API (wcześniej FLEDGE)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Testowanie natężenia ruchu | Testerzy zgłaszają niską liczbę odpowiedzi na stawkę w aukcji interfejsu PA API. | 1. Gęstość stawek jest powiązana z udziałem ekosystemu w PA API, który według naszych prognoz będzie się zwiększał w 2024 roku i później. Ostateczna decyzja o przyznaniu budżetów kampanii należy do reklamodawców, ich agencji i dostawców technologii. Spodziewamy się, że niektórzy uczestnicy ekosystemu mogą odłożyć inwestycje w różne rozwiązania „bez plików cookie”, w tym PA API, na czas po 3 czerwiecu 2023 r. Wtedy mogą zwiększyć budżet kampanii przeznaczony na takie rozwiązania. 2. Liczba żądań stawek w aukcjach PA API może być zależna od (1) tego, że wydawcy i ich dostawcy technologii reklamowych mogą zdecydować się na nieinicjowanie aukcji PA API, jeśli uznają, że popyt jest niski. To wydawcy decydują o priorytetach aktualizacji swoich stron i uczestnictwa w programie. Z tych powodów wydawcy mogą potrzebować czasu na przetestowanie i stopniowe zwiększanie ruchu. Raport zawiera też odpowiedź Google Ad Managera dotyczącą ustawień wydawcy dotyczących korzystania z interfejsu PA API. |
| (Również zgłaszane w poprzednich kwartałach) Oszustwo / nadużycie |
Jak ekosystem może ograniczyć ryzyko i zapobiec temu, aby nieuczciwi podmioty lub kupujący przedstawiali się jako pożądani odbiorcy? | Mechanizmy raportowania reklam w PA API zachowują informacje służące do odróżniania ruchu generowanego przez ludzi od ruchu generowanego przez boty. Ponadto w PA API można stosować obecne techniki uwzględniania i wykluczania domen oparte na domenach. Szczegółowe informacje na ten temat znajdziesz w naszej odpowiedzi na raport IAB Tech Lab na temat Piaskownicy prywatności. |
| Ograniczenie dotyczące tego samego pochodzenia w przypadku adresu URL właściciela i reguły ustalania stawek w IG | Ze względu na wymóg dotyczący tej samej domeny punkty końcowe właściciela IG będą musiały przechodzić przez ten sam system równoważenia obciążenia, co może powodować odrzucanie przekierowań. | Wymaganie ładowania skryptu z tego samego źródła jest ważnym zabezpieczeniem. Więcej informacji o proponowanym rozwiązaniu, które zapewnia równowagę między opiniami użytkowników a innymi czynnikami, znajdziesz tutaj. |
| Aukcja prywatna z wieloma slotami | W ramach granic prywatności można stosować aukcje prywatne z wieloma slotami, korzystając z elementu szumu i ściślejszej integracji z obecnymi praktykami dotyczącymi reklam. | Rozważamy tę opinię i analizujemy prośbę o aukcje wielotagowe pod kątem zwiększonej złożoności i zagrożeń dla prywatności związanych z tą funkcją. Więcej informacji na ten temat znajdziesz tutaj w ramach spotkania grupy dotyczącej inkubatora interfejsów API PA. |
| Najlepsi sprzedawcy | Obecna struktura interfejsu PA API zapewnia każdemu sprzedawcy na najwyższym poziomie znacznie więcej danych i wglądu w względną wartość wyświetleń niż wydawcom lub sprzedawcom komponentów. | W aukcji wielu sprzedawców każdy sprzedawca będzie miał najlepszą stawkę. Z doświadczeń w ekosystemie wynika też, że wydawcy mogą chcieć uwzględnić popyt sprzedawany bezpośrednio obok najlepszych stawek każdego sprzedawcy, z którym współpracują. Aby określić, która reklama ma się wyświetlać, należy wziąć pod uwagę wszystkie potencjalne możliwości zarabiania. Ta sytuacja, w której konieczne jest, aby jakiś podmiot widział pełny zestaw opcji, aby wybrać reklamę do wyświetlenia, jest starsza niż interfejs PA API. Interfejs PA API ma na celu obsługę aukcji z udziałem wielu sprzedawców oraz umożliwić wydawcom uwzględnianie najlepszej stawki każdego sprzedawcy obok kampanii reklamowych sprzedawanych bezpośrednio (gdzie to możliwe). Oznacza to, że musi istnieć mechanizm umożliwiający wybór spośród tych możliwości zarabiania, tak jak ma to miejsce obecnie. Uważamy, że nie powinno być rolą przeglądarki wybieranie reklam do wyświetlania. Dlatego koncepcja sprzedawcy najwyższego poziomu jest niezbędna do wybrania zwycięskiej reklamy spośród wielu możliwości. Logika tego sprzedawcy najwyższego poziomu musi umożliwiać uwzględnianie najlepszych stawek każdego sprzedawcy, z którym wydawca chce współpracować. Logika tego sprzedawcy może obejmować udostępnianie informacji o kampaniach sprzedanych bezpośrednio przez wydawcę, jeśli są one dostępne. Wszystkie te informacje mogą być uwzględniane w ramach logiki doboru reklam na najwyższym poziomie. Oznacza to, że logika najwyższego poziomu sprawdza najlepsze stawki z aukcji PA API oraz, w stosownych przypadkach, wszystkie opcje reklam sprzedawane bezpośrednio przez wydawcę, aby wybrać zwycięzcę. W tym raporcie w sekcji „Dostęp do informacji” Google Ad Manager podaje szczegółowe informacje o wdrożeniu interfejsu PA API jako sprzedawcy najwyższego poziomu. |
| Oddzielanie reklam konkurencyjnych | Prośba o oddzielenie reklam konkurencyjnych, np. o zapobieganie wyświetlaniu reklam konkurencyjnych marek obok siebie. | Nie znamy sposobu na zapewnienie oddzielenia konkurencji w dzisiejszym programistycznym ekosystemie reklam cyfrowych z licytacją i wielu sprzedawcami. Interfejs PA API umożliwia jednak sprzedawcom pobieranie dodatkowych sygnałów w czasie rzeczywistym na podstawie kombinacji adresu renderURL i nazwy hosta (reprezentującej domenę wydawcy), które można wykorzystać podczas wywoływania funkcji scoreAd() do oceny kreacji. Funkcja ta może być używana przez sprzedawców, aby zapobiec wyświetlaniu reklam konkurencyjnych marek obok siebie, o ile wydawca chce egzekwować tę zasadę. |
| Ograniczone informacje | Interfejs PA API ogranicza informacje dostępne wydawcom, takie jak wartość reklamy, nazwa kupującego komponent, nazwa reklamodawcy, adres URL strony docelowej, rozmiar kreacji, czas odpowiedzi i stawka stawki, a także stawki przegranych. | Proponowane rozwiązania znajdziesz tutaj. Zachęcamy do dzielenia się opiniami na temat ekosystemu. |
| Raportowanie na poziomie zdarzenia | Po wycofaniu interfejsu PA API do raportowania na poziomie zdarzenia wydawcy nie mogą uzyskać wystarczającej ilości informacji o wyświetlonej reklamie. | Zdajemy sobie sprawę z różnych przypadków użycia raportowania, które musimy nadal obsługiwać po wycofaniu raportowania na poziomie zdarzenia. Dlatego planujemy wycofanie raportowania na poziomie zdarzenia nie wcześniej niż w 2026 r. Zapraszamy do aktywnego udziału w procesie tworzenia trwałych rozwiązań, które mogą obejmować nowe pomysły na uzyskiwanie informacji przy zachowaniu prywatności. |
| Wiele platform SSP | Wartość dodana wynikająca z korzystania z wielu SSP będzie dla wydawców zbyt niska. | Nie uważamy, aby było to słuszne, i chcielibyśmy uzyskać więcej informacji od innych podmiotów z ekosystemu, aby zrozumieć uzasadnienie tego twierdzenia. |
| Działania związane z selekcją | Za pomocą interfejsu PA API nie można wykonywać czynności związanych z kuratorowaniem. | Otrzymaliśmy opinie na temat możliwości korzystania przez sprzedawców z interfejsu PA API do udostępniania kupującym informacji o odbiorcach w internecie (czyli rozszerzenia odbiorców). Uważamy, że jest to możliwe już teraz, za pomocą funkcji delegowania w PA i umowy biznesowej. Jednocześnie aktywnie rozważamy, czy i jak możemy lepiej dostosować się do tych rodzajów zastosowań. |
| Rezygnacja kupującego | Domyślne rezygnowanie przez kupującego z usług może spowodować gorsze wyniki aukcji komponentów. | Niezależnie od tego, czy definiujesz aukcję PA pojedynczego sprzedawcy czy wielu sprzedawców, sprzedawca musi wyraźnie podać kupujących w polu interestGroupBuyers w polu AuctionConfig. Na podstawie opinii z ekosystemu wiemy, że sprzedawcy mają umowy z niektórymi kupującymi, a z innymi nie, więc potrzebują wyraźnej kontroli nad tym, których kupujących uwzględnić w aukcji. Zapraszamy do dalszej dyskusji na GitHubie. |
| Rozmiar reklamy | Nie można przeprowadzić wstępnego filtrowania na podstawie rozmiaru reklamy i rozmiaru miejsca na reklamę. | Pracujemy nad dodaniem tej funkcji. Więcej informacji znajdziesz tutaj. |
| Obsługa kierowania wykluczającego na IG | Interfejs API do obsługi kierowania na wykluczające grupy odbiorców: wyświetlanie reklam tylko wtedy, gdy użytkownik nie należy do grupy odbiorców. | W tym zgłoszeniu na GitHub zaproponowano alternatywny sposób implementacji kierowania negatywnego, w którym przeglądarka bezpośrednio informuje serwer reklam, które reguły kierowania negatywnego powinny obowiązywać w przypadku konkretnego żądania reklamy. Chociaż wydaje się to atrakcyjnym podejściem, wszystkie zbadane przez nas wersje tej koncepcji umożliwiają serwerowi jednoznaczne zidentyfikowanie użytkownika. |
| akt prawny o usługach cyfrowych | Jak wydawca może korzystać z ramek ograniczonych, a jednocześnie zapobiegać renderowaniu odpowiedzi zawierających informacje podlegające przepisom ustawy o usługach cyfrowych? | Podobnie jak w przypadku każdej nowej technologii, każda firma jest odpowiedzialna za to, aby jej korzystanie z Piaskownicy prywatności było zgodne z prawem. Google nie może udzielać porad prawnych. W przypadku każdego interfejsu API opublikowaliśmy obszerną dokumentację techniczną, która powinna stanowić podstawę do dokonania niezbędnych ocen prawnych. Ramki ograniczone nie są wymagane do korzystania z interfejsu PA API przed 2026 rokiem, co daje zainteresowanym stronom dodatkowy czas na zapewnienie zgodności korzystania z tej technologii ze wszystkimi odpowiednimi przepisami. |
| Dokumentacja | Czy metoda updateAdInterestGroups() jest tymczasowa? | Nie ogłosiliśmy żadnych planów wycofania funkcji updateAdInterestGroup. W przyszłości możemy zastosować podobne zabezpieczenia prywatności, o których mówiliśmy w przypadku innych mechanizmów aktualizacji Instagrama, np. używając adresu IP jako serwera proxy i dodając opóźnienie przed aktualizacją. |
| Obsługa metadanych i własności logiki po stronie kupującego w przypadku systemów innych niż DSP | Prośba o możliwość działania jako serwer proxy dla platform DSP. | Jesteśmy świadomi tych opinii z segmentów innych niż DSP i rozważamy tę prośbę. Zapraszamy do dzielenia się opiniami na temat ekosystemu. |
| Raportowanie | Prośba o dodanie funkcji obsługi niestandardowej dla zbioru sygnałów lub wartości w raportach prywatnej agregacji. | Wiemy o tym i ta prośba o funkcję jest w kole na dalsze analizowanie. Zapraszamy do podzielenia się opinią na temat ekosystemu tutaj. |
| Dokumentacja | Czy istnieje link, w którym można wyświetlić wszystkie nagłówki odpowiedzi, które muszą być ustawione przez reklamodawcę i (delegowaną) domenę właściciela? | Planujemy aktualizację dokumentacji, aby wyjaśnić tę kwestię. Zapraszamy do dzielenia się opiniami na temat ekosystemu. |
| Określanie stawek w wielu wieżach | Prośba o wyjaśnienie procesu (trenowania i wyciągania wniosków) za pomocą diagramu architektury lub blokowej, który pokazuje, jak w ramach interfejsu PA API jest przewidziane podejście wielopoziomowe. | Dziękujemy za opinię. Mamy kilka prezentacji na ten temat, na podstawie których planujemy stworzyć dodatkową dokumentację. |
| Kierowanie wykluczające | Umożliwienie Piaskownicy prywatności ochrony wrażliwych odbiorców i osób małoletnich przed nieodpowiednimi reklamami, np. hazardem. | Interfejs PA API nie uwzględnia treści wyświetlanych reklam. To zależy od deweloperów technologii reklamowych korzystających z PA. Ogólnie rzecz biorąc, wydawca i jego dostawcy technologii reklamowych mogą blokować kreacje reklamowe w ramach aukcji Protected Audience, korzystając z informacji kontekstowych ze strony oraz zestawów reguł wydawcy. Odzwierciedla to nasze zrozumienie podejścia ekosystemu do tych wyzwań w obecnej chwili. Funkcja kierowania na negatywne wyszukiwanie w IG może być przydatna dla kupujących w niektórych przypadkach związanych z przestrzeganiem przepisów. |
| Projekt interfejsu API | Google stawia opór i chce, aby firmy technologiczne korzystały z funkcji ustalania stawek uniwersalnych, co zwiększa opóźnienie, zamiast różnych adresów URL funkcji ustalania stawek w różnych grupach reklam, co jest dozwolone. | W trakcie naszej dyskusji na temat czasu oczekiwania na aukcję podkreśliliśmy, że ponowne użycie tego samego skryptu na wszystkich stronach z grupami reklam kupującego przyspieszyłoby ustalanie stawek przez tego kupującego. Więcej informacji znajdziesz tutaj wraz z innymi zaleceniami dotyczącymi skracania czasu oczekiwania na aukcję w interfejsie PA API. |
| Marketing oparty na kontach | PA API nie jest czystym interfejsem API do zastosowań marketingowych opartych na kontach. | Zapraszamy do dzielenia się opiniami na temat konkretnych przypadków użycia, które według użytkowników są niemożliwe. Zachęcamy ich do kontynuowania tej dyskusji w naszym publicznym repozytorium GitHub lub podczas cotygodniowych rozmów. |
| Test A/B | Gdy interfejs PA API jest skonfigurowany w GAM dla wydawcy, musi być obecnie włączony dla całego zasobu reklamowego lub dla żadnego. Ogranicza to możliwość przeprowadzenia przez wydawców wiarygodnego testu A/B. | Odpowiedź zespołu Google Ad Manager: ustawienia interfejsu PA API w Google Ad Managerze (GAM) wpływają na możliwość korzystania z interfejsu API przez GAM, o ile jest on dostępny. Wydawcy mogą więc uruchamiać testy A/B, korzystając z funkcji zasad dotyczących uprawnień w Chrome, aby wyłączyć korzystanie z interfejsu API w podzbiorze ruchu, które ma służyć jako grupa kontrolna w ramach testu A/B. |
| Systemy uczące się | Wydawcy potrzebują większej kontroli nad proponowanym przez GAM wykorzystaniem systemów uczących się. | Odpowiedź Google Ad Managera: w styczniu 2024 r. wprowadziliśmy opcję, która umożliwia wydawcom wyłączenie ogranicznika działania systemów uczących się i włączenie aukcji Protected Audience API z udziałem sprzedawców spoza Google we wszystkich zasobach reklamowych. Więcej informacji o tej funkcji znajdziesz w Centrum pomocy. |
| (raportowane również w poprzednich kwartałach) Aukcji na najwyższym poziomie |
Możliwość korzystania z serwera reklamowego wydawcy Google bez konieczności przekazywania GAM kontroli nad aukcją na najwyższym poziomie interfejsu PA API. | Odpowiedź Google Ad Managera: z powodów podanych w raporcie Google za III kwartał 2023 r. plany GAM dotyczące integracji z interfejsem PA API nie obejmują obsługi wydawców korzystających z GAM jako serwera reklam wydawcy bez kontroli nad aukcją najwyższego poziomu. |
| Dostęp do informacji | GAM ma dostęp do cennych informacji o konkurentach, w tym o kontekstowych cenach aukcji, sygnałach przekazywanych przez kupujących do SSP w ramach aukcji PA API oraz parametrów konfiguracji pochodzących z SSP. | Odpowiedź Google Ad Managera: od lat kładziemy duży nacisk na uczciwość aukcji, w tym na naszej obietnicy, że żadna cena z żadnego niegwarantowanego źródła reklam wydawcy, w tym ceny niegwarantowanych elementów zamówienia, nie zostanie udostępniona innemu kupującemu przed złożeniem przez niego stawki w aukcji. Obietniliśmy to w zobowiązaniach wobec francuskiego urzędu ds. konkurencji. W przypadku aukcji w interfejsie PA API chcemy dotrzymać obietnicy i nie udostępniać stawki żadnego uczestnika aukcji żadnemu innemu uczestnikowi przed zakończeniem aukcji w aukcjach z udziałem wielu sprzedawców. Zapewniamy, że nie udostępnimy ceny aukcji kontekstowej żadnej aukcji komponentów, w tym naszej, jak wyjaśniliśmy w tej aktualizacji. Co więcej, w ramach naszej aukcji nie używamy informacji o konfiguracjach aukcji komponentów, w tym sygnałów przekazywanych przez kupujących do SSP. Zmiany w interfejsie PA API, które umożliwiłyby sprzedawcom komponentów określanie konfiguracji aukcji komponentów w sposób zaciemniony dla sprzedawcy najwyższego poziomu, byłyby dla nas bardzo korzystne. |
| Aukcje komponentów | Jako aukcja najwyższego poziomu GAM będzie określać, które SSP będą prowadzić aukcje komponentów w przypadku poszczególnych możliwości reklamowych. | Odpowiedź Google Ad Managera: jako serwer reklam wydawcy GAM udostępnia lekki interfejs API dla platform SSP, z których korzystają wydawcy, aby określać konfiguracje aukcji komponentów za pomocą interfejsu GPT (Google Publisher Tag). Więcej informacji znajdziesz tutaj. Jeśli dostawca SSP udostępnia konfigurację aukcji komponentów za pomocą tego interfejsu API, zostanie ona uwzględniona na liście aukcji komponentów dla danej możliwości reklamowej. GAM nie nakłada żadnych ograniczeń na aukcje komponentów. Każda sieć reklamowa, która chce przeprowadzić aukcję komponentów, może to zrobić, o ile wydawca zezwoli na uruchomienie niezbędnego kodu na swojej stronie. |
| Aukcje komponentów | GAM może stosować określony i nieujawniony minimalny poziom ceny w przypadku każdej wygranej stawki w aukcji komponentów. | Odpowiedź Google Ad Manager: przez wiele lat kładzieliśmy duży nacisk na sprawiedliwość aukcji. W ramach dbania o uczciwe i przejrzyste przeprowadzanie aukcji nie obsługujemy cen minimalnych, które mają zastosowanie tylko do określonych segmentów popytu. Jest to spójna zasada w naszej usłudze i będzie ona obowiązywać również w przypadku aukcji w interfejsie PA API. |
| Serwery reklamowe firm zewnętrznych | Serwery reklam zewnętrznych nie miałyby dostępu do udziału Google w aukcji na wyższym poziomie, co ogranicza ich możliwości korzystania z zasobów reklamowych SSP Google w kontekście interfejsu PA API. | Odpowiedź 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 komponentów w innych aukcjach najwyższego poziomu nie jest obecnie obsługiwany. |
| (raportowane również w poprzednich kwartałach) Skuteczność aukcji interfejsu API PA |
Testerzy zgłaszają, że aukcje interfejsu PA API mają długi czas oczekiwania. | Uwzględniając obawy związane z opóźnieniami, opracowaliśmy kilka funkcji w ramach interfejsu PA API, które pozwolą SSP ustalać limity opóźnień w DSP, a także wprowadzać ulepszenia, które mogą skrócić czas oczekiwania. Niedawno zaktualizowaliśmy przewodnik po sprawdzonych metodach dotyczących opóźnień, który zawiera więcej informacji o korzystaniu z tych funkcji. Cały czas pracujemy też nad nowymi ulepszeniami dotyczącymi opóźnień. Niektóre z nich znajdziesz tutaj. |
| (raportowane również w poprzednich kwartałach) Renderowanie filmów |
Obsługa renderowania filmów za pomocą interfejsu PA API i ramek ograniczonych. | W styczniu opublikowaliśmy prezentację, jak reklamy wideo in-stream mogą działać w ramach aukcji PA, wraz ze szczegółowymi informacjami o alternatywnych podejściach. Widzimy też, że uczestnicy ekosystemu zaczynają proponować rozwiązania dotyczące renderowania filmów dla partnerów, którzy się z nimi integrują, np. propozycje GAM dotyczące tworzenia adresów URL renderowania kompatybilnych z wideo czy pełny proces E2E. Przysłuchujemy się też opiniom użytkowników ekosystemu na temat zmian, które możemy wprowadzić, aby zwiększyć liczbę użytkowników. Jeden z takich pomysłów znajdziesz na GitHub. Wciąż aktywnie współpracujemy z ekosystemem, aby identyfikować inne przeszkody utrudniające wdrażanie i w sposób terminowy je rozwiązywać. |
| (również w poprzednich kwartałach) Zasady dotyczące przetwarzania danych |
Jakie są zasady dotyczące przetwarzania danych w interfejsie IGs / PA API? | W ramach projektu interfejsu PA API wszystkie dane przechowywane w IG lub dotyczące tego, w jakich IG znajdują się użytkownicy, (i) pozostają na urządzeniu lub (ii) są przetwarzane w usługach ustalania stawek i przetargów (B&A) działających w zaufanym środowisku wykonawczym (TEE). W obu przypadkach dane nie mogą być odczytywane przez inne strony ani wykorzystywane w żaden inny sposób niż do tworzenia ofert w aukcji. Niektóre ulepszenia dotyczące prywatności, które są obecnie testowane w Chrome, wymagają interakcji z prowadzonym przez Google serwerem k-anonimowości. Interakcje te są starannie projektowane, aby uniknąć udostępniania informacji o użytkownikach, oraz uruchamiane w urządzeniu TEE, aby zapewnić równość informacji w ekosystemie reklam. Google zobowiązało się do opracowania i wdrożenia propozycji dotyczących Piaskownicy prywatności w sposób, który nie zakłóca konkurencji przez preferowanie własnych usług, oraz do uwzględnienia wpływu na konkurencję w reklamach cyfrowych oraz na wydawców i reklamodawców. Nadal ściśle współpracujemy z CMA, aby zapewnić zgodność naszych działań z tymi zobowiązaniami. |
| (również w poprzednich kwartałach) Czas trwania interakcji z IG |
Prośba o przedłużenie okresu ważności identyfikatorów Google z 30 do 90 dni | Taka zmiana wymaga starannej oceny, w której należy porównać korzyści dla branży z jej wpływem na użytkowników Chrome i inne zainteresowane strony. Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj. |
| (również w poprzednich kwartałach) modelingSignals |
Poproś o dodanie nowego pola oprócz modelingSignals, które może kodować tylko informacje o kliknięciach i wyświetleniach. | W odpowiedzi na tę opinię przesłaliśmy propozycję tutaj. Aktywnie współpracujemy z branżą, aby poznać jej opinię na temat naszej propozycji. Obecnie porównujemy korzyści dla branży z efektem dla użytkowników Chrome i innych zainteresowanych stron. |
| Dodatkowe informacje w reportWin() | Dodaj dodatkowe bity w reportWin() z obecnego limitu 12 bitów przed 3PCD. | Obecnie szukamy sposobów na obsługę tego przypadku użycia. To zajmuje trochę czasu, ponieważ szukamy też sposobów, które pomogą nam w opracowaniu długoterminowego planu ochrony prywatności. |
| Projektowanie aukcji | Żądania dotyczące pojedynczej aukcji, które zwracają adresy URL renderowania z odpowiednimi wynikami. | Rozważaliśmy udostępnianie wielu adresów URL renderowania i odpowiednich wyników z jednej aukcji prywatnej, ale nie wprowadziliśmy tego ze względu na kwestie prywatności. Rozumiemy, że nie chcesz wyświetlać tej samej reklamy wielokrotnie jednemu użytkownikowi na jednej stronie. Zachęcamy do dalszej dyskusji na GitHubie. |
| reportWin | rejestrować dowolne pola za pomocą funkcji reportWin(). | Obecnie jest to już możliwe w trakcie okresu testów. Gdy Chrome przestanie obsługiwać 3 PC, wersja interfejsu API forDebuggingOnly zostanie przeniesiona, aby umożliwić debugowanie z obniżonym próbkowaniem, co zostało opisane tutaj. |
| Sprzedawcy komponentów | mieć niezależny mechanizm zliczania własnych wyświetleń i innych zdarzeń, który nie musi być zależny wyłącznie od raportów technologii reklamowych; | Ta prośba o funkcję jest w kolejce do dalszego sprawdzenia. Nie przewidujemy, aby udało się to rozwiązać w okresie testów przeprowadzanych przy użyciu Chrome. |
| Płatność za kliknięcie | Wdrożenie rozliczeń kosztem kliknięcia w PA API. | Rozpatrzyliśmy tę prośbę tutaj i uznaliśmy, że jest to prośba o sugestie dotyczące tego, jak wdrożyć ją za pomocą obecnego interfejsu API. |
| browserSignals | Dodaj incomingBidInSellerCurrency do specyfikacji browserSignals dla sprzedawcy. | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj. |
| Obsługa własności logiki i metadanych po stronie kupującego w przypadku systemów innych niż DSP | Obecna budowa interfejsu API może spowodować znaczną zmianę w kampaniach retargetujących na poziomie produktu, ponieważ może być konieczne przeniesienie ich na platformy, które pełnią funkcję zarówno dostawców DSP, jak i DCO. | Rozmawiamy o tym problemie i zapraszamy do podzielenia się opinią tutaj . |
| Obsługa własności logiki i metadanych po stronie kupującego w przypadku systemów innych niż DSP | Udostępnij przykłady, w których usługa DSP nie jest właścicielem konta IG. | Zdajemy sobie sprawę, że użytkownicy, którzy nie licytują, chcieliby korzystać z niektórych funkcji IG, ale nie z innych. Aktywnie analizujemy możliwości rozwiązania tych problemów i zapraszamy do dzielenia się opiniami tutaj. |
| Ustawienia limitu czasu | Wydawcy powinni mieć możliwość określenia liczby kont Ig, które mogą uczestniczyć w programie, oraz limitu czasowego na poziomie globalnym. | Zdajemy sobie sprawę, że użytkownicy chcą mieć większą kontrolę nad czasem oczekiwania i widocznością między sprzedawcą na najwyższym poziomie a sprzedawcą komponentów. Rozważamy tę prośbę. |
| Wiele rozmiarów reklam | Obsługa interfejsu PA API w przypadkach użycia związanych z wielu rozmiarami reklam. | Rozważamy tę prośbę i zapraszamy do podzielenia się opinią na temat ekosystemu. |
| Dokumentacja | Czy istnieje lista atrybutów IG, które podlegają k-anonowi? | Odpowiedź na to pytanie znajdziesz tutaj. |
| Debugowanie | Ulepszono możliwości debugowania interfejsu PA API. | Zdajemy sobie sprawę, jak ważne są niezawodne narzędzia do debugowania dla deweloperów korzystających z interfejsu PA API. Chcemy ulepszyć środowisko programistyczne, dlatego szukamy sposobów na lepsze zintegrowanie pobierania znanych plików z narzędziami dla deweloperów. Naszym celem jest zapewnienie większej przejrzystości i możliwości rozwiązywania problemów w środowisku programistycznym. Więcej informacji o tym problemie znajdziesz tutaj. Zachęcamy do podzielenia się z nami opinią. |
| Etykiety | Czy interfejsy API Piaskownicy prywatności są włączone dla wszystkich użytkowników, którzy mają etykiety trybu B? | Przypisania do grup eksperymentu w Chrome są ustalane losowo i niezależnie od ustawień Chrome skonfigurowanych przez użytkownika. Chociaż te interfejsy API mogą być dostępne dla użytkowników w określonych grupach eksperymentalnych (np. treatment_1.*), ich funkcjonalność można zmodyfikować lub wyłączyć w ustawieniach Chrome. Grupa kontrolna 2 w trybie B: dodanie do tej grupy powoduje automatyczne wyłączenie interfejsów API Piaskownicy prywatności służących do pomiaru i ustalania trafności. Użytkownik nie może zmienić tego ustawienia w ustawieniach Chrome. |
| Używanie API | Czy wywołanie reportWin() i renderowanie reklamy odbywają się równolegle czy po sobie? | Funkcja reportWin() jest wywoływana bezpośrednio po zakończeniu działania funkcji runAdAuction(). Jednocześnie proces renderowania reklamy może się rozpocząć, gdy wynik aukcji zostanie umieszczony w ramce iframe lub w ramce odizolowanej. Gdy funkcja reportWin() zakończy wykonywanie, a reklama zacznie się renderować, zostaną pobrane adresy URL podane do funkcji sendReportTo(). |
| (również w poprzednich kwartałach) Wsparcie dotyczące testów A/B |
Poproś o pomoc w testowaniu A/B interfejsu PA API. | Rozmawiamy o tej prośbie tutaj i zapraszamy do podzielenia się z nami opinią. |
| kształtowanie ruchu, | Proponowana przez Google metoda zarządzania wymaganą decyzją za pomocą serwera KV nie jest przydatna, ponieważ sprzedawcy nie mogą wchodzić w interakcje z ich backendem, co utrudnia kształtowanie ruchu. | Jak opisano w problemie na GitHubie, ujawnienie informacji o tym, czy poszczególne DSP mają IG, może wiązać się z problemami związanymi z odciskami palców użytkowników. W związku z tym problemem sugerujemy inne rozwiązania, ale chętnie poznamy też Twoje propozycje. |
| kształtowanie ruchu, | Mechanizmy buforowania zwiększają złożoność i uniemożliwiają platformom DSP poznanie prawdziwego kształtu ruchu, za który określają stawki. | Mechanizm buforowania został zaproponowany jako sugestia. Dostawcy technologii reklamowych mogą korzystać z sugestii, które odpowiadają ich potrzebom. Zachęcamy do dyskusji na ten temat tutaj. |
| Etykiety | Chrome powinien udostępniać etykietę jako parametr w żądaniach do zaufanych serwerów kupującego i sprzedawającego. | To rozsądliwa prośba, ponieważ jest zgodna z ogólnym celem odpowiedzialnego wykorzystywania danych na Instagramie. Rozważamy jednak prośbę, która podlega wewnętrznej weryfikacji, i będę informować o postępach w tej sprawie. |
| Używanie API | W dokumencie „Dodatkowe wskazówki CMA dla firm zewnętrznych dotyczące testowania” doprecyzowaliśmy definicję grupy „control_1”. 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 kontroli 1. | Nasz pogląd na ten temat znajdziesz w tym wątku na GitHubie. Nie możemy jednak wypowiadać się w imieniu CMA i zalecamy zgłaszanie wszelkich problemów związanych z interpretacją wskazówek dotyczących testowania bezpośrednio do CMA. |
| Używanie API | Czy Chrome pozwoli na wywołanie funkcji joinAdInterestGroup() na pustej stronie podczas przekierowywania do innego zasobu? | Jeśli użytkownik odwiedza jakąś witrynę, właściciel tej witryny może przekazać uprawnienia do wywołania metody joinAdInterestGroup stronie trzeciej. Ta delegacja umożliwia firmie zewnętrznej tworzenie interfejsów interfejsów Google bez konieczności dodawania żadnego rodzaju przekierowania na pustą stronę. Chętnie poznamy Twoje opinie na temat konkretnych powodów, dla których interfejsy Google powinny być tworzone w środku przekierowania zamiast za pomocą zamierzonego mechanizmu delegacji. |
| Używanie API | Giełdy powinny mieć możliwość zapisywania informacji o IG na stronach należących do współpracujących z nimi wydawców, a potem delegowania uprawnień do licytowania na podstawie tych informacji dowolnemu kupującemu lub platformie DSP. | Otrzymaliśmy Twoją opinię i sprawdzamy, czy możemy spełnić Twoją prośbę. Zapraszamy do dzielenia się opiniami na temat ekosystemu. |
| Używanie API | Jeśli nikt nie wygra aukcji interfejsu PA API, nie pojawi się powiadomienie o debugowaniu przegranej. | Funkcje reportWin i reportResult w Chrome zostały zaprojektowane do raportowania wygranych na poziomie zdarzenia w ramach systemu Privacy Auction (PA). W sytuacji, gdy wszystkie stawki są odrzucane podczas aukcji PA, te funkcje nie powinny być wywoływane, ponieważ nie jest określany zwycięzca. Niedawna aktualizacja Chrome może wyjaśniać rozbieżności, w których adresy URL przekazane do forDebuggingOnly.reportAdAuctionLoss() nie pojawiają się w panelu sieci w Narzędziach programisty. Zalecamy sprawdzenie tej funkcji w wersji Chrome z kanału Canary lub deweloperskiego. |
| Używanie API | Czy adCost zwracany przez generateBid może być ujemny (jest już losowo zaokrąglany do 2 bajtów)? | AdCost to koszt kliknięcia lub konwersji reklamodawcy przekazany z generateBid() do reportWin(). Ta wartość może być równa Null lub typu double. Wartości ujemne zostaną zignorowane i nie zostaną przekazane. Wartość zostanie zaokrąglona losowo. |
| Ulepszenie interfejsu API | Czy serwery z usługami Trusted and Encrypted Execution można wykorzystać do obsługi kierowania, grup odbiorców, atrybucji i aukcji zamiast przeglądarki Chrome? | Zalecamy zapoznanie się z komponentami i opcjami opartymi na TEE w PA API (np. serwery KV i usługi B&A), a także z komponentami opartymi na TEE w ramach raportowania atrybucji i prywatnej agregacji (np. usługa agregacji), które odpowiadają na to pytanie. |
| Ulepszenie interfejsu API | Czy odpowiedź na aukcję w ramach Piaskownicy prywatności może być odpowiedzią na stawkę (jak w przypadku określania stawek przez kod w nagłówku) zamiast odpowiedzią na reklamę (jak w przypadku tagów reklamy)? | Takie zmiany zasadniczo zmieniają właściwości prywatności interfejsu PA API, dlatego nie rozważamy ich. |
| Kontrola wydawców | Czy wydawcy mogą blokować kreacje PA API na swoich stronach? | Chrome zawiera propozycję skanowania kreacji w czasie rzeczywistym, która nie jest jeszcze dostępna do testowania. Chociaż ta funkcja nie jest jeszcze dostępna, zauważyliśmy, że większość SSP stworzyła rozwiązania, które ją umożliwiają. |
| Używanie API | Jaki jest limit rozmiaru sygnałów kupujących? | W klasycznej formie sygnały perBuyerSignals nie mają żadnych ograniczeń rozmiaru w Chrome. Główne ograniczenia to to, że dane można zserializować w formacie JSON i nie powodują one nadmiernego zużycia pamięci. Pamiętaj jednak, że bardzo duże i złożone sygnały perBuyerSignals mogą negatywnie wpływać na skuteczność. Istnieje alternatywna metoda przekazywania sygnałów kupującego za pomocą atrybutu directFromSellerSignalsHeaderAdSlot. To podejście umożliwia przesyłanie sygnałów perBuyerSignals w nagłówku, z ograniczeniem maksymalnego rozmiaru całej odpowiedzi nagłówka do 10 KB. Dodatkowo poszczególne serwery mogą nakładać własne ograniczenia dotyczące maksymalnego rozmiaru nagłówka. |
| Dokumentacja | Dokumentacja dotycząca wywołania registerAdBeacon z poziomu funkcji generateBid wymaga zmiany. | 17 lutego zaktualizowaliśmy tę dokumentację . |
| Używanie API | Jak reportEvent wybiera odpowiedni URL beacona spośród wielu zarejestrowanych opcji? | Każda aukcja powoduje utworzenie osobnej konfiguracji, która z kolei powoduje utworzenie osobnej mapy raportowania. Poszczególne aukcje (i ich ramki) są całkowicie od siebie niezależne i nie udostępniają danych. Więcej informacji na ten temat znajdziesz w artykule Raporty o reklamach w ramkach odizolowanych. |
| Interfejs Chrome | Dodaj w narzędziach deweloperskich Chrome na karcie „Application -> Groups of interest” filtr, który pozwoli filtrować według właściciela grupy zainteresowań (lub może też według nazwy grupy). | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią na temat naszego ekosystemu. |
| Chrome bez interfejsu graficznego | Obsługa interfejsu PA API w Chrome bez interfejsu graficznego. | Niektóre komponenty interfejsu PA API są powiązane z Chrome, np. wywołania k-anon na serwery Google, które mogą nie działać w „starej” wersji bez interfejsu użytkownika Chrome. Uważamy, że problem ten może zostać rozwiązany w „nowej” wersji bez interfejsu użytkownika Chrome, która została wydana w Chrome 112. |
| Używanie API | W przypadku raportowania strat w ramach funkcji reportAdAuctionLoss w wielu przypadkach widzimy wartość „topLevelWinningBid=0”. Jak to interpretować? | Wartość topLevelWinningBid pochodzi z funkcji scoreAd() w komponencie sprzedawcy na najwyższym poziomie. Ta wartość ma znaczenie przy określaniu wyniku aukcji najwyższego poziomu. Zgodnie z opisem wartość topLevelWinningBid równa 0 lub ujemna oznacza, że odpowiadająca jej reklama nie kwalifikuje się do wygrania aukcji. Mechanizm ten może być używany np. do odfiltrowywania reklam kierowanych na grupy zainteresowań, które nie wygrywają z reklamami kierowanymi na podstawie kontekstu. Chociaż wartość topLevelWinningBid = 0 może wskazywać, że wygrała aukcja kontekstowa, specyfikacja interfejsu PA API wskazuje, że inne czynniki mogą mieć wpływ na ten wynik. |
| Tryb testów A/B | Wyjaśnienie dotyczące wyboru ruchu w trybie B i A oraz promptów rezygnacji. | Kryteria uwzględnienia w trybie A i B są takie same. Celem jest tworzenie grup reprezentatywnych dla zwykłego ruchu w Chrome, o ile obsługują one interfejsy API Piaskownicy prywatności i metodę etykietowania, ponieważ niektóre konfiguracje klienta są niezgodne. W ramach eksperymentu ważne jest, aby porównywać tylko ruch z oznaczoną etykietą z innym ruchem z oznaczoną etykietą. Użytkownicy w trybie B mają włączoną funkcję ochrony przed śledzeniem i w związku z tym otrzymują powiadomienie o tej funkcji. |
| Ulepszenie interfejsu API | Czy „lifetimeMs” może być uwzględniony jako bezpośrednia właściwość w wywołaniu joinAdInterestGroup, czy też należy zarządzać nim jako osobnym argumentem? | Uważnie analizujemy opinie społeczności programistów dotyczące funkcji „joinAdInterestGroup” w ramach propozycji interfejsu PA API. Głównym tematem dyskusji będzie optymalna metoda zarządzania czasem trwania gradientu zintegrowanego. Oceniamy zalety oddzielnego argumentu dla parametru „lifetimeMs”, ponieważ zwiększa on elastyczność i możliwość dostosowania do potencjalnych przyszłych ulepszeń specyfikacji. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Możliwość zwiększenia liczby fałszywie negatywnych wyników w ramach interfejsu PA API z powodu kolizji z identyfikatorami przeglądarki o niskiej entropii. | Zespół Chrome stale pracuje nad ulepszaniem interfejsu PA API. Dziękujemy za dyskusję na temat potencjalnych współczynników fałszywie negatywnych wynikających z kolizji identyfikatorów przeglądarki. Starannie analizujemy te opinie i dołożymy wszelkich starań, aby zaktualizowane analizy uwzględniały wszystkie istotne czynniki. Jesteśmy zaangażowani w tworzenie rozwiązań, które zapewniają pożądane wyniki w zakresie ochrony prywatności, a zarazem zachowują dokładność i niezawodność. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Czy identyfikator przeglądarki o niskiej entropii jest niezbędny, aby uniemożliwić klientom wielokrotne przesyłanie żądań „Join” (Dołącz) dotyczących tego samego obiektu w systemie k-anonimowości? | Doceniamy trwającą dyskusję na temat stosowania identyfikatorów przeglądarki w ramach systemów zapewniających k-anonimizację. Rozumiemy obawy dotyczące potencjalnych konsekwencji takich identyfikatorów dla prywatności. Nasz początkowy system używał identyfikatora o niskiej entropii jako mechanizmu zapobiegania nadużyciom, ale aktywnie badamy alternatywne techniki, takie jak anonimowe tokeny zliczające, które kładą nacisk na ochronę prywatności użytkowników przy jednoczesnym zachowaniu integralności systemu. Zależy nam na znalezieniu rozwiązań, które pozwolą zachować równowagę między odpowiedzialnym korzystaniem z danych a skuteczną ochroną prywatności. Zachęcamy do dalszego dialogu z środowiskiem badaczy. Rozmawiamy o tym tutaj i chętnie poznamy Twoją opinię . |
| Używanie API | Czy AMP (przyspieszone strony mobilne) obsługuje interfejs PA API? | AMP nie obsługuje obecnie interfejsu PA API. Zachęcamy do przesyłania dodatkowych opinii z ekosystemu, jeśli obsługa AMP jest priorytetem. |
| Ulepszenie interfejsu API | Rozważ usunięcie tego typu z sprawdzeń k-anonimowości. | Uważnie rozważamy opinie na temat potencjalnej optymalizacji struktury żądań anonimowości k. Rozumiemy Twoją sugestię dotyczącą konsolidacji parametrów i ewentualnego ujednolicania typów w celu usprawnienia procesu. Naszym celem jest zapewnienie efektywności i możliwości konserwacji. W miarę rozwoju naszych rozwiązań dotyczących prywatności analizujemy wszystkie opcje. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Interfejs Chrome | Prośba o mechanizm umożliwiający mniej zaawansowanym użytkownikom łatwe wyświetlanie informacji o grupach, do których należą, oraz zarządzanie nimi, w tym potencjalne ustawienia na poziomie witryny umożliwiające rezygnację z dostępu do grupy. | Zdajemy sobie sprawę, jak ważne jest udostępnianie użytkownikom łatwych w użyciu narzędzi do analizowania i zarządzania informacjami o gościach. Po dokładnym przeanalizowaniu różnych metod stwierdziliśmy, że identyfikowanie kont IGS na podstawie witryny, do której zostały dodane, zapewnia najlepszy kompromis między przejrzystością a ochroną prywatności. Obecnie globalne zarządzanie IGs jest dostępne w ustawieniach Chrome. Cały czas szukamy sposobów na dalsze polepszanie wrażeń użytkowników w tym obszarze. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Bezpieczeństwo interfejsu API | Czy interfejs PA API jest podatny na wycieki danych osobowych w ramach interakcji z kreacją reklamy, nawet w kontekście odizolowanych ramek? | Zdajemy sobie sprawę z potencjalnego wycieku informacji w wyniku korzystania z zaawansowanych interakcji z reklamami. Aktywnie badamy wzajemne oddziaływanie chronionych ramek, interfejsu PA API i potencjalnych wektorów ataków. Minimalizowanie zagrożeń dla prywatności jest dla nas najwyższym priorytetem, dlatego opracowujemy niezawodne rozwiązania, które zapewniają równowagę między innowacyjnością a ochroną użytkowników. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Czas oczekiwania | Czy domyślny limit czasu 50 ms dla logiki określania stawek przez kupującego to realistyczna wartość? | Zdajemy sobie sprawę z wyrażonych obaw dotyczących potencjalnych niespójności między specyfikacją a czasem żądań sieci w ramach logiki ustalania stawek. Aktywnie sprawdzamy specyfikacje, aby mieć pewność, że są one prawidłowe, i badamy optymalne domyślne ustawienia limitu czasu, aby zachować równowagę między wydajnością a możliwościami. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Dokumentacja | Możliwe wycieki czasu w specyfikacji, w której witryna może wywnioskować, czy reklama nie spełnia wartości progowej k-anonimowości, oraz potencjalne konsekwencje dla śledzenia w witrynach. | Rozumiemy, że problem dotyczy potencjalnego wycieku informacji o czasie. Potwierdiliśmy rozbieżność w specyfikacji i podejmujemy działania, aby zapewnić, że stan k-anonimowości reklam jest określany przed aukcją, aby zapobiec takim wyciekom. Podchodzimy poważnie do tych obaw i zaktualizujemy specyfikację, aby uwzględnić te zmiany. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Sposoby implementowania listy zablokowanych SSP w interfejsie PA API | Dostrzegamy potrzebę mechanizmów zarządzania ograniczeniami reklam przez SSP. Zachęcamy do wypróbowania rozwiązań, które stawiają na pierwszym miejscu analizę na urządzeniu i korzystają z dotychczasowych metadanych reklam, aby chronić prywatność użytkowników i zapewnić elastyczność. Współpracujemy z deweloperami, aby znaleźć optymalne podejścia do korzystania z interfejsu PA API. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Czy ktoś może poprosić przeglądarkę, aby udawała interfejs PA API w sposób, którego nie da się wykryć w witrynach? | Zdajemy sobie sprawę, że w obecnej formie rezygnacja z interfejsu PA API może być wykrywana przez witryny. Aktywnie pracujemy nad funkcjami takimi jak dodatkowe stawki i kierowanie negatywne, a także nad renderowaniem ramek ograniczonych, aby zwiększyć prywatność i zapewnić niezauważalne opcje rezygnacji. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Tryb testów A/B | Ruch z centrum danych, który ma być związany z eksperymentem 1.1. | Zespół Chrome potwierdził zespołowi GAM, że ten ruch jest teraz odfiltrowywany z eksperymentu. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Skuteczność i sprawiedliwość wdrożenia interestGroupBuyers w PA API. | Wiemy, że trwa dyskusja na temat skuteczności i uczciwości pola „interestGroupBuyers” w aukcjach interfejsu PA API. Zdajemy sobie sprawę z kompromisów między wydajnością, prywatnością i sprawiedliwością na rynku. Podczas gdy sprzedawcy muszą zarządzać relacjami biznesowymi z kupującymi, my szukamy sposobów na optymalizację procesu dopasowywania. Mogą to być dynamiczne korekty na podstawie danych w czasie rzeczywistym i modeli hybrydowych. Nadal szukamy rozwiązań, które stawiają na pierwszym miejscu prywatność użytkowników i wspierają konkurencyjną ekosystem reklamowy. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Interfejs Chrome | Potencjalne problemy z pamięcią i czytelnością interfejsu związane z IG w Chrome. | Rozumiemy Twoje obawy dotyczące wyświetlania informacji o identyfikatorze w Narzędziach deweloperskich. Chociaż bieżący widok odzwierciedla wszystkie zdarzenia IG w przypadku śledzenia historycznego, zdajemy sobie sprawę z wartości, jaką stanowi zapewnienie lepszej widoczności bieżącego stanu przechowywanych informacji o gościach. Sprawdzimy optymalizacje i potencjalne ulepszenia interfejsu użytkownika, aby zwiększyć użyteczność dla deweloperów. Jeśli chodzi o zarządzanie pamięcią, implementacja Instagrama została zaprojektowana tak, aby zapobiegać wyciekom pamięci. Ciągle jednak monitorujemy i optymalizujemy wykorzystanie zasobów. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Dokumentacja | Pierwotny autor napotyka błąd, gdy próbuje użyć nazwanych rozmiarów reklam bezpośrednio w polu „sizeGroup” w funkcji „joinAdInterestGroup”. Chce wiedzieć, czy jest to zamierzone działanie. | Doceniamy wartość uproszczenia konfiguracji reklam w ramach funkcji „joinAdInterestGroup”. Pracujemy nad rozwiązaniem tego ograniczenia i planujemy wdrożenie tej funkcji w przyszłych aktualizacjach. Ta funkcja jest zgodna z naszym zobowiązaniem do zapewniania deweloperom elastycznych i skutecznych narzędzi do zarządzania reklamami. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Etykieta testów przeprowadzanych przy użyciu Chrome | Prośba o bezpośrednie dane o trybie A i B oraz dokładne etykiety w parametrze sendReportTo, abyśmy mogli konsekwentnie śledzić eksperyment. | Omawiamy tę prośbę tutaj i zapraszamy do podzielenia się dodatkowymi opiniami. |
| Dokumentacja | Czy nazwa domeny sprzedawcy jest uwzględniona w żądaniach wysyłanych do zaufanych serwerów sprzedawcy na potrzeby weryfikacji? | Przyznajemy, że parametr nazwy hosta został pominięty w dokumentacji interfejsu Protected Audience KV Server API. Zapewniamy deweloperów, że nazwa domeny sprzedawcy jest automatycznie uwzględniana w zapytaniach do zaufanych serwerów sprzedawcy. Ta funkcja jest niezbędna do wszechstronnego procesu weryfikacji reklam. Zaktualizowaliśmy dokumentację, aby naprawić ten błąd. W dalszym ciągu będziemy dawać priorytet jasności i przejrzystości dla społeczności deweloperów. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Możliwe metody uwzględniania nazwy IG w wywołaniach funkcji śledzenia wyświetleń reklam na potrzeby raportowania. | Staramy się zachować równowagę między potrzebą zapewnienia niezawodnych mechanizmów raportowania a podstawową zasadą ochrony prywatności użytkowników. Uwzględnianie nazw kont Instagram w śledzeniu wyświetleń reklam podlega zabezpieczeniom k-anonimowości, które mają na celu zapobieganie identyfikacji poszczególnych osób. Będziemy nadal szukać innowacyjnych rozwiązań raportowania, które będą zgodne z tymi ograniczeniami dotyczącymi prywatności. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Funkcja interfejsu API | Prześlij żądanie do zaufanych serwerów kupującego, aby otrzymać nagłówki HTTP wskazówek klienta. | Prośbę o dodanie tej funkcji śledzimy tutaj. |
| Używanie API | Czy plik delegowania powinien wymagać załadowania nagłówka „Access-Control-Allow-Origin”, ponieważ określa zachowanie członkostwa w IG w przeglądarce? | Zależy nam na stosowaniu sprawdzonych metod dotyczących bezpieczeństwa w internecie. Wymaganie nagłówka „Access-Control-Allow-Origin” w przypadku plików delegacji zapewnia zgodność z zasadami CORS i zapobiega niezamierzonemu ujawnieniu informacji poufnych. Szukamy sposobów na optymalizację tego procesu przy jednoczesnym zachowaniu wysokiego poziomu zabezpieczeń. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Umożliwianie serwerom reklamowym personalizowanie kreacji w ramach interfejsu PA API. | Zdajemy sobie sprawę, jak ważną rolę w personalizacji kreacji pełnią serwery reklam. Aktywnie szukamy rozwiązań, które wzmocnią serwery reklam w ramach interfejsu PA API, np. modelu „wspólnego IG”, w którym można połączyć logikę ustalania stawek i wyboru kreacji reklamy. Naszym celem jest znalezienie równowagi między zapewnieniem solidnych możliwości kreacji reklam a ochrona prywatności użytkowników. Zachęcamy do dalszej współpracy i przekazywania opinii na temat ulepszania interfejsu API, aby spełniał on potrzeby wszystkich zainteresowanych stron. Tutaj znajdziesz więcej informacji. |
| Kwestie dotyczące prywatności | Dostępność identyfikatorów alternatywnych (np. Użycie w interfejsie API reklam kontekstowych identyfikatorów sesji (np. RampID, ID5) może utrudniać realizację celów związanych z prywatnością w interfejsie PA API, ułatwiając zbieranie danych z różnych witryn. | Zdajemy sobie sprawę z potencjalnego konfliktu między identyfikatorami śledzącymi użytkowników w różnych witrynach a celami dotyczącymi prywatności w interfejsie PA API. Chociaż wydawcy mogą udostępniać takie identyfikatory, celem interfejsu PA API jest odseparowanie wyboru reklam od śledzenia w wielu witrynach. Zależy nam na tworzeniu ekosystemu reklamowego skoncentrowanego na ochronie prywatności, dlatego zachęcamy deweloperów do stosowania interfejsu PA API. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Pamięć podręczna | Czy można zapobiec ponownemu używaniu skryptów ustalania stawek w różnych aukcjach? | Zdajemy sobie sprawę z zachowania buforowania skryptów określania stawek w ramach interfejsu PA API. Chociaż obsługiwane są standardowe mechanizmy buforowania HTTP, istnieje możliwość ponownego użycia skryptu w ramach aukcji z powodu zawieszania urządzenia i projektu wykonawców ustalania stawek. Nasz zespół bada rozwiązania, które zapewnią kupującym większą kontrolę nad buforowaniem skryptów, aby mogli skuteczniej zarządzać strategiami ustalania stawek. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Scentralizuj raportowanie aktywności związanej z określaniem stawek we wszystkich grupach reklam na platformie DSP z poszanowaniem prywatności użytkowników. | Podczas projektowania interfejsu PA API priorytetem jest ochrona prywatności użytkowników. Ze względu na ryzyko śledzenia w wielu witrynach bezpośrednie raportowanie poszczególnych zdarzeń określania stawek jest niemożliwe, ale oferujemy mechanizmy takie jak współdzielona pamięć masowa i prywatna agregacja. Dzięki nim DSP mogą uzyskiwać zbiorcze statystyki dotyczące aktywności związanej z określaniem stawek w sposób, który chroni prywatność użytkowników. |
| Używanie API | Wybieranie danych z sendReportTo() w reportResult() występuje tylko w 94% przypadków w porównaniu z wybieraniem zarejestrowanym w forDebuggingOnly.reportAdAuctionWin(). | Nie muszą one być pobrane w tym samym momencie, ale może się zdarzyć, że oba adresy URL zostaną pobrane jednocześnie. W niektórych przypadkach element worklet sprzedawcy komponentu został usunięty i należy go ponownie załadować, aby uruchomić funkcję reportResult(). Jednak ani czas pobierania logiki punktacji, ani czas ponownego wczytywania workleta nie wpływa na limit czasu 50 ms w przypadku funkcji reportResult(). Pamiętaj, że w przypadku ponownego wczytywania workleta Chrome będzie używać nagłówków pamięci podręcznej, aby zdefiniować zachowanie pobierania. Więcej informacji o fazach aukcji PA znajdziesz tutaj. |
| K-anonimowość | Prośba o potwierdzenie, że nazwa grupy zainteresowań nie wpływa na k-anonimizację wyświetlania reklam. | Aby kreacja była uważana za k-anonimową, tupla adresu URL właściciela IG, adresu URL skryptu ustalania stawek, adresu URL kreacji i rozmiaru reklamy musi spełniać określony próg (k) w określonym okresie (w). Stan k-anonimowości jest okresowo aktualizowany (p). |
| Interfejs Chrome | Propozycja udostępnienia typu „widoczność wewnętrzna”, który oferują liczne frameworki, np. MVC, ORM. Zacznij np.od prostego rejestrowania wybranych zdarzeń wewnętrznych w nowym panelu w sekcji Narzędzia dla programistów -> Aplikacja -> Aplikacja. | Rozmawiamy o propozycji tutaj i zapraszamy do dzielenia się opiniami. |
| Interfejs Chrome | Wtyczka DevTools IG nie pokazuje elementów związanych z priorytetem. | Rozwiązaliśmy ten problem tutaj. |
| Ulepszenie interfejsu API | Lepiej jest zezwolić serwerowi reklamy kreacji na śledzenie własnych zdarzeń. Czy można skonfigurować listę dozwolonych domen śledzenia? | Udostępniliśmy propozycję tutaj i zapraszamy do podzielenia się opinią na temat tego rozwiązania. |
| Prośba o funkcję interfejsu API | Czy interfejs PA API można rozszerzyć o transakcje z mediami, które nie są realizowane w ramach RTB, i utrzymać kluczowe przypadki użycia, takie jak wyświetlanie reklam i DCO? | Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Czas oczekiwania na aukcję wydawcy | Wydawcy muszą mieć kontrolę nad czasem trwania aukcji, aby uniknąć utraty wyświetleń, zwłaszcza w przypadku konfiguracji określania stawek w nagłówku, w której reklamy są wybierane sekwencyjnie. | Zdajemy sobie sprawę, że ważne jest zapewnienie wydawcom szczegółowej kontroli nad czasem oczekiwania na zakończenie aukcji reklam. Aktywnie szukamy sposobu na implementację globalnego mechanizmu limitu czasu aukcji, prawdopodobnie w obiekcie „auctionConfig”, przy jednoczesnym dokładnym rozważaniu skrajnych przypadków. Ta funkcja ma na celu optymalizację współczynników wyświetleń dla wydawców. Będziemy nadal współpracować ze społecznością, aby znaleźć najlepsze rozwiązanie. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Ulepszenie interfejsu API | Obecna konstrukcja interfejsu IG w PA API powoduje duże rozmiary metadanych ze względu na długie adresy URL renderowania. Testerzy chcieliby skompresować te adresy URL, aby zwiększyć wydajność. | Zdajemy sobie sprawę, jak ważne jest optymalizowanie rozmiaru metadanych Instagrama, zwłaszcza w przypadku aukcji reklam, w których chodzi o skuteczność. Uważamy, że rozwiązanie oparte na szablonach do kompresji adresów renderURL ma duży potencjał. Będziemy dokładnie sprawdzać proponowane projekty szablonów i upewniać się, że każde wdrożone rozwiązanie zawiera solidne mechanizmy zapobiegania nadużyciom, które zapewniają stabilność przeglądarki. Współpraca ze społecznością zajmującą się standardami internetowymi w celu opracowania optymalnego podejścia z uwzględnieniem tych kwestii pozostaje priorytetem. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Testerzy zajmujący się formatami reklam natywnych chcą zoptymalizować proces aukcji w Piaskownicy prywatności, pobierając wiele wyników reklam w jednym wywołaniu, aby zmniejszyć obciążenie sieci i przyspieszyć renderowanie reklam. | Zdajemy sobie sprawę z problemów ze skutecznością renderowania reklam natywnych w Piaskownicy prywatności. Dokładamy wszelkich starań, aby znaleźć równowagę między wydajnością a skuteczną ochroną prywatności użytkowników. Chociaż zwracanie wielu reklam z pełną oceną narusza prywatność, aktywnie szukamy sposobów na optymalizację procesu aukcji. Staramy się zwiększyć obsługę interfejsu PA API w przypadku formatów reklam natywnych i badać alternatywne mechanizmy, które pozwolą zwiększyć skuteczność przy zachowaniu rygorystycznych ograniczeń dotyczących prywatności w ramach Piaskownicy prywatności. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | elastyczność w zakresie sposobu oceniania i sortowania stawek reklam w Piaskownicy prywatności, zwłaszcza w celu reprezentowania poziomów priorytetów lub reguł prywatnych rynków; | Zdajemy sobie sprawę, że w Piaskownicy prywatności potrzebna jest szczegółowa kontrola punktacji i sortowania reklam, zwłaszcza w kompleksowych scenariuszach ustalania stawek. Zdajemy sobie sprawę, że proponowane rozwiązania wykorzystują tuple i funkcje matematyczne do uzyskiwania wielowymiarowych wyników bez naruszania prywatności użytkowników. Chociaż te podejścia mogą zwiększać złożoność dla deweloperów, zapewniają niezbędną wyrazistość. Staramy się znaleźć sposoby na usprawnienie tych procesów, np. za pomocą funkcji pomocniczych lub wytycznych, aby zapewnić optymalne wykorzystanie funkcji Piaskownicy prywatności w ramach zaawansowanej logiki aukcji. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| reportEvent() | Dodaj nowe zarezerwowane zdarzenie (np. automatyczny sygnał beacon) wywoływane przez przeglądarkę po zainicjowaniu ramki z kreacją reklamy. | Rozmawiamy o tej prośbie tutaj i zapraszamy do podzielenia się z nami opinią. |
| adCost | Zezwalanie na podział według wartości adCost. | Każda wartość kosztu to możliwość wysłania ograniczonej ilości informacji z aukcji. Zezwalanie na wyświetlanie całej listy N tych kosztów wystarczyłoby do wysłania pełnego identyfikatora użytkownika, co umożliwiłoby śledzenie w wielu witrynach. Omawiamy to tutaj i zapraszamy do dzielenia się opiniami. |
| resolveToConfig | Czy wartość resolveToConfig powinna być dziedziczona z poziomu najwyższego i wyświetlana w browserSignals? | Rozmawiamy o tej prośbie tutaj i zapraszamy do podzielenia się z nami opinią. |
| Lepsze narzędzia | Czy istnieje coś podobnego do chrome://topics-internals, ale dla interfejsu PA API? | Nie ma nic dokładnie takiego samego. Dostępne są jednak rozbudowane narzędzia dla programistów dotyczące interfejsu PA API. |
| Etykiety | Czy Chrome może używać etykiet do identyfikowania 20% użytkowników anonimowych? | Rozważamy tę prośbę i zapraszamy do podzielenia się opinią na temat ekosystemu. |
| Dokumentacja | Czy elementy robocze aukcji w Piaskownicy prywatności staną się standardowymi typami elementów roboczych? | Ze względu na unikalne wymagania dotyczące prywatności i bezpieczeństwa te worklety różnią się znacznie od standardowych typów workletów w specyfikacji HTML, dlatego nie przewidujemy, aby w najbliższej przyszłości stały się one standardowymi typami workletów. Zamierzamy rozszerzyć nasze zasoby dla deweloperów o jasne wyjaśnienia dotyczące środowiska implementacji i wykonania workletów aukcji, aby ułatwić dostęp do tych informacji uczestnikom programu Privacy Sandbox. Więcej informacji na ten temat znajdziesz tutaj. |
| Serwer klucz-wartość (KV) z własnym serwerem (BYOS) | Strony mogą uzyskać informacje o wielu IG (należących do tego samego właściciela), do których użytkownik dołącza za pomocą zapytań do usług KV w ramach konfiguracji usługi KV w ramach usługi KV BYOS. | Nie będzie to już możliwe, gdy serwery KV będą działać w enklawach TEE, a my będziemy mogli mieć pewność, że będą one przestrzegać opublikowanego modelu zaufania. |
| userBiddingSignals | zaktualizować część sygnałów „userBiddingSignals”, zachowując pozostałe. | Jest to już możliwe bez wprowadzania żadnych zmian w interfejsie API. |
| Używanie API | Wdrożenie ograniczenia liczby wyświetleń w wielu IG w ramach Piaskownicy do prywatności, prawdopodobnie przy użyciu serwera KV lub zmodyfikowanych danych „prevWinsMs”. | Zdajemy sobie sprawę, że użytkownicy chcą korzystać z zaawansowanych funkcji ograniczania częstotliwości w Piaskownicy prywatności. Zdajemy sobie sprawę, że obecne ograniczenia dotyczące udostępniania danych w ramach interfejsów API mogą stanowić wyzwanie podczas wdrażania tych strategii. Serwer KV udostępnia potencjalny mechanizm z odpowiednimi środkami ochrony prywatności, ale zachęcamy deweloperów do zbadania rozwiązań w ramach pojedynczego modelu IG. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
| Używanie API | Sprzedawcy komponentów (czyli uczestnicy aukcji zagnieżdżonych w Piaskownicy prywatności) muszą mieć widoczne limity czasu aukcji na najwyższym poziomie, aby optymalizować własne konfiguracje i unikać niepotrzebnych opóźnień. | Zdajemy sobie sprawę z konieczności lepszej koordynacji limitów czasu między sprzedawcami na najwyższym poziomie a sprzedawcami komponentów w ramach piaskownicy prywatności. Aktywnie badamy możliwość dodania nowych mechanizmów limitowania czasu, w tym limitowania czasu w całości aukcji, i sprawdzamy, czy można stosować limity czasu na najwyższym poziomie w aukcjach komponentów. Naszym celem jest zwiększenie wydajności i przewidywalności dla wszystkich uczestników procesu aukcji w Piaskownicy prywatności. Rozmawiamy o tym problemie tutaj i zapraszamy do dzielenia się opiniami. |
Usługi Protected Audience
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Zaufane środowisko wykonawcze (TEE) | Czy uruchamianie TEE w chmurach publicznych jest droższe niż w przypadku lokalnych centrów danych technologii reklamowych? | Odpowiedź jest podobna do tej z poprzednich kwartałów: nasz obecny model zabezpieczeń TEE korzysta z praktyk związanych z wdrożeniami w chmurze publicznym. W szczególności obecne TEE oparte na sprzęcie nie chronią przed wszystkimi atakami fizycznymi. Nasi obecni dostawcy chmur publicznych, AWS i Google Cloud, opracowali i wdrožili rozwiązania ograniczające ryzyko związane z dostępem fizycznym, w tym ze strony pracowników. Poniżej znajdziesz informacje o pomocy na miejscu. Firmy zajmujące się technologiami reklamowymi poinformowały nas, że prowadzenie usług w chmurze jest droższe niż korzystanie z lokalnych centr danych. Nie możemy ocenić tych oświadczeń, ale chętnie poznamy Twoją opinię na temat kosztów i rozważymy dalsze opcje rozszerzenia obsługi TEE. |
| TEEs | Obsługa TEE w niepublicznych środowiskach chmurowych | Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: chociaż nadal rozważamy obsługę opcji innych niż rozwiązania oparte na chmurze publicznym, obecnie nie planujemy obsługiwać TEE na urządzeniach lokalnych. Na tym etapie, biorąc pod uwagę wymagania dotyczące bezpieczeństwa w Piaskownicy prywatności i znaczące wyzwania związane z wdrożeniami lokalnymi, uważamy, że dalsze rozszerzanie i ulepszanie wdrożeń w chmurze (np. obsługa Google Cloud oprócz AWS) jest najbardziej korzystne dla ekosystemu. Zapraszamy jednak do podzielenia się opinią na temat tego, dlaczego takie wymagania są konieczne i możliwe do spełnienia, biorąc pod uwagę ograniczenia związane z ochroną prywatności i bezpieczeństwem. |
| Inni dostawcy chmury | Pomoc dotycząca innych dostawców chmury | Zawsze chętnie przyjmujemy sugestie dotyczące innych dostawców usług w chmurze, ale planujemy zapewnić obsługę co najmniej Google Cloud i AWS, gdy wdrożymy 3PCD. Więcej informacji znajdziesz w tym artykule. |
| Interfejs B&A Services API | Jakie są kierunki rozwoju interfejsu B&A Services API w Google? Czy w ramach aukcji na urządzeniu będzie ona miała wyższy czy niższy priorytet niż w przypadku przeglądarki Chrome w ramach Protected Audience? | Nasz komentarz jest podobny do tych z poprzednich kwartałów: nadal trzymamy się obecnego rozwiązania dotyczącego określania stawek na urządzeniu w ramach Protected Audience. Usługi dotyczące pytań i odpowiedzi zostały zaproponowane, aby umożliwić zbadanie możliwych rozwiązań w przypadku podzbioru przypadków użycia, w których moc obliczeniowa lub szybkość sieci urządzenia może być ograniczona. |
| Standaryzacja | Usługi B&A nie przeszły procesu standaryzacji. | Propozycja dotycząca usług typu „zapytanie i odpowiedź” jest w trakcie realizacji jednej z faz procesu standaryzacji i z chęcią przyjmiemy dodatkowe zaangażowanie w realizację tego celu. Zaczęło się od propozycji (opracowanej na podstawie wcześniejszych propozycji), która jest publicznie testowana w ramach obszernej, otwartej dyskusji w W3C. Zainteresowani deweloperzy mogą zacząć z nią eksperymentować i przesyłać opinie. Jest to typowy schemat tworzenia funkcji internetowych, jak opisaliśmy na przykład w tym wpisie na blogu. |
| Serwer KV | Udostępnianie pełnego adresu URL serwerowi KV kupującego na potrzeby kierowania na treści, kontekst lub witrynę. | Rozmawiamy o tej prośbie tutaj i zapraszamy do dzielenia się opiniami na temat tego ekosystemu. |
| Dokumentacja | Dokumentacja na temat „Komponenty zaufane/wymagane a opcjonalne” na GitHubie wprowadza w błąd niektórych specjalistów ds. technologii reklamowych, którzy mają własny zestaw obrazów do wdrażania i infrastrukturę. | Chcemy ulepszyć dokumentację dotyczącą „Zaufanych/wymaganych komponentów a opcjonalnych” i chcielibyśmy poznać opinię przedstawicieli branży na temat tego, czy należy nadać priorytet tym działaniom. |
| Ulepszenie interfejsu API | Kod stanu HTTP wywołania serwera KV powinien być też dostępny dla funkcji scoreAd() jako parametr. | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią na temat naszego ekosystemu. |
| Dokumentacja | Przekaż więcej informacji o tym, jak dokładnie będą obsługiwane zadania JS i WASM podczas wykonywania UDF. | Sprawdzamy, jak udostępnić te informacje, i zapraszamy do podzielenia się opinią tutaj. |
| Dokumentacja | Prośba o zaktualizowanie nazwy repozytorium | Zmieniliśmy nazwę repozytorium na „protected-auction-key-value-service”. Jest to zgodne z nazwą kolekcji usług, do której należy to repozytorium. Do tej kolekcji należą też inne repozytoria, takie jak dyskusja na temat usług chronionych list odbiorców i repozytorium dokumentacji usług chronionych aukcji. |
| Dokumentacja | Usuń odwołanie do interfejsu API debugera Cloud w pliku bidding_auction_services_gcp_guide.md. | Zaktualizowaliśmy dokumentację i usunęliśmy odniesienie. |
| Używanie API | Opóźnienie spowodowane wyszukiwaniem par klucz–wartość trwa ponad 50 ms. Zajmuje to prawie 100 ms. Czy masz jakieś wskazówki dotyczące tego, co sprawdza się w przypadku innych sprzedawców? Czy masz jakieś sugestie dotyczące pomiaru limitów czasu i czasów? |
Wywołanie serwera KV odbywa się w kontekście skryptów, czyli w specjalnym chronionym środowisku w przeglądarce Chrome. Ma to na celu ochronę informacji w tych skryptach przed dostępem spoza interfejsu API. Szczegółowe wyjaśnienie znajdziesz tutaj. |
| Używanie API | Czy serwer KV ma określony czas na odpowiedź? | Sprzedawcy mogą określić pole „perBuyerCumulativeTimeouts” w konfiguracji aukcji. Ten limit czasu obejmuje czas potrzebny na pobieranie zaufanych sygnałów ustalania stawek. |
| Czas oczekiwania | Jak zespół Piaskownicy prywatności radzi sobie z opóźnieniami? | Strategie, które testujemy, aby utrzymać opóźnienie w akceptowalnych granicach, znajdziesz tutaj. |
Pomiar skuteczności reklam cyfrowych
Attribution Reporting (i inne interfejsy API)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Ręczne optymalizowanie kampanii | ARA nie obsługuje ręcznej optymalizacji kampanii. | Omówiliśmy ten scenariusz z zespołem ds. technologii reklamowych i przedstawiliśmy sposoby korzystania z ARA do obsługi ręcznej optymalizacji kampanii. Interfejs ARA został zaprojektowany tak, aby umożliwiać dostosowywanie technologii reklamowych i elastyczność w rozwiązywaniu różnych problemów związanych z technologiami reklamowymi. Wśród podanych sugestii znalazły się m.in. stosowanie różnych elastycznych konfiguracji na poziomie zdarzenia oraz korzystanie z raportów na poziomie zdarzenia z raportami podsumowania w celu zmniejszenia wpływu szumu i zaspokojenia potrzeb związanych z ręczną i automatyczną optymalizacją. Zapraszamy do dzielenia się opiniami na temat możliwości dostosowywania i elastyczności konfiguracji ARA. |
| Typ konwersji | Google zezwala tylko na 8 typów konwersji, co jest ograniczeniem. | Wdrożyliśmy większość raportowania na poziomie zdarzenia o dużej elastyczności, które daje firmom zajmującym się technologiami reklamowymi dodatkową elastyczność w zakresie liczby okien raportowania, liczby raportów atrybucji i danych wywołania, których mogą używać. Specjaliści od technologii reklamowych mogą wybrać konfigurację, która umożliwia pomiar do 32 różnych typów konwersji. |
| Limit zdarzeń raportu zbiorczego | Minimalna liczba 20 wydarzeń konwersji na raport możliwy do zsumowania nie jest odpowiednia dla mniejszych reklamodawców z ograniczonym budżetem. | Nie ma minimalnej liczby zdarzeń konwersji wymaganej na potrzeby raportów podlegających agregacji. Ponadto można podjąć kilka decyzji projektowych, aby zoptymalizować raporty podlegające agregacji na potrzeby mniejszych reklamodawców, np. zmienić strukturę kluczy lub śledzone wymiary, przetestować różne poziomy epsilona, przetestować dłuższe częstotliwości zbiorczego przetwarzania danych i przetestować różne przydziały budżetu pod kątem udziału w wynikach poszczególnych celów pomiarowych. Mniejsze firmy zajmujące się technologiami reklamowymi mogą też eksperymentować z kombinowaniem raportów na poziomie zdarzenia i raportów zbiorczych, aby ograniczyć wpływ szumu informacyjnego. |
| Dane w czasie rzeczywistym | Odbieranie dostawcom platformy DSP danych w czasie rzeczywistym (np. o kliknięciach, sesjach i konwersjach), których używają oni do dostosowywania strategii ustalania stawek i osiągania lepszej skuteczności kampanii, jest niezgodne z zobowiązaniem do zachowania dotychczasowych funkcji. | Nawet w przypadku ARA kliknięcia i sesje są rejestrowane w czasie rzeczywistym, a konwersje są zawsze rejestrowane z opóźnieniem, nawet w przypadku 3PC. |
| Brakujące pola | W ramach wdrażania pełnej implementacji zdarzeń z elastycznymi wymaganiami występują następujące braki: i) pole Currency (Waluta) oraz ii) pole orderID / TransactionID (Identyfikator zamówienia / Identyfikator transakcji). | Obecnie nie planujemy obsługi pola Waluta ani pól Identyfikator zamówienia / Identyfikator transakcji w ramach pełnej elastyczności na poziomie zdarzenia, ponieważ istnieją już sposoby na realizację tego w ramach obecnego raportowania na poziomie zdarzenia. Chętnie przyjmujemy opinie na temat tych pól i rozpatrzymy ich dodanie, jeśli będą one potrzebne do realizacji dodatkowych przypadków użycia. Możliwe sposoby korzystania z obecnego interfejsu ARA do pomiaru waluty i typu identyfikatora zamówienia: 1. Na podstawie opinii waluta jest określana na podstawie lokalizacji użytkownika, którą można dodać jako część identyfikatora source_event_id, aby określić, jaka waluta została użyta. 2. Z tego, co słyszymy od użytkowników, wynika, że pole identyfikatora zamówienia jest potrzebne, aby uniknąć podwójnego zliczania konwersji i wartości, które może się zdarzyć przez pomyłkę. Można tego uniknąć, używając kluczy deduplikacji. |
| Budżet na potrzeby prywatności | ARA Privacy Budget ogranicza możliwość pomiarów w różnych wymiarach | Interfejs ARA został zaprojektowany tak, aby umożliwić specjalistom ds. technologii reklamowych dostosowanie własnych konfiguracji ARA do różnych scenariuszy atrybucji. W przypadku obecnego projektu ARA dostawcy technologii reklamowych będą musieli rozważyć kompromis między tym, które wymiary są dla nich najważniejsze do pomiaru, a wpływem szumu na ich dane. Dodawanie do danych szumu w zależności od szczegółowości pomiarów wymiarów jest niezbędne dla zachowania prywatności. Chętnie poznamy opinie dotyczące możliwości pomiaru w różnych wymiarach, ale najpierw musimy poznać konkretne przypadki użycia, które tego wymagają. |
| Aktualizacja specyfikacji | Chociaż Google poinformowało, że z okresów raportowania zdarzeń o stałym czasie przeszedł na okresy elastyczne, nie zostało to uwzględnione w specyfikacji technicznej Google, która nadal określa minimalny okres wynoszący 1 godzinę. | Elastyczne raportowanie na poziomie zdarzenia umożliwia obecnie dostawcom technologii reklamowych zmianę liczby raportów atrybucji na zdarzenie źródłowe, bitów danych o wyzwalaczu oraz liczby i długości okien raportowania. ARA nadal ma minimalny okres raportowania wynoszący 1 godzinę w przypadku raportów na poziomie zdarzenia, co jest niezbędne do zachowania prywatności i ograniczenia pewnych rodzajów ataków polegających na odtwarzaniu historii. Ponieważ raporty zbiorcze zawierają informacje zbiorcze, dostawcy technologii reklamowych mogą, w razie potrzeby, wyrazić zgodę na otrzymywanie takich raportów bez opóźnienia. |
| Projekt interfejsu API | Obawa, że ograniczenie ilości informacji w raportach o konwersjach i dodanie szumów może mieć większy wpływ na ekosystem niż na Google. | Google zobowiązało się do opracowania i wdrożenia propozycji dotyczących Piaskownicy prywatności w sposób, który nie zakłóca konkurencji przez preferowanie własnych usług, a także do uwzględnienia wpływu na konkurencję w reklamie cyfrowej oraz na wydawców i reklamodawców o różnej wielkości. |
| Korekta atrybucji | ARA nie pozwala dostawcy technologii na kontrolowanie i weryfikowanie prawidłowego przypisywania. | W ramach ARA dostępnych jest wiele rozwiązań umożliwiających weryfikację: 1. Specjaliści ds. technologii reklamowych mogą sprawdzić, czy działanie ARA jest zgodne z ich oczekiwaniami: – kod ARA po stronie klienta jest udostępniany na licencji open source. – kod ARA po stronie serwera jest też udostępniany na licencji open source, a koordynatorzy dbają o to, aby tylko dozwolone wersje usługi agregacji mogły odszyfrowywać i przetwarzać raporty podlegające agregacji. 2. Chrome udostępnia firmom zajmującym się technologiami reklamowymi bibliotekę symulacji, która umożliwia weryfikację działania funkcji przypisywania. Dzięki niej firmy te mogą testować, jak ARA wykonuje przypisanie w symulowanym środowisku. 3. ARA obsługuje kilka sygnałów debugowania, które pomagają sprawdzić, czy oczekiwane przetwarzanie mogło się nie odbyć, i jeśli tak, to dlaczego. |
| (również w poprzednich kwartałach) Szum |
Opinia, że poziom szumu jest zbyt wysoki i wpływa na przydatność raportu. | Po przeprowadzeniu rozmów z technologiami reklamowymi dotyczących tej samej opinii udało nam się znaleźć sposoby dostosowywania ARA do różnych zastosowań, nawet w przypadku szumu. Mamy dokumentację dla deweloperów, która zawiera większość decyzji projektowych i dostosowań, które omawialiśmy z technologiami reklamowymi. Interfejs ARA został zaprojektowany tak, aby umożliwić specjalistom ds. technologii reklamowych dostosowywanie własnych konfiguracji ARA w celu uwzględnienia różnych scenariuszy atrybucji. Specjaliści od technologii reklamowych muszą jednak rozważyć, które wymiary są dla nich najważniejsze do pomiaru, i jaki wpływ na ich dane ma szum. Chętnie poznamy opinie o szumie w ekosystemie i możemy podać dodatkowe wskazówki dotyczące sposobów na ograniczenie jego wpływu. |
| Atrybucja w wielu domenach | Jak śledzić atrybucję w wielu domenach? | W tym przypadku specjaliści ds. technologii reklamowych mogą przekierowywać użytkowników na różne adresy URL raportów. Chętnie poznamy opinie dotyczące tego aspektu projektu ARA. |
| Ulepszenie interfejsu API | Regularnie zmieniaj współczynnik skalowania używany podczas rejestrowania atrybucji w raportach ARA Summary. | Na podstawie dyskusji na GitHubie wydaje się, że obsługa wielu czynników skalowania w usłudze Aggregation Service spowoduje prawdopodobnie zwiększenie ilości szumu w raportach zbiorczych w porównaniu z obecną funkcjonalnością. Chętnie przyjmiemy dodatkowe opinie na temat potrzeby stosowania czynników skalowania w raportach możliwych do zsumowania, ale chcemy zwrócić uwagę na potencjalny kompromis polegający na zwiększeniu szumu. Badamy też, czy inne przyszłe funkcje ARA mogą być pomocne w rozwiązaniu tego problemu. |
| Używanie API | Możliwość ujednoliwienia sposobu udostępniania zdarzeń atrybucji wszystkim uczestnikom, co jest korzystne dla SSP, DSP itp. | Planujemy skoordynować działania z firmami zajmującymi się technologiami reklamowymi, aby lepiej poznać ich opinie i ograniczenia, na które się natrafiają. |
| Testowanie natężenia ruchu | Czy ruch testowy w trybie B jest stabilny we wszystkich wersjach Chrome? | Uwzględnienie w grupie eksperymentalnej nie zależy od ustawień Chrome. |
| Dokumentacja | Obsługa ARA dla Pixeli. | Opublikowaliśmy informacje o tym, jak obsługiwać ten przypadek użycia. Zachęcamy do dzielenia się opiniami na temat naszego ekosystemu. |
| Używanie API | ARA może nie zostać przypisana do prawidłowego źródła w przypadku sprzedawców zewnętrznych na platformach e-commerce, jeśli konwersja nie została zrealizowana przez ostatnie kliknięcie. | Firmy mogą używać filtrów, aby zapobiec nieprawidłowej atrybucji (w tym przypadku nie zostanie wygenerowany raport o konwersjach). Pracujemy też nad propozycją filtrowania przed przypisaniem, która pomoże w tym zastosowaniu. |
| Obsługa przeglądarek | Czy interfejs ARA będzie obsługiwany w różnych przeglądarkach? | Zachęcamy inne przeglądarki do korzystania z interfejsów API Piaskownicy prywatności i nadal poświęcamy czas na omawianie naszej metody w ramach W3C. Wyraźnie stwierdziliśmy, że interoperacyjność jest celem wdrażania ARA. Projekt ARA ma być niezależny od przeglądarki, a wartości określone przez dostawców mają być elastyczne i odpowiadać różnym podejściom do prywatności. Inne przeglądarki same decydują, czy chcą oferować alternatywne rozwiązania dla identyfikatorów między witrynami, które mogą wspierać cyfrowy ekosystem treści i usług. Cieszymy się, że przeglądarka Microsoft Edge zapowiedziała, że będzie obsługiwać ARA. |
| Używanie API | Jaki jest oczekiwany typ źródła w przypadku rejestracji źródła ARA w przypadku metod registerAdBeacon/reportEvent (i automatycznych beaconów navigation_start/commit)? | To zależy od tego, czy beacony są automatyczne czy ręczne: - zarezerwowane.* (czyli automatycznych) muszą być typu „źródło nawigacji”. – zdarzenia wywoływane ręcznie muszą być typu źródło zdarzenia. |
| Używanie API | Czy maksymalny limit 20 raportów podlegających agregacji na źródło dotyczy każdego zdarzenia źródła? Czy limit jest globalny czy dzienny? Czy planujecie zwiększyć ten limit? | Limit 20 raportów podlegających agregacji na źródło to limit globalny, który pozwala utworzyć 20 raportów podlegających agregacji dla każdego źródła. Limit jest ustawiany przez przeglądarkę i nie można go zmienić. Ten limit ma na celu unikanie nadużywania ochrony raportów atrybucji rzeczywistych za pomocą raportów pustych. Więcej informacji na ten temat znajdziesz tutaj. |
| Używanie API | Obsługa marketingu e-mailowego za pomocą ARA. | Obecnie w ARA nie ma bezpośredniego wsparcia w przypadku tego przypadku użycia (jeśli nie masz kontroli nad witryną hostującą pocztę e-mail). Omawiamy to tutaj i zapraszamy do dzielenia się opiniami. |
| Epsilon | Kiedy zostanie określona wartość epsilon dla interfejsu Aggregate API? | Dostawcy technologii reklamowych mogą skonfigurować bieżącą wartość epsilon do z góry określonego progu określonego przez Piaskownicę prywatności (obecnie wynosi on 64). Zalecamy przetestowanie różnych wartości epsilona i wyznaczenie punktów zwrotnych w przypadku Twoich zastosowań oraz przesłanie opinii. Przed wprowadzeniem jakichkolwiek zmian w zakresie wartości epsilon poinformujemy o tym z wyprzedzeniem specjalistów ds. technologii reklamowych. |
| Ulepszenie interfejsu API | Obsługa przypadku użycia, w którym reklamodawca może wstawiać w polu trigger_data identyfikator do dopasowywania do zewnętrznych danych CRM, aby umożliwić reklamodawcom weryfikację jakości konwersji. | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią tutaj. |
| Używanie API | Jak obsługiwać adresy URL przekierowania jako docelowe adresy URL. | Specjaliści ds. technologii reklamowych mogą wykonać jedną z tych czynności: 1. W polu „Destination” (miejsce docelowe) wpisz końcowy adres URL miejsca docelowego. 2. Pole „Destination” (Docelowy) może zawierać maksymalnie 3 adresy URL, co pozwala na umieszczenie w nim kilku adresów URL. W obu przypadkach musisz podać końcowy docelowy adres URL. Więcej informacji znajdziesz tutaj . |
Usługa do agregacji
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Mechanizm znajdowania klucza | Prośba o mechanizm znajdowania kluczy | Mamy propozycję dotyczącą kluczy i zapraszamy do wyrażenia opinii na jej temat. |
| Używanie API | Plan dostrzegalności w usłudze Aggregation Service | Sprawdzamy opcje zwiększające przejrzystość i zapraszamy do dzielenia się opiniami na temat ekosystemu tutaj. |
| Ulepszenie interfejsu API | Prośba o możliwość ponownego wysłania zapytania o raporty. | Usługa agregująca pracuje nad propozycją dotyczącą wymagań, w ramach której dostawcy technologii reklamowych mogą dzielić epsilon na poszczególne raporty. Może to zwiększyć poziom szumu w przypadku poszczególnych zapytań, ale pozwoli też technologiom reklamowym ponownie wysyłać zapytania i utrzymać prywatność. |
| Ulepszenie interfejsu API | Chcę mieć możliwość powiązania wielu źródeł z tym samym identyfikatorem AWS. | Usługa agregacji umożliwia teraz tworzenie wielu witryn na tym samym koncie chmury (Google Cloud lub AWS). Umożliwi to specjalistom ds. technologii reklamowych korzystanie z tego samego obszaru odizolowanego usługi Aggregation Service do przetwarzania raportów z wielu witryn i z wielu źródeł w tych samych witrynach. |
| Używanie API | Gdy zbiorcze zbiory danych nie działają, nie wiadomo, czy budżet został wykorzystany i czy można ponownie przetworzyć zbiór. Gdy usługa agregująca napotka błąd budżetu w przypadku duplikatów raportów, pozostałe raporty zostaną utracone. Jak zminimalizować te straty? | W typowym przypadku, jeśli całe zadanie zakończy się niepowodzeniem, budżet nie zostanie wykorzystany. W rzadkich przypadkach, gdy budżet zostaje wykorzystany, specjaliści ds. reklam mogą poprosić o przywrócenie budżetu. Jeśli specjaliści ds. reklam często napotykają na błędy związane z wyczerpaniem budżetu, powinni sprawdzić swoją strategię grupowania. Instrukcje dotyczące prawidłowego tworzenia zbiorczych raportów oraz unikania ich duplikatów i błędów znajdziesz tutaj. Zachęcamy do dzielenia się opiniami na temat odzyskiwania budżetu tutaj. |
| Używanie API | Korzystanie z interfejsu Private Aggregation API z opisanym tutaj wyzwalaczem daje możliwość wygenerowania raportu z możliwością agregacji dla każdej aukcji. Jakie są możliwości skalowania usługi agregacji? | Usługa agregacji nie nakłada górnego limitu liczby kluczy ani raportów w zbiorze, ale obecnie nie obsługuje skali 10^14 raportów i 10^12 kluczy z powodu wymaganej pamięci. Nasze wskazania dotyczące rozmiaru podają przetestowane i zalecane zakresy, które zapewniają optymalną wydajność w zależności od spodziewanego obciążenia i obsługiwanych typów instancji maszyn wirtualnych w chmurze. |
| Przetwarzanie danych | Jeśli zaszyfrowane dane zawierają dane osobowe, jakie jest uregulowanie prawne dotyczące udostępniania zaszyfrowanych danych usłudze agregacji? Czy możesz potwierdzić, że koordynator nie będzie miał dostępu do zaszyfrowanych danych? |
Usługa agregacji nie udostępnia zaszyfrowanych danych ani danych użytkownika koordynatorowi. Usługa do agregacji korzysta z koordynatora do zarządzania kluczami i rozliczania. Niektóre szczegóły dotyczące koordynatora znajdziesz tutaj. Na potrzeby rozliczeń usługa agregacji udostępnia PBS tylko wspólny identyfikator i źródło raportowania na potrzeby wykorzystania budżetu. Gdy uruchomimy usługę dotyczącą wielu witryn, zastąpimy parametr „origin” parametrem „site”. Pamiętaj, że usługa agregacji działa w ramach TEE, który jest jedynym miejscem, w którym można odszyfrować raporty z klientów. Kod działający w TEE jest udostępniony na licencji open source i sprawdzany przez osoby trzecie zgodnie z opisem tutaj. |
Interfejs Private Aggregation API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Używanie API | Możliwość wysyłania raportów przez sprzedawców komponentów do wielu serwerów agregacji w ramach TEE. | Bieżący stan interfejsu Private Aggregation API nie obsługuje tej funkcji. Więcej informacji na ten temat znajdziesz tutaj. |
| Dokumentacja | Jaka jest wartość epsilon używana w testach Google? | W przypadku interfejsu Private Aggregation API wartość ε określona w zapytaniu do usługi agregacji odpowiada budżetowi udziału L1 równemu 2^16, który jest egzekwowany w ciągu 10 minut. Jest też „zabezpieczenie” w postaci budżetu udziału L1 o wartości 2^20, który jest stosowany w ciągu 24 godzin. Oznacza to, że parametr prywatności wynosi ε w ciągu 10 minut i 16ε w ciągu 24 godzin (a nie 144ε). Usługa agregacji obsługuje obecnie zakres wartości ε na potrzeby testów (do 64), aby umożliwić eksperymentowanie z różnymi strategiami agregacji i przekazywanie informacji o użyteczności systemu z różnymi parametrami prywatności w przypadku prywatnej agregacji i innych interfejsów API. Z czasem planujemy ponownie przyjrzeć się maksymalnej dozwolonej wartości epsilon, ponieważ będziemy otrzymywać opinie testerów i dodawać funkcje, które pozwolą na bardziej efektywne wykorzystanie budżetu na prywatność. |
Ograniczanie śledzenia ukrytego
Redukcja klienta użytkownika/Wskazówki dotyczące klienta użytkownika
W tym kwartale nie otrzymaliśmy żadnych opinii.
Ochrona IP (dawniej Gnatcatcher)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Identyfikator rozwiązania | Piaskownica prywatności musi bardziej przekonywać prasę, że identyfikatory rozdzielczości często tworzone na podstawie adresów IP nie są trwałym rozwiązaniem dla reklamodawców. | Piaskownica prywatności jasno określa, że naszym celem jest ograniczenie śledzenia w witrynach. Nasze publiczne inicjatywy, które wykraczają poza pliki cookie, są publikowane zarówno na stronie privacysandbox.com, jak i w GitHub. Staramy się ograniczać śledzenie w witrynach, w tym śledzenie na podstawie adresów IP. Ostateczna decyzja o tym, czy umożliwić aktywne śledzenie w wielu witrynach, należy jednak do poszczególnych witryn. W erze wzmożonej kontroli zgodności z wymaganiami regulacyjnymi poszczególne firmy powinny znać praktyki stosowane przez dostawców usług. |
| Chromecast | Czy ochrona adresów IP wpłynie na Chromecasta lub inne urządzenia z Chrome? | Obecnie nie planujemy stosowania ochrony IP na Chromecastach. |
| Lista ochrony adresów IP | Czy lista firm zewnętrznych, które mogą używać adresów IP do śledzenia w witrynach, zostanie opublikowana? | Lista zostanie opublikowana po jej sfinalizowaniu, zgodnie z informacjami podanymi tutaj. |
Łagodzenie śledzenia przekierowań
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wyjątek dotyczący logowania jednokrotnego (SSO) | Jak narzędzie do zapobiegania przypadkom odrzucenia (BTM) będzie weryfikować przypadki użycia logowania jednokrotnego w celu uzyskania wyjątku? | BTM zostanie wyłączony przez heurystyki Chrome. Szczegółowe informacje znajdziesz w tym objaśnieniu. |
| Przywrócenie wycofanej funkcji | Czy w przypadku witryn objętych testem wycofania 3 PC włączona jest usługa BTM? | Nie. BTM uwzględnia wyjątki dotyczące plików cookie utworzone w ramach okresu próbnego wycofania, jak opisano tutaj. |
Budżet na potrzeby prywatności
Jak wyjaśniono na GitHub (po angielsku) i na stronie dla deweloperów,budżet prywatności nie jest już aktywnie brany pod uwagę w ramach propozycji dotyczących Piaskownicy prywatności.
Wzmocnienie granic prywatności między witrynami
Zestawy powiązanych witryn (dawniej zestawy źródeł własnych)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Propozycja nowej funkcji | Dostęp do CHIPS i partycjonowania pamięci jest automatycznie zezwalany w całym RWS bez konieczności korzystania z interfejsu Storage Access API ani interakcji z użytkownikiem. | Zastanawiamy się nad korzyściami i możliwościami wdrożenia funkcji, która mogłaby pełnić tę funkcję. Jednym z problemów jest potencjalna luka w interoperacyjności między przeglądarkami, którą RWS rozwiązuje, korzystając z interfejsu Storage Access API. W innych przeglądarkach nie ma obecnie odpowiednika tej funkcji. Zachęcamy deweloperów do przesyłania przypadków użycia dotyczących tego problemu, aby ułatwić dyskusję tutaj. |
| Usuwanie niezgodnych zestawów | Jak usunąć z repozytorium zestawy, które stały się niezgodne? | Pracujemy nad określeniem procesu, a aktualne informacje będziemy udostępniać, gdy tylko będą dostępne. |
| Proces egzekwowania zasad | Niejasna jest rola Google w procesie egzekwowania zasad RWS. | Ponieważ RWS to trwający projekt, a my wciąż otrzymujemy nowe zgłoszenia, niektóre aspekty procesu i nasze kryteria są nadal doskonalone. Zgadzamy się, że ważne jest, aby nasze wytyczne dotyczące przesyłania zawierały wszystkie wymagania dotyczące przesyłania. W przyszłości dodamy do nich więcej szczegółów, aby uniknąć niejasności i nieporozumień. Chcemy, aby proces przesyłania był jak najbardziej techniczny, abyśmy mogli stopniowo ograniczać udział człowieka i całkowicie polegać na automatycznych kontrolach. Problemy z dostępnością, takie jak ten, wymagają większego zaangażowania człowieka, ponieważ obejmują zachowania, których nie przewidzieliśmy. Umożliwiają nam jednak identyfikację kolejnych obszarów do zautomatyzowania i sposobów na poprawienie naszych wytycznych, aby uniknąć takich problemów w przyszłości. |
| Udostępnianie danych | Prośba o funkcję, która pozwoli właścicielom domen określić, czy chcą, aby dane RWS były udostępniane przez osoby trzecie (z pozwoleniem użytkownika). | Żądana funkcja jest już dostępna za pomocą interfejsów API, takich jak FedCM i Storage Access API, które umożliwiają dostęp do uwierzytelnionej tożsamości po zaakceptowaniu prośby o uprawnienia przez użytkownika. Zachęcamy do przesyłania opinii o konkretnych przypadkach użycia, które według użytkowników są niemożliwe. |
| Inne metody przechowywania | Czy informacje zapisane w pamięci lokalnej lub pamięci sesji będą też interpretowane jako 3PC? | Pamięć lokalna, pamięć sesji i inne formy przechowywania danych bez plików cookie używane w kontekstach innych firm zostały podzielone na partycje w Chrome od wersji 115. Więcej informacji znajdziesz w tym poście na blogu. |
| Limit zestawów powiązanych | Co się dzieje w przypadku organizacji, które przesyłają więcej niż 5 domen, mimo że „maksymalna liczba powiązanych witryn to 5”? | Te zestawy zostaną zaakceptowane w procesie GitHub, ale przeglądarka (Chrome) zastosuje reguły automatycznego przyznawania dostępu interfejsu Storage Access API tylko do pierwszych 5 domen, a pozostałe zignoruje, jak opisano tutaj. |
| find_robots_txt | Sprawdzanie find_robots_txt nie działa w przypadku przekierowań. | Rozwiązanie tego problemu zostało przesłane tutaj. |
| Gest użytkownika | Usuń wymóg gestu użytkownika w funkcji accessStorage(). | To wymaganie zostało wprowadzone na podstawie podobnej funkcji, która jest dostępna we wszystkich głównych przeglądarkach w przypadku interfejsu requestStorageAccess API. Aby pomóc nam nadać priorytet temu zgłoszeniu i umożliwić prowadzenie dyskusji w różnych przeglądarkach, prześlij dodatkowe opinie i przypadki użycia na tym zgłoszeniu na GitHub. |
| Gest użytkownika | Czy po ponownym uruchomieniu Chrome lub systemu operacyjnego użytkownik musi wykonać gest, aby przyznać dostęp do pamięci zewnętrznej? | Tak, ale chętnie poznamy opinie na temat tego, czy należy zmienić to zachowanie. Możesz je przekazać tutaj. |
Fenced Frames API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| adComponent | Brak dokumentacji i elastyczności w przypadku korzystania z AdComponents w ramach wydzielonych ramek. | Chcemy udostępnić więcej dokumentacji dotyczącej tego przypadku użycia. Warto też dodać, że komponenty reklam są obsługiwane w ramkach odizolowanych za pomocą funkcji getNestedConfigs(), która jest opisana w specyfikacji tutaj. |
| (również w poprzednich kwartałach) Render adComponent |
Prośba o przykładowe kody renderowania komponentów reklamy w ramce odizolowanej | Pracujemy nad udostępnieniem przykładowych kodów tutaj. |
| Weryfikacja reklam przez firmy zewnętrzne | Więcej informacji o roli zewnętrznych usług pomiaru reklam w kontekście odizolowanych ramek. | Obecnie raportowanie reklam w ramkach wydzielonych pozwala dostawcom usług DSP wysyłać dane o wyświetleniach i zdarzeniach aukcji na poziomie reklamy do zewnętrznych weryfikatorów reklam na potrzeby rozliczeń i sprawdzania bezpieczeństwa marki po renderowaniu. |
| Reklamy rozwijane | Prośba o obsługę reklam rozwijanych | Jeśli reklama musi przełączać się między 2 rozmiarami o tym samym formacie obrazu i nie ma między nimi różnic funkcjonalnych (tylko rozmiar), osoba umieszczająca reklamę może zmienić rozmiar ramki ograniczonej na drugi rozmiar reklamy, a przeglądarka odpowiednio ją przeskaluje. |
| (również w poprzednich kwartałach) Obsługa zasobów reklamowych wideo i natywnych |
Czy Fenced Frames obsługuje zasoby reklamowe wideo i natywne? | Nasza odpowiedź jest podobna do tej z poprzednich kwartałów: 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 natywnych, które byłoby zgodne z ramkami ograniczonymi. Jest to jeden z powodów, dla których zdecydowaliśmy się przesunąć termin wprowadzenia ramek ograniczonych na rok 2026. Oznacza to, że jeśli partner zdecyduje się teraz wdrożyć ramki ograniczone, nie będzie obsługiwał reklam wideo ani natywnych. |
| Rada doradcza | Prośba o utworzenie zespołu doradczego dostawców reklam natywnych, który będzie dbać o to, aby implementacje odizolowanych ramek były zgodne ze standardami branżowymi. | Ramki ograniczone nie są wymagane do korzystania z interfejsu PA API przed 2026 rokiem. Dodatkowy czas pozwoli nam kontynuować współpracę z branżą w zakresie projektowania i wdrażania obsługi większej liczby krytycznych przypadków użycia. Wcześniej informowaliśmy, że zaktualizujemy odizolowane ramki, aby zachować obsługę reklam wideo i natywnych za pomocą interfejsu PA API. Zgodnie z naszym zobowiązaniem będziemy informować CMA o wszelkich takich zmianach i uzyskiwać od niego opinie. Będziemy też nadal zbierać opinie z całego ekosystemu przed wprowadzeniem wymagań dotyczących odizolowanych ramek. Nasz model zaangażowania w ekosystem w W3C i organizacjach zajmujących się standardami reklamowymi, takich jak IAB Tech Lab, pozwala ekspertom z różnych dziedzin prowadzić prace projektowe jeszcze przed ich rozpoczęciem. |
| (raportowane również w poprzednich kwartałach) Różnica rozmiaru na poszczególnych platformach |
zgłasza, że rozmiar treści wyświetlanych w klatce Fenced Frame wygląda inaczej na komputerach i smartfonach. | To znany problem w Chromium, który obecnie badamy. Zapraszamy do podzielenia się dodatkowymi opiniami tutaj. |
| Ulepszenie interfejsu API | Czy wymóg dotyczący odizolowanych ramek został przesunięty na rok 2025, aby reklamy natywne były obsługiwane w ramach Piaskownicy prywatności? | Jak informowaliśmy w publicznym ogłoszeniu dotyczącym egzekwowania zasad dotyczących odizolowanych ramek, nie wcześniej niż w 2026 r. dowiedzieliśmy się o znacznych „staraniach o dostosowanie” do odizolowanych ramek. Zdecydowanie tak, ale nie był to jedyny czynnik. Celem było zapewnienie więcej czasu na przygotowanie ekosystemu do obsługi kluczowych zastosowań, w tym reklam natywnych. |
Interfejs Shared Storage API
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Wyniki | Czasy powrotu z poziomu Shared Storage poza workletem wydają się być zależne od aktywności w worklecie. | Omawiamy ten wynik testu tutaj. |
| Szerokie rozpowszechnienie | Pamięć współdzielona powinna być standardem branżowym dostępnym w różnych przeglądarkach. | Dziękujemy za opinię. Chrome nadal aktywnie uczestniczy w forach W3C, w tym w WICG, aby promować propozycję, zbierać opinie i zachęcać do wdrażania. |
| Worklety ustalania stawek | Czy można odczytywać dane z Shared Storage w ramach funkcji generateBid (która jest już wykonywana w worklecie), aby stosować logikę podejmowania decyzji o reklamach lub logikę biznesową (np. ograniczenie częstotliwości wyświetlania) na podstawie informacji z wielu witryn i wybierać podzbiór reklam? | Nie, w ramach workletów ustalania stawek nie można odczytywać z wspólnego magazynu. |
CHIPS
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Pojemność partycji | Wyjaśnienie zachowania w przypadku przekroczenia pojemności partycji. | Gdy osiągnięta zostanie pojemność, najstarsze pliki cookie są usuwane z tych, do których nie było ostatnio uzyskiwane dostępu, aby zwolnić pamięć, dopóki limit nie zostanie przekroczony. Deweloperzy widzą zaktualizowany nagłówek Cookie w kolejnych żądaniach. |
| Dostęp do elementu iframe innych firm | Umieszczone w elemencie iframe treści pochodzące od zewnętrznego dostawcy, które otwierają nową kartę lub nowe okno w tej samej witrynie, powinny mieć dostęp do tych samych plików cookie z podzielonymi domenami co element iframe. | Omawiamy ten przypadek użycia i zapraszamy do dzielenia się opiniami na temat naszego ekosystemu tutaj. |
| Duplikowanie plików cookie | Jeśli plik cookie z partycjami i bez partycji ma tę samą nazwę, jaką wartość klucza przeglądarka zdecyduje się wysłać? | Jeśli masz 2 pliki cookie o tej samej nazwie (jeden z partycją, a drugi bez partycji), otrzymasz oba pliki cookie. Niestety nie ma możliwości odróżnienia jednego od drugiego. Specyfikacja RFC dotycząca tego tematu jest dostępna tutaj. Wyjaśnia ona, że nie należy polegać na kolejności, w jakiej są wysyłane pliki cookie. |
| Propozycja nowej funkcji | Włącz pliki cookie z podziałem na źródła. | Rozpatrujemy tę prośbę i zapraszamy do podzielenia się opinią na temat ekosystemu tutaj. |
FedCM
W tym kwartale nie otrzymaliśmy żadnych opinii.
Walka ze spamem i oszustwami
Interfejs Private State Token API (i inne interfejsy API)
| Temat opinii | Podsumowanie | Odpowiedź Chrome |
|---|---|---|
| Komponent WebView | Czy tokeny prywatności są przechowywane na wielu widokach Webview na tym samym urządzeniu mobilnym (profilu)? | Każda aplikacja korzystająca z webview będzie mieć inny lokalny magazyn danych, co oznacza, że wydawcy PST nie mogą wydawać tokenów w webview jednej aplikacji, a potem zezwalać na ich wykorzystanie w innej aplikacji. Dotyczy to również innych danych przechowywanych lokalnie w widoku strony, takich jak pliki cookie. Pliki PST nie są jeszcze w pełni dostępne w WebView. Aktualizację w tej sprawie opublikujemy do końca II kwartału. |
| Nowy typ tokena | Propozycja nowego typu tokena. | Dziękujemy za tę propozycję i dalsze badania dotyczące zastosowań i adaptacji PST. Chętnie dowiemy się więcej o tej propozycji podczas nadchodzących spotkań grupy ds. zapobiegania oszustwom w II kwartale 2024 r. |
| Identyfikacja użytkownika | Jak zapobiec identyfikacji użytkowników na podstawie konkretnych plików PST? | Obecnie ograniczamy to zjawisko, ograniczając próby realizacji na stronie do 2 wydawców niezależnie od tego, czy są dostępne tokeny tego wydawcy. Musisz uwzględnić wydawcę w limitach, nawet jeśli nie ma dostępnych tokenów, ponieważ w przeciwnym razie witryna może przeszukiwać wszystkich wydawców, aż znajdzie dopasowanie. |
| Rejestracja | Jak długo będzie wymagana rejestracja w przypadku PST? | Rejestracja będzie wymagana przez najbliższe kilka lat, co zostało szczegółowo wyjaśnione tutaj. |
| Obsługa innych przeglądarek Chromium | Czy rejestracja wydawcy PST w przypadku innych przeglądarek opartych na Chromium będzie obsługiwana przez repozytorium rejestracji wydawcy Chrome? | Chrome pobiera kluczowe zobowiązania i rozpowszechnia je wśród klientów Chrome za pomocą mechanizmu o nazwie Aktualizator komponentów. W miarę jak inne przeglądarki będą dodawać bardziej kompleksowe wsparcie dla interfejsu API, będą musiały wprowadzić proces uzyskiwania kluczowych zobowiązań od klienta, za pomocą metody aktualizacji komponentów lub innej metody. Więcej informacji znajdziesz tutaj. |