FAQ

テストページや、サーバー死活監視用のページ、特定のディレクトリ内のページへの定期アクセスを集計対象から除外することが可能です。

ファイル名称、PDFやCGIなどの拡張子について、特定のディレクトリ内であっても集計対象から除外することが可能です。

自社内や協力会社からのアクセスや、Webサーバーの死活監視用サーバーからの定期的なアクセスをドメイン名やIPアドレスにて排除することが可能です。

ボタンなどをクリックした際に通信が都度サーバーと送受信される作り（アクションスクリプトへのスクリプト追加など）によって、ユーザビリティチェックを含め、ユーザー行動・動線解析などRTmetrics、RTbandwidthでの解析が容易に可能です。

都度通信が行われない作りであっても、Javascript（アクティブスクリプト）にて、ボタンなどをクリックした際に通信が都度ダミーページなどと行われる作りにするなどで解析可能になります。

広告やリンクにパラメータを付与することで可能になります。

例：「www.a.com/index.html」へのリンクを外部のbというサイトに依頼する際に、「www.a.com /index.html?ad=b」として広告を出稿します。この事で、bというサイトの広告をクリックして「www.a.com」というサイトに来訪した場合、「www.a.com/index.html?ad=b」と集計できるため、自然来訪や他のリンクからの来訪と区別し集計することを可能にします。 RTmetricsでは「ad=」について1件1件設定せずに「ad=b」「ad=c」「ad=d」それぞれ広告別に集計出力可能です。

リスティング広告キーワード出稿時にパラメータを付与することで可能になります。

例：「www.a.com/index.html」へのリンクにbというキーワードで出稿する際に、「www.a.com/index.html?key=b」としてキーワードを出稿します。
この事で、bというサイトの広告をクリックして「www.a.com」というサイトに来訪した場合、「www.a.com/index.html?key=b」と集計できるため、自然検索での来訪と区別し集計することを可能にします。 RTmetricsでは「key=」について1件1件設定せずとも「key=b」「key=c」「key=d」それぞれキーワード別に集計出力可能です。

QRコード出稿時にパラメータを付与することで可能になります。

例：「www.a.com/index.html」へのリンクをbという媒体にQRコードを出稿する際に、「www.a.com /index.html?qr=b」としてQRコードを作成します。
この事で、bという媒体のQRコードをクリックして「www.a.com」というサイトに来訪した場合、「www.a.com/index.html?qr=b」と集計できるため、bという媒体からの来訪と区別し集計することを可能にします。

RTmetricsでは「qr=」について1件1件設定せずとも「qr=b」「qr=c」「qr=d」それぞれ媒体別に集計出力可能になります。

多くのアクセス解析ソフトは、「個」を特定する判断にIPアドレスを使用します。しかし、最近は会社や家庭で1個のIPアドレスを複数人で共有するケースが多くあり、指標としては有効といえますが、「個」を特定する精度としては落ちつつあります。
RTmetrics、RTbandwidthでも同様に、デフォルトではIPアドレスとブラウザ名（User-Agent）の組み合わせにより、「個」を特定しています。
WebサイトやWebサーバーの構成及び、PCサイト、携帯サイトなどの対象としているブラウザによっては、IPアドレス+User-Agent以上に精度の良い「個」を特定する情報が含まれている場合があります。このような場合、この値を基軸とすることでより精度の高い判定が可能になります。

ユニークユーザーの判別方法の例については

• cookieのセッション情報を元にユニークユーザーを識別できますか？
• 会員IDを元にユニークユーザーを識別できますか？
• cookie未対応のブラウザを考慮しているWebサーバーでユニークユーザーを識別できますか？

をご確認ください。

RTmetricsは、パケットキャプチャ方式で実装している場合、HTTPヘッダ情報を解析することができるため、Cookieを用いた精度の高いユニークユーザーの判別が可能になります。 多くのWebサイトは、Cookieの使用を前提にしており、HTTPリクエストのCookieヘッダとHTTPレスポンスのSet-Cookieヘッダの両方を取得対象とする設定を入れるだけでセッションの先頭から漏れなくデータを記録することができます。

