Pliki cookie innych firm mogą być blokowane przez ograniczenia przeglądarki, ustawienia użytkownika, flagi dewelopera lub zasady przedsiębiorstwa.
Musisz zadbać o to, aby Twoja witryna lub usługa zapewniała komfort obsługi wszystkim użytkownikom, niezależnie od tego, czy pliki cookie innych firm są dostępne.
Na tej stronie znajdziesz informacje o typowej ścieżce użytkownika, na którą może mieć wpływ blokowanie plików cookie innych firm.
Typowe ścieżki użytkownika
Wiele procesów płatności i zakupów opiera się na plikach cookie innych firm. W tabeli poniżej znajdziesz niektóre ścieżki użytkownika, na które może mieć wpływ wyłączenie plików cookie innych firm, oraz sugerowane alternatywne interfejsy API, których deweloperzy mogą używać, aby uniknąć problemów. Ta lista może być niepełna i może być aktualizowana w miarę udostępniania kolejnych rozwiązań Privacy Sandbox.
Testowanie ścieżek użytkowników związanych z płatnościami
Aby sprawdzić, czy na przepływy użytkowników mają wpływ ograniczenia dotyczące plików cookie innych firm, przejdź przez nie z włączoną flagą testowania plików cookie innych firm.
Aby mieć pewność, że witryna działa zgodnie z oczekiwaniami, przetestuj ten proces przy ograniczonym dostępie do plików cookie innych firm:
- Płatność w innej witrynie: przetestuj procesy płatności, które korzystają z usług dostawcy płatności zewnętrznych (np. Zapłać za pomocą <example-provider>). Upewnij się, że:
- Przekierowanie zostało zrealizowane.
- Bramka płatności wczytuje się prawidłowo.
- Proces płatności można ukończyć bez błędów.
- Użytkownik zostanie przekierowany z powrotem do Twojej witryny.
- Panele płatności: sprawdź, czy widżety panelu transakcji działają zgodnie z oczekiwaniami przy ograniczonych plikach cookie innych firm. Sprawdź, czy użytkownik może:
- Otwórz panel.
- Wszystkie płatności są widoczne zgodnie z oczekiwaniami.
- bezbłędnie poruszać się po różnych sekcjach panelu (np. historia transakcji, szczegóły płatności);
- Zarządzanie formami płatności: sprawdź, czy widżety do 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łatności za pomocą wcześniej zapisanych form płatności.
- Wykrywanie oszustw: porównaj działanie rozwiązania do wykrywania oszustw z plikami cookie innych firm i bez nich.
- Czy blokowanie plików cookie innych firm wymaga dodatkowych czynności, które mogą zniechęcić użytkowników?
- Czy nadal może wykrywać podejrzane wzorce, gdy w przeglądarce blokowane są pliki cookie innych firm?
- Spersonalizowany przycisk płatności: sprawdź, czy przyciski płatności są prawidłowo renderowane po ograniczeniu plików cookie innych firm.
- Czy użytkownik może dokonać zakupu, nawet jeśli przycisk personalizacji nie wyświetla jego preferowanej metody?
Płatności w wielu witrynach
Niektórzy dostawcy usług płatniczych mogą korzystać z plików cookie innych firm, aby umożliwić użytkownikom dostęp do konta w wielu witrynach sprzedawców bez konieczności ponownego uwierzytelniania. W przypadku użytkowników, którzy zdecydują się przeglądać internet bez plików cookie innych firm, ta ścieżka może ulec zmianie.
Osadzone formularze płatności
Rozważ te domeny:
payment-provider.exampleświadczy usługi płatnicze w witrynach sprzedawców i przechowuje dane użytkowników dotyczące płatności i sesji.merchant.exampleto witryna, która zawiera formularz płatności udostępniony przezpayment-provider.example.
Użytkownik właśnie zalogował się w payment-provider.example (np. podczas finalizowania płatności w innej witrynie). Użytkownik rozpoczyna proces płatności na stronie merchant.example.
Gdyby pliki cookie innych firm były dostępne, formularz płatności payment-provider.example osadzony na stronie merchant.example miałby dostęp do własnego pliku cookie sesji najwyższego poziomu ustawionego na stronie payment-provider.example w kontekście najwyższego poziomu.
Jeśli jednak pliki cookie innych firm są zablokowane, osadzony element nie będzie miał dostępu do własnych plików cookie najwyższego poziomu.
Rozwiązanie z możliwością dostosowania oparte na FedCM
payment-provider.example powinny rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. Takie podejście może się sprawdzić, gdy:
payment-provider.examplejest umieszczony w niepowiązanych witrynach zewnętrznych.payment-provider.examplejest umieszczony w więcej niż 5 powiązanych witrynach.
Główną zaletą FedCM jest to, że interfejs może dostarczać użytkownikom więcej kontekstu dotyczącego 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 jednego dostawcę tożsamości, a interfejs FedCM będzie wyświetlany tylko w określonych warunkach.
W zależności od potrzeb deweloperzy mogą wybrać tryb pasywny, w którym prośba FedCM pojawia się automatycznie, gdy użytkownik jest zalogowany u dostawcy tożsamości, lub tryb aktywny, w którym proces logowania powinien być wywoływany po działaniu użytkownika, np. kliknięciu przycisku płatności.
FedCM działa też jako sygnał zaufania dla interfejsu Storage Access API (SAA), który umożliwia osadzonemu elementowi dostęp do plików cookie najwyższego poziomu bez partycji po tym, jak użytkownik zgodzi się zalogować za pomocą dostawcy osadzonego elementu, bez konieczności wyświetlania dodatkowego monitu.
Rozwiązanie skupione na dostępie do pamięci
Warto też rozważyć użycie interfejsu Storage Access API (SAA).
Za pomocą Storage Access API użytkownik zostanie poproszony o zezwolenie na dostęp do własnych plików cookie najwyższego poziomu.payment-provider.example Jeśli użytkownik zezwoli na dostęp, formularz może być renderowany tak samo jak w przypadku dostępności plików cookie innych firm.
Podobnie jak w przypadku FedCM użytkownik będzie musiał zatwierdzić prośbę w każdej nowej witrynie, w której jest umieszczony element payment-provider.example. Aby dowiedzieć się, jak działa interfejs API, zapoznaj się z demonstracją SAA.
Jeśli domyślny prompt SAA nie spełnia Twoich potrzeb, możesz wdrożyć FedCM, aby uzyskać bardziej spersonalizowane działanie.
Ograniczanie utrudnień dla użytkowników w przypadku niewielkiej liczby powiązanych witryn
Jeśli witryna sprzedawcy i dostawca usług płatniczych należą do tej samej firmy, możesz użyć interfejsu Related Website Sets (RWS), aby zadeklarować relacje między domenami. Może to pomóc zmniejszyć problemy użytkowników: na przykład jeśli insurance.example i payment-portal-insurance.example znajdują się w tym samym zestawie powiązanych witryn, payment-portal-insurance.example automatycznie uzyska dostęp do własnych plików cookie najwyższego poziomu, gdy w osadzonym elemencie payment-portal-insurance.example zostanie wysłane żądanie dostępu do pamięci.
Inne eksperymentalne rozwiązania
Inny eksperymentalny interfejs API, który może być przydatny w tym scenariuszu, to Partitioned Popins. Interfejs API jest obecnie w fazie aktywnego rozwoju.
W przypadku podzielonych wyskakujących okien użytkownik może zostać poproszony o podanie danych logowania, aby zalogować się w usłudze payment-provider.example w wyskakującym okienku otwartym przez merchant.example. Pamięć masowa zostanie podzielona przez otwierającego merchant.example. W tym przypadku element payment-provider.example
embed będzie miał dostęp do wartości pamięci ustawionych w wyskakującym okienku. W tym przypadku użytkownik będzie musiał logować się u dostawcy usług płatniczych w każdej witrynie.
Płatności za pomocą linku
Niektórzy dostawcy usług płatniczych oferują usługę generowania linku do płatności, który renderuje niestandardową stronę płatności w witrynie sprzedawcy. Usługa linku 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 osadza formularz płatności dostarczony przez payment-provider.example. Jest to odmiana wzorca formularza płatności wbudowanego.
FedCM, SAA i RWS to również dobre opcje w tym przypadku.
Panele płatności
Niektóre aplikacje wyświetlają użytkownikom panele transakcji w wielu witrynach, zapewniając scentralizowany widok ich działań finansowych. Wymaga to dostępu panelu do danych konkretnych użytkowników w wielu domenach.
Rozważ te domeny:
earnings.exampleudostępnia panel wypłat, który można umieścić w różnych aplikacjach internetowych. Ta usługa przechowuje dane o zarobkach użytkownika i informacje o sesjach.catsitting.exampleidogsitting.exampleto osobne witryny, które umieszczają w swoim kodzie panelearnings.example.
Użytkownik loguje się na swoje konto earnings.example. Gdy odwiedzą stronę catsitting.example lub dogsitting.example, będą mogli sprawdzić swoje zarobki. Osadzony 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, osadzony element earnings.example nie będzie mieć dostępu do plików cookie najwyższego poziomu, gdy pliki cookie innych firm są wyłączone.
Panele własne
Jeśli wszystkie 3 domeny należą do tego samego podmiotu, rozważ użycie SAA razem z RWS.
Dzięki Storage Access API earnings.example może uzyskać dostęp do swojego pliku cookie najwyższego poziomu za zgodą użytkownika. Jeśli ta firma używa earnings.example w maksymalnie 4 domenach, deklarowanie między nimi relacji za pomocą RWS może zapewnić użytkownikom lepsze wrażenia.
Jeśli ten sam podmiot umieści widżet w więcej niż 5 domenach, nie będzie mógł zadeklarować relacji między wszystkimi witrynami, w których umieszczono widżet, a domeną widżetu, ponieważ RWS obsługuje tylko do 6 witryn w zestawie – 1 główną i 5 powiązanych.
Dystrybucja paneli na dużą skalę
W tych przypadkach SAA i RWS mogą nie być optymalnym rozwiązaniem:
- Dystrybuujesz rozwiązanie do tworzenia paneli do witryn innych firm.
- Masz więcej niż 5 witryn, które zawierają widżet panelu.
W takim przypadku earnings.example powinien rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. Oznacza to, że użytkownik będzie musiał zalogować się w usłudze dogsitting.example przy użyciu konta zarządzanego przez earnings.example.
FedCM oferuje interfejs użytkownika, który można dostosować, aby jasno informować użytkownika o tym, jakie informacje są udostępniane. Za pomocą FedCM aplikacja dogsitting.example może prosićearnings.example o udostępnienie niestandardowych uprawnień, np. dostępu do danych transakcji.
FedCM służy też jako sygnał zaufania dla interfejsu Storage Access API, a osadzony earnings.example uzyska dostęp do własnych plików cookie najwyższego poziomu bez dodatkowego monitu użytkownika podczas wywołania interfejsu SAA API.
Ustawienia panelu dotyczące konkretnej witryny
Jeśli dane nie muszą być udostępniane w wielu witrynach, rozważ podzielenie plików cookie za pomocą CHIPS. CHIPS mogą być przydatne do przechowywania ustawień dotyczących konkretnej witryny, np. układu panelu lub filtrów.
Zarządzaj formami płatności
Inny typowy proces to wyświetlanie i edytowanie form płatności w osadzonym elemencie bez opuszczania witryny hosta.
Rozważmy ten proces:
payments.exampleudostępnia narzędzie do zarządzania płatnościami, które można zintegrować z witrynami. Ta usługa przechowuje dane płatności użytkownika i informacje o sesji.shop.exampleto witryna, która zawiera narzędziepayments.example, aby umożliwić użytkownikom wyświetlanie, edytowanie lub wybieranie preferowanych form płatności powiązanych z ich kontemshop.example.
Dostawcy usług płatniczych, którzy wdrażają zarządzanie formami płatności, powinni też rozważyć zostanie dostawcą tożsamości z FedCM. Dzięki FedCM użytkownik będzie mógł zalogować się w usłudze Relying Party (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 dostarczać użytkownikom więcej informacji o ich wyborach. Działa też jako sygnał zaufania dla interfejsu Storage Access API, który umożliwia osadzonemu elementowi dostęp do plików cookie najwyższego poziomu.
Gdy pliki cookie innych firm są wyłączone, osadzony element payments.example nie ma dostępu do plików cookie najwyższego poziomu. W takim przypadku SAA może zapewnić prawidłowe działanie, prosząc o dostęp do pamięci masowej.
Czasami informacje ustawione w osadzonym elemencie nie muszą być udostępniane w innych witrynach, w których jest on osadzony. payments.example może potrzebować tylko przechowywania różnych preferencji użytkownika w przypadku każdej konkretnej witryny z osadzonymi treściami. W takim przypadku rozważ podzielenie plików cookie za pomocą CHIPS. Dzięki CHIPS plik cookie ustawiony w ramce payments.example na stronie shop.example nie będzie dostępny dla ramki payments.example na stronie another-shop.example.
Kolejny eksperymentalny interfejs API, który można potencjalnie wykorzystać w tym przepływie użytkownika, to Partitioned Popins.
Gdy użytkownik zaloguje się w payments.example w wyskakującym okienku otwartym przez shop.example, pamięć będzie podzielona według otwierającego, a osadzony element payments.example będzie mieć dostęp do wartości pamięci ustawionych w wyskakującym okienku. Wymaga to jednak od użytkowników wpisywania danych logowania w celu zalogowania się u dostawcy płatności w każdej witrynie.
Wykrywanie oszustw
Systemy analizy ryzyka mogą analizować dane przechowywane w plikach cookie, aby identyfikować wzorce odbiegające od normy. Jeśli na przykład użytkownik nagle zmieni adres dostawy i dokona kilku dużych zakupów na nowym urządzeniu, potencjalny wynik oceny ryzyka oszustwa może wzrosnąć. Pliki cookie wykrywające oszustwa to zwykle pliki cookie innych firm, które są umieszczane w witrynach sprzedawców przez dostawców usług płatniczych lub widżety usług zapobiegających oszustwom.
Ograniczenia dotyczące plików cookie innych firm nie powinny powodować awarii systemów wykrywania oszustw, ale mogą utrudniać korzystanie z usługi. Jeśli system nie może z pewnością zweryfikować, czy użytkownik jest prawdziwy, z powodu zablokowanych plików cookie, może wymagać dodatkowych kontroli, np. weryfikacji tożsamości.
Aby wspierać wykrywanie oszustw, gdy pliki cookie innych firm są zablokowane, rozważ zintegrowanie z rozwiązaniem do wykrywania oszustw interfejsu Private State Tokens (PST) API. Dzięki PST dostawca usług płatniczych może zarejestrować się jako wydawca tokenów i przyznawać użytkownikom tokeny, które nie są zależne od plików cookie innych firm. Te tokeny można następnie wykorzystać w witrynach sprzedawców, aby sprawdzić, czy użytkownik jest godny zaufania. Szczegóły implementacji znajdziesz w dokumentacji dla programistów PST.
W Piaskownicy prywatności testowane są inne interfejsy API zapobiegające oszustwom.
Spersonalizowany przycisk płatności
Przyciski płatności (np. Zapłać za pomocą <preferowanej formy płatności>) umieszczone w witrynach sprzedawców często korzystają z informacji z innych witryn ustawionych przez dostawcę usług płatniczych. Umożliwia to personalizację, a użytkownicy mogą korzystać z płynnego procesu płatności za pomocą preferowanej formy płatności. Jeśli w przeglądarce użytkownika zablokowane są pliki cookie innych firm, może to mieć wpływ na renderowanie spersonalizowanego przycisku płatności.
Chociaż SAA może zezwalać na dostęp do pamięci, wymagany komunikat może nie zapewniać optymalnych wrażeń użytkownika.
Rozważamy potencjalne rozwiązanie, które jest ukierunkowane na ten przypadek użycia: Fenced Frames z lokalnym dostępem do niepodzielonych danych. Interfejs API jest obecnie w fazie aktywnego rozwoju, a Ty możesz wpłynąć na jego przyszłość. Wypróbuj i przekaż opinię.
Pomoc i opinie
Jeśli masz pytania lub uwagi na temat ścieżek użytkownika lub interfejsów API opisanych w tym przewodniku, możesz podzielić się swoją opinią.