プロダクトスタック

概要

ここでは各種Cxense製品のコンセプトやその間にある依存関係について説明していきます。これは技術者の方が チュートリアルとサンプルコード で技術的かつ詳細なものを確認する前の、全体概要を把握するためのドキュメントです。技術者ではない方が技術に関する理解を進めていただくのにも役立ちます。 

基本的

Cxenseや他の企業はオンラインで発信されている情報にアクセスしてくる訪問者をどのようにトラッキング、管理しているのでしょうか？簡潔に言えばそれは、Cookie や ユーザーやトラフィックデータをトラッキングしてレポーティングするためのピクセルリクエストを分析用スクリプトとしてサイトに設置することで実現されます。ユーザートラッキングに関する基本的なことについて学んでいくために以下のことを説明していきます。

• Cookies

• ピクセルリクエスト

• 分析用スクリプト

• ページビューイベント

• クロスドメインのユーザートラッキング

Cookieとは何か？

CookieはあなたのブラウザがPC上に保存する小さなテキストファイルです。訪問しているサイト別に Cookie をいくつも持っていることもあれば、ないこともあります。Cookieにはあなたがそのサイトに来訪した際の情報が残っています。あなたは次回そのサイトに訪問した際、その情報を使ってサイトへアクセスすることができます。とある大学であなたが40ページものオンラインテストをしなければならないと想像してみましょう。テストをすべて終了させるには数日かかります。その間に睡眠をとったり、食料品を買ったり、他のこともしなければならず、ログアウトすることになります。ブラウザがCookieを持っていることによって、大学はあなたがテストのどのページまで到達したかを保存して、戻ってきた時に正しいページからテストを再開させることができます。

Cookieはキーと値の組み合わせのリストです。大学の試験のCookieは'page' と名前のついた1つのキーと共にあなたがいたページをトラッキングし続けるために  '21' という値を、テストを5日で完了しなければならないとした時にはあなたがいつテストを開始したのかをトラッキングするために 'start' というキーに '2016-07-21 12:43:08' という値を持っています。　

多くのサイトでは非常に大きな無作為な数値を 'Cookie ID' や 'ユーザーID' と呼ばれる1つのCookie キーに割り当てています。その値はCookieが作成される初回訪問時に割り当てられ、その後に変更されることはありません。このIDがあることによって、そのサイトはあなたが1回訪問してから次に訪問されるまでを認識できるようになり、望むならそのサイト上でのすべての行動をトラッキングし、データベース上にその情報を保管しているかもしれません。そしてあなたの過去の利用（過去の購入、過去に読んだ記事など）を基準にして、あなたに対してどのように反映させていくかのビジネスルールを持つことができます。

ピクセルリクエストとは何か？

まずはピクセルとは何かを思い出していきましょう。ピクセルとは画像の最小コンポーネントです。
画像のサイズは保持しているピクセル数で決まります。例えば 250 x 200 ピクセルのパスポート写真は 50,000ピクセルが含まれており、各々のピクセルには全体イメージ内で表されるポイントの色（白黒の場合はグレートーン）を表す値を保持しています。 

マイクロソフトやGoogleのような企業がブラウザを実装する際に、インターネットプロトコルやインターネット標準で定義された規則を尊重しています。そのような規則として、他のドメインからのWebコンテンツは混在できませんし、訪問されたサイトのドメイン外部のサイトで他の通信をすることはできません。
つまり、 http://www.ourSite.com (ourSite.com がドメイン）というサイトを見に行っていたとして、
ダウンロードするページは http://www.theirSite.com（theirSite.comが他のドメイン）のWebコンテンツを持つことはできません。それをやろうとしても、ブラウザはクロスドメインエラーというフラグが立って、ウェブページの実行を停止するでしょう。 これは他のサイトにウェブセッションが引き継がれ、銀行やクレジットカード会社のふりをして行われるフィッシング攻撃から私たちを守るためには大変重要なことです。

但し幾つかの例外もあり、その1つが他のドメインから画像をダウンロードできることです。つまり http://ourSite.com/ourPage.html というWebページは前述のエラーによって停止させられることなく、http://theirSite.com/theirImage.jpg という画像を参照することができるのです。ここで今、私たちは2つの違うドメイン上で2つの違うWebサーバーのWebページが通信する方法を確認できました。イメージリクエストURLにパラメーターをつけることによって、私たちはサードパーティのサーバーに情報を配信したり、この通信フォームを使う時の帯域を減らしたりできます。1x1ピクセルサイズの画像を使うことができます。そして、この技術が「ピクセルリクエスト」という名前を持っています。私たちは関係のない単一のピクセルイメージを要求しています。しかしながら、そのリクエストが不要なイメージピクセルを付与するサーバーに対して、データを渡す許可を与えています。

上の図では publisher.com と tracker.com  という2つのサイトがあります。前者は Cxenseの顧客に多い出版社です。後者は Cxenseのようなユーザーをトラッキングすることに特化した企業です。ユーザーが http://publisher.com 上のWebページの1つに行くと、ブラウザがそれをダウンロードしてきます。そのページ内で私たちはこのようなピクセルリクエストを確認することができます。

<img src="http://tracker.com/pixel.gif?id=1234&loc=uk"> 

ピクセルリクエストに付け加えられているパラメータはユーザーのID(上述のCookie ID)を、
そしてユーザーがページにアクセスしている物理的な場所をどのように含めているか、に注目してください。パラメータは http://tracker.com  によって拾い上げられ、ユーザーをトラッキングしているデータベースに格納されます。

