Categories
Web分析一般

意識データと行動データ 2

前回の続き
意識データと行動データ 1

それでもあえて意識データを擁護する

このように時代は明らかに行動データへと傾きつつ有り、行動データによって成果もあげつつあります。しかし、ここでは、あえて意識データを擁護したいと思います。
まずは、意識データへの不信への回答から始めたいと思います。
一つ目の疑問:「人の意識を数量化することができるのか?」
答え。できません。全てのユーザー調査は恣意的にならざるを得ないと思います。学問的な誠実さから考えると、明らかに失格です。僕は学生時代は社会学のエスノメソドロジーという分野を学んでいました。エスノメソドロジーについては、詳しく述べることはしませんが、エスノメソドロジーでは「実践の厳密な記述」を目指します。自ら調査主体の構成員となり、内側の視点から社会の構築を記述します。このことによって学問としての真摯さを保とうとします。
このように、意識を数量化することは学問的には無理があります。しかし、それが本当に役に立たないのかというと疑問です。マーケティングでは学問的な厳密さよりも、「役に立つかどうか」の方が重要です。学問的な厳密さには欠けるものの、アンケートデータは役に立つ程度のデータを出すことは可能です。そのためには、無理のない調査設計を行うことと、結果の解釈は有意性検定に基づいて行うことが必要です。これにより、ある程度の信頼性は保障されます。ビジネスにおいては「ある程度」で十分だったりします。
2つ目の疑問:「人は自分の意識を言語化することができるのか?」。答え、ほぼ無理です。質的調査では、これに対する回答として2つの方法があります。1つは他者が人の意識を解釈する。2つ目は言語化するスキルを持った人自らが調査対象となり、記述することです。1つ目の方法がエスノグラフィーであり、2つ目の方法が先ほど述べたエスノメソドロジーです。
問題は量的データです。量的調査では質的調査のような解決方法は適用できません。しかし、ここでも回答は1つ目と同じです。ある程度正しければ良いのです。役に立つ程度の信頼性はあります。

量的データと質的データ

これまで、あえて量的データと質的データの両方を扱ってきましたが、ここで一旦整理したいと思います。なぜかマーケティングの世界では意味不明な定量データ、定性データという言葉で呼ばれることが多いですが。
この2つのデータの違いは明白です。数学として取り扱えるか否かです。「テキスト」それ自体では、質的データですが、テキストマイニングを行い、数値化すると量的データへとなります。
量的データと質的データには4つの点で大きな違いがあります。

  • 抽象性
  • コンテキスト
  • 解釈の自由度
  • データの代表性

量的データは抽象性が高く、コンテキストが希薄で、解釈の幅が狭く、データの代表性が高いです。質的データは、全てその逆です。簡潔に書くと、量的データには有無を言わせない数字のチカラがあり、質的データは、いかようにも解釈できる、という具合です。
しかし、一方では量的データからは発想の飛躍がしにくいということも言えます。これはデータの性質以前にデータ収集の段階で、決められた枠内でしかデータが収集できないということからも生じます。つまり、量的データは基本的に「仮説検証型」のアプローチであり、データから「探索的に」何かを発見することは難しいと言わざるを得ません。データマイニングは探索型のアプローチとも言えますが、これは小さな仮説検証を積み重ねるという意味での探索型調査であって、本当の意味の探索型アプローチをしようとすると、いくら時間があっても足りません。データの代表性の問題は常に残りますが、新たな発見や新しい発想を生み出すための調査としては質的データに頼る他ありません。(データの代表性については、GTA:グラウンデッド・セオリー・アプローチのやり方はうまくやっていると思います。問題の解消はできていませんけど。なんかWikiPediaの説明は、かなり偏っていますが。。。)
質的データにも当然、意識データと行動データがあります。しかし、質的データにおいては両者に大きな違いはありません。なぜなら、それらの違いよりも「解釈」の違いの方が圧倒的に大きな影響力を持つからです。ユーザーテストによる「観察データ」は、行動データであり、デプスインタビューによるインタビューは意識データです。エスノグラフィーによる参与観察はインタビューを通して、意識を探り、観察を通して行動を理解します。エスノメソドロジーについては、行動なのか意識なのかは既に重要ではありません。どの種類の調査にとってもデータの種類よりも解釈のほうが遥かに重要です。

まだ続きます。

意識データと行動データ 3

Categories
Web分析一般

意識データと行動データ 1

意識データと行動データ

マーケティングリサーチで用いられるデータには意識データと行動データの2種類のデータがあります。意識データとはユーザーが考えていることをデータ化したもので、行動データはユーザーが行動した結果をデータ化したものです。よく混同されるのですが、定量データ(量的データ)と定性データ(質的データ)とは別物です。意識データにも量的、質的データの両方があり、行動データにも量的、質的データの両方があります。あくまでもデータとなる対象が、意識か行動結果かの違いです。他にもデモグラフィック属性データなどもありますが、ここでは割愛します。
ここ最近この2つのデータについて、あれこれと考えていたのですが、まだ考えがまとまっていません。まとまってはいないのですが、考えている途中結果をここに書いてみようと思います。

行動データの優位性

近年のマーケティングデータ分析における大きな転回として、意識データから行動データへ、という点が挙げられます。以前はそもそも行動データ(量的)を取得することはほとんど不可能でした。マーケティングで利用するユーザー調査データの大多数がアンケートで取得された意識データでした。しかし、POSシステムによって状況は一転します。POSによって、「いつ、どの商品が、どんな価格で、どんな人に対して、いくつ売れたか」がわかるようになりました。人がある時点で「考えていた」情報よりも、実際にとった「行動」の方が圧倒的な説得力を持って迎え入れられます。POSデータを基にした仕入れは当たり前のように行われるに至りました。
Webの登場も行動データへの転回に大きく貢献します。Webではアクセスログを通して、ユーザーの「行動」が詳しくわかります。ユーザーが、どこから来て、どのページを見て、購入してくれたのかどうかが簡単にわかります。ユーザーの行動結果こそが真理であり、行動結果を改善するために何をすれば良いのか、がマーケティングとなってきています。
ここにおいて、マーケティングとマーケティングリサーチの垣根が低くなります。つまり、マーケティング施策とマーケティングリサーチが、同時に行われるようになります。A/Bテストや、MVTなどの実験調査は、まさしくマーケティングとリサーチが同時に行われる手法です。新たなマーケティング施策を行い、次の施策へのリサーチも同時に行う。マーケティングとリサーチが同時に行われることで素早い改善が可能となります。これも結果へと直線的に結びつく行動データが容易に取得できて初めて成り立つ手法です。

意識データの劣勢

