SiteCatalystのメニューはカスタマイズ（非表示、順番変更、名称変更、フォルダで階層化）ができます。

変数をSAINTで分類すると、メニューがフォルダで階層化され、分類後のレポートが下層に表示されるようになります。

ところが、この下層メニューはカスタマイズできません。分類前の項目しかメニューのカスタマイズ画面に表示されないのです。

が、回避策があります。子レポートをカスタムレポートとして保存するのです。

分類後の子レポートがメニューのカスタマイズ画面に表示されるようになりました！

元のレポートはまるごと非表示にし、このカスタムレポートを同じ場所に移動すれば、そっくりな状態になります。

名前を変えたり順番を変えたり、フォルダに入れずにフラットに並べたり、どうぞ好きなようにカスタマイズしてください！

SiteCatalystのデータ収集サーバーへ送られるHTTPリクエストのURLは、いつも「&AQE=1」で終わります。これは、パラメータの終わりを示します。同様に、AQEは始まりを意味します。BeginとEndなのです。

実は、AQEはパラメータがすべて送信されたかを確認するために使われています。SiteCatalystのレポート上では確認できませんが、Data Feed（Data Warehouseを導入している場合はクライアントケアに依頼すれば送ってもらえる生データ）に「truncated_hit」というフラグがあり、AQEが無かった場合＝URLが途切れた場合に「YES」がセットされます。

途切れたリクエストを送信したブラウザの種類を調べたところ、すべてIEでした。H.22.1以降のs_code.jsだと、IEでIMGリクエストが長くなった場合に自動で後半の変数をカットしれくるので、リクエストが飛ばなくなることはなくなります。

page_urlを見ると、どのページで発生しているかが分かります。referrerも長くなりがちなので、要注意です。HTTPヘッダで送られたリファラが記録されるので、サイト内の遷移時にもサイト内ドメインのリファラがセットされるのです。

• 変数の見直し
• ダイナミック変数の活用
• サイト内遷移時のリファラ消去
• IEの場合のみ特定の変数を飛ばさない

参考：IEでは計測データが欠損することがある

プライマリサーバーコールを消費しない簡易的な計測方法として、ライトサーバーコールがUSでリリースされています。

元ネタ：Light Server Calls User Guide

こんな場合に

• 大量にコールされる
• 計測する変数は少しで良い
• サイト全体の訪問や訪問者数を増やしたくない
• クロス集計やセグメント分析は不要

例えば、サイト内外に掲載するバナー広告のビュースルーやメールの開封率＆コンバージョン率測定、Webやアプリの単純なクリック計測、などで使えます。

なぜ「ライト」のか

以下の制約があります。

• eventと2つ以内のeVarのみ計測できる（eVarを追加すると単価が上がる）
• 指定したeventとeVarは、他の変数とクロス集計ができない（つまりただのカウンターになる）
• 該当eVarやEventのレポートにセグメントを適用できない（適用するとeventがゼロになる）
• サイト全体のページビュー、訪問、訪問者が増えない
• VISTAルールや処理ルールが適用されない（適用すると単価が上がる）

Light Server Callとして計測するeventとeVarは、通常の処理をスキップして独立したデータベースでカウントアップされる、と考えると分かりやすいです。

使うための手順

• ClientCareまたはAccount Managerに、以下の情報を伝える　日本ではまだ準備中のようです
• コールが飛んだ時に自動セットするeventの番号（複数指定可能）
• 値を飛ばすeVarの番号
• Light Server CallのProfile ID：8文字以内の半角英数字（RS内でユニークに）
• 以下のような特殊な実装を行う

Light Server Callの実装方法

JavaScriptでコールを飛ばす場合

例

s.lightTrackVars = 'eVar75';
s.eVar75 = '20120108';
s.trackLight('email1', 0, 1);

• リンクトラッキングと同様に、どのeVarを送信するかを指定する必要がある
• trackLightの1つ目の引数はライトサーバーコールのprofile ID
• trackLightの2つ目の引数は0（ゼロ）
• trackLightの3つ目の引数は該当profile IDで指定したeventの増加数。広告のインプレッションで重み付けをしたい場合などに。省略時は「1」になる

注意

• Profile作成時に指定しなかったeVarを飛ばしてもサーバー側で無視されます
• Eventは通常のCounterとして設定する必要があります

imgタグ、またはAJAXでURLを直接指定する場合

例

<img src="http://*.2o7.net/b/ss/RSID/1/CODEVERSION/s1234567890?mtp=email1&v75=20111208&ce=UTF-8">