ユーザーについての情報をレポートするためのピクセルリクエストを使う技術は他の名称もあり、
一般的に「ピクセルトラッキング」や「ウェブビーコン」とも呼ばれています。

分析用スクリプトとは何か?

上のページではHTML内にトラッキングピクセルがハードコードされていました。IDや位置情報のパラメータはPHPなどのサーバーサイドにあるスクリプト言語によって付与されることもありますが、ピクセルリクエストと同時にHTMLコードラインがブラウザに到達するとき、それは静的なHTMLです。 しかしながら、 レポートしたい情報のいくつかがページがダウンロードされた後までわからないということもあります。
例えば、 ページ上でユーザーがどのくらいの距離をスクロールダウンしたかをレポートしたい場合、それはそのページがレンダリングされるまでわかりません。このケースで、その情報は少し時間が経ってから動的にピクセルリクエストへ追加する必要があります。こうした理由から、望む情報を取得してピクセルリクエストを作成するために、クライアントサイドのJavaScriptを使うことが一般的になっています。 

JavaScriptタグで生成するピクセルリクエストの非常に簡易なバージョンを以下に示します。

<script type="text/javascript">
	function sendPageViewEvent(userId, location) {
    	new Image().src = 'http://tracker.com/pixel.gif?id=' + userId + '&loc=' + location;
	}
 
	var id = readCookieIdValue('ourCookie')
    var location = getUserLocation();
    sendPageViewEvent(id, location)
</script>

情報をレポートするだけでなく、レポートにする前に情報を集めて、できる限り処理する、このようなスクリプトが分析用スクリプトと言われています。Cxenseでは分析用スクリプトのことを Cxenseスクリプトや別称として Cxenseタグ（上で見たように、JavaScriptタグを使ってデプロイしていることから）と呼んでいます。

ページビューイベントとは何か?

ページビューイベントとは分析用スクリプトを含んだWebページへのユーザー訪問であり、ピクセルリクエストを介してトラッキングサーバーにアップロードされるユーザーとユーザーの訪問に関する情報を発生させます。次のいくつかのセクションで明らかになるように、全ての Cxense製品はページビューイベント収集と処理に際して、一方向またはリレーしつつ、アウトプットを生成しています。

ドメインをまたがったユーザーのトラッキングはどのようにするか?