利用されるデータが行動データへと大きく傾いているのは、行動データが取れるようになったことだけが原因ではありません。意識データへの不信がその根底にあります。その根本的な不信は以下の2点です。

  • 人の意識を数量化することができるのか?
  • 人は自分の意識を言語化することができるのか?

最初の要因は、意識データというよりも量的データに対する疑問です。行動データが取得される前は、量的データといえば、人口統計データか、アンケートによって作成される意識データでした。アンケートにおける設問は全て設問作成者による恣意的なものであり、事前に作成された仮説を検証するために作られます。仮説を検証するために有利に調査を設計することから逃れられません。また、アンケートの回答も恣意的となります。例えば、5段階尺度でのアンケートで、3段階目と4段階目の境目の解釈は人によって、大きく異なります。それを同一の尺度で語っても良いのかという疑問があります。人口統計データでも、アンケートでも同様ですが、何らかの事象を数量化するとき、必ず「定義」が必要となります。定義は量的データを作成したものによって恣意的に行われざるをえません。
2つ目の要因はより根本的です。自分は自分のことをどれだけ知っているのかという問いへと繋がります。特に未来のことについては、自分自身でも全くわかりません。コンビニに買い物へ行く前と、実際に買ったものを比べてみると、全然違う買い物をしているということも往々にしてありえます。過去に行ったことに対する意識については、まだ妥当性は高いですが、記憶は常に捏造されます。記憶とは現在の意識に基づいて再構成されるものです。過去に取った行動と現在の状況が異なるとき、過去にとった行動を書き換えてしまいます。

長いので続きます。
意識データと行動データ 2

Categories
Web分析一般

アクセス解析ツールの仕組み(TPPモデル)

ruby+mongoDBでアクセス解析ツールを作ってみて、アクセス解析ツールの仕組みがよく理解できました。アクセス解析ツールの説明をしている本やWebサイトなどよくありますが、多くは表層的な解説だけで本質的なところは解説できていません。というか、おそらく理解すらしていないと思います。
ちょっと技術よりになって難しいかもしれませんが、ここでは本質的な理解ができるような解説をしたいと思います。本質的な理解をすることで、各解析ツールがなぜああいう動作をしているのかを理解することができると思います。そして、結局は自分で作った方がいいやって思うと思います。

アクセス解析ツールのTPPモデル

アクセス解析ツールは3つの階層によって成り立っています。
1つ目は、データを取得する層(トラッキング層)
2つ目は、データを処理し、DBに格納する層(プロセッシング層)
3つ目の層は、データをUI上に表示する層(プレゼンテーション層)です。
このアクセス解析ツールの3階層モデルを、僕は勝手にTPPモデルと呼んでいます。
全てのアクセス解析ツールはこの3層モデルで理解することができます。

トラッキング層

トラッキング層はアクセスログを取得する仕組みを提供します。
よく言われるように、アクセス解析ツールはトラッキング層によって3つに分類されます。

  • サーバーログ型
  • パケットキャプチャー型
  • JavaScript型(ビーコン型)

サーバーログ型はWebサーバーが吐き出したログデータを利用して解析を行います。アクセス解析ツール自体はトラッキング層を提供しておらず、Webサーバーがトラッキング層を担当します。ツールによっては、ApacheやIIS用のモジュールを提供して、Webサーバーに組み込んだ形でトラッキング機能を追加するものもあります。モバイル系の分析で用いられることが多いです。

2つ目のパケットキャプチャー型はWebサーバーの通信を監視して、通信したパケットを傍受したデータを解析します。トラッキング専用の「箱」が必要となります。

3つ目のJavaScript型が現在主流となっているトラッキング方法です。ページにアクセスする度に、Webページ上にごく小さなgif画像(ビーコン)を読み込んで、その画像のログデータを解析します。
JavaScript型の優れている点は、JavaScriptを利用して、自由にカスタマイズしたデータを取得することが出来る点です。JavaScriptでできることであれば、ほとんどどんなデータも取得することができます。

取得できるデータ量としては、圧倒的にJavaScript型が優っており、今後導入するのであれば、JavaScript型一択ですが、他の方法にも利点があります。
まず、サーバーログ型ですが、Webサーバーはデフォルトの状態でアクセスログを吐き出しています。そのため、分析を始める前の段階からデータが揃っていることになります。よって、過去に遡って解析することが可能です。また、データが自社環境の外側にでないので、セキュリティ上望ましいと考えられることも多いです。実は、サーバーログ型も工夫次第では、多岐に渡ったデータを取ることも可能です。

次にパケットキャプチャー型ですが、規模が大きくなるとTCO(トータルコストオブオーナーシップ)が他のツールよりも優れている場合が多いです。あとは、特にないかな。。。

後で、詳しく書きますが、アクセス解析ツールをこの3つに分類するだけでは不十分です。プロセッシング層とプレゼンテーション層における処理内容も各ツールで大きくことなります。TPPモデルで理解することで初めて、アクセス解析ツールを理解できるようになります。

プロセッシング層

2つ目の層はプロセッシング層です。ここは多くのツールにとって、ユーザー側に見える部分ではないので、あまり意識されませんが、アクセス解析ツールのキモとなる部分です。

どのようなことをするのかというと、ログデータを利用しやすい形に変換して、DBに流し込むという作業を行います。ここでどのように処理して、どのような形式でDBに入れるのかによって、アクセス解析ツールの性質が大きく変わります。

プレゼンテーション層

3つ目の層はプレゼンテーション層です。ここでは処理済みのデータを集計して、表やグラフとしてブラウザ上に表示させたり、CSVとしてダウンロードさせたりします。
この層がそれぞれの解析ツールの見せ場となります。どうでもいい素敵なグラフや、かっこいいだけで使いにくいUIなど、多くのツールベンダーはこぞってプレゼンしてきます。全力で無視しましょう。

どこで集計をするのか?

トラッキング層はデータを収集するだけなので、集計は含まれていません。集計は多かれ少なかれ、プロセッシング層とプレゼンテーション層の2つの層で行っています。このどちらの層で主に集計を行うのかでツールの性質が変わってきます。

SiteCatalystなどリアルタイム計測が可能なツールはプレゼンテーション層における集計を重視しています。おそらくプロセッシング層では、ほとんど集計作業を行わずにデータを変形させてDBに格納しているだけのものと思われます。

WebTrendsは逆にプロセッシング層でかなりの集計を行っていて、プレゼンテーション層では集計済みのデータを加工しているというような位置づけだと思われます。日次程度で、プロセッシング層における集計作業をバッチ処理させて、プレゼンテーション層に受渡します。そのため、リアルタイムでのデータ反映は不可能です。

