Treasure Data CDP<第9弾>Server Side 1st Party Cookieのご紹介
投稿者: Treasure Data担当者
![](https://storage.googleapis.com/website1-prd-wordpress-bkt/1/2023/06/treasuredata_techblog_eyecatch-1024x538.jpg)
NI+C マーケソリューションチームです:)
本Tech Blogでは、NI+Cで取り扱っているTreasure Data CDPを紹介していきます。
今回は、Treasure Data CDPが提供するServer Side 1st Party Cookieの概要、導入方法について紹介します。
Cookieの規制強化がより進行している昨今ですが、直近ではSafari 16.4のアップデートにて、トラッキング対象ドメインとCookie発行ドメインのIPアドレスレンジが異なる場合、1st Party Cookieであっても有効期限が7日となる変更が行われたようです。
Client Side 1st Party Cookie規制強化への対応策のひとつとして、トラッキング対象ドメインと同じドメインのサーバで発行したCookieを利用することで有効期限を延ばすことができていましたが、この方策もいよいよ規制対象となったわけです。
この方式を採用する様々な他社サービスと同様、今回ご紹介するTreasure Data CDPのServer Side 1st Party Cookieもこの変更の影響を受け、これまで有効期限が2年間であったのが、Safari 16.4ではこの変更により7日となってしまいました。(Safari 16.4と同じWebKitバージョンを利用する他のブラウザも同様です。)
とはいえ、Server Side 1st Party Cookieには依然としてClient Side 1st Party Cookieにはない強みがありますので、この記事で是非ご興味を持っていただければと思います。
Server Side 1st Party Cookieの利用メリット
Treasure Data CDPで発行可能なCookieは以下の3種類があります。(2023年4月6日現在)
![](https://storage.googleapis.com/website1-prd-wordpress-bkt/1/2023/06/treasuredata_ssc_cookie-1024x507.png)
Client 1st Party Cookie、Server Side 1st Party CookieともにSafari(iOS)では有効期限が7日となりますが、Client 1st Party Cookieの場合は4つの条件に該当する場合、有効期限が24時間に制限されます。
Server Side 1st Party Cookieの場合はその制限が適用されない点が、Server Side 1st Party Cookieを利用するメリットとなります。
仕組み
Server Side 1st Party Cookieの発行からTreasure Data CDPへの保存までの仕組みは下図の通りです。
![](https://storage.googleapis.com/website1-prd-wordpress-bkt/1/2023/06/treasuredata_ssc_flow-1024x289.png)
Treasure Data Java Script SDK(以降、TD JS SDK)、およびServer Side 1st Party Cookieを取得する為のJava Scriptコードを実装したサイトにユーザがアクセスすると、Webサイトと同じドメインを持つTreasure Data側Cookie発行サーバにリクエストが送信されます。(①②)
Treasure Data側サーバでは新たにCookieを発行してブラウザに戻します。(③)
戻されたCookieは、TD JS SDKにてTreasure Data側に送信され、テーブルに保存されます。(④)
Webサイトのドメインに対するCookie発行リクエストをTreasure Data側サーバに転送する必要がありますので、Webサイトのドメインを管理するDNSサーバにNSレコードを設定する必要があります。(設定内容はTreasure Data社から提供されます)
実装の流れ
Server Side 1st Party Cookieの実装は、以下のような流れで行います。
- 利用者側にて、Web行動ログの収集対象ドメイン、およびTreasure Data側Cookie発行サーバ用のサブドメインを決定します。(仕組みの図の場合、example.comが対象ドメイン、ssc.example.comがTreasure Data側サブドメイン)
- Treasure Dataにて、Treasure Data側Cookie発行サーバのセットアップを行います。また、利用者側へ、DNSサーバに登録するための情報を提供します。(このステップは最長で5営業日程度)
- 利用者側にて、Treasure Dataから提供された情報をDNSサーバに登録します。
- Treasure Dataにて、DNSサーバへ正しく登録されたことの確認などを行います。
- 利用者側にて、TD JS SDKおよびServer Side 1st Party Cookieを取得するJava Scriptコードを実装し、疎通確認を行います。想定通りWeb行動ログおよびCookieがテーブルに記録されれば、実装完了となります。
Webサイト側のJava Script実装コード例
Webサイト側には以下のようなJava Scriptコードを設置します。
記述の意味などはコメントで補足説明を入れておりますが、詳細な情報および最新のSDKはgithubで公開されております。
<script type="text/javascript">
// Treasure Data JavaScript SDK本体
!function(t,e){if(void 0===e[t]){e[t]=function(){e[t].clients.push(this),this._init=[Array.prototype.slice.call(arguments)]},e[t].clients=[];for(var r=["addRecord","blockEvents","fetchServerCookie","fetchGlobalID","fetchUserSegments","resetUUID","ready","setSignedMode","setAnonymousMode","set","trackEvent","trackPageview","trackClicks","unblockEvents"],s=0;s<r.length;s++){var c=r[s];e[t].prototype[c]=function(t){return function(){return this["_"+t]=this["_"+t]||[],this["_"+t].push(Array.prototype.slice.call(arguments)),this}}(c)}var n=document.createElement("script"),o=(n.type="text/javascript",n.async=!0,n.src=("https:"===document.location.protocol?"https:":"http:")+"//cdn.treasuredata.com/sdk/4.0/td.min.js",document.getElementsByTagName("script")[0]);o.parentNode.insertBefore(n,o)}}("Treasure",this);
</script>
<script type="text/javascript">
// Webログを取得するための記述
var td = new Treasure({
// Webログ記録先データベース名
database:'database_name',
// Treasure DataのWrite-Only API Key
writeKey: 'write-only–key',
// Treasure Data側Endpoint(利用リージョンにより異なる。SDK4.0よりEndpointが変更)
host: 'ap01.records.in.treasuredata.com',
// Cookieを取得する場合、匿名付きモードを有効化。同意取得後に設定する方法もあり
startInSignedMode: true,
// 計測対象ドメイン
sscDomain: 'example.com',
// Cookie発行サーバ用サブドメイン
sscServer: 'ssc.example.com',
// Server Side 1st Party Cookieを収集する場合trueを設定
useServerSideCookie: true
});
// Server Side 1st Party Cookieの取得要求
td.fetchServerCookie(successCallback, errorCallback);
// Webログの記録を実行
function fireEvents () {
// 記録先テーブル名を指定
td.trackPageview('pageviews');
}
// Server Side 1st Party Cookie取得成功時実行
function successCallback (result) {
// Webログ記録項目としてServer Side 1st Party Cookieを設定(result=取得したCookieの値)
// WebサイトのログインIDなども同様の方法で設定することで、
//Webログの同じレコードにCookieとログインIDなどを記録可能
td.set('$global', { td_ssc_id: result });
fireEvents();
}
// Server Side 1st Party Cookie取得失敗時実行(失敗してもWebログの記録は実行可能)
function errorCallback () {
fireEvents();
}
</script>
上記コードを設置したWebサイトにアクセスすると、1回ごとにTreasure Data CDPに1レコードのWebログが記録され、Server Side 1st Party Cookieが「td_ssc_id」カラムに設定されます。
![](https://storage.googleapis.com/website1-prd-wordpress-bkt/1/2023/06/treasuredata_ssc_sampledata-1024x201.png)
最後に
Server Side 1st Party Cookie、いかがでしたでしょうか。
今後は企業が持つ1st Party Dataの活用や、データクリーンルームなどの新しいサービスによる施策展開がより進むものと考えられますが、一方でCookieが持つ、点としてのWeb行動を線としてつなげて見るためのキーとしての役割は依然として有力であり、当面その状況は変わらないと考えます。
折角使うのであればより役に立つものを、ということで、Treasure Data CDPが提供するServer Side 1st Party Cookieのご利用をご検討頂ければ幸いです。
ご興味を持たれた方はぜひ「こちら」からお問い合わせください
その他、Treasure Data CDP についての記事はこちら↓
セグメント作成について↓↓
Treasure Data CDP <第1弾>Audience Studio の機能でセグメント作成してみた!!
Activationについて↓↓
Treasure Data CDP <第2弾>Audience Studio の機能 Activation を使ってみた!
Predictive Scoring について↓↓
Treasure Data CDP <第3弾>Predictive Scoring のご紹介
データのインポートについて↓↓
Treasure Data CDP <第4弾>Treasure Data にデータをインポートしてみた
SQLを使ったデータの抽出方法について↓↓
Treasure Data CDP<第5弾>SQL を使ってデータ抽出してみた!
Treasure Workflowについて(前編)↓↓
Treasure Data CDP<第6弾>Treasure Workflow とは(前編)
Treasure Workflowについて(後編)↓↓
Treasure Data CDP<第7弾>Treasure Workflow とは(後編)
新機能 ジャーニーオーケストレーションについて↓↓
Treasure Data CDP<第8弾>新機能 ジャーニーオーケストレーション ご紹介