質問に答える前に、ドメインとは何であったかを思い出してみましょう。2つのサーバー(http://www.ibm.com  と http://www.usatoday.com )は同じトップレベルドメインの .com ですが、異なるドメインでもあります。もしも、もう一つ ( test.ibm.com )というサーバーがあったとします。そのサーバーは http://www.ibm.com  と同じドメインにあります。一般的にドメインはウェブサイトアドレス（例えば、 http://www.voegol.com.br  は http://voegol.com.br )は最初のピリオドの後に続いています。  

上の問いに答える前にもう一つ知るべきことは、ファーストパーティとサードパーティCookieの間には違いがあるということです。ある人が someDomain.com に訪問し、ブラウザは正しいドメイン名（ブラウザのアドレスバーに示されているものと同じ）と一緒にCookieを残します。それがファーストパーティCookieです。もしも代わりに他のドメイン名のCookieが残っていたら、それはサードパーティCookieです。

私たちは下のようにユーザーがファーストパーティCookieとサードパーティCookieの両方をトラッキングする、2つのドメインに訪問した後、どのように3つのCookieが残るのかを確認できます。

全体を通じて1つの問題があります。サードパーティCookieはユーザーだけにではなく、アンチスパイウェアのプログラムにもブロックされています。多くのサイトでログインするために不可欠なファーストパーティCookieとは違い、サードパーティCookieを拒否することはネットサーフィンに悪影響をもたらすことはありません。ファーストパーティCookieの拒否率は5%未満とされているのに対して、サードパーティCookieの拒否率は20-50%にもなります。いくつかのブラウザ（例えば、Safari）やいくつかのOS(例えば、iOS)はサードパーティCookieを全くサポートしていません。

Cxense はサードパーティCookieの制約を克服する方法を持っています。例えばサイトのページがHTML5の場合にサードパーティCookieの代わりにブラウザのローカルストレージを使用できます。しかしそのアプローチをブロックしている Safari の場合、パブリッシャーのドメインからトラッカーのドメインにリダイレクトするスクリプトをデプロイでき、（まだ存在していない）ファーストパーティcookieが作られていれば元のサイトにリダイレクトされます。このようにしてファーストパーティクッキーであったかのように、サードパーティクッキーの制約をバイパスすることができます。

全体像

上の図で、Cxenseが3つの層のプロダクトスタックでデータを収集しており、その一番上にCxenseプロダクトが提供されているのが確認できます。左側でデータを収集する元となるのは、サードパーティデータ（サードパーティデータを提供する企業のユーザーデータ）はもちろん、トラフィックイベント（ユーザー訪問がWebページでトラッキングされる）、コンテンツの取得（Cxenseクローラーが訪問したページから抽出）、ファーストパーティデータ（通常は顧客のCRMシステムにある購読や申込のデータ）です。青のボックスはCxenseの各製品を指しており、Insight、Content、DMP、Searchです。Data Store とそのデータにアクセスするためのAPIを備えた基盤となるプラットフォームはEIE(Extraordinary Insight Engine)と呼ばれています。

全ての最上位レベルのコンポーネントはデータストアからデータ抽出をしたり、データストアにデータをプッシュするためにCxense APIを中継します。

Cxenseデータストア

以下の図で示されているのはCxenseデータストアの内部構造です。2種類のストレージがあり、それは一番左側にある検索インデックスと右側にあるその他すべてのデータキューブです。 

キューブ

スピーディーなソート、フィルタリング、検索のために、データストレージは列で構成されています。
このような形態は 列ストアインデックス や キューブ と呼ばれます。Cxenseではデータストレージを呼ぶ時に、後者の名称を使います。

各々のキューブがデータベーステーブル（コンテンツテーブル、ユーザーテーブル、イベントテーブルなど）に対応し、各々のセルが格納されている値と同様に、それに属するレコード（行）のIDの両方を保持しています。一つの列にある全ての値が同じデータ型であるため、非常に効率的な配列操作が実行でき、結果セットのレコード（行）IDは値と共に格納されるので、非常に素早く取得することができます。

LTS

データが格納される量を減らすために、ほとんどのイベントデータは31日後に削除されます。すべてのデータを長期保存する必要がある場合、任意の設定期間でサイトごとに LTS(Long Term Storage) を購入することができます。 

上の図ではページビューイベントが31日よりも古いものはCxenseデータストア（赤い×印は期間が経つとデータにアクセスできなくなることを示しています）には格納されなくなるというデフォルトの動作とお客様がLTSを購入することによって、データベースの保存期間を拡張できるということを示しています。

よくある誤解は、LTSを有効にすることで既に有効期間を過ぎたデータを取り戻すことができたり、
その時点で格納されているデータ全ての保存期間が拡張される。というものです。LTSの有効化は未来のイベントにのみ影響を与えます。既に削除されたデータは取り戻せませんし、現在格納されているイベントは31日以降で削除されます。 上の図にある N日前にLTSを有効にしたとすると、左から2番目のイベントは31日以降で削除されることに変わりはなく、右側の2つのイベントもやはり31日以降に削除されます。将来のイベント（LTSが有効になった瞬間から開始）のみが、拡張された保存期間になります。 

サーチインデックス

キューブによるアプローチの例外があります。それはクロールされた（またはカスタマーにプッシュされた）コンテンツがインデックスされた検索インデックスです。このため、追加のCxense機能にそれらをラップして Lucene ベースの検索エンジンである Elasticsearch を使っています。 

データ管理構造

カスタマーオブジェクト

下の図では主なデータを編成するオブジェクトを確認できます。顧客が見たり、アクセスすることができないオブジェクト（上のグレーの箇所）から見ていきましょうまず顧客あたりに1つのカスタマーオブジェクトがあります。それはCxenseの内部CRMシステムである Salesforce(Salesforce ID) から参照し、保持しています。また、顧客が自分のサイトグループにアクセスを許可するユーザーのプール（保管領域）と同じように、顧客のサイトグループのいずれかに割り当てられるカスタマープリフィックスのプールを保持しています（カスタマープリフィックスはキーと値の組み合わせのキーの方に付く顧客ごとの接頭語として使われます）。これによって、異なる顧客や同じ顧客で異なるサイトグループで、データを混在しません。例えば、サードパーティユーザーデータの "profession(職業)" のキーは IBMが顧客の場合は ibm-profession  のように、ウォールストリートジャーナルが顧客の場合は wsj-profession のように呼ばれます。このようにして、IBMとウォールストリートジャーナルのデータはどちらもキーとして "profession" が使われてたとしても、各々で保持することが可能となります。ユーザーの領域はカスタマーオブジェクトにマップされているユーザー群です。ユーザーは1人が1つの Customer にのみにしかマップされません。

赤い線はあるシステムから他のシステムにデータがコピーされていることを示しています。例えばCustomer name はSalesforceからカスタマーオブジェクトにコピーされますが、一方で Customer id は反対にSalesforce にコピーされます。

サイトグループオブジェクト

次に上の図で(Cxenseだけでなく）顧客がアクセスする下の方のグレーの箇所に移ります。この箇所の主なオブジェクトはサイトグループです。顧客はサイトを追加したり、サイトグループを使ってユーザーアクセスを許可します。 

サイトへのアクセスはサイトグループを介して制御され、サイトグループはいくつかのサイトと一緒に子サイトグループを保持できます。下の図はどのようにユーザーにデータが見えるようになっているかを示しています。サイトグループ B にアクセス権を持つユーザーはサイト a を除く全てのサイトにアクセス権を持っていますが（ユーザーはサイトグループ A へのアクセス権を持っていないため）、サイトグループ X にアクセス権を持つユーザーはそのサイトグループのメンバーである3つのサイト（x,y,z)のみを見ることができます。 

サイトオブジェクト

サイトはゼロまたは1以上のサイトグループの一部とすることができ、それは実際に存在しているウェブサイトに関する情報を保持しているオブジェクトのことです。いわゆる、WebサイトURLやサイト固有の制限（トラッキングできるユーザーの最大数やクロールできるページ数）、そのサイトやそのユーザーに関して収集される全てのデータ（ユーザーコンテンツ、ユーザープロファイル、トラフィックイベント）などを含んでいます。

ユーザーオブジェクト

ユーザーは customerId を割り当てなければなりません。ユーザーオブジェクトはユーザー名（メールアドレス）、ユーザーが利用できる機能または機能のバージョン（例えばβバージョンやαバージョン）やユーザーの役割（一般ユーザーか管理者か）の設定から構成されています。

ユーザーはサイトグループのレベルでユーザー固有の設定に加えて、参照権限や更新権限を保持しています。

データとデータソース

ページビューイベント

ページビューイベント(別名 トラフィックイベント）はカスタマーがトラッキングしたい全てのページに設置する Cxense スクリプト（別名 Cxense タグ）が実行されることによって作成されます。これは下の図の緑のステップ1で示されている、「ページビューイベントを送信」はページへのユーザーの訪問によってsendPageViewEvent() 機能の実行を表示しています。その機能は下記のコードの4行目で確認できます。図に見られるように、3つの情報セットがイベントの送信を元にしてCxenseデータストアに格納されます。クローラーがページを周回してコンテンツプロファイルを作り、イベントそのものとそれらの情報を元にユーザープロファイルが作成されます。

以下はページに設置されたスクリプトです。実際のスクリプトと異なるのは、以下のコード例では偽のサイトIDとして '9999999999999999999' がセットされています。

<script type="text/javascript">
    var cX = cX || {}; cX.callQueue = cX.callQueue || [];
    cX.callQueue.push(['setSiteId', '9999999999999999999']);
    cX.callQueue.push(['sendPageViewEvent']);
</script>

<script type="text/javascript">
    (function(d,s,e,t){e=d.createElement(s);e.type='text/java'+s;e.async='async';
    e.src='http'+('https:'===location.protocol?'s://s':'://')+'cdn.cxense.com/cx.js';
    t=d.getElementsByTagName(s)[0];t.parentNode.insertBefore(e,t);})(document,'script');
</script>

スクリプトは2つのパートから成り、7-11行目は Webページから Cxense 機能へアクセスするために必要となるCxense cx.js ライブラリファイルをインポートしています。1-5行目はライブラリの機能を利用して、サイトのサイトID（3行目）を通知し、ページビューイベント（4行目）を送信します。 2行目で示されているように、関数の呼び出しがキューにプッシュされ、Cxenseライブラリコードがロードされるたびに非同期で実行されます。sendPageViewEvent() はユーザーとページへの訪問に関しての全ての既知の情報を集め、CxenseデータストアにサイトIDと一緒にして渡します。イベントデータとスクリプトに関する詳細はこちらで確認できます。

ユーザーIDとCookie ID

同じユーザーに関して、カスタマーのCRMデータとCxenseのユーザーデータを紐づけることなしに、Cxenseが人間のユーザーをトラッキングすることはできません。代わりにブラウザのCookieを使ってブラウザのデバイスをトラッキングします。

Cookieはブラウザによって管理されている小さなテキストファイルに格納された、ドメイン名に紐づいたキーと値の組み合わせです。ウェブサイトはこれらのデータを残しておき、それで次回訪問した際にそのユーザーを認識します。ウェブサイトはユーザーや過去の訪問に関する情報を格納するためにCookieを使います。例えば、とある大学のサイトは学生の次回訪問時にどこからテストを再開するかを正確に知るために、学生がオンラインテストから離脱したページ番号を残すことができます。

Cxenseはユーザーの初回訪問時に乱数生成した数値を格納したCookieを使います。この数値はユーザーIDまたはCookie IDと呼ばれます。

これ以降の全ての訪問の際に、ユーザーはこの番号で認識されるように成ります。Cookie IDはドメイン固有のものであり、同じユーザーが別のドメインの別のサイトに訪問するとすぐに、追加のCookie IDを持つことになります。Cxenseは全てのドメイン固有のCookieIDがマッピングされた（実際に同じユーザーだと認識できる程度で）内部グローバルユーザーIDで動作しています。

上で説明されたページビューイベントを介してCxenseにレポートされる値の1つがCookie ID/ユーザーIDです。

ピクセルトラッキング

カスタマーのWebページに訪問したユーザーに関する情報はピクセルトラッキングと呼ばれる手法を使ってCxense Insight に送られます。これは上で説明したページビューイベントと同じように、下で説明するDMPイベントにも当てはまります。現代のブラウザにはセキュリティ上のクロスドメインの制約が課されているにもかかわらず、この技術によってCxenseに情報を送信することができます。

上のコードの4行目でCxenseにレポートされた情報はCxenseサーバーから画像を要求するURLにパラメーターとして追加されます。しかしながら、Cxenseは画像そのものには関心がなく、情報の伝達手段としてこれを使うだけなので、できる限り小さな画像を適用しています。つまり、1ピクセルのサイズ（1x1サイズ）の画像を使います。この技術をピクセルトラッキング（ピクセルを介してユーザー行動をトラッキングします）と言います。

以下ではHTMLとJavaScriptにピクセルリクエストをどのように実装できるかを説明していきます（cx.jsライブラリは後者のアプローチです）。

<img src="http://comcluster.cxense.com/Repo/rep.gif?parameter1=value1&parameter2=value2" width="0" height="0">
 
function sendInfoViaPixelRequest(value1, value2) {
	(new Image()).src = "http://comcluster.cxense.com/Repo/rep.gif?parameter1=" + value1 + "&parameter2=" + value2;
}

Cxense サーバー (comcluster.cxense.com) は誰も何にも使われないダミーの 1x1 画像（rep.gif)を返す前に
全てのパラメーターの値（value1, Value2, ...)を抽出し、格納します。各々のページビューにおいて、全てのパラメーターの抽出されるリストはこちらをご確認ください。