当然、プレゼンテーション層での集計の方がオンデマンドでの集計ができるため、ユーザーにとっては望ましいものとなります。ただし、ユーザーからリクエストがあるたびに毎回集計しなおさなければならないため、サーバーに負荷がかかり、集計に時間がかかります。この負荷を下げるために3つの工夫をしています。
1つはキャッシュ処理。1度行ったクエリはキャッシュとして保存しておいて、同じクエリを行なった場合はキャッシュ側からデータが送信されます。
2つ目はデータ型の工夫。例えばSiteCatalystでは滞在時間を正確な秒として保存していません。「1分~3分の間」のような形にして保存しています(そのため平均滞在時間は推定値となっています)。その他にもDBに格納するデータ形式を工夫して集計量を少なくする工夫を取り入れています。
3つ目はトラッキング層の重視。そもそもサーバー側で集計しなくても良いように、トラッキング層で細かい設定をしてデータを取得することを要求します。そのため、SiteCatalystを使う場合は事前の解析設計が非常に重要になり、計測タグ設計が複雑になります。そしてアナリストはエンジニアじゃないのにと思いながら、ひーひー言います。

一方、プロセッシング層における集計を重視する場合は、集計時にデータの加工ができるため、タグ設計にそれほど悩まなくても良いという利点があります。たとえば、WebTrendsでは集計時に正規表現でコンテンツグループを設定することができます。SiteCatalystやGoogle Analyticsではコンテンツグループの設定はトラッキング層で行わなくてはいけません。集計の柔軟性という意味ではプロセッシング層を重視した方が望ましいことも多くあります。当然、プロセッシング層における設定作業が複雑になり、エンジニアはひーひー言います。

Google Analyticsに関していうと、SiteCatalystとWebTrendsの中間程度だと思います。プロセッシング層における集計の柔軟性は全く無いですが、UI上で効果的な集計ができるためにプロセッシング層である程度の加工を行っていると考えられます。このおかげで、特徴的なアドバンストセグメントとカスタムレポートが可能になっています。その一方で、リアルタイム性が犠牲になっています。

ただ、Google Analyticsもデータの持ち方の工夫や、サーバーの増強で、リアルタイムとまでは言わないですが、かなり早く計測結果が出てくるようになりました。SiteCatalystもVer15でデータの持ち方を工夫して、UI上での集計が多くできるようになるようです(GAのパクリ)。WebTrendsについては、新しいものは知りません。。。。

自家製ツールは?

僕が作っているruby+mongoDBによる解析ツールについていうと、プロセッシング層の極端な重視という特徴があります。というか、プレゼンテーション層は他のツールに任せるという位置づけです。プロセッシング層で強力なバッチ処理を行うことで、既存のツールでは出すことができないデータも集計できるようにしています。
ちなみにトラッキング層についていうと、今のところサーバーログだけですが、画期的なアイデアを思いついたので、トラッキング層で収集するデータも増やすようにする予定です。

Categories
GoogleAnalytics

gaPlugin.js 経過時間計測:timeToCompleteの使い方

■Google Analyticsでタスク完了までの経過時間を計測できる

gaPlugin.jsを使うと、予め設定しておいたスタートページから終了ページまでの経過時間を測ることができます。先日のアップデートでクリック数も同時に取得できるようになりました。データはGoogle Analyticsのカスタムイベントを利用して、googleへと送信されます。
計測の仕組みを簡単に説明すると、スタートページに最初にアクセスした時間をcookie上に保存して、終了ページに到着した際、現在時と保存してある時間を引き算して、経過時間を算出しています。
途中スタートページと同じURLのページを踏んでも、特に計測には影響有りません。セッションの最初にスタートページを踏んだ時にcookieが発行されます。その後に初めて踏んだ終了ページで計測が完了し、データが送信されます。

■何が嬉しいのか?

大前提として、僕はパス系の分析はKPIにはなり得ないと考えています。だからといって、もちろん不要というわけではありません。ユーザーが制作側が描いたシナリオ通りに行動してくれているのかを計る上でパス分析は必要です。

導線評価の方法論としては、以下のエントリを参考にしてください。

http://web-analytics-or-die.org/2010/12/サイトの導線を評価する:基本編/

http://web-analytics-or-die.org/2010/12/サイトの導線を評価する:応用編1/

http://web-analytics-or-die.org/2010/12/サイトの導線を評価する:応用編2/

基本編では、セッションレベルの分析とページレベルの分析について述べています。
応用編では、ページレベルでの分析の応用編です。

タスク完了時間は、セッションレベルの分析での応用例として考えていただければ良いかなと思います。

例えば、リニューアルをして、インデックスページから商品詳細ページまでのナビゲーションを改善した場合、リニューアル前後でインデックスページから商品詳細ページ到達までにかかった時間、クリックした回数を評価することができます。
もし、リニューアル後、ナビゲーションが改善していたのであれば、経過時間もクリック数も減少しているはずです。そうでなれば、リニューアルは失敗だろうと考えられます。
このように、タスク完了までの時間を計測することはユーザビリティを評価する上で有効です。実際、ユーザーテストを行うときも、ストップウォッチを用いて、タスク完了時間を計測することもあります(あんまり良いとは思っていませんが)。

この機能の一番の使いどころは入力フォームだと思います。入力フォームの最初のページから、完了までにかかった時間、クリック数を計測することで入力フォームのユーザビリティを評価することができます。
逆に使うべきではない箇所も多くて、タスクが直線的ではない場合は、ほとんど意味がないデータになると思います。例えば、スタートページからサイトをたくさん回遊して、最終的にゴールページに辿り着かせるという設計方針の場合は、この機能は無意味です。

■設定方法

ここからは、機能の設定方法・有効化の方法を記載します。
まずは、gaPlugin.jsの最新版をダウンロードしてください。

https://github.com/yosimox/gaPlugin.js

*設定ファイルの編集

設定はgaConf.jsというファイルで行います。
gaConf.jsをテキストエディタで開いて、下のように変更してください。

var gaConf = {}
gaConf.conf1 = {
     cnf : {
          //change here
          account : "UA-xxxxxxx-x",
          pageLevel : [1, 2]
     },

     //↓を追加してください。↑のカンマも忘れずつけてください。
     //timeToCompleteの設定
     timeToComplete : {
          //カスタム変数のアクション名を指定してください。
          action : "timeToComplete_TEST",
          //計測開始URLを配列で指定してください。
          startUrl : [/gaPluginV2/start1.html$/, /ga/start2.html$/],
          //計測終了URLを配列で指定してください。
          endUrl : [/gaPluginV2/end1.html$/, /ga/end2.html$/],
          //利用するcookie名を指定してください。
          cookieName : "_utmTimeToComp"
     }
}