ユニークユーザーの判別方法の例については

• 会員IDを元にユニークユーザーを識別できますか？
• cookie未対応のブラウザを考慮しているWebサーバーでユニークユーザーを識別できますか？

をご確認ください。

RTmetricsは、ユニークユーザーを識別する設定を自由に定義できるようになっています。Cookieを使用していないWebサイトの場合でも、セッションIDやIPアドレス＋User-Agentなど、代替となる値を取得する設定を入れることでユニークユーザーとして記録することが可能です。

ユニークユーザーの判別方法の例については

• cookieのセッション情報を元にユニークユーザーを識別できますか？
• 会員IDを元にユニークユーザーを識別できますか？

をご確認ください。

RTmetricsは、ユニークユーザーを識別する設定を自由に定義できるようになっています。セッション内において会員IDが取得できるコンテンツ構成になっているWebサイトにおいては、その値を取得する設定を入れることでユニークユーザーとして記録することが可能です。

ユニークユーザーの判別方法の例については

• cookieのセッション情報を元にユニークユーザーを識別できますか？
• cookie未対応のブラウザを考慮しているWebサーバーでユニークユーザーを識別できますか？

をご確認ください。

RTmetricsは、ユニークユーザーを識別する設定の他に、同一セッション内で一時的に取得できた値を保存時に使用する設定（ユニークユーザーID（保存時））を選択できるようになっています。これは、Cookieでユニークユーザーを判別しておいて、かつ同一セッション内で訪問者にログイン行動があり、ログインIDも取得できた場合において、ログインIDの値でユニークユーザーのデータを記録させることができる機能です。もう一つのやり方は、アプリキーにログインIDを取得する設定を入れ、各セッションに紐つくラベルとして使用する方法です。ユニークユーザーは、Cookieの値で記録されていますが、Cookieの一連の行動は、アプリキーで取得したログインIDでラベリングされています。このログインIDの値で、特定のセッションの行動データをDBから抽出したり、レポートの分析結果をフィルタして、特定のログインIDの訪問で絞り込む、などが可能です。

ユニークユーザーの判別方法の例については

• cookieのセッション情報を元にユニークユーザーを識別できますか？
• 会員IDを元にユニークユーザーを識別できますか？
• cookie未対応のブラウザを考慮しているWebサーバーでユニークユーザーを識別できますか？

をご確認ください。

広告効果測定、コンバージョン測定にて、あらかじめ指定した経路ポイントを通った全セッション数と、入口（ランディングページ）の詳細内訳を集計することが可能です。

「www.a.com/campaign.html」というページと、「www.a.com/campaign_success.html」というページを経路ポイントとして設定することで、「www.a.com/campaign.html」に来訪した全セッション数と流入元、入口ページと、「www.a.com /campaign.html」を通って「www.a.com/campaign_success.html」まで来訪した全セッション数と流入元、入口ページの測定が可能になります。

キャンペーンページを経由して、会員登録や購買完了といったコンバージョンを測定したい場合、キャンペーンの入口となる広告が掲載されているページ、そこから移動する応募ページや購入ページといった経路ポイントを設定するだけで、登録した経路を通過したセッションの測定が可能になります。

外部からの流入測定については

• サイト外広告やリンクなどからのアクセスを区別して集計することはできますか？
• リスティング広告のキーワードからのアクセスを区別して集計することはできますか？
• QRコードからのアクセスを集計することはできますか？
• キャンペーンページへの流入元の測定はできますか？

をご確認ください。

サイト内検索ページに引数として検索単語が付いたリクエストが送信されて来るので、その引数を処理することでサイト内の検索窓で検索された検索用語を取得することが可能になります。
サイト内の検索窓で検索された検索用語が使われた回数と、自然検索にて検索された検索用語、リスティング広告で利用された検索用語を個別に測定可能です。

リスティング広告のキーワードからの流入測定については

• リスティング広告のキーワードからのアクセスを区別して集計することはできますか？

をご確認ください。

