サードパーティ Cookie の変更に対する Tray のアプローチ

Tray は、ブラジルの小売市場で 20 年以上の経験を持つ e コマース コンテンツ管理システム(CMS)プロバイダです。販売者は Tray's インフラストラクチャでオンライン ストアを運営します。このインフラストラクチャは、ビジネスの物流、支払い、プロモーション、レポートを管理するためのサービスと統合も提供します。

TrayLWSA グループのメンバーであり、e コマース分野の原動力となっています。Tray は 18 万人以上のクライアントに信頼されており、2024 年第 1 四半期の GMV の合計は 30 億米ドルを超えています。

tray.com.br ウェブサイトのホームページ

サードパーティ Cookie に依存した手法

Tray's 技術アーキテクチャでは、サードパーティ Cookie(3PC)を使用して、販売者のサイトにサードパーティ機能を提供します。特に、ストアの管理に使用される販売者のバックオフィス管理パネルに提供します。これらの Cookie は、販売者のドメイン以外のドメインでホストされているサードパーティ アプリケーションから配信されるコンテンツのレンダリングに不可欠です。Tray's の調査では、ブラウザが 3PC を処理する方法の計画的な変更により、この機能が中断される可能性があることが判明しました。Tray は多くのオンライン小売業者にとって重要なインフラストラクチャであるため、Chrome や他のブラウザで 3PC の処理方法が大幅に変更される場合でも、通常どおりビジネスを継続することが不可欠です。

このケーススタディでは、Tray's が潜在的な中断を検出し、考えられる解決策を評価し、サイトが 3PC への変更に対応できるように実装した成功したソリューションについて説明します。

技術的なアーキテクチャ

マイクロサービス

Tray は、すべてのストアフロント アプリケーションとバックオフィス アプリケーションをドメイン tray.com.br にホストします。販売者は CNAME を使用して、独自のカスタム ドメインからこれらのアプリケーションを提供できます。この設定では、買い物客にはショップのドメイン(merchant.example など)のみが表示されます。Tray は、マイクロサービス アーキテクチャを活用して機能と機能を提供します。このアプローチでは、それぞれ特定の機能に焦点を当てた独立した自己完結型のアプリケーションを使用します。これらのマイクロサービスは、機能に基づいてスコープにグループ化されます。

  • ストア: 商品の表示、検索、テーマ管理などのストアフロント機能を担当するアプリケーションが含まれます。
  • 購入フロー: ショッピング カート、購入手続き、購入経路での顧客とのやり取りを管理します。
  • ストア管理: 管理、レポート、データ インポートなどのタスク用のバックオフィス アプリケーションを提供します。
  • 統合: 外部プラットフォームとの接続を容易にし、ショッピングモール間のリスティングや物流の管理などを可能にします。

バックオフィス アプリケーション

バックオフィスは、ストア管理のコア アプリケーションであり、Tray で販売者の仮想ストアの中央管理パネルとして機能します。このパネルでは、販売者は以下を行うことができます。

  • 商品を登録する
  • 配送方法とお支払い方法を設定します
  • プロモーションを実施する
  • ライブ配信を管理する
  • 注文フローを管理する
  • 販売レポートをモニタリングする

Backoffice は、Tray によって運用されるものもあれば、サードパーティによって運用されるものもある、多くのマイクロサービスを 1 つのインターフェースにまとめているため、サードパーティ Cookie の処理方法の変更による中断の影響を受けやすくなります。

販売者のカスタマイズ用の CNAME

TrayCNAME レコードを使用して、ストアフロントをシームレスに統合します。

販売者は、新しいストアをセットアップするときに CNAME をセットアップして、Tray's ドメイン(tray.com.br)でホストされているアプリケーションにリクエストを転送できます。つまり、ユーザーが販売者のウェブサイト(example.com など)にアクセスすると、CNAME レコードによって Tray's ドメインにリダイレクトされますが、アドレスバーには販売者の URL が維持されます。これにより、販売者のウェブサイトから直接コンテンツが配信されているように見える、スムーズなユーザー エクスペリエンスが実現します。

CNAME について

CNAME レコードは、スマートフォンの通話転送と同様に機能します。555-0199 に電話をかけたが、友人が応答しなかったとします。通話は、555-0100 などの別の番号のボイスメールに転送される場合があります。ただし、呼び出し元は、このリダイレクトをまったく認識しません。スマートフォンはシームレスに接続されますが、ボイスメールの応答メッセージには、友人の元の電話番号(555-0199)が表示されます。