タスク完了時間はtomeToComplete: { } の波カッコ内で設定しています。
まず、
action : “timeToComplete_TEST”,
はカスタムイベントのアクション名を指します。
わかりやすいアクション名を付けてください。
クリック数取得を有効化した場合は、クリック数のアクション名は_clcikを付けたものになります。
この場合だと、
timeToComplete_TEST_click
です。

また、カテゴリ名は全てtimeToCompleteで統一されます。
ラベル名が秒数、またはクリック数となります。

startUrlは計測を開始するスタートページのURLの設定です。
正規表現で一致したページがあると計測が開始されます。
上のサンプルの場合だと、
gaPluginV2/start1.html を含むURL
または、gaPluginV2/start2.html を含むURL
で計測開始します。
gaPluginV2/start1.html だけで良い場合は、
startUrl : [/gaPluginV2/start1.html$/]
としてください。

endUrlは終了ページのURL設定です。
設定方法はstartUrlと同様です。
上の例では
gaPluginV2/end1.html を含むURL
または、gaPluginV2/end2.html を含むURL
で計測が終了となります。

cookieNameは利用するcookieの名前です。この機能は30分間の有効期限を持ったcookieを利用して実現しています。cookie名の競合がないように指定してください。クリック取得を有効にした場合、_cを付けたcookieも作成されます。上の例では
_utmTimeToComp と
_utmTimeToComp_c
の2つのcookieが作成されます。

これで設定終了です。

*機能の有効化

機能の有効化はgaPlugin_start.jsで行います。
window.onloadイベント内に
firstTracker.timeToComplete(gaConf1.timeToComplete, true);
を追加してください。

(function(){

/////////////////// TRACKING SETTING /////////////////////////////
     var gaConf1 = gaConf.conf1;
     var _gaTrackName = "_firstTracker";
     var firstTracker = new GaPlugin(gaConf1.cnf, _gaTrackName);

     firstTracker.dirGroup(1);
     firstTracker.dirGroup(2, 2);
     firstTracker.getParam(3);
     firstTracker.weekDay(4);
     firstTracker.dayTime(5);

     _gaq.push([_gaTrackName+'._trackPageview']);

     window.onload=function(){
          firstTracker.autoLink();
     //ここに追加
          firstTracker.timeToComplete(gaConf1.timeToComplete, true);
     };

})();

引数の
・gaConf1.timeToComplete
は設定ファイルの名前です。
・true
はクリック数取得可否の設定です。
trueにするとクリック数も取得されます。falseにすると経過時間のみ取得されます。
省略も可能で、
firstTracker.timeToComplete(gaConf1.timeToComplete)
とすると、経過時間のみでクリック数は取得されません。

これで設定完了です。

■2つ以上のタスクを計測したい!

2つ以上のタスクを計測したいという場合は、設定ファイル内でもう一つ設定を追加してください。
そして、その設定をgaPlugin_start.jsで読み込めばいくつでも追加できます。

gaConf.js

var gaConf = {}
gaConf.conf1 = {
     cnf : {
          //change here
          account : "UA-xxxxxxx-x",
          pageLevel : [1, 2]
     },

     //↓を追加してください。↑のカンマも忘れずつけてください。
     //timeToCompleteの設定
     timeToComplete : {
          //カスタム変数のアクション名を指定してください。
          action : "timeToComplete_TEST",
          //計測開始URLを配列で指定してください。
          startUrl : [/gaPluginV2/start1.html$/, /ga/start2.html$/],
          //計測終了URLを配列で指定してください。
          endUrl : [/gaPluginV2/end1.html$/, /ga/end2.html$/],
          //利用するcookie名を指定してください。
          cookieName : "_utmTimeToComp"
     },
     //↓2つ目の設定。↑のカンマも忘れずつけてください。
     //timeToComplete2の設定。
     timeToComplete2 : {
          //アクション名は1個目の設定と違うものに変更してください。
          action : "timeToComplete_TEST2",
          //計測開始URLを配列で指定してください。
          startUrl : [/gaPluginV2/start3.html$/],
          //計測終了URLを配列で指定してください。
          endUrl : [/gaPluginV2/end3.html$/],
          //利用するcookie名を指定してください。必ず1個目と被らないようにしてください。
          cookieName : "_utmTimeToComp2"
     }
}

gaPlugin_start.js

(function(){
/////////////////// TRACKING SETTING /////////////////////////////
     var gaConf1 = gaConf.conf1;
     var _gaTrackName = "_firstTracker";
     var firstTracker = new GaPlugin(gaConf1.cnf, _gaTrackName);

     firstTracker.dirGroup(1);
     firstTracker.dirGroup(2, 2);
     firstTracker.getParam(3);
     firstTracker.weekDay(4);
     firstTracker.dayTime(5);

     _gaq.push([_gaTrackName+'._trackPageview']);

     window.onload=function(){
          firstTracker.autoLink();
     //ここに追加
          firstTracker.timeToComplete(gaConf1.timeToComplete, true);
     //2つ目の計測
          firstTracker.timeToComplete(gaConf1.timeToComplete2, true);
     };

})();

これで2つの計測が可能になります。

そこまで難しくないと思いますので、ぜひお試しください。

Categories
GoogleAnalytics

gaPlugin.js Ver2 アップデート:設定なしで利用可能に!

やっぱり設定がめんどくさい!
決められた道を歩いていく方が楽に決まっています。
ということで、設定をせずにそのまま利用できるようにしました!
(もちろんアカウントの設定は必要ですが)
gaConf.jsのアカウントを修正すれば、設定完了です。
もはや、通常のga.jsコードよりも簡単です!

ダウンロードはこちらから

gaPlugin.js

すみません、一部(timeToCompleteの箇所)バグがありました。
修正しましたので、既にダウンロードしてしまった人は最新版をもう一度ダウンロードしてください。

サーバー上にアップし、HTML上から

<script src="/ga/gaConf.js" type="text/javascript"></script>
<script src="/ga/gaPlugin.js" type="text/javascript"></script>
<script src="/ga/gaPlugin_start.js" type="text/javascript"></script>

こんな感じで読み込んでください。
これで基本的な機能が使えるようになります。

■カスタム変数スロット1:トップディレクトリ名

カスタム変数にトップディレクトリ名を格納します。
トップディレクトリごとでコンテンツをグループ化します。

■カスタム変数スロット2:セカンドディレクトリ名

カスタム変数にトップディレクトリと第2ディレクトリを結合させたものを格納します。
例えば、/neko/inu/index.html だったら、
「neko_inu」 が格納されます。