DMPイベント

上で説明したイベントのタイプは ページビューイベント または トラフィックイベント と呼ばれています。
これらは、訪問（訪問時間と長さ、過去や現在と次のページのURLなど）や訪問者（ブラウザ、OS、地域、IPアドレスなど）を記述したデータの集まりです。もう一つのイベントのタイプはDMPイベント（別名 パフォーマンスイベント）です。これらはユーザーがページを訪問している間に行ったことを記述したイベントです。例として、広告やコンテンツをレコメンドした際のインプレッションやクリック、あるビジュアル部分がブラウザビュー内にある時間、オンラインクイズへのユーザーの参加確認があります。これらのイベントのトラッキングはユーザーエンゲージメントトラッキングと呼ばれます。

以下で示されているようにページビューとDMPイベントには 1:N の関係があります。これはDMPイベントが常に時間と空間の両方のページビューイベントと関連していることを意味します。これによって、「どのくらいのユーザーが期間中に行ったか」「どのくらいのユーザーがオンライン新聞で最新の広告キャンペーンを見たか」といった興味深いトラフィック調査が容易になります。

上の図では、緑のルートはあるWebページから次のページへのリンクをクリックするページビューイベントを示しており、青のステップはどのようにDMPイベントがデータ収集を行うかを示しています（この場合、広告インプレッションとクリックのパフォーマンスデータ）。最初のページの上部には広告が表示されていますが、ユーザーにそれは効果はありませんでした（なぜなら青のステップ2はインプレッションのDMPイベント）。次のページでもう一つの広告が表示され、今回はユーザーがそれを実際にクリックし、
広告のランディングページに移動します（緑の6)。しかし、その前に2つのDMPイベントが発生します。
広告インプレッションと広告クリックの2つです（青の5)。