• *.2o7.net - 計測サーバー名。RDC利用時は*.omtrdc.net、1st-Party Cookie利用時は独自ドメインなど
• RSID - レポートスイートID
• CODEVERSION - 計測ライブラリのバージョン名。JSの場合は「H.24.1--NS」などが入る。処理ルールを併用する場合にこれで対象を特定するため、「EMAIL1」など、Profile IDに似たユニークな値を指定する。
• s1234567890 - ビーコン画像がブラウザによってキャッシュされないようにするため。 同一ブラウザで繰り返し発生する場合は、毎回ランダム値を算出する。
• mtp - ライトサーバーコールのprofile ID。サーバー側でこのIDをキーとして利用eventとeVarを特定し、データ保存する。
• mti - Eventの増分（省略時は1）
• v - eVar。該当profile IDで指定したeventが自動セットされ、このeVarに紐づく。このeVarの番号はprofile IDを有効化する時に指定しておく必要がある（指定しないと値がセットされない）
• ce - 文字コード（eVarにマルチバイト文字をセットしない場合は不要）

レポートの見え方

Light Server Callとして指定したEventのレポート

Light Server Callとして指定したeVarのレポート

• インスタンス、訪問、訪問者は増えない
• 指定したEventを指標として追加できるのは、Light Server Callとして指定し、同時に計測されたeVarのレポートのみ

このように制約はあるものの、ライトでエコノミカルなのは魅力的です。リンクのクリックやHTMLメールの開封、広告やパーツの表示などにぜひ活用してみてください。

参考KB：10635

実は管理コンソールのレポートスイート設定画面では、複数のRSを選択して一気に同時編集することができます。レポートスイートを選択する時にControlキーを押しながらクリックすれば、現在の選択状態を残したまま追加で行を選択できます。背景色が緑色になったRSが、選択された状態です。

この状態で各種の設定を編集すれば、選択された複数のRSに対して変更が適用されます。
編集画面に移動すると、どのRSが選択されているかが画面上から見えなくなるので、予期しない変更を複数のRSに適用してしまわないように注意しましょう。

変数の設定画面では、選択した複数RSの間で名称や設定の違いがある場合は、「複数の」と表示されます。

この「複数の」はリンクになっていて、クリックするとRSごとの設定が表示されるダイアログがpop-upします。

このような違いを確認した上で、それでも全部を一気に変更したい場合は、「複数の」の上を外して少し右側をクリックすると、上書き変更できます。

なお、「メニューのカスタマイズ」に関しては、メニュー構造が全く同じRSしか同時に編集できません。少しでも差異があると、以下のような警告が表示されます。

実際のところ、同時にメニュー編集する可能性があるのは本番と開発用のRSくらいでしょう。それらは常に同時編集し、違いが生まれないように注意深く運用しておくと、末長くハッピーになれそうです。

前回はサイトカタリストにおける訪問 (Visit)の定義について紹介しましたが、今回は訪問者（ビジター＝Visitor）の定義について紹介します。最後の2点は、あまり知られていない仕様・新機能です。

訪問者をカウントする方法

Cookieが使える場合

訪問者は、SiteCatalystの計測サーバーによって発行されるランダムなID「ビジターID」によって識別されます。このビジターIDはブラウザのCookie（SiteCatalystでは「永続的なCookie」と呼ばれる）に保存されるため、かなり高い精度で同じブラウザからのアクセスを紐付けできます。

ただし、ブラウザを変えたりCookieをリセットすると、同じユーザーでも別の訪問者として識別されるようになります。そういう意味では、「ユニーク訪問者数」というよりは「ユニークブラウザ」と考えた方が正確です。

Cookieが使えない場合

SiteCatalyst 14以前：

IPアドレスとUA（User Agent＝ブラウザの種類）の組み合わせで訪問者を特定します。企業のネットワークからアクセスする場合、複数の訪問者が同じIPアドレスでアクセスすることがあります。インストールできるソフトウェアもコントロールしている場合、ブラウザ名が同じ確率も高まります。

この方法で計測された結果は、サイト指標＞訪問者のレポートでのみ表示されます。他のレポートに指標として追加できる「日別／週別／月別訪問者」には、Cookieが使えない場合の訪問者は含まれません。不正確な値を反映させないための仕様と思われます。

参考Knowledge Base: 555

SiteCatalyst 15以降＆Discover

IPアドレスとUAによる判定ロジックが変更され、別のデータも加味したより正確なロジックで訪問者を特定できるようになりました。サイト指標＞訪問者のレポートでも、他のPropやページなどのレポートに追加できる指標でも、Cookieを使えない場合のアクセスが含まれるようになります。

参考Knowledge Base: 129

重複のカウント対象期間による違い

このうち、指標としてレポートに追加できるのは日別、週別、月別のみですが、どのレポート（ページ、サイトセクション、カスタム変数など）でこれらを計測するかは設定が必要です。Adminコンソールでは設定できないため、ClientCareかAccount Managerに依頼する必要があります。

