知りたいことは、２つ。

• ＄インデックスと平均訪問目標値は似ているけど、どうなの？
• 「平均訪問目標値」をコンテンツレポートで使えちゃうけど、これは何を意味してるの？

かと。

＄インデックスと平均訪問目標値は似ているけど、どうなの？

違いを列挙してみます；

＄インデックスは、「どのページが売上や、目標達成に貢献してるの？」を知るのに都合がいい。
（Eコマースの収益＋合計目標値）／ページ別訪問数という式で計算できます。

平均訪問目標値は、「どの流入元、どんなユーザ属性からの『訪問』が、目標達成に貢献してるの？」を知るのに都合がいい。
合計目標値（＋Eコマースの収益で計算と公式ヘルプでは書いてありますが、Eコマース収益がなぜか足されない…）／訪問数という式で計算できます。 ?-
*V5では合計目標値の名称が目標値（Goal value）になってます。あ”―ホントにややこしいっ。

なるほど似ているようですが、それぞれ意味する内容が異なるんですね。

＄インデックスはページがどれくらい売り上げや目標達成に貢献したかを、平均訪問目標値は訪問毎の目標達成状況を測るのによさそうです。

ただ、平均訪問目標値は＄インデックスと違ってeコマースの収益は含まれません。それを補うためなのか平均訪問単価という指標があって、これは「どの流入元、どんなユーザ属性からの『訪問』が、売上につながってるの？」を知るのに都合がよくなっているわけです。

でも「平均訪問目標値」をコンテンツメニューのレポートで使えちゃうけど。。。この場合これは何を意味することになるの？

「平均訪問目標値」は通常トラフィックメニューの目標タブなどに表示される指標です。
でもなぜかコンテンツメニューの「ページ」もしくは「上位のページ」などからも、見ることができてしまいます。分母に「訪問数」を持つ平均訪問目標値ですが、この「訪問数」コンテンツメニュー内で表示される場合は、要注意なんです。。この辺のこと、実は昔の記事に詳しく書いてますので読んでみてください。（http://susumukatachi.jp/archives/1747　内の「セッション数とページ別セッションの関係」を参照）

要は、
コンテンツメニューにおける「訪問数」は「閲覧開始数」と同じになるわけですね。これを踏まえて平均訪問目標値の計算式に戻ってみたとき、

合計目標値／訪問数　＝　合計目標値／閲覧開始数

と言えるわけですが、これはいったい何を教えてくれる指標になるのでしょうか。。。なんとなく、「どのランディングページ（閲覧開始ページ）が、目標達成に貢献していたのか」を教えてくれそうですが、本当にそうなのでしょうか。もう少し見てみます。（目標値の金額は適当にいれてます）

ページディメンションで（合計）表示される目標値はこのページを閲覧した全訪問の合計目標値のため金額が高いと考えられる

上の例では、ページ毎の合計目標値に合算される目標値は、そのページが閲覧開始ページであったかどうかは考慮されていません。目標を達成した訪問において一度でも閲覧されたページであるならば、合計目標値に合算されます。

となると、そんな合計目標値を、閲覧開始数で割ったところで、何がわかる指標になりえるのでしょうか？。。。良い使い方が、あまり思いつかない。。。

でも、↓のように、合計目標値にカウントされるものが閲覧開始ページのものに限るというのであれば、この平均目標値も少しは使い道が出てきそうです。（ディメンションに閲覧開始ページを持ってくることで、指標である合計目標値も、閲覧開始ページがｘｘｘであったときの値を示してくれます）

ディメンションが閲覧開始ページの目標値は、そのページがランディングページだったときに目標を達成した金額が反映される

平均目標値＝閲覧開始ページにおける合計目標値／閲覧開始数ということですから、「どのランディングページ（閲覧開始ページ）が、目標達成に貢献していたのか」を表す指標となりえませんか。

ゆえに
、GA Version5 のレポートでインデックス値みたいなものを確認したい！で表示されている平均訪問目標値 は、残念ながらあまり有用な指標となりえなさそうです。ただ、ディメンションを「ページ」から「閲覧開始ページ」に変えてみると、有用な指標となりえそうだと。