以下では青の2の箇所について、実際のJavaScriptの実装について説明していきます。ここでは 'xyz-'と persistedQueryパラメータに関しては割愛します。ここで重要なことはイベントの origin に adcampaign というラベル付けがされ、イベントのタイプが impression とラベル付けされたことです。これらはCxenseのGUI上に現れる語句であり、のちにAPIのTrafficクエリを作る際のフィルタリングのための語句としても使われます。

cX.setEventAttributes({origin:'xyz-adcampaign', persistedQueryId:'1234567890abcdefghijklmnopqrstuvwxyz1234567890'});
cX.sendEvent('impression');

DMPイベントについてさらに学びたい場合は、ユーザエンゲージメントトラッキングチュートリアルを確認してください。 

コンテンツプロファイルとユーザープロファイル

1st と 3rd パーティユーザーデータのAPIをベースとしたフィードを除いて、イベントはコンテンツプロファイルとユーザープロファイルにある全てのデータのソースになっています。

コンテンツプロファイルはトラッキングされたWebページそれぞれで作成されます。ページのURLはイベントから取得され、コンテンツ取得のためにクローラーに渡されます。それからコンテンツは処理され、主要な用語がその重要度を示す重み付けをされて格納されます。

ユーザープロファイルは各々のユーザー（ほとんどの場合はユニークブラウザに相当します）によって作成されます。ユーザープロファイルにあるデータのいくつかはユーザーが訪問したページのコンテンツプロファイルから生じます。他のデータはイベントから直接生成されます。後者の例は地理的な位置、ブランド、ユーザーのブラウザのバージョン数またはモバイル端末などユーザー固有の情報です。

コンテンツプロファイルからユーザープロファイルに渡された主要な用語は重要度や頻度に基づいてスコアを蓄積していきます。ユーザーが似たようなコンテンツに新たに訪問していかない限り、（そのタイプに依存はするものの）主要な用語のスコアは時間の経過によって落ちていき、ユーザーの現在の興味関心が反映されるようになっています。

上の図はCxenseのエコシステムの様々なデータコンポーネント間でデータを記述していくフローを示しています。下の表はこれをより具体的に示したものです。各々の項目に関する詳細を確認したい場合はコンテンツプロファイルとユーザープロファイルを確認してください。

シーセンスクローラーとドキュメント処理

上で説明したページビューイベントは訪問したページのURLを含んでいます。それらのURLはクローラーキューに追加され、ページはクローラーによってある時点での情報を取得します。最初にページがクロールされるには、所定の期間内に決まった最小回数の訪問がされる必要があります（この執筆時点では6時間以内に3回）。そのあと、指数関数的に頻度を減らつつ、定期的に再クロールされます。初期のクロールや後の再クロールはクローラーキューにGUIを介して（1つずつ）URLを追加する、APIを介して（まとめて）URLを追加することによって強制的に行うこともできます。 

クローラーはCxenseにドキュメントをアップロードする唯一の方法ではありません。下の図で見られるように、カスタマーはAPIを用いてドキュメントのアップロードを行うこともできます。これはカスタマーがCxenseにはクロールされない、自社の検索ソリューションで生み出されたデータを、検索ソリューションで更に活用したい時には特に有効です。

ドキュメントがクロールまたはプッシュされると、ドキュメントプロセッシングを通過します。以下では最も重要な処理操作をリストにしています。全ての言語において同じ対応範囲ではないことにご注意ください。

• 言語判定 - 
  後半の操作の多くは判定された言語に依存します

• トークン化 - 
  言語固有の単語分割として、例えば "He said: 'Don't go!' は ["He", "said", "Don't", "go"] として分割され、空白のない日本語では "私は日本人です。" は [ "私", "は", "日本人", "です" ] に分割されます。

• 文字の正規化 - 
  言語固有の文字の正規化は英語では A を a 、Å を a に、ノルウェー語では A を a 、Å を å に、ドイツ語では ß を ss に、スペイン語では ñ を n に、日本語では 國 を 国 にします。