通常RTmetricsはHTTP応答コードのエラー以外の応答コードのアクセスのみを解析対象としています。これを逆に、アクセスされたページが存在しなかった場合の応答コードである「404」のみを解析対象と設定することで、リンク漏れページなどを測定することが可能になります。

さらにReffererヘッダの情報を追加することで、どのページからのリンクが切れているかなども測定することが可能になります。
RTbandwidthは400番以降のエラーコードの集計を標準機能として搭載しているので、 RTmetricsとRTbandwidthの併用がお勧めです。

BlogやCMSといったツールも含めると、動的に生成されるサイトは非常に増えてきており、ページ名だけではなく引数も合わせた形で集計対象ページとなるケースが増えてきています。
HTTPにおけるページへの引数の受け渡し方は「GET」と「POST」の2種類のメソッドがありますが、RTmetrics、RTbandwidthではこれらを特に区別することなく処理することが可能です。

例えば、GETにおいては「www.a.com/index.html」（ページ名）の後ろに「?a=A&b=B&c=C」、POSTにおいては「」（ボディ）部分に「a=A&b=B&c=C」となります。 RTmetricsではこれらの引数を一元的でも、個別でも自由に分析することが可能です。

RTmetricsのコレクターサーバーが設置できない環境に、解析対象としたいWebコンテンツがあった場合に、対象WebコンテンツにJavascriptタグを埋め込むことで、タグが埋め込まれたページが呼ばれる際に、RTmetricsのコレクターサーバーが設置された場所へアクセス情報を送り、RTmetricsでのアクセス解析に準じた解析を行うことが可能になります。

RTmetricsのタグ受けサーバー用のモジュールとして、Beacon Collectorのライセンスをご用意しています。 取得したいデータに対して、どのようにタグをカスタマイズし、Webサイトに実装すればよいかについては、カスタマーサポートにて参考資料をご用意していますので、お気軽にお申し付け下さい。

詳細につきましてはこちらよりお問い合わせください。

取得するパケット内に測定したい暗号化パケットが存在している場合、RTmetrics、RTbandwidth用のSSLデコードモジュールを使用し、分析対象となるWebサイトのサーバー秘密鍵（以下：秘密鍵）を登録することで分析可能となります。

専用SSLデコードモジュールがサポートする方式は以下となります。
※ IEの場合SSLv3/RSA/RC4/MD5の組み合わせが最優先に使用されます。
※ 輸出用40ビット暗号化アルゴリズムには対応しておりません

カスタマーサポートにて手順書をご用意しております。お客様ご自身や導入した代理店、システム運用を担当されているベンダーにて作業を実施される場合は、カスタマーサポートまでご相談下さい。
バージョンアップに際して、サーバ更改を伴う場合は、作業期間中に限定し、新旧環境を並行稼働できるように、作業用のテンポラリライセンスをご提供いたします。
AURIQにて、バージョンアップ作業およびサーバ更改作業をお請けすることも可能です。

詳細につきましては、担当営業へのお問い合わせ、もしくはこちらよりお問い合わせください。

RTmetricsではデータを採取するコレクターサーバーと、データの蓄積管理を行うデータマネージャーサーバー間の通信について、変動要因はありますが、通常計測ポイント（接続するミラーポート）のデータ総量の1%程度を目安としてお考えください。 RTbandwidthでは、5分毎に基本統計データ：400byteと詳細ログデータ：最大7Mbyte（通常数100Kbyte）を設定したMU（モニタリングユニット）毎に通信が発生します。

変動要因については、一般的に以下のポイントになります。

• 計測ポイントのデータ総量に占める暗号化（https）ページの量が多い場合
• 計測したいURLの長さが数10バイトを超える極端に長い文字列の場合
• RTmetricsにて、.gif、.jpgなどデータ量が増加する要因となるデータの解析が多い場合

ログ型でご利用中の場合は、キャッシュサーバーのログ、Webサーバーのログのフォーマットをご確認の上、それぞれのカラム構成に合わせて、ログ取込のセットアップを行って下さい。
パケットキャプチャでご利用中の場合は、以下のどちらのケースに該当するかご確認の上、環境に適した設定を行って下さい。

