Pliki cookie innych firm mogą być blokowane przez ograniczenia przeglądarki, ustawienia użytkownika, flagi dewelopera lub zasady firmy.
Musisz zadbać o to, aby Twoja witryna lub usługa zapewniała użytkownikom komfort korzystania, niezależnie od tego, czy pliki cookie innych firm są dostępne.
Ta strona zawiera informacje o typowych działaniach użytkowników, które mogą zostać zakłócone, gdy zablokujesz pliki cookie innych firm.
Typowe ścieżki użytkownika
Wiele procesów płatności i zakupów korzysta z plików cookie innych firm. W tabeli poniżej znajdziesz listę ścieżek użytkownika, które mogą zostać zakłócone, jeśli pliki cookie innych firm zostaną wyłączone, oraz sugestie dotyczące interfejsów API, których deweloperzy mogą użyć, aby uniknąć problemów. Ta lista może nie być wyczerpująca i może być aktualizowana w miarę udostępniania kolejnych rozwiązań Privacy Sandbox. Zachęcamy do przesłania opinii, jeśli zauważysz inne scenariusze, na które ma wpływ ta zmiana.
Testowanie ścieżek użytkowników związanych z płatnościami
Najlepszym sposobem na sprawdzenie, czy na przepływy danych użytkowników mają wpływ ograniczenia dotyczące plików cookie innych firm, jest przetestowanie ich przy włączonej opcji testowania plików cookie innych firm.
Aby się upewnić, że Twoja witryna działa zgodnie z oczekiwaniami, przetestuj tę procedurę z ograniczonym dostępem do plików cookie innych firm:
- Proces płatności w wielu witrynach: przetestuj procesy płatności, które korzystają z zewnętrznego dostawcy płatności (np. Płać za pomocą <nazwa-dostawcy>). Upewnij się, że:
- Przekierowanie nastąpiło.
- Bramka płatności jest wczytana prawidłowo.
- Proces płatności może być zakończony bez błędów.
- Użytkownik zostaje przekierowany z powrotem do Twojej witryny zgodnie z oczekiwaniami.
- Panele płatności: sprawdź, czy widżety panelu transakcji działają zgodnie z oczekiwaniami, gdy pliki cookie innych firm są ograniczone. Sprawdź, czy użytkownik może:
- Otwórz panel.
- Wszystkie płatności są zgodne z oczekiwaniami.
- bezbłędne poruszanie się między różnymi sekcjami panelu (np. historia transakcji, szczegóły płatności);
- Zarządzanie formami płatności: sprawdź, czy widżety zarządzania formami płatności działają zgodnie z oczekiwaniami. Po zablokowaniu plików cookie innych firm sprawdź, czy:
- Dodawanie i usuwanie formy płatności działa zgodnie z oczekiwaniami.
- Nie ma to wpływu na płacenie za pomocą wcześniej zapisanych form płatności.
- Wykrywanie oszustw: porównaj działanie rozwiązania do wykrywania oszustw z włączeniem i wyłączeniem plików cookie innych firm.
- Czy blokowanie plików cookie innych firm powoduje konieczność wykonania dodatkowych czynności, które mogą zniechęcić użytkowników?
- Czy nadal wykryje podejrzane wzorce, gdy pliki cookie innych firm są zablokowane w przeglądarce?
- Przycisk płatności spersonalizowany: sprawdź, czy przyciski płatności są wyświetlane prawidłowo, gdy pliki cookie innych firm są ograniczone.
- Czy użytkownik może nadal dokonywać zakupów, nawet jeśli spersonalizowany przycisk nie wyświetla jego preferowanej metody?
Płatność w wielu witrynach
Niektórzy dostawcy usług płatniczych mogą używać plików cookie innych firm, aby umożliwić użytkownikom dostęp do ich kont w wielu witrynach sprzedawców bez konieczności ponownego uwierzytelniania. Ta ścieżka użytkownika może być zaburzona w przypadku osób, które zdecydują się przeglądać internet bez plików cookie innych firm.
Wbudowane formularze płatności
Rozważ te domeny:
payment-provider.examplezapewnia usługi płatności w witrynach sprzedawców oraz przechowuje dane o płatnościach i sesjach użytkowników.merchant.exampleto witryna, która zawiera formularz płatności udostępniony przezpayment-provider.example.
Użytkownik właśnie zalogował się na konto payment-provider.example (np. podczas procesu płatności w innej witrynie). Użytkownik rozpoczyna proces płatności na stronie merchant.example.
W przypadku dostępnych plików cookie innych firm formularz payment-provider.example umieszczony na stronie merchant.example miałby dostęp do własnego najwyższego poziomu plików cookie sesji ustawionych na stronie payment-provider.example w kontekście najwyższego poziomu.
Jeśli jednak pliki cookie innych firm są zablokowane, element osadzony nie będzie miał dostępu do własnych plików cookie najwyższego poziomu.
dostosowywalne rozwiązanie z FedCM,
payment-provider.example powinien rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. To podejście może być odpowiednie, gdy:
payment-provider.examplejest umieszczony na niezwiązanych stronach zewnętrznych.payment-provider.examplejest umieszczony w ponad 5 powiązanych witrynach.
Główną zaletą FedCM jest to, że interfejs może zapewnić użytkownikom więcej kontekstu dotyczących ich wyborów. Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną zależną (merchant.example) a dostawcą tożsamości (payment-provider.example). Strona zależna może obsługiwać co najmniej 1 dostawcę tożsamości, a interfejs FedCM będzie wyświetlany tylko warunkowo.
W zależności od potrzeb deweloperzy mogą wybrać tryb pasywny, w którym prompt FedCM pojawia się automatycznie, gdy użytkownik jest zalogowany u dostawcy tożsamości, lub tryb aktywny, w którym proces logowania powinien zostać uruchomiony po wykonaniu przez użytkownika określonego działania, np. kliknięciu przycisku płatności.
FedCM pełni też funkcję sygnału zaufania dla interfejsu Storage Access API (SAA), który umożliwia umieszczaniu dostęp do plików cookie bez partycji najwyższego poziomu po tym, jak użytkownik wyrazi zgodę na logowanie się u dostawcy umieszczania, bez konieczności wyświetlania dodatkowego prompta.
Rozwiązanie skupiające się na dostępie do pamięci
Innym interfejsem API, który warto wziąć pod uwagę, jest Storage Access API (SAA).
W przypadku Storage Access API użytkownik otrzyma prośbę o zezwolenie na dostęp do plików cookie najwyższego poziomu w ramach funkcji embeddowania payment-provider.example. Jeśli użytkownik zatwierdzi dostęp, formularz może się wyświetlać tak samo jak w przypadku dostępu do plików cookie innych firm.
Podobnie jak w przypadku logowania sfederowanego użytkownik będzie musiał zatwierdzić prośbę w przypadku każdej nowej witryny, w której payment-provider.examplejest umieszczony. Aby dowiedzieć się, jak działa interfejs API, obejrzyj prezentację interfejsu SAA.
Jeśli domyślny prompt SAA nie odpowiada Twoim potrzebom, rozważ wdrożenie FedCM, aby dostosować prompt do swoich potrzeb.
Zmniejsz utrudnienia dla użytkowników w przypadku niewielkiej liczby powiązanych witryn
Jeśli witryna sprzedawcy i dostawca płatności należą do tej samej firmy, możesz użyć interfejsu API zestawów powiązanych witryn (RWS), aby zadeklarować relacje między domenami. Może to pomóc w zmniejszeniu trudności odczuwanych przez użytkowników: jeśli na przykład insurance.example i payment-portal-insurance.example znajdują się w tym samym RWS, payment-portal-insurance.example automatycznie uzyska dostęp do własnych plików cookie najwyższego poziomu, gdy zostanie przesłane żądanie dostępu do pamięci masowej w ramach wbudowanego elementu payment-portal-insurance.example.
Inne eksperymentalne rozwiązania
Innym eksperymentalnym interfejsem API, który może być przydatny w tym scenariuszu, jest Partitioned Popins. Interfejs API jest obecnie w fazie aktywnego rozwoju.
W przypadku podzielonych popinów użytkownik może zostać poproszony o podanie danych logowania, aby zalogować się w aplikacji payment-provider.example w otwartym przez nią popinie.merchant.example Miejsce na dane zostanie partycjonowane przez osobę otwierającą merchant.example. W tym przypadku element payment-provider.example
embed będzie mieć dostęp do wartości pamięci ustawionych w pop-inie. W ramach tego rozwiązania użytkownik musi zalogować się w witrynie dostawcy usług płatniczych.
Płatność za pomocą linku
Niektórzy dostawcy usług płatniczych oferują usługę generowania linku do płatności, który powoduje wyświetlenie niestandardowej strony płatności w witrynie sprzedawcy. Usługa linków do płatności i portal użytkownika dostawcy płatności są często wdrażane w różnych domenach, np. payment-provider.example i payment-link.example.
payment-link.example umieszcza formularz płatności udostępniony przezpayment-provider.example. To wariant wzorca osadzonego formularza płatności.
W tym przypadku warto też rozważyć stosowanie FedCM, SAA i RWS.
Panele płatności
Niektóre aplikacje wyświetlają użytkownikom panele transakcji z różnych witryn, zapewniając im centralny widok ich działań finansowych. Wymaga to dostępu panelu do danych użytkowników z różnych domen.
Rozważ te domeny:
earnings.exampleudostępnia panel płatności, który można umieszczać w różnych aplikacjach internetowych. Ta usługa przechowuje dane o zarobkach użytkowników i informacje o sesji.catsitting.exampleidogsitting.exampleto osobne witryny, które zawierają panelearnings.example.
Użytkownik loguje się na konto earnings.example. Gdy wejdą na stronę catsitting.example lub dogsitting.example, będą mogli sprawdzić swoje zarobki.
Wbudowany earnings.example panel korzysta z plików cookie najwyższego poziomu i wyświetla spersonalizowane informacje o zarobkach użytkownika.
Podobnie jak w innych przykładach, gdy pliki cookie innych firm są wyłączone, strona earnings.example nie będzie mieć dostępu do plików cookie najwyższego poziomu.
Panele własne
Jeśli wszystkie 3 domeny należą do tej samej strony, rozważ użycie SAA w połączeniu z RWS.
Dzięki interfejsowi Storage Access API usługa earnings.example może uzyskać dostęp do swojego pliku cookie najwyższego poziomu za zgodą użytkownika. Jeśli ta strona używa earnings.example w 4 lub mniej domenach,
oświadczenie o związkach między nimi za pomocą RWS może zapewnić płynniejsze wrażenia użytkowników.
Jeśli ta sama osoba umieszcza widżet w większej liczbie niż 5 domen, nie może deklarować relacji między wszystkimi witrynami, w których widżet jest umieszczony, a domeną widżetu, ponieważ RWS obsługuje maksymalnie 6 witryn w zbiorze: jedną główną i 5 powiązanych.
Dystrybucja paneli na dużą skalę
W tych przypadkach SAA i RWS mogą nie być optymalnym rozwiązaniem:
- rozpowszechniasz rozwiązanie w postaci panelu dla witryn innych firm;
- masz więcej niż 5 witryn, które zawierają widżet panelu.
W takim przypadku firma earnings.example powinna rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. Oznacza to, że użytkownik musi zalogować się w systemie dogsitting.example przy użyciu konta zarządzanego przez earnings.example.
FedCM udostępnia dostosowywalny interfejs użytkownika, który może pomóc w jasnym komunikowaniu użytkownikowi, które informacje są udostępniane. Dzięki FedCM aplikacja dogsitting.example może poprosić aplikację earnings.example o udostępnienie specjalnych uprawnień, na przykład dostępu do danych o transakcjach.
FedCM pełni też funkcję znaku zaufania dla interfejsu Storage Access API, a w przypadku osadzenia earnings.example zostanie przyznany dostęp do pamięci dla własnych plików cookie najwyższego poziomu bez dodatkowego wyświetlania prośby o zgodę użytkownika w wywołaniu interfejsu SAA API.
Ustawienia panelu dotyczące witryny
Jeśli danych nie trzeba udostępniać w różnych witrynach, rozważ podzielenie plików cookie za pomocą CHIPS. Pliki CHIPS mogą być przydatne do przechowywania preferencji dotyczących poszczególnych witryn, np. układu lub filtrów panelu.
Zarządzaj formami płatności
Innym typowym scenariuszem jest wyświetlanie i edytowanie przez użytkownika form płatności w ramach elementu embedowanego bez konieczności opuszczania witryny hosta.
Rozważ ten proces:
payments.exampleudostępnia narzędzie do zarządzania płatnościami, które można umieszczać w witrynach. Ta usługa przechowuje dane płatności użytkownika i informacje o sesji.shop.exampleto witryna, która zawiera narzędziepayments.exampleumożliwiające użytkownikom wyświetlanie, edytowanie i wybieranie preferowanych form płatności powiązanych z ich kontemshop.example.
Dostawcy usług płatniczych, którzy wdrożyli zarządzanie formami płatności, powinni też rozważyć zostanie dostawcą tożsamości za pomocą FedCM. Dzięki FedCM użytkownik będzie mógł zalogować się na konto strony korzystającej (shop.example) za pomocą konta zarządzanego przez dostawcę tożsamości (payments.example).
Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną zależną a dostawcą tożsamości. Główną zaletą korzystania z FedCM jest to, że interfejs może zapewnić użytkownikom więcej kontekstu dotyczącego ich wyborów. Jest on też sygnałem zaufania dla interfejsu Storage Access API, który umożliwia osadzonym elementom dostęp do plików cookie najwyższego poziomu.
Gdy pliki cookie innych firm są wyłączone, element payments.example nie będzie miał dostępu do plików cookie najwyższego poziomu. W takim przypadku SAA może pomóc w zapewnieniu prawidłowego działania, prosząc o dostęp do pamięci masowej.
Czasami informacje zawarte w zawartym embedzie nie muszą być udostępniane innym witrynom, w których jest on umieszczony. payments.example może być konieczne przechowywanie różnych preferencji użytkowników w przypadku każdej konkretnej witryny, w której treści są umieszczane. W takim przypadku rozważ podzielenie plików cookie za pomocą CHIPS. W przypadku CHIPS pliki cookie ustawione w payments.example umieszczonym w shop.example nie będą dostępne dla payments.example umieszczonego w another-shop.example.
Innym eksperymentalnym interfejsem API, który można potencjalnie wykorzystać w tym procesie użytkownika, jest Partitioned Popins.
Gdy użytkownik zaloguje się w payments.example w wyskakującym okienku otwartym przez
shop.example, miejsce na dane zostanie podzielone przez osobę, która otworzyła okno, a element payments.example w ramach tego okna będzie miał dostęp do wartości miejsca na dane ustawionych w wyskakującym okienku. Takie podejście wymaga jednak od użytkowników wpisywania danych logowania w przypadku dostawcy usług płatniczych w każdej witrynie.
Wykrywanie oszustw
Systemy analizy ryzyka mogą analizować dane przechowywane w plikach cookie w celu identyfikowania wzorców odbiegających od normy. Jeśli na przykład użytkownik nagle zmieni adres dostawy i dokona kilku dużych zakupów za pomocą nowego urządzenia, może to zwiększyć wynik potencjalnego oszustwa. Pliki cookie służące do wykrywania oszustw to zazwyczaj pliki cookie innych firm, które są ustawiane w witrynach sprzedawców przez dostawców płatności lub widżety usług zapobiegania oszustwom.
Ograniczenia plików cookie innych firm nie powinny zakłócać działania systemów wykrywania oszustw, ale mogą powodować dodatkowe problemy dla użytkowników. Jeśli system nie może z pewnością potwierdzić, że użytkownik jest autentyczny z powodu zablokowanych plików cookie, może wymagać dodatkowych kontroli, takich jak weryfikacja tożsamości.
Aby wykrywać oszustwa, gdy pliki cookie innych firm są zablokowane, rozważ zintegrowanie interfejsu Private State Tokens API (PST) z rozwiązaniem do wykrywania oszustw. Dzięki PST dostawca płatności może zarejestrować się jako wydawca tokenów i przyznawać użytkownikom tokeny, które nie są oparte na plikach cookie innych firm. Tokeny te można następnie wykorzystać na stronach sprzedawców w celu sprawdzenia, czy użytkownik jest godny zaufania. Szczegóły implementacji znajdziesz w dokumentacji dla programistów dotyczącej PST.
Piaskownica prywatności eksperymentuje z innymi interfejsami API do zwalczania oszustw.
Przycisk personalizowanych płatności
Przyciski płatności (np. Zapłać za pomocą <preferowanej formy płatności>) umieszczone na stronach sprzedawców często korzystają z informacji z różnych witryn ustawionych przez dostawcę płatności. Umożliwia to personalizację, a użytkownicy mogą płacić za pomocą preferowanej formy płatności. Jeśli w przeglądarce użytkownika są zablokowane pliki cookie innych firm, może to wpłynąć na renderowanie spersonalizowanego przycisku płatności.
Chociaż SAA może umożliwiać dostęp do pamięci, wymagany komunikat może nie zapewnić użytkownikom optymalnych wrażeń.
Rozważamy potencjalne rozwiązanie, które jest przeznaczone do tego konkretnego przypadku użycia: Fenced Frames z dostępem do lokalnych danych bez partycjonowania. Interfejs API jest obecnie w aktywnej fazie rozwoju, a Ty możesz mieć wpływ na jego przyszłość. Wypróbuj i przekaż opinię.
Pomoc
Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem w GitHub w repozytorium pomocy dla deweloperów dotyczącej Piaskownicy prywatności.