• 固有表現抽出 - 
  人、場所や会社の名前の辞書による抽出、頭字語や概念（まだ抽出されていない出現数の高い単語）や
  エンティティ(まだ抽出されていない大文字の単語または単語列)のルールをベースにした抽出を行います。

• ユーザー関心事項のカテゴリー抽出 - 
  言語をベースにした辞書は、明示的に有効化されている場合にだけ、タクソノミの抽出に依存します。抽出は Cxenseが提供しているがタクソノミ（標準タクソノミとも言われる、下の図の青の1）、あるいはカスタマーが管理するタクソノミ（カスタムタクソノミとも言われる、下の図の青の2）が基準となります。

• 見出し語化（レマ化） - 
  検索機能でのみ使われます。例えば、単数形と複数形の名詞のような、会話のある一部分の文法の変化に沿った検索を可能にします。したがって、 'house' の検索が 'houses' という単語を含む文書のヒットも可能にします。

ドキュメントプロセッシングは2つの出力があります。1つは検索エンジンに渡される検索可能なドキュメント構造（検索インデックス）で、もう1つはキューブ内に格納されたキーと値の組み合わせをベースにしたコンテンツプロファイルです。コンテンツプロファイルは2つの種類のデータ、HTMLのメタデータタグから抽出されたメタデータとHTMLページの title や body から抽出された異なる種類のエンテティ（人名、組織、場所、概念など）から構成されています。

上の図はこれまでの説明を全てにまとめたものです。緑のステップは 4. を除いて、その前の図と全く同じです。入ってくるドキュメントはコンテンツプロファイルの作成だけが目的ではなく、それらを検索しやすくする目的（コンテンツプロファイルと更新された検索インデックスの2つのデータ出力を確認）で処理を行います。（送信元に関係なく）受信したドキュメントプロセッシングはタクソノミーのタグ付けやエンティティ抽出などをサポートする辞書に追加されることによって、部分的に設定を行うことができます。
これはデフォルトの辞書を有効にするか、青のステップ1とステップ2に示されるような、カスタム辞書を追加することによって実行できます。現時点の設定はクローラーまたはプッシュAPIを介してのみ、ドキュメントのフィードが可能となり、切り替えることはできません。

サイトはホワイトリストにも、ブラックリストにも、グレーリストにもできます。デフォルトでは全てのサイトがグレーリストから始まります。つまり、クローラーは一定のページ数(1k)以上のクロールは行わず、容量の問題が発生した時にグレーリストのサイトのページはキューの最後にして終了します。テストサイトやデモサイトは永久にグレイリストされたままであることが多いのに対し、本番システムはほとんどいつもホワイトリストになります（ホワイトリストは容量制限がなく、キューの中で最優先）。ブラックリストは問題のあるサイトからのアクセスをクローラーがブロックするのと同じです。

Cxense プロダクト ポートフォリオ

Cxense Insight

Cxense Insight は上図のデータレイヤーの一番上にある GUI です。その唯一の目的は人がアクセスしやすいようにデータを格納することです。 標準のデフォルトビュー（データを数値、リスト、グラフで表示した Webページ）に加え、Cxense Insight はユーザーが望む形式で、望むデータを正確に示す、カスタムメードのウィジェット を使用した独自のワークスペースを作成することができます。

Cxense DMP

Cxense DMPはユーザーの現在と過去の行動や特性を反映したオーディエンスセグメントとしてユーザー群を編成する機能を提供しています。オーディエンスセグメントの例として、「サンパウロに住んでいて、英語を話せる、乗馬が趣味の40歳以上の女性」といったものを作ることができます。このようなオーディエンスセグメントはターゲティング広告やEメールのキャンペーンに使うことができます。

以下の図で示しているのは、Cxense DMPのオーディエンスセグメントを利用する際のサイクルで、色分けされた3つから構成されています。緑はデータを収集する段階を示し、赤はオーディエンスセグメントの作成とエクスポートをする段階、青はセグメントを活用する段階です。

緑の1では Cxenseスクリプト が Cxenseにイベントデータをアップロードしています。ここのこれまでとの唯一の違いは、ファースト または サードパーティデータが追加されていることです。この場合、Cxense の CookieベースのユーザーID をカスタマーのデータベース（例えば、購読者データベース）内の同じユーザーIDと同期させるために、特別なコード行を追加します。IDの同期を行う目的はCxense DMPが 緑の 2a) と 2b) でアップロードされたファーストパーティ あるいは サードパーティ の ユーザーデータをCxense データストア内の対応するユーザーに対してマッピングできるようにすることです。

ユーザーのデータ収集をしたので、次に赤のステップ（セグメントの作成とエクスポート）に進みます。3 ではCxense のGUIを使って、オーディエンスセグメントを作成していきます。オーディエンスセグメントはブール演算子を組み合わせた1組のフィルターに過ぎません（ブール演算子とは結果が「真(true)」か「偽(false)」で表される式を AND や OR で組み合わせたもの）。例えば、「リオデジャネイロにいる若い女性のモバイルユーザーが最近3日間で Rock in Rio（年1開催のロックフェス）に興味を示している」というのはここで示されているような行で実装されます。

age < 23 AND 
gender is 'female' AND
device is 'mobile' AND
location is 'rio de janeiro' AND
HAVING(
　MINIMUM 10 page view AND 
　category is 'rock in rio') AND 
start is 3 days ago AND 
stop is now

セグメントを作成した後、カスタマーに利用されているアドサーバーにそれをエクスポートします。