実はこれ、わざわざカスタムレポートを作らなくてもV5ならば次の方法で、平均目標値を閲覧開始ページ別に見ることができたりして。

1. 「標準レポート　＞　トラフィック　＞　参照元　＞　すべてのトラフィック」メニューを選びます。
2. タブメニューから「目標セット１」を選びます。（注：目標の設定がされていないプロファイルではこのタブが表示されません）
3. 表示中のセグメントから「その他」をクリックし、トラフィックメニュー内にある「ランディングページ」を選択します。
4. ディメンションが「ソース／メディア」から「ランディングページ」に変わります。
5. 平均目標値が右から2列目に表示されているので、項目名をクリックして平均目標値でソートすると使いやすいです。

年明けから大きくいろんなことが変わっていくことになるので、それに向けて準備を進めています。なんか回りくどい言い方だけど、そのうちご紹介できればと思います。

2010年もありがとうございました。2011年もどうぞよろしくお願いしますね。

アクセス解析Q＆Aフォーラムの「サイト内検索による遷移把握について 」という質問を見て、気になり出したのがコトの発端。いろいろ調べたところ、Avinash氏の記事を見つけました。
September 22, 2009：Internal Site Search Analysis: Simple, Effective, Life Altering!

(1)「コンテンツ」＞「サイト内検索」＞「検索キーワード」を表示する

サイト内検索：キーワードをひとつ選択する

(2)任意のキーワードを選択して「サイト内検索キーワード：」レポート画面を表示させる

サイト内検索：キーワード画面を表示させる

(3)こんなところに「分析：検索キーワードサマリー」というプルダウンメニューがあるので、そこから「検索ナビゲーション」を選ぶ

サイト内検索：分析メニューを選ぶ

(4)こんな感じで検索キーワードの検索結果が表示される前後のページ遷移が表示される

サイト内検索：検索結果前後の遷移を表示するには遷移元を選択する

「コンテンツ」カテゴリで利用できる「ナビゲーションサマリー」のような情報ですね。

それに、順序通りやってくよりも「Feed Reference」を始めにやったほうが実践的で良かったかもと。…がんばります。

とはいえ、せっかく途中までやっ（ってしまっ）たので、ここに載せとこうと思います。
間違いなどありましたら、アドバイスください。

Manamgement API

グーグルアナリティクスの設定や、アカウントデータへのアクセスをより良くしてくれるのが、このGoogle Analytics Management API。

こんないいこと（ベネフィット）があります：

柔軟性

アカウントリクエストの範囲をカンタンに調整することができます。
(どういうことかというと)例えば、
１回のリクエストで、あなたのアカウント全てのデータやプロファイルにアクセすることができたり、特定のプロファイルのデータだけリクエストする、なんてことができます。

パフォーマンス

全てのアカウント／プロファイルの全部のゴール値をわざわざとってくるのではなく、一つのプロファイルのゴール値だけをとってくるので、フィードのレスポンス時間を減らすことができます。

構造

グーグルアナリティクスのデータ階層構造を横断できます。
The Management APIは、それぞれのフィード毎に親と子を紐づけるので、データオブジェクトに紐づいたプログラムクエリーをアプリケーション内で使うことができます。
（ここの訳はなんかあやしいですね）

いまのところ、Management APIは、以下の５つに限り、リードオンリー（書き込みは不可）でアクセスできます。

• アカウントデータ
• プロファイルッデータ
• ウェブプロパティデータ
• ゴールデータ
• アドバンスセグメント

言語ガイド

google Analytics Managementデータへアクセスし始めるのに、下にあげたガイドページが役に立つかもしれません。

Javaガイド
JavaScript ガイド

その他使えるライブラリなどは、「Libraries and Examples」ページに詳しい情報があります。

Labsのポリシー