なお、SiteCatalyst 15以降では、「実訪問者」(Unique Visitor)という指標が増えました。重複のカウント対象期間は固定ではなく、指定した任意の期間（レポート右上で指定した期間）になります。

1年訪問しないとリセットされる

実は、訪問者は1年間以上アクセスしないと、サーバー側からビジターIDが削除されます。Cookieの有効期限を5年など長くし、同じビジターIDがサーバーへ送信されても、1年以上の間隔を開けた場合は、サーバー側でビジターIDが削除されているため、新しい訪問者としてカウントされるのです。有効期限を無期限にしたeVarもリセットされます。

デバイスを超えた訪問者の統合が可能に

これは2011年10月のメンテナンスリリースで実装された新しい機能です。ビジターIDは、昔からs.visitorID='12345abcde';などと明示的に指定することができました。このCross-Device Visitor Identificationという機能をRSごとに有効化すると、ブラウザやデバイスに関わらず同じビジターIDを明示的に指定した場合に同じ訪問者として認識され、訪問がつながるようになるのです。そのためには、ビジターIDをランダムに生成するのではなく、ユーザーIDなどを利用したアルゴリズムを使うことで、同じ人なら同じ値になるようにする必要があります。これによって、デバイスを超えたアトリビューション分析が可能になりました。

参考Knowledge Base: 10627
※英語のImplementation Guideにも詳しい解説があります

2011年8月に、Googleアナリティクスにおける訪問（Visit、セッション）の定義変更が発表され、話題になりました。 

Adobe SiteCatalyst（サイトカタリスト）における訪問の定義について、Googleアナリティクスと比較しながらまとめてみました。

「処理ルール」はSiteCatalystのv15で追加された新機能です。SiteCatalystの場合、「VISTAルール」を使うことで、送信されたデータを処理・加工してから計測することができました。これはプログラミング言語なので、いろいろ複雑な処理ができる反面、Adobeに依頼する必要があるので、コストと時間がかかるというデメリットがあります。

v15の処理ルール（Processing Rules）は、このVISTAの手前で動作する簡易サーバー側処理です。Google Analyticsでいう「フィルタ」と同じようなものですね。

できること

• 製品ページでeventをセットする
• URLのパラメータを変数にセットする
• カテゴリとページ名を結合してpropにセットする
• eVarの内容を別のpropにコピーする
• 実装ミスで発生しているスペルミスを正しく置換する

できないこと

• 計測しないように除外することはできない
• リファラーとUser Agentは書き換えられない
• Product変数、モバイル関連の変数、SAINT分類項目は読むことも書くこともできない

ルールの設定方法

管理者権限でログインし、管理コンソール＞レポートスイート設定、を開くと、「設定を編集」のメニューに「処理ルール」のリンクがあります。

ただし、処理ルールは間違えるとデータを正しく計測できなくなるため、理解度テストに回答して80％以上の正答率を達成し、この機能をONにしてもらう必要があります。詳細はClientCareまで。

次に、「ルールの追加」をクリックします。

編集のためのフォームが表示されます。

ルールセット毎に、以下を指定します。

• 適用する条件（Condition）
• 対象の変数
• 処理内容

メモも書けるのが便利です。

指定できる適用条件

対象変数	条件の種類
URL ドメイン パス URLパラメータ ページ名 サイトセクション サーバー RSID AppMeasurementバージョン IPアドレス User Agent リファラー リファラーのURLパラメータ 参照ドメイン Campaign Purchase ID Transaction ID State Zip 各種eVarとpropとevent コンテキスト変数	次に等しい 次を含む 次を含まない 前方一致 次で始まらない 次で終わる 次で終わらない 空ではない 空である

条件もANDまたはORで複数指定できます。

指定できる処理

処理
値の上書き 値の削除 eventのセット

処理ルールセットの例

下記は、Google検索からのリファラーにキーワードが含まれていなかった場合に、カスタムイベント1をセットし、さらにeVar1に「Google SSL」とセットするルールセットの例です。

この管理画面はv15でログインしないと利用できませんが、v14のレポートスイートに対しても設定・適用できます。

こんな高度な処理を、一つのレポートスイートにつき50個まで自分で設定できるようになったのです。素晴らしい！

関連情報

• 15 for 15: Processing Rules and Context Data Variables - Adobe Industry Insights
• SiteCatalyst 15 Processing Rules - Web Analytics TV
• Omniture SiteCatalyst 15: Context Variables & Processing Rules - JasonEgan.net
• Processing Rulesの公式マニュアル（英語）

Web担当者Forumでの投稿「ファーストビューは何pxまで？ ブラウザの表示領域サイズ5年間の変化を大公開」では、SiteCatalystのデータが活用されています。

Google Analyticsの場合はデスクトップ（モニタ自体）の解像度しか分からないのですが、
SiteCatalystの場合はブラウザウィンドウの実際の表示領域を計測しているのです。