■カスタム変数スロット3:GETパラメータ名(cid)

URL GETパラメータのcidの値を取得します。
例:index.html?cid=hoge
であれば、hogeをカスタム変数に格納します。
Convention over Configurationです。cidを使ってください。
もちろん設定ファイルを利用すれば設定することはできますが。

■カスタム変数スロット4:曜日

カスタム変数にアクセスした時の曜日を格納します。
次期GAから、曜日でカスタムレポートが作れるようになるらしいので、必要ないかもしれないです。

■カスタム変数スロット5:時間帯

アクセスした時間帯をカスタム変数に格納します。
カスタム変数のセッションスコープですので、最後にアクセスした時間の時間帯がレポートに反映されます。

当然、外部リンククリック数、DLリンククリック数も自動的に取得されます(カスタムイベントを利用)。

それ以外にも結構パワーアップさせました。
高度な機能は今後必ずどこかで解説できるように頑張ります。

*それ以外の変更

dirGroup でトップディレクトリ以外も指定できるように変更しました。
併せて、ディレクトリ指定でもバーチャルページビューが利用できるようにしました。

timeToCompleteで時間だけではなく、クリック数も取得できるようにしました。

movieTrackが使いにくかったので、完全に修正しました。
設定ファイルで指定した全てのURLで動作するようにしました。

Categories
GoogleAnalytics

gaPlugin.js アップデート

gaPlugin.jsをアップデートしました。
正確にはgaPlugin_start.jsとコンフィグファイルを修正しています。
gaPlugin.js本体は修正していません。

ダウンロードはこちらから。

設定ファイルを読み込む方法を修正しています。
このバージョンからは、<head>タグ内で以下の方法で読み込むようにしてください。

<script src="/ga/gaPlugin.js" type="text/javascript"></script>
<script src="/ga/gaConf.js" type="text/javascript"></script>
<script src="/ga/gaPlugin_start.js" type="text/javascript"></script>
<!-- src=""3つのJSファイルを置いたパスを指定してください。 -->

以前のバージョンのgaPlugin_start.jsはIE6でうまく動きません。
また、これまで設定ファイルは、XMLHttpRequetで読み込んでeval()するという方法を採っていましたが、セキュリティ的に不安があったので、HTML上でJSファイルを呼び出すという普通の方法に戻しました。

もし既に以前のバージョンを利用していて、なかなか変更できない場合は、IE6に対応するようにしたファイルも用意しました。
gaPlugin_start.js
注意:eval()を使っているので、セキュリティ的に微妙です!基本的には、GitHub上にある最新版を使うようにして、このファイルは使わないようにしてください。

あと、ちゃんとドキュメントを書かなくてはダメだということはわかっていますが、なかなか心のゆとりがないのです。。。。

Categories
Web分析一般

MongoDBの$where句について

$where句を使うと、処理は遅いけど色んなクエリをかけることができます。
という備忘録です。
下のdataというようなデータの場合、

Data={
    page : ["/", "/index2.html", "index3.html"],
    time : ["Fri Oct 01 2010 19:48:37 GMT+0900 (JST)","Fri Oct 01 2010 19:48:46 GMT+0900 (JST)", ,"Fri Oct 01 2010 19:49:42 GMT+0900 (JST)"] ,
              referer : ["yahoo.co.jp", "", ""]
}

MongoDBのShell上で、下のようなクエリを書くと、
page[0]が”/”で、page[1]が”/index2.html”
というデータが含まれているデータを全て抜いてくることができます。

db.Data.find({$where : function(){
        if(this.page[0]=="/" && this.page[1]=="/index2.html"){
            return true
        }
    }
})

SQLより柔軟で素敵!
おそいけど。

そして、これさえできれば、
1ページ目に「/」を見て、「/index2.html」に遷移した人に絞った
ページの滞在時間も計算できたり!
こういう行動した人のリファラーを出せたり!
色々細かい分析ができます!面倒なのでしませんが!

Categories
GoogleAnalytics

gaPlugin.js マイナーアップデート

gaPlugin.jsをマイナーアップデートさせました。
ちょっとバグフィックスと、ちょっと機能を追加しました。

ダウンロードはこちらから
gaPlugin.js

変更点

CV -> 対象範囲をパス名までからGETパラメータ(?以下)までに変更
timeToComplete -> cookieのExpire指定がおかしかったので修正
getParam -> パラメータが無いときもデータを送信していたので、送信しないように変更
メソッド:virtualPVPlusを追加


新機能vritualPVPlus

たいした機能ではないですが、一定時間以上ページに滞在したユーザーは直帰とさせないために、バーチャルページビューでページビューを飛ばしてしまうという機能です。
GAのセッション定義とは少し変わってしまうので、完璧にセッションを管理できているわけではないですが、ほぼほぼ問題なく直帰と見なすことを防ぐことができると思います。

.virtualPVPlus(seconds)
*機能:
引数で指定した秒数後に「パス名+_時間over」というページビューを送信します。
例:「/index.html_30over」
基本的には指定した時間以上経過した人を直帰としてみなさないようにするためのものです。
そのため、セッションの最初のページでのみ、動作するようにしています。
(30分の有効期限をもったcookieで管理しています。有効期限はページが開かれる度に更新されます)

*引数:
seconds : バーチャルPVが動作するまでの時間

Categories
GoogleAnalytics

Getting Started gaPlugin.js : gaPlugin.jsの簡単な設定方法

2011/03/12修正。

gaPlugin.jsのダウンロード

gaPlugin.jsの具体的な使い方に関する説明がちょっとというか、かなり少なかったので、JSがわからない人向けに簡単な説明をしたいと思います。

ただし、Google Analyticsのカスタム変数とイベントトラッキングの最低限の知識は前提としますので、Google Codeのカスタム変数とイベントトラッキングの項目は事前に読んでおいてください。

カスタム変数 – Google Analytics

イベントトラッキングの概要 – Google Analytics

今回取得するデータ

とりあえず、今回はGAで一般的に取得できる項目に加えて以下のデータを取得できるようにしたいと思います。

  • コンテンツのグループ化
  • GETパラメータを持ったユーザー
  • コンバージョンしたユーザー
  • アクセスした曜日
  • アクセスした時間帯
  • 外部サイトへのリンク・DLリンク

設定ファイル(gaConf.js)のセッティング方法

設定ファイル:gaConf.jsで設定を行います。
それでは、お好きなテキストエディタでgaConf.jsを開いてください。デフォルトのものは日本語文字も使っていますので、文字コードに気をつけてください。デフォルトはUTF8で書かれています。

全般設定 : cnf