• Webページ自体はWebサーバーにアクセスさせ、イメージなど負荷の高いコンテンツのみをキャッシュサーバーにて処理をしている。
  このケースでは、負荷の高いコンテンツ自体を分析したいという要望でなければ、Webページとのアクセスが 発生していますので、特に設定をせずアクセス解析を行うことが可能です。
• Webページを含む全ての静的コンテンツをキャッシュサーバーにて処理をしている。
  一般的なキャッシュサーバーでは、Web上のオブジェクト毎に、オリジナルのWebサーバーの内容をTTL （Time To Live）と呼ばれる値にて同期の頻度が設定可能です。このTTLを0に設定されたオブジェクトは、 キャッシュサーバーからオリジナルのWebサーバーまで、更新が無いかのステータス確認リクエストが発生 します。更新情報が無い場合は「変更無し」のステータスコードがキャッシュサーバーに送信され、 キャッシュサーバーより、キャッシュを利用してユーザーに戻します。

RTmetricsでは、このステータス確認のパケットを分析することで、キャッシュサーバーを利用していてもアクセス解析を行うことを可能としています。
TTLを0としても、ステータス確認のパケットのみが送受信されることとなり、元データの更新が行われない限りキャッシュとして機能されますので、ネットワークとサーバーには負荷をかけることなく、 キャッシュサーバーの機能を活かしながらRTmetricsで解析を行うメリットがあります。
尚、キャッシュサーバのコンテンツについては、タグを併用することも選択肢としてご検討下さい。

RTmetrics、RTbandwidthではAPIを公開しています。
このAPIにより、レポートのエクスポートがLinuxのコマンドラインから行うことが可能になります。

取得したデータから任意のレポートデータを外部に取り出すことが可能になり、お客様の顧客データベース、売上データベースなどと RTmetricsで取得した顧客会員IDを紐付けたり、商品IDを紐付けることで、よりKPIに活用可能なデータを生成することが可能になります。

解析可能です。

VLANタグ（802.1Q）付きのトラフィックはサポートしています。ただし、この場合はミラーポートに接続されているインターフェースのドライバもVLANタグをサポートしているものを使用する必要があります

AURIQでは、ご利用になるサイトの設置環境やサイトのトラフィックの状況に合わせて、RTmetricsをインストールするサーバーの推奨スペックをサイジングさせて頂いております。ご導入から数年が経過し、利用サイト数が順調に増加、あるいはサイトが成長し、トラフィックが当初と比較して大幅に増大するなどの状況に付随して、パケットロスが問題になるケースがあります。パケットロスの原因については、以下の要因が考えられます。

• スイッチのミラーポートでパケットをロスしている
• コレクターサーバーにてパケットをロスしている（NICが原因）
• コレクターサーバーのOS、Linuxのカーネルによりパケットをロスしている
• RTmetrics、RTbandwidthがパケットをロスしている

AURIQ製品のご使用にあたり、気になる事象がありましたら、カスタマーサポートまでお気軽にご相談下さい。

RTmetrics、RTbandwidthは1つのグループの中に設定したドメイン、IP（サイト設定）を、解析を行う際に解析対象自身のサイトとして判断します。よって、複数ドメイン、IPの分析が必要な場合は以下のようなグループ分けを行うことで、それぞれ個別のサイト（サイト設定）と考え、サイト（サイト設定）間の移動を解析したい場合と、サイト（サイト設定）をひとまとめに考え、外部からのアクセスとサイト内の行動解析がしたいといった別視点にて解析することが可能になります。

グループに全サイトを設定

設定されたサイト（サイト設定）間の遷移を動線分析・解析可能（広告効果測定、順方向経路解析、逆方向経路解析など）

ドメイン・IP別にグループを作成して、それぞれのサイトを設定

設定されたサイト（サイト設定）のみの動線分析・解析可能（広告効果測定、順方向解析、逆方向経路解析など）

例1：1MUずつ2グループを作成した場合

グループ設定1の場合、解析対象サイトのドメイン「www.a.com」を1MUに登録し、登録したドメイン配下の解析が可能になります。

