ユニバーサル アナリティクス（モバイルアプリ アナリティクスも含む）を使用している場合、レポートで多数の自己参照が報告される可能性はほとんどありません。
背景
アナリティクスでは、サイトにアクセスしたユーザーがどこから来たか（トラフィックの参照元）が特定され、それぞれの参照元に応じてノーリファラー、オーガニック検索、キャンペーン、参照元サイトに分類されます。
参照トラフィックとは、一般的に他のウェブサイトからサイトに来たトラフィックのことを指します。レポートの集客カテゴリにある参照サイトレポートでは、このタイプのトラフィックを分析することができます。
自己参照の有無を調べる方法
アナリティクスでは、ご自身のドメインをご自身で表示すると自己参照と判断されます。自己参照のトラフィックは、[集客] > [すべてのトラフィック] > [参照サイト] レポートに表示されます。たとえば www.example.com というウェブサイトの場合は、このレポートで www.example.com と表示されているエントリが自己参照となります。
アナリティクスで複数のドメインやサブドメインをまたぐ横断的なセッションを測定するよう設定している場合なら、多少の自己参照の発生は自然な現象です。
しかし、自己参照の多くは、アナリティクスの設定に問題があることを示している可能性もあります。その場合は、自己参照によりデータが歪み、サイトでのコンバージョンやその他のエンゲージメントにつながったトラフィックの本当の参照元が見えなくなっている可能性があります。
自己参照の原因を調べる
analytics.js
ページに analytics.js スニペットのタグを設定している場合は、所有するすべてのドメイン（サブドメインを含む）をプロパティの参照元除外リストに追加しておく必要があります。追加手順は次のとおりです。
- Google アナリティクス アカウントにログインします。
- [管理] をクリックして、目的のプロパティに移動します。
- [トラッキング情報] をクリックします。
- [参照元除外リスト] をクリックします。
- [+ 参照の除外を追加] をクリックします。
- 除外するドメインを入力して [作成] をクリックします。
urchin.js
ページに ga.js スニペットのタグを設定している場合は、残念ながら、自己参照の発生原因には代表的なものがなく、実にさまざまな原因が存在します。そこでこのガイドでは、実際にお客様のウェブサイトで確認された原因として多かったものをご紹介します。これをチェックリストとして活用し、お客様ご自身の自己参照のケースに潜む原因を絞り込んでください。
ご自身のコンテンツで問題がありそうなセクションを調べるには、次のビューフィルタやカスタム レポートをご利用ください。自己参照の問題のトラブルシューティングに効果的です。詳細については、次の各セクションを展開してご覧ください。
ビューフィルタ自己参照の原因を調べるには、[集客] > [すべてのトラフィック] > [参照サイト] レポートに移動します。
このレポートにご自身のドメインのエントリがある場合は、その行をドリルダウンし、[参照 URL] ディメンションを表示します。自己参照の原因として、これらの参照 URL はさらに調べる価値があります。参照 URL ディメンションでは、ユーザーがサイトにアクセスする前に参照していたページの情報が少しだけわかります。しかし、デフォルトでは有益な情報となるクエリ パラメータの部分が含まれません。このため、クエリ パラメータを含む参照 URL 全体を確認するには、ビューフィルタを作成する必要があります。
次のような参照 URL の例を考えます。
/path/sub-path/?query=123¶meter=456
この場合、参照 URL レポートには、デフォルトで次の情報のみが表示されます。
/path/sub-path/
レポートに参照 URL の全体を表示するには、次のビューフィルタを使用します。
警告: アナリティクスのビューにフィルタを適用する際には、必ず事前に用意した新しいビュー（複製したビュー）を使うようにしてください（ビューのコピーの作成方法をご確認ください）。後々のための元データのバックアップとして、フィルタが適用されていないビューを必ず 1 つは保存しておく必要があります。これは、データ収集が適切に行われているか確認するためのソースにもなります。
よく使用するビューフィルタは、次のように設定します。
ビューフィルタの属性
- フィルタ名: パラメータを含む参照 URL 全体を表示
- フィルタの種類: カスタム フィルタ => アドバンス
- フィールド A -> 引用 A: キャンペーン メディア、^referral$
- フィールド B -> 引用 B: 参照、^https?://[^/]+(/.*)
- 出力先 -> 構成: キャンペーン コンテンツ、$B1
- フィールド A は必須: はい
- フィールド B は必須: いいえ
- 出力フィールドを上書き: はい
- 大文字と小文字を区別: いいえ
自己参照の一般的な原因とソリューション
自己参照の一般的な原因にはさまざまなものがあります。詳細については、次の各セクションを展開してご覧ください。
ランディング ページにトラッキング コードがないか、正しく機能していない自己参照の一般的な原因として、ランディング ページやウェブサイトのページにアナリティクスのトラッキング コードが設定されていないケースが挙げられます。これを防ぐには、Google Chrome の Google Tag Assistant プラグインを使用すると、トラッキング コードの欠落や不具合に関する問題を調べることができます。
アナリティクスを使用する場合は、サイトのすべてのページにアナリティクスのトラッキング コードを確実に設定する必要があります。
トラッキング コードに欠落や問題があるページを絞り込むには、上述のカスタム レポートやビューフィルタをご利用ください。
自己参照の最もよくある原因の 1 つは、トラッキング コードの矛盾です。次に挙げるメソッドは、お客様のドメインに関するアナリティクス Cookie の設定や保存の方法を変更します。
このため、これらのメソッドはウェブサイト全域で一貫して呼び出すことが極めて重要です。ウェブサイトの同じページや異なるページでこれらのメソッドを一貫性なく呼び出すのは、Cookie の設定がリセットされたり、新しい Cookie が作成されたりする原因になります。どちらのケースでもアナリティクスでそのキャンペーン ソースが調べられるため、多くの場合はこの時点で自己参照が発生します。
次に、この現象の具体例をいくつか説明します。
サブドメインをトラッキングしている場合の例:
サブドメインのトラッキングは一般的な設定です（詳しくはこちらをご覧ください）。しかし、複数のテンプレート ファイルを使用するウェブサイトでは（サイト全体でグローバルなインクルード ファイルが使用されない場合）、アナリティクスのトラッキング コードを複数の場所に挿入する必要があります。このような場合は、すべてのテンプレート ファイルに同一のトラッキング コードが含まれていることを確認してください。
上述の例で、ホームページと商品ページで 1 つのテンプレート、ショッピング カートのページで別のテンプレートを使用しているとします。
間違っている例
ホームページ:（www.example.com）_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);ショッピング カート ページ:（basket.example.com）
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push([‘_trackPageview’]);
上記の例の場合、ホームページからショッピング カート ページに移動したユーザーは、セッションごとに 2 つの Cookie セット（utma、utmb、utmz）を持つことになります。そして、1 つのセットは次のそれぞれのドメインで作られます。
- example.com（ホームページと商品ページ）
- basket.example.com（ショッピング カート ページ）
_setDomainName を呼び出さないということは、_setDomainName(‘auto’) を呼び出すことと同じ意味を持ちます。このため、document.domain メソッドを使用すると、ga.js により basket.example.com のための新しい Cookie が作成されます。
この状況で自己参照の発生を回避するには、ユーザーがトップレベル ドメイン（www.example.com）にいるか、サブドメイン（basket.example.com）にいるかにかかわらず、アナリティクスで常に同じ Cookie セットを読み出すようにします。
親ドメインとサブドメインで常に同じ Cookie セットが使われるようにするには、ウェブサイト全体のアナリティクス スニペットに _setDomainName の行を含めるようにします。
ソリューション: トラッキング コードでアナリティクス Cookie の設定を変更するメソッドを呼び出す際には、常に同じ種類のメソッドを使用するようにします。
正しい例
ホームページ:（www.example.com）_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);ショッピング カート ページ:（basket.example.com）
_gaq.push([‘_setAccount’, ‘UA-XXXXXXX-X’]); _gaq.push(['_setDomainName', 'example.com']); _gaq.push([‘_trackPageview’]);
複数のアナリティクス トラッキング コードを設定している場合の例
よくあるものの一般的に推奨されない設定は、複数種類のトラッキング コードを併用した設定です。こうした設定は、複数のアナリティクス アカウントに同時に情報を送信する目的で使用されます。
こうした設定では往々にして、トラッカーごとに異なるエンティティ（オブジェクト）が作成されると誤解されている場合があります。しかし、実際にはドメインレベルで Cookie が設定され、トラッカーレベルでは設定されないため、同じページのすべてのトラッカー オブジェクトで同じ Cookie セットの情報が共有、使用されます。
したがって、上記のサブドメインの例で、ウェブサイトのすべてのページで一貫したトラッキング コードを使用することが重要であったように、複数のトラッカー オブジェクトでも一貫したトラッキング コードを使用することが重要です。
間違っている例
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], ['secondTracker._trackPageview'] );
2 番目のトラッカー secondTracker では _setDomainName メソッドが呼び出されていません。このことは、トラッカーとウェブプロパティ（UA-XXXXX-1 および UA-XXXXX-2）の両方で自己参照につながる可能性があります。
ソリューション: 同じドメインに設定しているすべてのトラッカー オブジェクトで必ず同じメソッドを呼び出すように（同じように設定）し、トラッカー間で矛盾が起きないようにします。次の例では、両方のトラッカーで一貫して _setDomainName が呼び出されています。
正しい例
_gaq.push( ['firstTracker._setAccount', 'UA-XXXXX-1'], [‘firstTracker._setDomainName’, ‘example.com’], ['firstTracker._trackPageview'], ['secondTracker._setAccount', 'UA-XXXXX-2'], [‘secondTracker._setDomainName’, ‘example.com’], ['secondTracker._trackPageview'] );
クロスドメイン トラッキングを行っている場合の例
アナリティクスのもう 1 つの一般的な設定として、複数のトップレベル ドメインでの行動を横断的にトラッキングする設定があります。クロスドメイン トラッキングについてはこちらをご覧ください。
2 つのドメイン（www.example.com と www.otherexample.com など）を運営し、両方のドメインを行き来するユーザーの行動をトラッキングする場合は、次のメソッドの 1 つを使用する必要があります。
これらのメソッドを使用すると、アナリティクスの Cookie データを複数のドメインに渡すことができます。どのメソッドを使用するかは、ユーザーがドメイン間を行き来する方法（リンクをクリックする、フォームを送信する、iframe を開くなど）に応じて異なります。
しかし、ここでよく見受けられる問題は、異なるドメイン間で情報を受け渡しするためのタグが、すべてのリンク、フォーム、iframe で適切に設定されていない場合があることです。
HTML ページの例（www.example.com）
間違っている例
<html> <head></head> <body> <a href="http://www.otherexample.com/" onclick="_gaq.push([‘_link’, this.href]); return false;">link 1</a> <a href="http://www.otherexample.com/page2">link 2</a> </body> </html>
上記の例で、link 1 ではアナリティクスの Cookie 情報を otherexample.com に渡すように設定されていますが、link 2 には onclick 属性が含まれていません。
このため、link 1 をクリックしたユーザーは、実際にはドメイン全体でトラッキングされ、link 2 をクリックしたユーザーは example.com からの参照トラフィックとして記録されます。
ソリューション: Cookie 情報が example.com から otherexample.com に渡されるよう、すべてのリンクを適切にタグ設定する必要があります。
正しい例
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> <a href=”http://www.otherexample.com/page2” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 2</a> </body> </html>
ヒント: 別のドメインに移動するリンクが複数ある場合は、JavaScript のフレームワーク（JQuery など）を使用して、別のドメインにユーザーを渡す onclick イベントをチェックすることもできます。
この方法では各リンクに手動でタグを設定する必要がないため、ドメインを横断するリンクの処理方法として当たり障りがなくおすすめです。
ドメイン間のリダイレクトがある場合の例
リダイレクトについてはこの後で詳しくご説明しますが、クロスドメイン トラッキングで自己参照が発生する場合の一般的な原因はもう 1 つあります。それは、アナリティクスの ga.js コードが受け取り側のドメインの URL からクロスドメイン Cookie の情報を読み出す前に、リダイレクトによってこの情報が削除されてしまうケースです。
上記のクロスドメイン HTML の例をここでもう一度見てみましょう。
HTML ページの例（www.example.com）
<html> <head></head> <body> <a href=”http://www.otherexample.com/” onclick=”_gaq.push([‘_link’, this.href]); return false;”>link 1</a> </body> </html>
この例では、_link メソッドは次のようなアナリティクスのクロスドメイン URL を生成します。
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
しかし、ホームページで次のようなリダイレクトが発生した場合:
http://www.otherexample.com/
ユーザーは次の URL に送られます。
http://www.otherexample.com/home
このリダイレクトでは、アナリティクスのクロスドメイン情報を取り込んでリダイレクト先の URL に渡すという操作が無視される可能性があります。
http://www.otherexample.com/?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
リダイレクト先:
http://www.otherexample.com/home
注: この例ではアナリティクスのクロスドメイン パラメータ（?__utma=......）が欠落しています。
こうした現象はよく見受けられますが、これは、サーバーサイド ベースのリダイレクトのほとんどで、元の URL のクエリ パラメータが適切に継承されないことが原因です。リダイレクトのルールは 1 つの URL から次の URL にユーザーを渡すだけのもので、リダイレクトの際にこれらの Cookie パラメータは継承されません。
ソリューション:
-
リダイレクトでアナリティクスのトラッキング パラメータが次の URL に継承されるようにします。
http://www.otherexample.com/home?__utma=117945243.497169939.1345210711.1359390130.1360067715.18&__utmb=117945243.3.10.1360067715&__utmc=117945243&__utmx=-&__utmz=117945243.1358253212.11.5.utmgclid=TeSt1234|utmcsr=(not set)|utmccn=(not set)|utmcmd=(not set)|utmcct=(not set)&__utmv=-&__utmk=258513226
-
または、リダイレクトを削除するか、新しい場所を指すように元のドメインのリンクを変更して、リダイレクトが発生しないようにすることもできます。
モバイルのサブドメインを使用しているか、PC サイトと同じドメインでモバイル専用サイトをホストしている場合
一般的に、ウェブサイトのモバイル版の作成には、PC サイトのサブドメインが使用されます（m.example.com など）。
ウェブサイトのモバイル版でアナリティクスのサーバーサイド トラッキング ライブラリ（PHP、JSP、ASP.NET、Perl）を使用するように設定し（WAP トラッキングと呼ばれる手法）、ユーザーがウェブサイトの PC 版とモバイル版を行き来できるようにしている場合、モバイル ドメインやプライマリ ドメインからの自己参照が発生する可能性があります。
モバイルページで標準の ga.js トラッキング コードを使用していない場合は、ウェブサイトにタグを設定していないページがあるのと同じ状態になります。
WAP トラッキング ライブラリの主な目的は、ローエンド モバイル端末（Cookie や JavaScript のサポートが限られている端末）のトラッキングを可能にすることです。
しかし、最近のほとんどのスマートフォンでは通常の PC 端末と同じように JavaScript や Cookie、画像がサポートされるようになり、スマートフォンの普及も進んでいます。このため Google では、モバイルページで WAP トラッキング ライブラリを使用する代わりに、標準の ga.js トラッキング スニペットを使うように移行されることをおすすめします。
リダイレクトは自己参照の原因となるのでしょうか。実際にはほとんどの場合、リダイレクトが自己参照の原因になることはありません。ただし、クロスドメイン トラッキングを行っている場合は例外です（このドキュメントのクロスドメイン トラッキングのセクションをご覧ください）。ここでは、リダイレクトがアナリティクスのキャンペーン設定に及ぼす影響を例を挙げてご紹介します。
301/302 リダイレクト
このタイプのリダイレクトはサーバーサイドで発生するリダイレクトで、HTTP ステータス コード 301 か 302 が送られます。一般的にこうしたリダイレクトは、ページの場所が変わった場合に採用されます。
301/302 リダイレクトでは、元の参照情報を継承する必要があります。
例:
上記の図で、どこか別のサイト（some-other-website.com）にいるユーザーが example.com のホームページへのリンクをクリックすると、サーバーサイドの 301 リダイレクトが発生し、そのユーザーがホームページの新しい URL（/home）に転送されます。
この場合、301 リダイレクトでは some-other-website.com からの参照情報（JavaScript の document.referrer で取得）を継承する必要があります。
メタリフレッシュや JavaScript ベースのリダイレクト
サーバーサイド以外の手法で発生するリダイレクト（メタリフレッシュの HTML タグや JavaScript の window.location メソッドなど）では、アナリティクスからの参照情報が隠れたり不明になったりすることがあります。このため、ランディング ページとなる可能性のあるページでは、こうした手法を使用しないことをおすすめします。
アナリティクスで iframe を使用した場合の影響や自己参照の可能性について詳しくは、フレームで構成されたサイトとアナリティクスに関する記事をご覧ください。
Flash トラッキング API のトラッキング ライブラリをご利用の場合は、できれば AS3 モードではなく Bridge モードを使用することをおすすめします。詳しくはこちらをご覧ください。Bridge モードを使用すると、Flash トラッキング ライブラリで標準の ga.js トラッキング コードと同じ Cookie を使って情報をやり取りできるため、Flash オブジェクト内のアクティビティの元となる正しいキャンペーン ソース（ウェブサイトの発見に使われたソース）をトラッキングで遡ることができます。
AS3 モードを使用すると、ライブラリで Flash Cookie が使用されます。そして、キャンペーン ソースを特定する際には Flash オブジェクトを開く際に使用された参照 URL が調べられますが、この URL は通常お客様ご自身のウェブサイト（親ページである www.example.com など）になります。