まずは全体の設定をします。
gaConf.jsの
cnf : {
という項目を見てください。

//全般設定
cnf : {
//アカウント名 : UA-XXXXXX-Xを入力してください。
account : "UA-XXXXXX-X",
//ページレベルでのカスタム変数のスロット名を配列形式で入力してください。
pageLevel : [1]
},

* account
まずはaccountの所のUA-XXXXXX-Xを、ご自身で取得されたGoogle Analyticsのアカウント名に変更してください。これは必須設定項目です。ここを間違えると、データがあらぬ方向へ飛んでいくので注意してください。

*pageLevel
ちょっとわかりにくいかもしれないですが、カスタム変数でページレベルの変数(scope->3)を利用しているスロット番号を記載してください。
カスタム変数はイベントトラッキングでもデータが送信してしまうので、2重送信を防ぐために、ここで設定した変数をイベントトラッキングデータ送信時に削除しています。ここで設定しないと、外部リンククリックした時も、カスタム変数で設定した値(コンテンツグループなど)がPVとしてカウントされてしまいます。
今回はコンテンツグループの箇所でページレベルのカスタム変数を利用するので、
pageLevel : [1]
としておいてください。
2つ以上利用する場合は
pageLevel : [1, 2]
などカンマ区切りで記載してください。

コンテンツグループの設定

次にコンテンツグループの設定です。
ココが一番ややこしいところだと思います。

//コンテンツグループの設定
cg : {
//コンテンツグループに利用するカスタム変数のカテゴリを指定してください。
category : "ContentGroup",
//コンテンツグループのスコープを設定してください。(デフォルト3 -&gt; PageLevel)
scope : 3,
//コンテンツグループを正規表現で指定してください
//グループ名:/グループ定義/
pages : {
groupA : /.+sampling.+/,
groupB : /ga_test.html$/,
groupC : //test/ga//,
topPage : /^/$|^/index.html$/
}
},

*category :
category欄にはカスタム変数で送信されるカテゴリ名を指定してください。
レポートにはこのカテゴリ名が表示されます。

*scope :
scope欄はカスタム変数のスコープです。
ここを何にするのかは、実はちょっと難しい問題なのですが、とりあえずページレベル「3」としておいてください。

ちなみに、ページレベルで設定した場合は、GAレポート画面でのカスタムレポートでうまくクロス集計できないというよく分からないバグ?があります。。。。
*追記:「セッション」がおかしな値にになってしまいますが、セッション数を出したい場合は、「ユニークイベント数」を利用すれば良さそうです。

*pages :
pages欄でコンテンツグループのルールを設定します。
「グループ名」:「ルール」
という書き方で記載してください。
グループ名は自由に記載して大丈夫です(JavaScriptの予約語と被らないようにしてください)。
このグループ名がGoogle Analyticsのレポートに表示されます。
ルールは正規表現で指定することができます。
ココで記載した正規表現がルート以下のパス名(ドメイン・GETパラメータは含みません)と評価され、マッチされたもの左側に記載された「グループ名」に含まれると判断します。
(JavaScriptのlocation.pathnameと評価しています)

例えば、/products/配下全てを「product」というグループ名で纏めたい場合は
product : /^/products//,
と記載してください。
(正規表現の詳しい説明は省きます)

ここで指定しなかったURLがあった場合は、全て「other」というグループにまとめられます。

(ちなみに、別のコンテンツグループ群を作って別のカスタム変数に入れることもできます)

Getパラメータを持ったユーザー

Getパラメータを持ったユーザーをカウントするための設定は「getPar」という欄にあります。

getPar : {
//カスタム変数のカテゴリ名を指定してください。
category : "Parameter",
//スコープを指定してください(デフォルト2 -&gt; Session Level)
scope : 2,
//取得するパラメータ名を指定してください。
paramName : "cid"
},

*category :
ここにはカスタム変数で利用するカテゴリ名を記載してください。GAのレポート画面で表示されます。

*scope :
ここで、カスタム変数のスコープを記載してください。通常はセッションレベルで利用されると思いますので、「2」としておいてください。ユーザーレベル「1」を利用することも考えられます。

*paramName :
ここに取得したいパラメータの名称を記載してください。
上の設定例では、
http://web-analytics-or-die.org/?cid=neko
というURLが表示されたとき、
「neko」という値が取得され、GAのレポート画面で表示されるようになります。

utm系のパラメータは階層化できて便利なのですが、ちょっと設定が面倒なのと、なぜか通常のヒット数を出してくれないので、これで代用することができます。

コンバージョンしたユーザー

コンバージョンユーザーの取得設定は「cv」欄で行います。

//コンバージョンユーザーの取得
cv : {
//カスタム変数のカテゴリ名を指定してください。
category : "conversed",
//スコープを指定してください(デフォルト1 -&gt; User Level)
scope : 1,
//コンバージョンしたユーザーにつける名前を指定してください。
cvName : "conversed",
//コンバージョンとするURLを正規表現で指定してください。
urlstring : [//test/ga/index.html/, //test/ga/index2.html/]
},

*category :
カスタム変数のカテゴリ名です。他の項目と同様です。

*scope :
カスタム変数のスコープです。セッションレベルについてはGAレポート側でちゃんと設定していれば、アドバンスドセグメントで普通に追えるので、ユーザーレベルにしておいたほうが良いかと思います。ユーザーレベルにしておけば、セッションを超えてコンバージョンしたユーザーを追跡することができます。

*cvName :
コンバージョンしたユーザーにつける名前です。カスタム変数のvalueとして記録されます。

*urlString :
コンバージョンとして定義するURLを正規表現でしていしてください。
ここはパラメータも含めて評価します。

設定は以上です!
他の項目はとりあえず無視しておいてください。

トラッキングセッティング

次にgaPlugin_start.jsの設定を行います。

設定ファイル読み込み

//load configure file. Set the pathname for configure files
var gaConf1 = gaConf.conf1;
var _gaTrackName = "_firstTracker";
var firstTracker = new GaPlugin(gaConf1.cnf, _gaTrackName);
//Cross Domain Tracking Setting
//_gaq.push([_gaTrackName+'._setDomainName', '.sample.com']);
//_gaq.push([_gaTrackName+'._setAllowLinker', true]);
//_gaq.push([_gaTrackName+'._setAllowHash', false]);

ここはクロスドメイン用の設定なので、とりあえず無視しておいてください。

機能の有効化

firstTracker.contentGroup(1, gaConf1.cg);
//firstTracker.dirGroup(1);
firstTracker.getParam(2, gaConf1.getPar);
firstTracker.cv(3, gaConf1.cv);
firstTracker.weekDay(4);
firstTracker.dayTime(5);
//firstTracker.debug();

_gaq.push([_gaTrackName+'._trackPageview']);
//firstTracker.virtualPageviews(gaConf1.cg)

ここで機能を有効化します。
今回はコンテンツグループ、パラメータ、コンバージョン、曜日、時間帯を取得できるようにしますので、上記の通りにしてください。
括弧内の数字はスロット名です。1~5まで設定することができます(基本的には)。

機能の有効化は必ず
_gaq.push([_gaTrackName+’._trackPageview’]);
の前に記載してください。
_trackPageviewまでのデータが送信されます。

オンロードイベント

次に自動外部リンク取得の有効化を行います。

window.onload=function(){
//firstTracker.autoLink(gaConf1.autoLink);
firstTracker.autoLink();
//firstTracker.timeToComplete(gaConf1.timeToComplete);
//firstTracker.allowLinker(gaConf1.allowLinker);
//firstTracker.movieTrack(gaConf1.movie);
};

firstTracker.autLink(); で外部リンク・DLリンクの取得が可能になります。
こまかい設定も設定ファイル(gaConf.js)のautoLink欄で行うこともできます。
その場合は
firstTracker.autoLink(gaConf1.autoLink);
のようにして設定ファイルを読み込むようにしてください。

デフォルトでは
firstTracker.timeToComplete(gaConf1.timeToComplete);
が有効化されているので、頭に「//」を付けて機能を無効化させてください。

これでトラッキングセッティングは終了です!

HTMLページでの設定

HTML側ではタグの直前あたりで、「gaPlugin.js」と「gaPlugin_start.js」を読み込んでください。

<script type="text/javascript" src='/ga/gaPlugin.js'></script>
<script type="text/javascript" src='/ga/gaConf.js'></script>
<script type="text/javascript" src='/ga/gaPlugin_start.js'></script>

src=”パス名” といった感じで記載してください。
通常のGAコード(ga.jsの読み込みなど)もgaPlugin.js内に含まれていますので、これまでのGAコードは削除してください。
gaConf.jsonはgaPlugin_start.js内で読み込みますので、ここでは読み込み不要です。

これで設定完了です!!
そんな難しくないはず!!

Categories
GoogleAnalytics

Google Analytics機能拡張プラグイン gaPlugin.js version2を公開します。

以前、微妙に公開していましたが、かなり使いづらい状態だったので、特にインターフェイス周りを整理し直して、バージョンアップをしました。
今回のバージョンアップでようやく実用レベルにはなったと思います。

gaPlugin.jsのダウンロード
(githubに移行しました)

*注意:
まだベータ版です。利用は自己責任でお願いします。
利用は自由ですが、商用で利用される場合はご連絡いただけると助かります。
追記: とりあえずMITランセンスにしておきます。

特徴

・データ取得機能の強化
Google Analyticsに不足している機能を気軽に補完することができます。
外部サイトリンクのクリック数や曜日別のセッション数など、あると便利なデータを簡単に取得できるようになります。

・複数アカウントの対応
GAが対応している複数アカウントをサポートしました。
2つ以上のアカウントを使って自在にデータを取得することができます。
例えば、1つ目は通常のページビューを取得し、2つ目はグループ化したページビューを取得するということができます。
当然、1アカウント5個までと制限されているカスタム変数も、2アカウントなら10個使うことができます。

・柔軟なカスタマイズ
GAがサポートする範囲内であれば、柔軟にカスタマイズすることができます。
例えば、5個のカスタム変数全てをコンテンツグループに利用することもできます。
通常の_setCustomVarを利用して、個別にカスタム変数を利用することも可能です。

・プラグインを一切使っていません
jQueryやprototype.jsなどのプラグインを一切使わずに作成しています。
シンプルな設計になっているので、プラグインを使った場合と比べて、高速に動作するはずです。また、プラグイン同士の衝突も回避できます。

・設定ファイルで一括管理
基本的に機能を全て設定ファイルで管理するので、各ページごとに異なったタグを入れる必要がありません。全ページ同じタグで簡単に導入することができます。
(一部例外あり)

機能一覧

・外部サイトリンク、ダウンロードリンクの自動取得
外部サイトのクリックや、ファイルのダウンロードクリックを自動的に取得することができます。もうaタグ内にonClick=~なんて書く必要がありません。

・コンテンツグループの設定
コンテンツをグループ化して取得することができます。
通常のレポートでは不可能だったグループ別のセッション数を取得することができます。

・タスク終了までの時間取得
あるページの表示から、あるページの表示までにかかった時間を取得できます。
例えば、フォームの入力ページの表示から、入力完了ページまでの時間を取得できます。

・ムービー閲覧時間の取得
15秒おきにカスタムイベントリクエストを送信することによって、ムービー等の閲覧時間を取得できるようになります。
当然直帰したユーザーも含めた滞在時間が取得できます。

・グループ化バーチャルページビュー
通常のtrackPageviewsの代わりに、コンテンツグループを利用することができます。
コンテンツグループをページビューとみなすことによって、GAのパス解析機能を使うことが可能です。
つまり、あるコンテンツグループの次に見たグループ、ランディングとなったグループなどを追跡できます。
複数アカウント利用と組み合わせると強力な機能になります。

・コンバージョンしたユーザーの特定
コンバージョンしたユーザーを追跡することができます。
GAレポート画面上でもコンバージョンした追跡することは可能ですが、カスタム変数を使っているため、セッションを越えたユーザー単位で追跡することができます。

・パラメータ取得
指定したパラメータを持ったURLを表示すると、そのパラメータの値を取得します。
キャンペーン等の簡易取得に利用できます。

・ディレクトリグループ
コンテンツグループは設定するのが面倒という人には、トップディレクトリをコンテンツグループとして設定することができます。

・_link の自動設定
クロスドメイン解析に必要な_linkも自動的に設定することができます。
それぞれのリンクにonClick~と書く必要はありません。

・曜日の取得
曜日を自動的にカスタム変数に格納します。
曜日別にデータを見ることが可能になります。

・時間帯の取得
朝、昼、夕方などページが見られた時間帯を自動的に取得します。

利用方法

A. 動作ファイル(gaPlugin_start.js)の記述
1. コンフィグファイルの読み込み
var gaConf = loadJson(“/test/ga/js/gaConf.json”);
コンフィグファイルのパスを指定してください。
JSONファイルを読み込みます。

2.トラックネームの設定
var _gaTrackName = “_firstTracker”;
マルチアカウントトラッキングに必要なトラッカーの名称を設定します。
名称はどんなものでも構いません。

3.計測用オブジェクトの作成
var firstTracker = new GaPlugin(gaConf.cnf, _gaTrackName);

4.各種設定
クロスドメイン用の設定など各種設定してください。

5.機能のON
利用する機能を定義してください。

6.trackPageview
データを送信します。
_gaq.push([_gaTrackName+’._trackPageview’]);
メソッド:virtualPageviewsを利用することもできます。
(併用はできません)

7.onloadイベントの設定
autoLinkなどonloadイベントを設定します。

8.2つめのアカウント設定
複数アカウントを利用する場合は、2つめ以降のオブジェクトを生成してください。
方法は1-7と同様です。

B.HTMLファイルへの記述
gaPlugin.jsと動作ファイル(gaPlugin_start.js)を読み込んでください。

 <script src="/js/gaPlugin.js" type="text/javascript"></script>
 <script src="/js/gaPlugin_start.js" type="text/javascript"></script>

gaPluginのAPI

API一覧
new
.contentGroup
.dirGroup
.getParam
.cv
.dayTime
.weekDay
.virtualPageviews
.autoLink
.timeToComplete
.allowLinker

——————————–
new (conf, trackName)
*機能:
計測用オブジェクトを作成します。

*引数:
conf : 全般設定のコンフィグ
trackName : 任意の文字列

*confCgの形式:

    //全般設定
    cnf : {
    //アカウント名 : UA-XXXXXX-Xを入力してください。
        account : "UA-XXXXXX-X",
    //ページレベルでのカスタム変数のスロット名を配列形式で入力してください。
        pageLevel : [1]
    },

——————————–
.contentGroup(slot,confCg);
*機能:
設定ファイルに記載したURLルールに基づいて、コンテンツをグループ化します。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)
confCg : コンテンツグループのコンフィグ

*confCgの形式:

    //コンテンツグループの設定
    cg : {
        //コンテンツグループに利用するカスタム変数のカテゴリを指定してください。
        category : "ContentGroup",
        //コンテンツグループのスコープを設定してください。(デフォルト3 -> PageLevel)
        scope : 3,
        //コンテンツグループを正規表現で指定してください
        //グループ名:/グループ定義/
        pages : {
            groupA : /.+sampling.+/,
            groupB : /ga_test.html$/,
            groupC : //test/ga//,
            topPage : /^/$|^/index.html$/
        }
    },

——————————–
.dirGroup(slot);
*機能:
トップディレクトリでグループ化します。
ルートディレクトリの場合は「top」となります。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)

