カスタマーレプリゼンタティブチームの高見 翔です
今回は、”はじめてのCookie”と題して、「なんとなく知っているけどちゃんと理解できているか不安」、「デジマに関わることになったけど、デジタル分野での仕事はゼロからスタート」といった方に向けて、ちょっと周りには聞きにくいかもしれないCookieの初期知識からTreasure Data CDPを利用した活用シーンをご紹介します。
実際にご契約企業様のご担当の方でも、元々リアルの広告やマーケティング部門で活躍されていて、自社のデジタル強化にあたって役割変更されてくる方もいらっしゃいます。
また、「十分理解している」という方には”新しいメンバーに説明する素材”として活用いただけたら幸いです。
Cookieとは
WebブラウザとWebサーバのやりとりに使われるファイルのこと
いきなり“？”が浮かぶ方もいるかもしれないですが、前提知識としてふんわり理解していただければ大丈夫です。例えば、私がAmazonのURLをクリックすると、WebブラウザからAmazonのWebサーバに「サイト見せて」とリクエストが飛びます。するとWebサーバはそのリクエストへOKを出すとともにCookieを渡します。Webブラウザ毎に違うCookie番号が渡されているので名札のような役割を果たします。
その後、サイトから離脱して後日改めてAmazonを見る時に、Webブラウザが前もらったCookie（名札）をリクエストと一緒にWebサーバへ渡すことで、「あ、この人（ブラウザ）が来たの2回目だ。前にこんな商品見ていたんだ」とWebサーバが把握することができるのです。
Cookieは”本質的には”みんなにとって便利で快適さを提供する仕組み
例えば以下のような便利なことに使われています。
- CookieによるSession管理によって、（Session保持中であれば）ID、Passwordを都度入力しなくても済む
- Amazonで見ていた商品やカートに入れていた商品を次来た時にわかる
- Webサーバ（Amazon側）の目線だと、「この人（ブラウザ）はキャットフードを定期的に買ってるな。だったら猫砂もおすすめしてみよう」といったことができる
似たような仕組みとして広告ID（IDFA、ADID/AAID）
CookieがWebブラウザとWebサーバ間での名札なのに対し、アプリとスマートフォン・タブレット端末などのデバイス端末間でやりとりされる名札のことを広告IDと呼びます。Cookieはブラウザ単位での発行ですが、広告IDはデバイス端末単位でユニークなものです。
IDFA：iOS端末で振られるID
ADID/AAID：Android端末で振られるID
Cookieの種類、違い
Cookieには2種類あります。仕組みの違いは“どのWebサーバから発行されるか？”です。
1st Party Cookie
訪問先のサイト（Webサーバ）から発行されるCookie。最初にご説明したAmazonを訪問した際にAmazonから発行されるCookieです。“一度発行されると消えにくい“という特徴がありますが、”ドメインを跨ぐと別のIDが発行される“ためサイトを横断した行動分析などには使えません。
3rd Party Cookie
訪問先のサイト（Webサーバ）ではない第三者サーバから発行されるCookie。例えば、みなさんの会社HPやサービスページに広告効果を図るためにJavaScriptタグを設置されていると思いますが、これらは各広告企業のWebサーバから発行される3rd Party Cookieとなります。“ドメインを跨いでも同じIDが発行される”ので、サイト横断の分析や外部データと紐づけることが可能です。※ただし個人情報保護の観点で使い方には注意が必要です（後述記載）
Treasure Data CDP（TD JS SDK）で取得可能なCookieの種類
トレジャーデータから提供しているJavaScriptタグを設置いただくことで3種類のCookieが取得可能です。
- 1st Party Cookieにあたるもの：td_ssc_id 、td_client_id
- 3rd Party Cookieにあたるもの：td_global_id
1st Party Cookieにあたるものが2種類ありますが、td_ssc_idは近年話題に上がっているApple社のITP（後述記載）に対応するものとして提供を開始しました。
td_client_idの場合、現在、SafariブラウザでのCookie有効期限が1日のところ、td_ssc_idは従来通り2年という有効期限で発行されます。発行にはタグ設置に加えて、Treasure Data CDPから発行するNSレコードの設定が必要になります。弊社カスタマーサクセスまでご相談ください。また、td_ssc_idの仕組み・活用方法についてはこちらの記事をご参照ください。
Treasure Data CDPでのCookie活用シーン
実際のユースケースとともに、どうCookieが使われているかご紹介します。
【Case1】サイト訪問情報などの行動データをtd_client_id、td_ssc_idで時系列データとして蓄積。更に購買など会員情報と統合することで詳細な顧客の実情を分析。施策の仮説をつくる。
1st Party Cookie （td_client_id、td_ssc_id）は保持期間が長いのでユーザーの長期間におけるサイト内行動データを時系列に分析することができます。また、会員登録機能があるサービスであればログイン時にCookieと会員IDを紐づけることで、例えば、“店舗で購買していたユーザーが実は前日にサイトでその商品情報を閲覧していた”ということがわかります。施策視点で考えると、“サイトで同じ商品を定期的に閲覧しているが、まだ購買が起きていないユーザー”に対して対象商品のセール情報をDMすることで店舗行動の促すことも期待できます。
【Case2】上記の統合されたデータをベースにのデータをベースに、アンケートデータやパブリックDMP・提携企業などのデータをtd_global_idで紐付けることによって顧客をより鮮明に理解し、広告配信ツール等と連携してアプローチを実施。
1st Party Cookie （td_client_id、td_ssc_id）はドメイン単位で発行されるため、サイト外部での行動を把握することができません。対して、3rd Party Cookie（td_global_id）はドメインを跨いでもブラウザ単位で同じIDが発行されるため、Treasure Data CDPのタグが入っている外部サイトのデータと紐づけ、自社ドメインでは把握できない顧客の属性や趣味・嗜好を取得し、新たな顧客セグメント作成と打ち手を考案することができます。ただし、3rd Party Cookieの利用については2点注意いただく必要があります。
- 改正個人情報保護（2022年施行予定）
- Apple、GoogleによるCookie規制対応
これにより“提供先において個人データとなることが想定される情報の第三者提供について、本人同意が得られていること等の確認”が必須となります。まだ施工はされていませんが、もし、外部データとの連携を検討している場合はプライバリーポリシーの見直し等、顧客への配慮を十分に考慮いただく必要があります。
Apple社はSafariブラウザ（ITP対応）では、現時点で3rd party Cookie （td_global_id）は即時破棄されてしまいます。また、Googleも2022年目標でのChromeブラウザにおける3rd Party Cookieのサポート終了を発表しております。
そのため、今後は3rd Party Cookie（td_global_id）に頼らない＝自社ドメインでどうデータを集めていくかが重要になると考えています。
例えば、自社でオウンドメディアを持ちユーザーとの接点を増やす（＝新規サービス立ち上げとなると相応の労力がかかる）、会員登録の仕組みを設けて顧客情報を登録してもらう（＝そのためには登録するモチベーションを作る必要あり）、LINEなどユーザーとの接点をもてるプラットフォームをコミュニケーション基盤にする等、簡単に実現するものではないかもしれないですが、だからこそ今のうちから準備を進めていく必要があります。
3rd Party Cookie（td_global_id）に頼らない活用方法アイデア、法規制への対応等、もし悩まれていることありましたら担当のカスタマーサクセスまでご相談ください。