Google Analytics Management APIはまだ実験段階のものです。そのためたびたび変更が加えられていきます。通常、何か機能を削除したり、非推奨にする際は新しいAPIをリリースするおよそ１ヶ月程度前にアナウンスするよう努力します。
専用のメーリングリストに登録して、最新情報を得るようにしておきましょう。エンドユーザーに高いレベルのサービスを提供できない事態や、内部システムに多大な影響を与えるような非常時は、短い期間のアナウンスですぐに変更できる権利が私たちにあります。
通常、APIの使用状況は開発者向けのサービス条件によって統制されています。

Management API – Getting Started

Analytics Management API を使うには、既存のグーグルアナリティクスアカウントへのアクセスが必要となります。
あなたのアプリケーションへアクセスするユーザーも同じようにアクセスすることになります。
グーグルアナリティクスアカウントがないなら、作成してください。グーグルアナリティクスはグーグルアカウントを使うので、もしすでにグーグルアカウントをお持ちであれば、アナリティクスのアカウントとしてそのIDを使い、設定することが出来ます。
IDを設定したら、指示に従って、アナタのサイトへトラッキングコードを埋め込む設定を行ってください。

Feed Retrieval Basics 基本的なフィード取得方法

アカウント内のゴールやプロファイル、ウェブプロパティとグーグルアカウントそのものとの関係性を理解するのが大事です。

アカウントとプロファイルの説明ページを読めば、特定のデータをManagement APIのフィードを使ってどうリクエストすることができるのか、よく分かるはずです。

Management APIを使ってデータを取得する際、あなたのアプリが従うことになるプロセスをまとめたのが、下の基本ステップです。

1. 認証
   アプリにアクセスするユーザは必ずアナリティクスへログインしなければなりません。通常そのアプリは、アクセスするユーザーからログイン証明をもらうことになります。ユーザはグーグルアカウントのメールアドレスとパスワードでログインします。
   認証について詳しくは、認証ガイドページをご覧下さい。
2. APIクエリーの管理
   ユーザがそのアナリティクスIDへのアクセス権を持っていることをアプリが認証できれば、そのユーザーがアクセスできるアカウント、webプロパティ、プロファイル、ゴールそしてアドバンスセグメントの情報をアプリで使うことができます。

   それぞれのデータタイプ毎にフィードが分かれているので、そのユーザが利用可能なすべてのエンティティから結果をフィードで返すことができます。
   例えば。プロファイルフィードはそのユーザーアカウントに示されているプロファイルのリストを返すことができます。
   詳しくは、Feed Referenceページを参照してください。

3. IDもしくは、そのユーザーの全データを取得する
   The Management APIは、そのユーザが利用可能な全てのデータタイプ（例えば全アカウント情報、全プロファイル情報など）の取得や、特定のデータタイプ（特定のアカウント情報、プロファイル情報）の取得方法を提供しています。
   1. IDで：
      特定のIDを使うことで、webプロパティや、プロファイル、ゴールといったフィードをそれぞれのエンティティから取得することが出来ます。例えば、webプロパティIDが、こんな感じ（UA-12345-1)だったとします。このIDを使うことで、アナリティクスの全データから探すよりも、時間を短縮することが出来ます。その結果、アプリのレスポンスタイムも向上するわけです。
      IDを使えば、特定の重要な情報（例えば特定のプロファイルにあるゴール名とか）だけ取得するといったことも、カンタンにしてくれます。データクエリーは階層構造になっているので、子のエンティティのIDを特定したいといった場合は、その子エンティティの親のIDも特定する必要があります。
   2. ~allを使う：
      IDを入力する箇所に「~all」と入れれば、そのユーザが利用できる全データを取得することができます。この~all識別子を使う場合は、その要素に続く子の要素でも同じように~all識別子を使わなければなりません。

注意：
~all識別子を使って全てのデータ取得をする場合、遅いです。というのも、グーグルアナリティクスでは、アカウントから始まる全ての階層構造をwebプロパティ、プロファイルといった具合に順に見ていく仕様だからです。
ですので、
たくさんアカウントやプロファイルを設定しているユーザーの場合、レスポンスが返ってくるまでに相当な時間がかかります。
そのためエンドユーザーには特定のIDを入力させるなどして、返答時間を向上させ、結果を絞り込める方法を基本的には用意すべきですね。

