サードパーティ Cookie は、ブラウザの制限、ユーザー設定、デベロッパー フラグ、エンタープライズ ポリシーによってブロックされる場合があります。
サードパーティ Cookie を使用できるかどうかに関係なく、サイトまたはサービスですべてのユーザーに優れたエクスペリエンスを提供する必要があります。
このページでは、サードパーティ Cookie がブロックされた場合に影響を受ける可能性がある一般的なユーザー ジャーニーについて説明します。
一般的なユーザー ジャーニー
多くの支払いワークフローとショッピング ワークフローは、サードパーティ Cookie に依存しています。次の表に、サードパーティ Cookie が無効にされた場合に影響を受ける可能性があるユーザー ジャーニーと、デベロッパーが使用して機能の損失を回避できる代替 API を示します。このリストはすべてを網羅しているわけではなく、プライバシー サンドボックス ソリューションが利用可能になると更新される場合があります。影響を受けるその他のシナリオが見つかった場合は、フィードバックを送信していただけますと幸いです。
お支払い関連のユーザー ジャーニーをテストする
ユーザーフローがサードパーティ Cookie の制限の影響を受けているかどうかをテストする最善の方法は、サードパーティ Cookie テストフラグを有効にしてユーザーフローをテストすることです。
ウェブサイトが想定どおりに動作することを確認するには、サードパーティ Cookie を制限して次のフローをテストします。
- クロスサイト チェックアウト: サードパーティの決済プロバイダ（ <example-provider> で支払うなど）に依存する支払いフローをテストします。次のことを確認します。
- リダイレクトが正常に実行されます。
- 決済ゲートウェイが正しく読み込まれている。
- お支払い手続きをエラーなく完了できる。
- ユーザーは、想定どおりにウェブサイトにリダイレクトされます。
- お支払いダッシュボード: サードパーティ Cookie が制限されている状態で、取引ダッシュボード ウィジェットが想定どおりに動作することをテストします。お客様が次の操作を行えることを確認します。
- ダッシュボードにアクセスします。
- すべての支払いが期待どおりに表示されます。
- ダッシュボードのさまざまなセクション（取引履歴、お支払いの詳細など）をエラーなく移動します。
- お支払い方法を管理: お支払い方法の管理ウィジェットが想定どおりに動作することをテストします。サードパーティ 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が 5 つを超える関連サイトに埋め込まれている。
FedCM の主なメリットは、UI でユーザーに選択の状況に関するより多くのコンテキストを提供できることです。ユーザーの許可があれば、FedCM は利用者と ID プロバイダ（payment-provider.example）の間でカスタムデータを共有できます。利用者は 1 つ以上の ID プロバイダをサポートすることを選択できます。FedCM UI は条件付きでのみ表示されます。merchant.example
デベロッパーは、必要に応じて、ユーザーが ID プロバイダでログインしたときに FedCM プロンプトが自動的に表示されるようにするパッシブ モードと、ユーザーによるアクション（購入手続きボタンのクリックなど）後にログイン プロセスをトリガーするアクティブ モードを選択できます。
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 は自動的に独自のトップレベル クッキーにアクセスします。
その他の試験運用版ソリューション
このシナリオで役立つ可能性がある別の試験運用版 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 を使用してドメイン間の関係を宣言すると、よりスムーズなユーザー エクスペリエンスを提供できます。
同じ事業者が 5 つを超えるドメインにウィジェットを埋め込む場合、RWS は 1 つのプライマリ サイトと 5 つの関連サイトのセット内の最大 6 つのサイトのみをサポートしているため、埋め込みサイトとウィジェットのドメインの間の関連性を宣言することはできません。
スケーリングされたダッシュボードの配信
次のケースでは、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 は、ダッシュボードのレイアウトやフィルタなど、サイト固有の設定を保存する場合に便利です。
お支払い方法の管理
別の一般的なフローとして、ユーザーがホストサイトを離れることなく、埋め込み内でお支払い方法を表示、編集する方法があります。
次のフローについて考えてみましょう。
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 がブロックされている場合に不正行為の検出をサポートするには、不正行為検出ソリューションに Private State Tokens（PST）API を統合することを検討してください。PST を使用すると、決済プロバイダはトークン発行者として登録し、サードパーティ Cookie に依存しないトークンをユーザーに付与できます。これらのトークンは、販売者のサイトで利用して、ユーザーの信頼性を確認できます。実装の詳細については、PST デベロッパー向けドキュメントをご覧ください。
プライバシー サンドボックスでは、他の不正行為防止 API もテストされています。
パーソナライズされた購入手続きボタン
販売者のサイトに埋め込まれた支払いボタン（<優先するお支払い方法> で支払うなど）は、多くの場合、支払いプロバイダによって設定されたクロスサイト情報を使用します。これにより、パーソナライズが可能になり、ユーザーは希望するお支払い方法でスムーズに購入手続きを行えます。ユーザーのブラウザでサードパーティ Cookie がブロックされている場合、カスタマイズされた支払いボタンのレンダリングに影響する可能性があります。
SAA ではストレージへのアクセスを許可できますが、必要なプロンプトによってユーザー エクスペリエンスが損なわれる可能性があります。
Google では、このユースケースを具体的にターゲットとするソリューション（ローカルのパーティショニングされていないデータアクセスを使用したフェンスド フレーム）を検討しています。この API は現在開発中であり、今後の開発にご協力いただけます。ぜひお試しください。フィードバックをお寄せください。
ヘルプ
発生した不具合は goo.gle/report-3pc-broken にご報告ください。フィードバック フォームを送信するか、GitHub の プライバシー サンドボックスのデベロッパー サポート リポジトリで問題を報告することもできます。