CNAME はウェブサイトでも同じように機能します。ユーザーが販売者のウェブサイト(example.com など)にアクセスすると、CNAME レコードによってリクエストが assets.example.com などの別のサーバーにリダイレクトされることがあります。ただし、ユーザーとブラウザの観点からは、すべて example.com で処理されます。アドレスバーには販売者の URL が表示され、ユーザーはコンテンツがそのドメインから直接発信されたかのようにウェブサイトを操作します。

サービス停止の可能性の評価

Tray's 3PC 処理の予定されている変更を分析した結果、バックオフィス アプリケーションの中断が明らかになりました。サードパーティ Cookie がブロックされている場合、バックエンド ページに埋め込まれた iframe 内の異なるドメインからページを読み込む際に問題が発生していました。これは、会社の独自のサービスに属する内部ドメインと、API を使用して Tray と統合するアプリケーションを開発する外部パートナーに適用されます。

たとえば、tray.com.br やその他のサードパーティがホストするコンテンツを埋め込んだ backoffice.merchant.example のページがあるとします。ブラウザは、ドメインが異なるため、この埋め込みコンテンツをサードパーティとして扱い、サードパーティに関する制限によって制限される可能性があります。

この設定では、次のような問題が発生する可能性があります。

  • セッションが破損する: 3PC がブロックされると、影響を受けるセッションが破損し、ユーザーが複数回ログインすることを要求してユーザー エクスペリエンスが断片化されたり、iframe の機能が停止したり、バックオフィス ページ内の不整合が生じたりすることが考えられます。
  • 統合の課題: API を使用して Tray's バックエンドと統合するパートナー アプリケーションと内部サービスは、サードパーティ製の制限により同様の困難に直面する可能性があります。

次の図は、このシナリオを示しています。

  • ユーザーが merchant.example でホストされているバックオフィス アプリケーションにアクセスします。
  • 埋め込みアプリケーションは異なるドメインに存在します。一部は Tray が所有する tray.com.br に存在し、一部はサードパーティ ベンダーのドメイン(third-party.example)に存在します。
  • このドメインの違いにより 3PC の制限がトリガーされ、埋め込みアプリで問題が発生する可能性があります。
CNAME の例を示す図: backoffice.merchant.example のウィジェットは CNAME を継承するため、すべて販売者のサイトと同じ SameSite になります

クリティカル ユーザー ジャーニーのテスト

Tray's テストと分析は、サードパーティとの統合と、多くのユーザーが 3PC を使用せずにブラウジングする将来への準備に重点を置いて、ウェブサイトのパフォーマンスとユーザー エクスペリエンスを改善することを目的としていました。

Tray は、プライバシー サンドボックス分析ツール(PSAT)と Chrome DevTools を使用して、顧客と販売者の主要なユーザーフローを分析しました。これには、iframe 内のページ読み込みのテスト、ユーザー セッションが有効なままであるかどうかの確認、サードパーティ製アプリケーションが引き続き想定どおりに機能することを確認することが含まれます。テストでは、さまざまなユーザーロール、デバイス、ブラウザ(Chrome、Firefox、Safari など)を対象に、ブラウザ間の互換性に関する潜在的な問題を特定しました。Tray は、PSAT と Chrome DevTools を使用して Cookie を分類し、ユーザー エクスペリエンスへの影響を評価しました。

この分析は、サードパーティ Cookie が制限または使用できなくなる将来に備え、スムーズで一貫したユーザー エクスペリエンスを確保するための重要なステップでした。

プライバシー サンドボックス ソリューションの分析

Storage Access API

Storage Access API(SAA)は Tray's の中断に対処する可能性があり、すべての主要ブラウザでサポートされていますが、主に次の 2 つの理由から、ビジネスには最適ではありませんでした。

  1. 埋め込まれたコンテンツは、埋め込まれたオリジンの Cookie にのみアクセスする必要があり、複数のサイトにまたがる同じ Cookie にアクセスする必要はありませんでした。
  2. SAA に関連付けられたブラウザ プロンプトは、特に Cookie がサイト間でユーザーをトラッキングするために使用されていないため、理想的ではありませんでした。

CHIPS

CHIPS は、クロスサイト埋め込みに優れたユーザー エクスペリエンスを提供する強力なソリューションでした。Partitioned 属性は実装が簡単で、Chrome のユーザーの操作に目立った影響はありませんでした。Tray がサービスを変更した時点で、CHIPS は他の主要なブラウザでサポートされていなかったため、Tray は、ブラウザ間で一貫したエクスペリエンスを提供するために、所有および運営する埋め込みをトップレベル アプリケーションと同じサイトに移動することを選択しました。サードパーティの埋め込みコンテンツは Chrome の CHIPS に依存し、他のブラウザでは新しいウィンドウ(ファーストパーティ コンテキスト)を開きます。ただし、Tray's の初期実装以降、Firefox は CHIPS をまもなくリリースする予定を確認しており、Safari は Technology Preview から Partitioned 属性のサポートを追加し始めています。