Management APIをExport APIと一緒に使う

プロファイルフィードは、そのユーザーがアクセス権を持つ全てのプロファイルデータに、アプリがアクセスできるようにします。
また、プロファイルで使っているData　Export　APIのデータへアクセスするのに、それぞれのプロファイルエントリーに存在するテーブルIDをアプリで使うことが出来ます。

割当制度(Quota)のポリシー

Google Analytics Management A PIでは、何百万というデータを処理しています。処理できる以上のデータを受けつけてしまうといったことからシステムを守るためにも、またシステムのリソースを均等配分するためにも、割当制度を使うことが必要なんです。
これらポリシーは変わることがありますが、今のところは以下の通りです。

全てのManagement APIフィードについて

それぞれのAPIのリクエストは、１度のレスポンスに対して最大10,000までとなっています。
標準（デフォルト）では１度のレスポンスに対して1,000までとなってますが、max-results queryパラメータを使えば、そのレスポンス量を10,000まで増やすことができます。

全Management APIのクエリにおいて、アプリは１秒間において10リクエスト(10qps)まで可能。

一度割り当てが制限値を超えると、オーバーした分のリクエストについては、特定のアカウントにおいて割当が充分でありませんといったページが表示されると同時に、APIがHTTPステータスコード503を返します。詳しくは、サービス規定をご覧下さい。

ということで、グーグルによる加重並び替え機能の説明ビデオ（英語）、こちらにあげておきます。

正式なアナウンスもないので（この記事をアップした直後にYoutubeに説明ビデオがアップされてました）、知らない間にまた消えてしまっているかもしれませんが、カンタンなレポートを書いておこうと思います。

どんな機能なのか

グーグルアナリティクスの説明では、

加重並べ替えでは重要性に基づいて関連する列が表示され、最も有益な列が最初に表示されます。

とあります。
…難しく感じますが、使ってみるとかゆいところに手が届く機能なことが分かります。

例えば、下のように「すべてのトラフィック」レポートを普通に出した場合。

ソートしたい項目の上に「加重並び替え」が表示された

新規セッションの割合でソートすると、100%の項目がずらりと並びます。
確かにソートできてるのだけど、「セッション数が5とか2とかなら、そりゃ新規100%もありえるよな」とか思いますよね。
そこで、「加重並び替え」のチェックボックスにチェックをいれてみます。

新規セッション率が高いものでありながらセッション数の多いものを表示してくれる

こんな感じで新規セッションの割合項目と同時にセッション項目のデータも並び替えられる仕組み。

項目全てで加重並び替えができるわけではなく、ざっとみていったところ「割合や％」で表される指標項目において、利用できるようです。

使った感じは…。
エクセルの「並び替え」機能で「最優先されるキー」と「２番目に優先されるキー」を使ってソートできますよね？
あれと似たようなことがこの加重並び替えでできます。

追加補足(2010.08.20 10:20)：
きちんと降順、昇順に並び替えするというのがこの機能の目的ではなく、直帰率を見る際に関連してくる重要なことがら（この場合はセッション数）の多さ／少なさも「加味」しながら並び替えてくれる、というのがこの機能の特長だと。
まぁ使ってみてください

どこに表示されるのか

全部のレポートで表示されるわけではないようです。
ざっと調べたところ、加重並び替えが表示されるレポートと、機能が表示される項目はこれら。

ユーザー：新規ユーザーとリピーター

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

ユーザー：言語

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

ユーザー：PC環境内の全レポート

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

ユーザー：ネットワーク環境内の全レポート

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

ユーザー：モバイル内の全レポート

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

ユーザー：ユーザー定義

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

トラフィック：サマリー、ADWORDSサマリー、Adwordsの掲載位置以外のレポート全て

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

コンテンツ：サマリー、サイト上のデータ表示以外のレポート全て

→離脱率、$インデックス

コンテンツ：サイト内検索：利用状況