グループ設定2の場合、解析対象サイトのドメインがロードバランサなどによりサーバーを分散させている際に「www1.a.com」「www2.a.com」「www3.a.com」の3つのサーバー、ドメインを1MUに登録し、ドメイン配下を一括した分析が可能になります。

各グループに登録する閲覧ユーザー数に制限はありません。権限についても、管理者権限から閲覧のみの権限まで強力なグループユーザー管理機能を持っているため、全社レベルでビジネス組織に合わせた柔軟な運用が可能になります。

例2：5MUを3グループに振り分けた場合

グループ設定1	グループ設定2	グループ設定3
サイト設定1	サイト設定2	サイト設定4
www.a.com https://www.a.com	www.b.com	www1.d.com/link/ www2.d.com/link/ www3.d.com/link/
	サイト設定3	サイト設定5
	www.c.com	www1.d.com/shop/ www2.d.com/shop/
閲覧ユーザー	閲覧ユーザー	閲覧ユーザー
administrator@a.com	administrator@b.com	administrator@d.com
marketing@a.com	marketing@b.com	sales@d.com
marketing@d.com	marketing@b.com	shop@d.com

グループ設定1の場合、解析対象サイトのドメイン「www.a.com」「https://www.a.com」を1MUに登録し、登録したドメイン配下の解析が可能になります。

グループ設定2の場合、解析対象サイトのドメイン「www.b.com」をサイト設定2に1MUを使用して登録し、「www.c.com」をサイト設定3に 1MUを使用して登録することで、「www.b.com」配下の解析結果と、「www.c.com」配下の解析結果をそれぞれレポートします。また、「サイト設定2」と「サイト設定3」の間の渡り歩きも分析可能になります。

グループ設定3の場合、解析対象サイトがロードバランサなどにより分かれていた場合「www1.d.com/link/」「www2.d.com/link/」「www3.d.com/link/」をサイト設定4に1MUを使用して登録し、「www1.d.com/shop/」「www2.d.com/shop/」をサイト設定5に1MUを使用して登録することで、「www1.d.com/link/」「www2.d.com/link/」「www3.d.com/link/」配下の解析結果と、「www1.d.com/shop/」「www2.d.com/shop/」配下の解析結果をそれぞれレポートします。また、「サイト設定4」と「サイト設定5」の間の渡り歩きも分析可能になります。

各グループに登録する閲覧ユーザー数に制限はありません。権限についても、管理者権限から閲覧のみの権限まで強力なグループユーザー管理機能を持っているため、全社レベルでビジネス組織に合わせた柔軟な運用が可能になります。

例3：5MUを5グループに振り分けた場合

グループ設定1	グループ設定2	グループ設定3
サイト設定1	サイト設定2	サイト設定3
www.a.com https://www.a.com	www.b.com https://www.b.com	www.c.com https://www.c.com
閲覧ユーザー	閲覧ユーザー	閲覧ユーザー
administrator@a.com	administrator@b.com	administrator@c.com

グループ設定4	グループ設定5
サイト設定4	サイト設定5
www.d.com https://www.d.com	www.e.com https://www.e.com
閲覧ユーザー	閲覧ユーザー
administrator@d.com	administrator@e.com

グループ設定1、グループ設定2、グループ設定3、グループ設定4、グループ設定5の場合、解析対象サイトのドメインを1MUに登録し、サイト設定内に登録されたドメイン配下の解析が可能になります。
各グループに登録する閲覧ユーザー数に制限はありません。権限についても、管理者権限から閲覧のみの権限まで強力なグループユーザー管理機能を持っているため、全社レベルでビジネス組織に合わせた柔軟な運用が可能になります。

2013年10月現在、 MUは最少単位5MUから販売をしております。追加MUに関しましては、10MU、50MU、100MUという単位で販売をしております。 MU追加に関しましても同様の単位で販売しております。
価格などに関しましてはこちらよりお問い合わせください。

クラウドでのRTmetricsをご利用する場合、以下の3種類の方法がございます。

AWSやプライベートクラウドなど、お客様の環境に最適な方法をご提案します。
対応バージョンなど詳細については、こちらよりお問い合わせください。
尚、タグ型、ログ型については、クラウド・実機などWebサイトの設置環境に依存することなく、ご導入が可能です。