——————————–
.getParam(slot, confPar);
*機能:
設定ファイルに指定したパラメータを持っている場合、その値をカスタム変数に保存します。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)
confPar : コンテンツグループのコンフィグ

*confParの形式:

    //GETパラメータの取得
    getPar : {
        //カスタム変数のカテゴリ名を指定してください。
        category : "Parameter",
        //スコープを指定してください(デフォルト2 -> Session Level)
        scope : 2,
        //取得するパラメータ名を指定してください。
        paramName : "cid"
    },

——————————–
.cv(slot, confCv)
*機能:
設定ファイルに指定したURLのページを閲覧したとき、コンバージョンユーザーとして定義することができます。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)
confCv : コンテンツグループのコンフィグ

*confCvの形式:

    //コンバージョンユーザーの取得
    cv : {
        //カスタム変数のカテゴリ名を指定してください。
        category : "conversed",
        //スコープを指定してください(デフォルト1 -> User Level)
        scope : 1,
        //コンバージョンしたユーザーにつける名前を指定してください。
        cvName : "conversed",
        //コンバージョンとするURLを正規表現で指定してください。
        urlString : [//test/ga/index.html/, //test/ga/index2.html/]
    },

——————————–
.dayTime(slot);
*機能:
アクセスした時間帯を記録します。
0時-5時:late night
5時-9時:early morning
9時-12時:morning
12時-15時:after noon
15時-18時:evening
18時-21時:late evening
21時-24時:night
として、定義されます。
ユーザー側の時間が記録されるため、時差がある場合はサーバー側と異なる時間帯が記録されます。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)