→新規セッションの割合、直帰率、コンバージョン率、Eコマースのコンバージョン率

コンテンツ：サイト内検索：検索キーワード

→検索による離脱数の割合

コンテンツ：サイト内検索：検索開始ページ

→検索による離脱数の割合

コンテンツ：サイト内検索：到達ページ

→検索による離脱数の割合

コンテンツ：サイト内検索：カテゴリ

→検索による離脱数の割合

コンテンツ系レポートでは新規セッションの割合、直帰率の割合が加重並び替え項目にならないんですね。
また、カスタムレポートでも、セッション数と直帰率といった関連し合う項目がレポート内にあれば、加重並び替えが表示されてました。他にもありそうですので、見つけたらぜひ教えてください。

それなら、ユーザーの「コピペ」回数が計測できるこの「tynt」、ニッチですが、面白いです。今見ているこのページの適当な文章をコピーして、それを新規メールなり、テキストエディタにペーストしてみてください。

するとこんな感じでペーストしたところに引用元のURLが表示されます。

Read more: http://susumukatachi.jp/archives/1767#ixzz0wyg9WNfL
より引用

URLの最後にtyntが生成したユニークなIDが付与されるので、どのページの「コピー」がクリックされたのかtyntの管理画面を見れば分かるという仕組み。

コピーされた回数がわかるんですね

…これ、ユーザーの「シェアしたい度」を表す指標(aka ユーザーエンゲージメント)として見たらいいのかも。

要は

コピーされた回数
記事をコピペして誰かとクローズドにシェアしてくれそうだ
（あの人にこれ、教えて上げよう）

↓

はてブ数
はてなブックマークでオープンにシェアしてくれた
（自分＋このことに興味のある人たちにも教えてあげよう）

↓

Tweetされた数
Twittterでその人のコミュニティでオープンにシェアしてくれた
（自分の知っている人みんなに教えてあげよう）

といった順でだんだん「シェアしたい度」が上がってくる、といった具合ですかね。
これら３つをGoogle Analyticsとかけあわせて分析すると、深堀できそうです。

例えばこんなのはいかがでしょう。

セッション数がユニークユーザー数よりも少ないのはなぜ？

セッション数（訪問数）＞　ユニークユーザー数
であるはずだ、と思っていませんか？
でも、Google Analyticsは、
セッション数（訪問数）＜　ユニークユーザー数
なデータも表示している…。

なぜでしょうか？

セッション数とページ別セッション数の関係

Web Analytics TV #５で説明されていますが、

グーグルアナリティクスでは、
最初にアクセスしたページに,セッション数（Number of Visits）を紐づける仕組みになっている。

つまり。
仮にAさんが、
page01.html→page02.html→page03.htmlと見ていってサイトを離れた場合、

セッション数にカウントされるのは、最初のpage01.htmlだけ、ということ。

だから、
カスタムレポートで指標に「セッション数」、ディメンションに「ページ」を選んで表示させると、セッション数が１となるのは、page01.htmlだけ、となります。先ほどの図でセッション数のほうがユニークユーザー数よりも少なかったのはこのため。

「いやいや、Aさんがみたのはpage01.htmlと、page02.htmlとpage03.htmlなんだから、それぞれにセッション数１を加えてくれよ」
とお思いの方も多いはず。
そこで登場するのが、「ページ別セッション数」。

これならAさんが、
page01.html→page02.html→page03.htmlと見ていってサイトを離れた場合、
ページ別セッション数はそれぞれ１となります。
ページ単位で訪問数を数えたのが「ページ別セッション数」です。

セッション数と閲覧開始数の関係