下記参考値はお客様の解析要件、データの保存期間に大きく依存するため、ハードウェアでの動作を保障するものではありません。
CL=コレクターモジュール / DM=データマネージャーモジュール
※上記値は標準的な環境での最低推奨スペックとなります。お客様のトラフィックの傾向や解析要件（保存期間・解析設定数）に依存して変化します。具体的な必要容量を算出につきましては、サイジングに必要な情報をご提供いただく必要がございますので、お問い合わせください。

※コレクターサーバーが搭載するネットワークインターフェースは、通常の通信用途の他にキャプチャー用インターフェースを必要とします。

※コレクターサーバーのディスク容量は、OSの稼動分に加え、コレクターモジュール用に１GB 程度の領域が必要となります。

下記参考値はレポートにアクセスするユーザー数、アクセス頻度、および一度のクエリで引き出すレポートデータの期間、量に大きく依存するため、ハードウェアでの動作を保障するものではありません。

CL=コレクターモジュール / DM=データマネージャーモジュール
※上記値は標準的な環境での最低推奨スペックとなります。お客様のトラフィックの傾向、解析要件（保存期間・解析設定数）、レポートの閲覧状況（同時閲覧数・人数・期間）に依存して変化します。具体的な必要容量を算出につきましては、サイジングに必要な情報をご提供いただく必要がございますので、お問い合わせください。

※データマネージャーサーバーのディスク容量は、OSの稼動分に加え、データマネージャーモジュール用に１GB 程度、UIのキャッシュ領域に10GB以上に、取得データの蓄積用データベースの領域が必要となります。

※上記値は標準的な環境での最低推奨スペックとなります。お客様のトラフィックの傾向、解析要件（保存期間・解析設定）、レポートの閲覧状況（同時閲覧数・人数・期間）に依存して変化します。具体的な必要容量を算出につきましては、サイジングに必要な情報をご提供いただく必要がございますので、お問い合わせください。

※AMサーバーのディスク容量は、OSの稼動分に加え、AMモジュール用に１0GB程度、取得データの蓄積用データベースの領域が必要となります。

下記の値は標準的な環境におけるデータベースで必要なディスク容量の目安です。こちらは、解析対象、解析範囲、設定する項目数、取得するデータ量に大きく依存するため、具体的な必要容量を算出につきましては、サイジングに必要な情報をご提供いただく必要がございますので、お問い合わせください。

[データマネージャーサーバーのデータベース容量の目安]
1サイトあたり月間1000万PVあたり約2GB/月

例）月間1000万PVのサイトを5サイト解析して3年分保存する場合
5サイト × 2GB × 36ヶ月 = 360GB

また、AM利用時には、AM用中間データの保存先として1サイトあたり月間1000万PVあたり約2GBが必要です。

[AMサーバーのデータベース容量の目安]
1サイトあたり月間1000万PVあたり約7GB/月

例）月間1000万PVのサイトを5サイト解析して3年分保存する場合
5サイト × 7GB × 36ヶ月 = 1.3TB

AURIQでは、導入フェーズから運用フェーズにいたるまで、お客様の課題に合わせた各種サービスをご用意しております。

提供中のサービスについては、プロフェッショナルサービスのページをご確認ください。

導入フェーズのサービスとして、サーバーの設置およびインストール作業を行う「RTmetrics・RTbandwidth導入設置サービス」、導入設置後、解析要件やデータの利用目的に合わせて適切な設定を実装し、分析に利用するレポートのセットアップをご支援する「設定コンサルティングサービス」をご用意しております。保守にご加入頂くことで、毎年3名様まで無償でRTmetricsのトレーニングコースを受講頂けますので、無理なくアクセス解析やツールの使い方のノウハウを身につけて頂けます。

提供中のサービスについては、プロフェッショナルサービスのページをご確認ください。

RTmetricsを活用した分析運用をご支援するレポーティングサービス「アクセスログ分析サービス」をご用意しております。

提供中のサービスについては、プロフェッショナルサービスのページをご確認ください。