面白いのが、左側の虫眼鏡アイコン。クリックすると、そのデータの幅でサイトを表示してくれます。

知らなかった！

Google検索が2011-10-18に検索サービスの本格SSL移行を発表した件について、実践CMS*IAにまとめておきました「SSL版Google検索の新仕様まとめ」。

ここでは、SiteCatalystへの影響と対策についてまとめます。

影響を受けるレポートは3種類

まず、Adobeの公式グログで発表がありました。

• The Impact of Google Encrypted Search (Adobe Industry Insights)

影響を受けるのは、下記の3種類のレポートです。

• 検索キーワード：全体的に減る
• 有料は、リンク先URLにパラメータをつけていれば正しく計測される
• 検索エンジン：「Google」が減る
• 有料は、リンク先URLにパラメータをつけていれば正しく計測される
• リファラータイプ：「検索エンジン」が減り、「その他のウェブサイト」が増える

計測漏れした件数の調べ方

検索キーワードが計測できなった数の推移を調べる方法を紹介します。

1. 「トラフィックソース＞リファラー」のレポートを開き、対象期間を設定する

2. フィルターで絞り込む

「google.com/url AND q=&」で「検索」して、レポートをキーワードなしのGoogle検索のみに絞り込みます。

3. 合計の数字を取得する

右下の数字が、期間内に計測された（正しく計測できなかった）SSL版Google検索からの流入数（インスタンス＝クリック数）です。この数字は、表示されている行のみではなく、全行数のインスタンスを加算した数字です。

日々の推移を調べるには、データ抽出の方が便利です。以下のように設定します。

• フィルタを「リファラー」にし、クリックしてトップ500000、「google.com/url」と「q=&」でアドバンス検索

• 日付の設定で期間を指定し、精度を「日」にする

しばらくすると、以下のようなCSVがメールで届きます。

急増中...（汗）
問題は、これがGoogleからのアクセス全体のどれ位を占めるかです。

ExcelClientを使うと半自動化できる

そこで、ExcelClientを使ってデータブロックを２つ並べて、Googleからのアクセス全体における計測不能なアクセスの割合を自動計算することにします。
RSIDや日付をセルから参照できるので、いろいろなRSについて調べたり、日々の推移を調べるための反復作業が楽になります。

設定済みのExcelドキュメントを公開しておきます。ページ下部からダウンロードできます。

• 開いたらExcelClientにログインし、RSIDを書き換えて「ワークシートのリフレッシュ」を実行
• ２つ目のブロックでは、「検索エンジン - 自然」から「Google」を含む項目を日別に抽出
• 割合の算出方法はキーワード欠損数÷（各国のGoogle流入総数＋キーワード欠損数）
• 期間が長いとタイムアウトするため、取得済みの過去データを別途保存しておき、差分のみを取得すると良い

どう対策すべきか？

現状の問題は、キーワードどころか検索エンジンからの流入であることも認識できない点です。

11/11追記：サーバー側で対応したので、11月11日以降は正しく認識できるようになりました。検索エンジン、リファラータイプが正しく認識されるようになり（Marketing Channel Report含む）、検索キーワードは「Keyword Unavailable」（キーワードを使用できません）としてカウントされます。

プラグインのChannel Managerに関しては、別途修正が必要です。

標準的な導入方法の場合、SiteCatalystは2o7.netまたはomtrdc.netのドメインで発行するCookieにビジター固有のIDを保存します。計測対象サイトとは異なるドメインと送受信されるため、「第三者のもの」という意味でサードパーティーCookieと呼ばれます。

3rd-party Cookieは便利なので、手軽に使われてきました。

• 自社ドメインの発行Cookie数が増えない
  （IEではドメインあたりのCookie数が20に制限されます）
• 複数のドメインを超えても同じCookieが使える
  （1st-party Cookieの場合、例えば.cms-ia.infoにセットすればgoogle.cms-ia.infoとwww.cms-ia.infoのドメインで同じCookieを読み書きできますが、s.evar7.orgとはシェアできません）

一方、訪問していないサイトへ知らないうちに行動データが送信されるのが最近はプライバシーの観点で問題視されるようになってきました。
ブラウザの設定を変更すると、この3rd-party Cookieを無効にすることができますが、AppleのSafariは最初から3rd-party Cookieが無効になっています。FirefoxやIEも、メジャーアップグレードで3rd-party Cookieを無効にするのがデフォルト設定になる可能性があります。ウイルス対策ソフトによっても、3rd-party Cookieを無効化したり定期的に削除する場合があります。

という背景で、3rd-party Cookieの拒否率は日々上昇しています。

その割合やスピードは業界やサイトによって異なるため、

• 自社サイトのサードパーティー拒否率を定期的にチェックする
• ファーストパーティーCookieへの移行プランを立てる

Cookie拒否率の調べ方