最初のページにだけセッション数を紐づける(さっきの例だとpage01.htmlですね）ということは、閲覧開始したページにセッション数をカウントするということ。
そう、これつまり「閲覧開始数」指標ですね。

試しにカスタムレポートで「セッション数」と「閲覧開始数」指標をいろんなディメンションで切ってみてください。
基本同じ数字が出てくるはずです。例えばこんなふうに。

閲覧開始数とセッション数が同じ（都市ディメンションでみたときの例）

閲覧開始数とセッション数が同じ（ソースディメンションでみたときの例）

まとめ

1. 「セッション数」を「コンテンツ」カテゴリにあるディメンション（ページタイトルやページ等）で表示させると、セッション数　＜　ユニークユーザー数といった意図しない数字が表示されることがある。
2. 「コンテンツ」カテゴリディメンションでは、「ページ別セッション数」を使うと良い。

（実際標準セットされているツールのコンテンツレポートでは「セッション数」は表示されず、すべて「ページ別セッション数」になっていますね）

ページ滞在時間もあって、なんで直帰率が100%？って思ってみたり…

「あれ、なんで直帰率が100%なのに、ページ滞在時間が０じゃないの？」とか、「ページ別セッション数が０じゃないってことは、あれ、なんでだ？」となってしまったり。

なぜこんなふうに思ってしまうの？

おそらくその大きな原因は、

なんとなく直帰率と一緒に表示されている「ページビュー」や「ページ別セッション数」が直帰率に影響をあたえるもんだと思い込んでしまうから。

そう、ホントは関係ないんです。ページビューとかページ別セッション数は。

ここで表示される「直帰率」は、ここに表示されていない「直帰数」ってやつと、「閲覧開始数」っていう指標を使って計算しているわけで。
直帰数　÷　閲覧開始数　＝　直帰率　なんです。

直帰数２を閲覧開始数２で割ると1になりますね。

上は、カスタムレポートでページビュー数、ページ別セッション数、平均ページ滞在時間、直帰数、閲覧開始数の指標を出してみたところ。
最初の図にあったページ(archives/37)の直帰数が２、閲覧開始数が２で 計算すると直帰率が1（100%)になります。（余談：本当はカスタムレポートに直帰率も出したかったのですが、ディメンションで「ページ」を選ぶと直帰率が選択できずで断念）

つまり。

ページ別セッション数やページビューが存在するのに直帰率100％なコンテンツは；

このサイトで最初のページがそのコンテンツだった人は全員帰っちゃったけど、他から入ってきてそのページにやってきた人はいるようだ

を意味しています。

そういった人たちに何ページ総数で見られたかという指標がページビュー数で、
そういった人たちの訪問が何回あったかはページ別セッション数で、知ることができるわけです。

つまづかなきゃ、つまづかないポイントですが、ひとたび「うーん、なんでだろう」と思い込むとぐるぐる回り出すんですよね、こういうのって。

アップデートされたGAREnhancer

はじめての人はこちらの記事をどうぞ。
「標準の「セカンダリディメンション」にはない項目で深堀したい」

これだけでは、つまらないので…。
「ページURLとページタイトルの組み合わせ」もGAREで閲覧できるようにしました。ユーザスクリプトにほんの少し手を入れて。
で、出来たのがこんな感じ。

「ページタイトル」をセカンダリディメンションへ追加してみた

これならソース×ページタイトル↓とか、

ソース×ページタイトルで分析できる

キーワード×ページタイトル↓なんかも、ひょひょいとできて面白いかと。

キーワード×ページタイトル

肝心のスクリプトの追記方法です。
(1)Firefoxの「ツール」メニューから、「GreaseMonkey」＞「ユーザースクリプトの管理」を選択します。
(2)リストが左側に表示されるのでそこから「GAREnhancer」を選択。リスト外の下にある「編集」をクリック。
(3)GAREnhancer.user.jsのスクリプトが表示されるので、function doSegment()を探す。

[php]newScript.addAfter("request_uri_1", ["request_uri_2","request_uri_last"]);[/php]

↑このスクリプトを、request_uri_lastの後にpage_titleを追加して下のようにする。

[php]newScript.addAfter("request_uri_1", ["request_uri_2","request_uri_last","page_title"]);[/php]

(4)修正が終ったら保存して、Greasemonkeyのメニューも閉じる

これで設定完了です。
再度Google Analyticsを開くなりしてセカンダリディメンションを開いてみてください。