——————————–
.weekDay(slot);
*機能:
アクセスした曜日が記録されます。
ユーザー側の時間が記録されるため、時差がある場合はサーバー側と異なる曜日が記録されることがあります。
カスタム変数を利用します。

*引数:
slot : カスタム変数のスロット番号(1-5)

——————————–
.virtualPageviews(confCg);
*機能:
コンテンツグループをページビューとして、カウントします。
通常の_trackPageviewと併用できません。

*引数:
confCg : コンテンツグループのコンフィグ
(形式は.contentGroupの設定と同じです。)

—————————-
.autoLink(confLink)
*機能:
外部サイトへのリンク、DLリンクを自動的に取得できるようになります。
カスタムイベントを利用します。

*引数:
confLink : オートリンクのコンフィグ
(省略することができます)

*confLinkの形式:
    //オートリンクの設定
    autoLink : {
        //除外するドメイン名を配列で指定してください。
        internalDomain : ["www.sample.com"],
        //
        category : {
            offSite : "OffSiteLink",
            download : "DownLoadLink"
        },
        //取得するDLファイルを設定
        dlFiles : {
            emailLink : /^mailto:(.+)$/i,
            pdf: /^(.+.pdf)$/i,
            zip: /^(.+.zip)$/i,
            PowerPoint: /^(.+.pptx?)$/i,
            Excel: /^(.+.xlsx?)$/i,
            Word: /^(.+.docx?)$/i
        }
    },

—————————-
.timeToComplete(confTC)
*機能:
設定ファイルに記載したスタートページを表示してから、終了ページを表示するまでの時間をカウントします。
カスタムイベントを利用します。

*引数:
confTC : timeToCompleteのコンフィグ

*confLinkの形式:
    //timeToCompleteの設定
    timeToComplete : {
        //カスタム変数のアクション名を指定してください。
        action : "timeToComplete_TEST",
        //計測開始URLを配列で指定してください。
        startUrl : [/ga/start1.html$/, /ga/start2.html$/],
        //計測終了URLを配列で指定してください。
        endUrl : [/ga/end1.html$/, /ga/end2.html$/],
        //利用するcookie名を指定してください。
        cookieName : "_utmTimeToComp"
    },

—————————-
.allowLinker(confLinker)
*機能:
クロスドメインサイトの取得に必要な_linkを自動的に設定します。
_setAllowLinkerをtrueにしておく必要があります。
aタグのみ対応しています。
formタグでのPOSTによるサイト遷移については対応していません。

*引数:
confLinker : allowLinkerのコンフィグ
*confLinkerの形式:

    //Cross Domain用Trackingの設定
    allowLinker : {
        //許可するサイトのURLを指定してください。
        allow : ["www.sample.co.jp", "www.sample2.co.jp/"]
    }

——————————–