サードパーティ Cookie は、ブラウザの制限、ユーザー設定、デベロッパー フラグ、エンタープライズ ポリシーによってブロックされることがあります。
サードパーティ Cookie を使用できるかどうかに関係なく、サイトやサービスでユーザーに優れたエクスペリエンスを提供できるようにする必要があります。
このページでは、サードパーティ Cookie がブロックされた場合に影響を受ける可能性がある一般的なユーザー ジャーニーについて説明します。
一般的なユーザー ジャーニー
多くの支払いとショッピングのワークフローは、サードパーティ Cookie に依存しています。次の表に、サードパーティ Cookie が無効になった場合に影響を受ける可能性のあるユーザー ジャーニーと、デベロッパーが破損を回避するために使用できる代替 API を示します。このリストはすべてを網羅しているわけではなく、プライバシー サンドボックスのソリューションが追加されるたびに更新される可能性があります。
お支払い関連のユーザー ジャーニーをテストする
ユーザーフローがサードパーティ Cookie の制限の影響を受けるかどうかをテストする最善の方法は、サードパーティ Cookie のテストフラグを有効にしてユーザーフローをテストすることです。
ウェブサイトが想定どおりに動作することを確認するには、サードパーティ Cookie を制限した状態で次のフローをテストします。
- クロスサイト チェックアウト: サードパーティの決済プロバイダ（ <example-provider> で支払うなど）に依存する支払いフローをテストします。次のことを確認してください。
- リダイレクトが正常に行われます。
- 決済ゲートウェイが正しく読み込まれている。
- お支払い手続きをエラーなく完了できる。
- ユーザーは想定どおりにウェブサイトにリダイレクトされます。
- 支払いダッシュボード: サードパーティ Cookie が制限されている状態で、トランザクション ダッシュボード ウィジェットが想定どおりに動作することを確認します。ユーザーが次の操作を行えることを確認します。
- ダッシュボードにアクセスします。
- すべての支払いが想定どおりに表示されます。
- ダッシュボードのさまざまなセクション（取引履歴、お支払い情報など）をエラーなく移動できる。
- お支払い方法の管理: お支払い方法の管理ウィジェットが想定どおりに動作することをテストします。サードパーティ Cookie がブロックされた状態で、次のことをテストします。
- お支払い方法の追加または削除が正常に機能する。
- 以前に保存したお支払い方法でのお支払いには影響しません。
- 不正行為の検出: サードパーティ Cookie の有無による不正行為検出ソリューションの動作を比較します。
- サードパーティ Cookie をブロックすると、追加の手順が必要になり、ユーザーの負担が増えますか？
- ブラウザでサードパーティ Cookie がブロックされている場合でも、疑わしいパターンを検出できますか？
- パーソナライズされた購入手続きボタン: サードパーティ Cookie が制限された状態で、支払いボタンが正しくレンダリングされるかどうかをテストします。
- パーソナライズされたボタンに希望の支払い方法が表示されない場合でも、購入を完了できますか？
クロスサイト チェックアウト
一部の決済プロバイダは、ユーザーが複数の販売者サイトでアカウントにアクセスする際に再認証を必要としないように、サードパーティ Cookie を使用している場合があります。サードパーティ Cookie を使用せずにブラウジングすることを選択したユーザーは、このユーザー ジャーニーに影響を受ける可能性があります。
埋め込み購入手続きフォーム
次のドメインについて考えてみましょう。
payment-provider.exampleは販売者サイトに支払いサービスを提供し、ユーザーの支払いデータとセッションデータを保存します。merchant.exampleは、payment-provider.exampleが提供する購入手続きフォームを埋め込んでいるウェブサイトです。
ユーザーが payment-provider.example にログインしたばかりである（たとえば、別のサイトでチェックアウトを完了したときなど）。ユーザーが merchant.example で購入手続きを開始します。
サードパーティ Cookie が利用可能な場合、merchant.example に埋め込まれた payment-provider.example の購入フォームは、トップレベル コンテキストで payment-provider.example に設定された独自のトップレベル セッション Cookie にアクセスできます。ただし、サードパーティ Cookie がブロックされている場合、埋め込みは独自のトップレベル Cookie にアクセスできません。
FedCM を使用したカスタマイズ可能なソリューション
payment-provider.example は、ID プロバイダとして機能する FedCM の実装を検討する必要があります。このアプローチは、次のような場合に適しています。
payment-provider.exampleが関連性のないサードパーティのサイトに埋め込まれている。payment-provider.exampleが 6 つ以上の関連サイトに埋め込まれている。
FedCM の主なメリットは、UI でユーザーが選択肢をより深く理解できることです。FedCM では、ユーザーの権限に基づいて、利用者（merchant.example）と ID プロバイダ（payment-provider.example）の間でカスタムデータを共有できます。利用者は 1 つ以上の ID プロバイダをサポートすることを選択でき、FedCM UI は条件付きで表示されます。
ニーズに応じて、デベロッパーは FedCM プロンプトのパッシブ モード（ユーザーが ID プロバイダでログインしたときに自動的に表示される）とアクティブ モード（ユーザーが決済ボタンをクリックするなど、操作を行った後にログイン プロセスがトリガーされる）のいずれかを選択できます。
また、FedCM は Storage Access API（SAA）の信頼シグナルとしても機能します。これにより、ユーザーが埋め込みのプロバイダでのログインに同意すると、追加のユーザー プロンプトなしで、埋め込みがトップレベルのパーティション化されていない Cookie にアクセスできるようになります。
ストレージ アクセスに特化したソリューション
もう 1 つの API として、Storage Access API（SAA）があります。SAA を使用すると、payment-provider.example 埋め込みが独自のトップレベル Cookie にアクセスすることを許可するかどうかをユーザーに確認するメッセージが表示されます。ユーザーがアクセスを承認すると、サードパーティ Cookie が利用可能な場合と同様にフォームをレンダリングできます。
FedCM と同様に、ユーザーは payment-provider.example が埋め込まれた新しいサイトごとにリクエストを承認する必要があります。API の仕組みについては、SAA のデモをご覧ください。デフォルトの SAA プロンプトがニーズに合わない場合は、FedCM を実装して、よりカスタマイズされたエクスペリエンスを実現することを検討してください。
少数の関連サイトでユーザーのストレスを軽減する
販売者サイトと決済プロバイダが同じ会社に属している場合は、関連ウェブサイト セット（RWS）API を使用してドメイン間の関係を宣言できます。これにより、ユーザーの不満を軽減できます。たとえば、insurance.example と payment-portal-insurance.example が同じ RWS にある場合、payment-portal-insurance.example の埋め込み内でストレージ アクセスがリクエストされると、payment-portal-insurance.example は独自のトップレベル Cookie に自動的にアクセスできるようになります。
その他の試験運用ソリューション
このシナリオで役立つ可能性がある試験運用版 API として、パーティション分割されたポップインがあります。この API は現在開発中です。
パーティション分割されたポップインでは、ユーザーは merchant.example によって開かれたポップイン内で payment-provider.example にログインするために認証情報の入力を求められることがあります。ストレージは、オープナー merchant.example によってパーティション分割されます。この場合、payment-provider.example 埋め込みは、ポップアップ内で設定されたストレージ値にアクセスできます。このソリューションでは、ユーザーはすべてのサイトで決済機関にログインする必要があります。
お支払いリンクの購入手続き
一部の決済プロバイダは、販売者のサイト用にカスタムの購入手続きページをレンダリングする決済リンクを生成するサービスを提供しています。支払いリンク サービスと支払いプロバイダのユーザー ポータルは、多くの場合、payment-provider.example や payment-link.example などの異なるドメインに実装されます。
payment-link.example は、payment-provider.example が提供する購入手続きフォームを埋め込みます。これは、埋め込みの購入手続きフォーム パターンのバリエーションです。このケースでは、FedCM、SAA、RWS も検討すべきオプションです。
お支払いダッシュボード
一部のアプリケーションでは、複数のサイトにわたってユーザーに取引ダッシュボードを表示し、財務アクティビティを一元的に確認できるようにしています。そのため、ダッシュボードは複数のドメインにわたってユーザー固有のデータにアクセスする必要があります。
次のドメインについて考えてみましょう。
earnings.exampleは、さまざまなウェブ アプリケーションに埋め込むことができる支払いダッシュボードを提供します。このサービスは、ユーザーの収益データとセッション情報を保存します。catsitting.exampleとdogsitting.exampleは、どちらもearnings.exampleダッシュボードを埋め込んでいる別々のウェブサイトです。
ユーザーが earnings.example アカウントにログインします。catsitting.example または dogsitting.example にアクセスすると、収益を確認できます。埋め込みの earnings.example ダッシュボードは最上位の Cookie に依存し、ユーザーのパーソナライズされた収益情報を表示します。
他の例と同様に、サードパーティ Cookie が無効になっている場合、earnings.example 埋め込みはトップレベルの Cookie にアクセスできません。
ファーストパーティ ダッシュボード
3 つのドメインがすべて同じパーティに属している場合は、RWS とともに SAA の使用を検討してください。SAA を使用すると、earnings.example はユーザーの権限でトップレベルの Cookie にアクセスできます。このサイトが 4 つ以下のドメインで earnings.example を使用している場合、RWS でドメイン間の関係を宣言することで、ユーザー エクスペリエンスを向上させることができます。
同じ当事者が 6 つ以上のドメインにウィジェットを埋め込む場合、RWS はセット内のサイトを最大 6 つ（プライマリ サイト 1 つと関連付けられたサイト 5 つ）しかサポートしていないため、すべての埋め込みサイトとウィジェットのドメイン間の関係を宣言することはできません。
ダッシュボードの配布をスケーリングする
次のような場合、SAA と RWS は最適なソリューションではない可能性があります。
- サードパーティ サイト向けのダッシュボード ソリューションを配布している。
- ダッシュボード ウィジェットを埋め込んでいるサイトが 5 つ以上ある。
この場合、earnings.example は ID プロバイダとして機能する FedCM の実装を検討する必要があります。つまり、ユーザーは earnings.example によって管理されているアカウントで dogsitting.example にログインする必要があります。
FedCM は、共有される情報をユーザーに明確に伝えるのに役立つカスタマイズ可能な UI を提供します。FedCM を使用すると、dogsitting.example は earnings.example にカスタム権限（トランザクション データへのアクセスなど）の共有をリクエストできます。
また、FedCM は Storage Access API の信頼シグナルとしても機能し、earnings.example 埋め込みは SAA API 呼び出しで追加のユーザー プロンプトなしで、独自のトップレベル Cookie へのストレージ アクセス権が付与されます。
サイト固有のダッシュボード設定
複数のサイト間でデータを共有する必要がない場合は、CHIPS を使用して Cookie をパーティショニングすることを検討してください。CHIPS は、サイト固有の設定（ダッシュボードのレイアウトやフィルタなど）を保存するのに役立ちます。
お支払い方法の管理
もう 1 つの一般的なフローは、ユーザーがホストサイトを離れることなく、埋め込み内で支払い方法を表示して編集することです。
次のフローを考えてみましょう。
payments.exampleは、ウェブサイトに埋め込むことができる支払い管理ツールを提供しています。このサービスは、ユーザーの支払いデータとセッション情報を保存します。shop.exampleは、payments.exampleツールを埋め込み、ユーザーがshop.exampleアカウントに関連付けられたお支払い方法を表示、編集、選択できるようにするウェブサイトです。
お支払い方法の管理を実装する決済機関は、FedCM を使用した ID プロバイダになることも検討してください。FedCM を使用すると、ユーザーは ID プロバイダ（payments.example）が管理するアカウントを使用して、リライング パーティ（shop.example）にログインできます。
FedCM では、ユーザーの許可を得て、利用者と ID プロバイダの間でカスタムデータを共有できます。FedCM を使用する主なメリットは、UI でユーザーの選択肢に関するコンテキストをより多く提供できることです。また、Storage Access API の信頼シグナルとしても機能し、埋め込みがトップレベルの Cookie にアクセスできるようになります。
サードパーティ Cookie が無効になっている場合、payments.example 埋め込みはトップレベル Cookie にアクセスできません。この場合、SAA はストレージ アクセスをリクエストすることで、適切なオペレーションを保証できます。
埋め込み内で設定された情報が、他の埋め込みサイト間で共有される必要がない場合があります。payments.example は、特定の埋め込みサイトごとに異なるユーザー設定を保存するだけでよい場合があります。この場合は、CHIPS を使用して Cookie をパーティショニングすることを検討してください。CHIPS を使用すると、shop.example に埋め込まれた payments.example 内で設定された Cookie は、another-shop.example に埋め込まれた payments.example からアクセスできなくなります。
このユーザーフローで利用できる可能性のあるもう 1 つの試験運用版 API は、パーティション分割されたポップインです。ユーザーが shop.example によって開かれたポップイン内の payments.example にログインすると、ストレージはオープナーによってパーティショニングされ、payments.example 埋め込みはポップイン内で設定されたストレージ値にアクセスできるようになります。ただし、この方法では、ユーザーはすべてのサイトで認証情報を入力して決済プロバイダにログインする必要があります。
不正行為の検出
リスク分析システムは、Cookie に保存されているデータを分析して、標準から逸脱したパターンを特定できます。たとえば、ユーザーが突然配送先住所を変更し、新しいデバイスを使用して高額な購入を複数回行った場合、不正行為の可能性スコアが上昇する可能性があります。不正行為検出 Cookie は通常、決済プロバイダまたは不正行為防止サービス ウィジェットによって販売者サイトに設定されるサードパーティ Cookie です。
サードパーティ Cookie の制限によって不正行為検出システムが機能しなくなることはありませんが、ユーザーの利便性が損なわれる可能性があります。Cookie がブロックされているため、システムでユーザーが正当なユーザーであることを確実に確認できない場合は、身元確認の完了などの追加の確認が必要になることがあります。
サードパーティ Cookie がブロックされた場合の不正行為の検出をサポートするには、プライベート ステート トークン（PST）API を不正行為検出ソリューションに統合することを検討してください。PST を使用すると、支払いプロバイダはトークン発行者として登録し、サードパーティ Cookie に依存しないトークンをユーザーに付与できます。これらのトークンは、販売者サイトでユーザーの信頼性を確認するために使用できます。実装の詳細については、PST デベロッパー向けドキュメントをご覧ください。
プライバシー サンドボックスでは、他の不正防止 API のテストも行っています。
パーソナライズされた購入手続きボタン
販売者のサイトに埋め込まれた支払いボタン（[<お支払い方法> で支払う] など）は、多くの場合、支払いプロバイダによって設定されたクロスサイト情報に依存しています。これにより、ユーザーは好みの支払い方法でスムーズに決済できるようになります。ユーザーのブラウザでサードパーティの Cookie がブロックされている場合、パーソナライズされたお支払いボタンのレンダリングに影響する可能性があります。
SAA ではストレージへのアクセスを許可できますが、必要なプロンプトが理想的なユーザー エクスペリエンスにつながるとは限りません。
このユースケースを対象とした潜在的なソリューションとして、ローカルのパーティショニングされていないデータへのアクセスを伴うフェンス付きフレームを検討しています。この API は現在開発段階であり、今後の展開を形作ることができます。実際に試して、フィードバックをお寄せください。
ヘルプとフィードバック
このガイドで説明されているユーザー ジャーニーや API に関する質問やフィードバックがある場合は、フィードバックを共有してください。