CHIPS は優れたソリューションだと考えていましたが、複数のブラウザで採用されたことを嬉しく思います。Google は、ファーストパーティのサイトに移行するだけでなく、CHIPS ソリューションを維持することで、すべてのブラウザが CHIPS を採用する前からサポートできるようにしました。

- Tray CTO の田中隆氏

ブラウザの互換性、W3C、標準

Chrome は標準化コミュニティにおいて重要な役割を果たしています。新しいウェブ技術を広範なブラウザ エコシステムに導入するには、W3C のワーキング グループコミュニティ グループPrivacyCG など)に積極的に参加することが重要です。

プライバシー サンドボックスはウェブ エコシステムと連携し、業界からのフィードバックとエンゲージメントに基づいて CHIPS などの API を継続的に進化させています。この透明性の高い標準主導のアプローチは、他の主要ブラウザでの CHIPS の採用を促進するうえで重要な役割を果たしてきました。

Tray は、あらゆる種類のデバイスとブラウザで販売者とその顧客をサポートします。CHIPS のみをベースとしたアプローチが望ましかったものの、当時 CHIPS をサポートしていなかった他のブラウザをサポートするために、追加の変更も行われました。

Tray's アプローチでは、3PC が使用できない場合に発生する中断に対処するために、主に 2 つの戦略が使用されています。

1. 社内向けアプリケーション

ライブショップ、ドロップシッピング、請求書発行者など、完全に運用されている Tray マイクロサービスが更新され、埋め込みコンテンツのソースが販売者によって設定された CNAME を継承するようになりました。簡単に言うと、埋め込みコンテンツが更新され、埋め込み先のページとともにファーストパーティのものになりました。これにより、サードパーティ Cookie の変更による中断が回避されました。

2. サードパーティ製アプリ

Backoffice からアクセスするサードパーティ アプリケーションの場合、Tray はより動的アプローチを実装しました。仕組みは次のとおりです。

  • パーティション化された属性の実装: Partitioned Cookie 属性の実装は信頼できるベンダー向けに維持され、サードパーティ アプリは CHIPS をサポートするブラウザに Cookie を効果的に設定できるようになりました。
  • サードパーティ Cookie がブロックされている場合: ユーザーのブラウザで 3PC がブロックされている場合、サードパーティ アプリケーションは新しい(ファーストパーティ)ウィンドウで開きます。これにより、開く際の問題を回避し、3PC の制限があっても継続的に動作できます。
  • サードパーティ Cookie が許可されている場合: ユーザーのブラウザで 3PC が許可されている場合、アプリケーションは引き続き iframe 内で開きます。

ソリューションを可視化する

次の図は、このソリューションを示しています。ストアのメインドメイン(merchant.example)を継承することで、埋め込まれたすべてのアプリが同じソースから発信されたものとして認識されます。これにより、すべてのウィジェットが相互にファーストパーティとなり、サードパーティ Cookie の制限が考慮されなくなります。これらのフレームはすべて相互にファーストパーティになるため、プライバシー原則は他のファーストパーティ Cookie と同じになります。つまり、ファーストパーティのコンテキストでのみアクセス可能で、クロスサイト トラッキングを制限します。

Tray が所有していないサードパーティ サービスは、Partitioned 属性を使用して CHIPS Cookie を設定します。つまり、設定されたコンテキストでのみアクセス可能であり、クロスサイト トラッキングを制限します。

CHIPS の例を示した図: ファーストパーティ ドメインに移動されたウィジェットはファーストパーティ Cookie ジャーにアクセスできます。サードパーティ ウィジェットはパーティション化された Cookie ジャーを使用します。

要点

  • ウェブ上のプライバシーには万能なソリューションはありません。プライバシーを保護しながら、スムーズなユーザー エクスペリエンスを実現する方法は数多くあります。
  • リソースを同じトップレベル ドメインに統合すると、サードパーティ Cookie の制限があっても Cookie を機能させることができます。
  • CHIPS は、すべてのリソースを同じトップレベル サイトに移行するよりも簡単なソリューションになる場合があります。
  • Tray's ソリューションは持続可能で、ブラウザ間で機能します。CHIPS のサポートを追加のブラウザが実装するにつれて、Tray's などのシナリオで信頼できるクロスブラウザ ソリューションと見なされるようになります。