赤のステップ4では広告オペレーターが広告キャンペーンを作成しています。広告キャンペーンはそこで伝えるメッセージを受け取ってくれそうなユーザーグループに対してターゲットにすると、より効果的になります。ここではオーディエンスセグメントが動いてくれそうな場所があります。上の図では広告オペレーターがフェラーリに関する広告キャンペーンを作成しており、マンハッタンに住む50歳以上の男性をキャンペーンのターゲットにしています（例えばウォール・ストリートがあり、小さなアパートにオイル輸送船と同じくらいの費用がかかります）。そのゴールはお金持ちの男性にリーチすることで、そうした人の方が人口全体よりもフェラーリを購入する可能性が高いのです。

赤いステップを行なって、作成したセグメントのアクションを見る準備が整いました。青の5 はユーザーがページを開くとどのようにして、ユーザーが属している全てのセグメントのリストを要求するリクエストが発生するかを示しています。セグメントIDのリスト（この例では1つのセグメントIDだけです）が返ってくると、次の青の6では同じJavaScriptタグから新しいリクエストが送られます（アドサーバーはこの時、ページに配置可能な広告を要求します）。このリクエストは前のステップで取得したセグメントID のリストがつけられています。青の 7ではアドサーバーは最適な広告がどれかを決めるためにオーディエンスセグメント情報を使い、Webページに表示されるように広告を渡します。 

DMPに関する詳細は DMPオーディエンスセグメントチュートリアル をご確認ください。

IDの同期とユーザーデータのアップロード

上でIDの同期とファースト、サードパーティデータのアップロードについて触れました。以下の図で再び確認していきます（今回はもっと詳細な内容です）。

赤の 1 は サイトにユーザーがログインしています。この時に、青の 2 で示されているようにカスタマーがCxenseにIDを提供し、(これはCxenseスクリプトがページで展開されるコード行を介して行われます）Cxenseとカスタマーのシステムの両方でユーザーのIDが認識されるようになります。 Cxenseタグが緑の3で実行される時、 Cxense ID (ブラウザのCookie）とカスタマーID(カスタマーのデータベースのユーザーID）の両方が Cxense に送られるデータの中に入ります。そして、外部カスタマーIDはそれぞれのユーザーのユーザープロファイルに格納されます（緑の4) 。

その後、カスタマーがCRMシステムからユーザーデータをアップロードすると（青の5)、これらのIDはこの時にCxenseに知られるようになるので、カスタマーはCxense上でユーザーIDを自由に使用して、ユーザーの識別を行えるようになります。 

類似(Lookalike) モデリング

類似(Lookalike) モデリングは既存のオーディエンスセグメントから新しいセグメントを作ります。元のセグメントで定義されたものと同じ特性を持った、よりたくさんの数のユーザーにリーチすることを目的としています。類似セグメントの例として、特定の商品を購入したことがあるユーザーから構成されたセグメントに似たような特性を持ったユーザーを含むセグメントになります。類似セグメントはその商品を買ったことがないユーザーを含めるのに使えますが、それ以外は元のセグメントのユーザーと非常に似たものになります。将来その商品を購入する可能性の高いユーザーをターゲットにするためにセグメントを使います。

技術的には類似セグメントはセグメントのメンバーかそうでないかを示す、いくつかの属性の値を各々のユーザにチェックするフィルタとして実装されます。

以下では類似のオーディエンスセグメントを作成して使用する手順を説明しています。まず青の1 では ベースとして機能する通常のセグメント（赤い色の円で示される箇所）を作成します。次に、このベースとなるセグメントを基に、類似モデリングを有効化します。システム上に類似セグメント（オレンジの円）を作成し、最新式の AI/機械学習技術に基づく、繰り返しモデルトレーニングのジョブを開始します。24時間以内に類似モデリングは初期の実行を完了し、類似セグメントは合計したオーディエンスからリクエストされた割合が含まれます。類似モデリングはベースとなるセグメントへの類似の程度に応じてオーディエンス内の全てのユーザをランク付けし、そのリストのトップからリクエストされた割合に到達するまでのユーザを含めます。したがって新規の類似セグメントの品質はセグメントのサイズに反比例します。オーディエンスにより大きな割合をリクエストをすると、弊社のバックエンドはあまり似ていないユーザを含めなければならなくなることを意味します。

これでセグメントの使用を開始する準備が整いました（赤いルート）。ページ上でどのオーディエンスセグメントをベースとした広告またはコンテンツレコメンドをしたかで、ユーザが属しているセグメントのリクエストがされ（赤のステップ1）、そのリストが生成され、返され（赤のステップ2）、当のユーザに正しい広告またはコンテンツレコメンドが選択され、使用されます。

類似セグメントのサイズは全てのユーザーの割合によって付与され、緑の3 で セグメントに追加されるユーザーの入ってくる割合を決めます。休眠ユーザーやユーザープロファイルに変更が加わって対象として分類されなくなったユーザーはセグメントから徐々に削除されていきます。

ファネル

広告がWebページで表示される時、それをインプレッションを呼びます。もし誰かが広告をクリックしたら、それをクリックと呼びます。インプレッションに対するクリックの割合をCTR（クリックスルー率）と言います。もしユーザーが広告をクリックし、広告主が望むアクション（例えば購入）として定義されたものがそのまま実行された場合、それをコンバージョン と言います。最初に広告がクリックされてから、コンバージョンが実行されるまでに、ステップがいくつか存在していることがあります。 例えば以下に示されているように、もし広告が大学入学のためのものである場合、願書をアップロードする最後のページに到達する前に、いくつかの入力フォームを埋めるかもしれません。そのような一連のステップはコンバージョンファネル と呼ばれます。この名前のステップを踏むごとに少しずつユーザーが減っていく（ファネル（漏斗）が徐々に狭くなるような）ことから由来しています。 

Cxense DMP にはパフォーマンス統計（CTR）を表示するために、ファネルの一部としてWebページにタグ付けする機能があります。そうすることで、それぞれのWebページやファネルが全体のファネルの中でどのくらい優れているのかを確認できます。

Cxense DMP のファネルに関しての詳細は ファネルの開発とレポーティング をご覧ください。

Cxense Search

Cxense Search はCxense Content が内部的に使っているものと同じ検索インデックスにアクセスできるAPIです。入力（クエリ）と出力（検索結果）の形式はJSONです。 

上図は緑の矢印で Cxense の動作、赤い矢印でユーザー行動、青い矢印はカスタマーの行動を示しています。最初に検索可能なデータを収集します。ユーザーはページに訪問し、ページビューがCxenseに送られます（緑の1）。ページビューはクローラーキューに追加されるページURLが含まれます（緑の2）。ある時点でクローラはページを取得し（緑の3）、処理されてページコンテンツがインデックスされます（緑の4）。これで1つまたはそれ以上の検索語を入力することによって、ユーザーは検索することができます（赤の5）。

次の2つのステップはカスタマーに実装される部分です。ユーザーによって付与される検索語句は Cxense Search API のURLにラップされて、Cxense Search に渡されます（青の6）。クエリは検索インデックスに対して実行され、検索結果はユーザーに渡されます（青の7）。

Cxense Searchについての詳細は Cxense Search実装例（クエリ）をご覧ください。

クエリコンプリション

下図で示しているようにCxenseはユーザーによって書き出されたクエリのような、クエリ前処理をサポートしています。これは緑の1で示されているような、カスタマーがクエリコンプリションの辞書をアップロードすることが前提となります。これが完了するとすぐに、Webサイトのバックエンドはユーザーがクエリ句の頭の数文字を書いている時に（赤の2）、クエリコンプリション候補をリクエストできるようになります（青の3）。ユーザーが青の4で受け取ったクエリコンプリションの候補を除外（または拒否）するとすぐに、実際のクエリが渡されます（青の5）

Cxense Searchの言語辞書の使用法について、詳しくは 辞書管理チュートリアル をご覧ください。

クロール vs. カスタマーデータフィード

クロールされたWebページがどのように検索可能になるか、2つの形式を見てきました。下の図で示されているのは、クロールされていないドキュメントをプッシュすることで、クロールされたコンテンツとは関係のない検索インデックスを作成できます。これを行うためには、クローラーはドキュメントがAPIを介してインデックスをプッシュする前に（青の3）無効にしなければなりません（青の2）

緑の1はどのようにドキュメント処理（とこの図では示されていない検索クエリ処理）様々な辞書を有効化、アップロードすることで、カスタマーに設定できるかを示しています。これらの辞書は言語的なもの（スペルチェックやクエリコンプリションなど）またはタクソノミで行うことができます。

カスタマーデータフィードについて詳しくはCxense Search実装例（インデックス）をご覧ください。

Cxense Content

私たちは読者をできるだけ長くサイトに滞在させようと、コンテンツレコメンデーションを使います。そのためには読者が読みたくなるよなものをレコメンドすることが重要です。レコメンドをどのようにすべきかはそのレコメンドがページのどこに配置されているかにも依存してきます。右側にはいくつかの候補地を色づけしています。

緑のレコメンデーションは全体の記事を最後まで読んだユーザーに見られます。したがって、現在の記事から証明された興味関心を基準にして、同じようなもの（contextual)をレコメンドできます。黄色の箇所は開始の時点から現在の記事に興味関心を失っており、ここでは現在の記事とは異なるものをレコメンドすべきです。これは最新ニュース(trend)や過去にユーザーが興味を示したもの（behavioral)は意味があるでしょう。緑のレコメンデーションの下の領域、ユーザーコメント領域の終わりの灰色の部分は
CTRがゼロに近い結果になることが保証されているようなものなので、避けるべきです。一番上の赤い箇所はすぐに立ち去ってしまうような、散漫なユーザーに使うことができます（例えばFacebookやGoogle検索からの単一記事の読者）。他の全てのユーザーにとっては現在の記事を見る前に気を逸らすことになるので、一切表示すべきではないでしょう。 

下の図の青のステップ1では Cxense Content レコメンデーションでの開発と設定作業を示しています。
その全てはCxenseポータル内で行います。この実行結果がCxense内に格納される content config (何をレコメンドするか)、Javascript template（レコメンドでデータ構造を展開するコード）、CSS Style Sheet(レコメンデーションのレイアウトを定義)の3つのコンポーネントから成るウィジェットです。
青の2ではウィジェットコードを取得し、Webページにそれを挿入します。ウィジェットの唯一の目的はウィジェットIDを保持し、レコメンデーションを表示するときにそのウィジェットを要求することです（緑のステップ1)。

ユーザーがページにアクセスするとき、cx.jsのライブラリファイルの insertWidget() 機能が呼び出され、
トップに位置づけられた記事が設定した分だけ返されます。緑のステップの2で返されたデータはコンテンツのレコメンドデータ構造、データを展開するテンプレートコード、そして配置を決めるCSS Style sheet を含んでいます。 

Cxense Content に関する詳細を知りたい場合は Cxense Content レコメンデーションチュートリアルをご覧ください。

Last updated: January 12, 2022