テストのブログ

アクセス解析、ウェブ解析、ウェブマーケティングなどの役立つことや役立たないことを綴ります。

トラッキングとラッキング

どうもおはこんばんちは。しがない解析士です。
しがないねえ。しがないですねえ。あーしがない。

今日はホントにどうでもいい話です。
この前アップした投稿でやたらと「トラッキング」って言葉を使ったんですよ。 ummmummm.hatenablog.com
アクセス解析メインのブログなんで、まあ使いますよね。トラッキング
GAでもトラッキングコードとかトラッキングIDとか言いますしね。
それで気づいたんですが、なんか言葉に下線が付いてリンクされてるんです。

f:id:ummmmmmm:20160518212817p:plain


調べたら、はてなキーワードというんですか?
なにかしらのキーワードに自動的にリンクが付いて、その言葉の意味が書いてあるページにリンクされているという。
これ、どうしたらいいんですかね。

まあ別にリンクされるだけだったらいいんですが、「トラッキング」という言葉の「ラッキング」というところだけにしかリンクされないって、SEO的にもよくなくなくなくなくなくない?


今夜はブギーバック (Smooth rap) / スチャダラパー

これってよいのかよくないのかどっちだかわからないですね。detail.chiebukuro.yahoo.co.jp
SEO的にもよくないと思うんですよ。
ラッキングって、最近ラグビーちょっと流行ってるからいいけど、トラッキングラッキングって。

d.hatena.ne.jp
やめて欲しいんですが、管理画面見ても修正できるところが見当たりません。
有料だったらリンク外せるみたいですが。

というわけで、どなたか直す方法ご存知でしたらお教えください。できれば無料のままで。
どうぞよろしくお願いいたします。

スチャダラ外伝

スチャダラ外伝

 

 

Googleアナリティクスで計測タグを複数入れると2重カウントになりますよ

いやー、みなさま、お疲れ様です。
ゴールデンウィーク略してGWが終わってはや数日が経っておりますが、やっとブログも書く気になってきました。

さて今日もGoogleアナリティクス関連のお話です。

先日、「なんかGAでダブルカウントされてるっぽいんだけどー」と相談があり、サイトのHTMLソースを見てみるとGAの計測タグ(GAで言う トラッキング コードですね)が2つ入ってました。
同じトラッキングID(プロパティID)が2つ入ってたら、同じIDが入ってるじゃないすかーそりゃ2重に重複してダブルカウントされますよーガハハーつって終わるんですが、トラッキングIDが異なってたんです。
ほら、みなさまの会社でもありがちかもしれませんが、部署ごとに計測したいから複数のトラッキングIDが入っちゃってるとかそういうアレです。

タグ2つ入れててもそれぞれのトラッキングIDごとに計測されなかったっけなーと思いながらも、GA本体は触らせてもらえなかったので、Googleタグアシスタントで調べたのですが、やはりエラーが出ていました。

HTMLソースの上のほうにあるタグのトラッキングIDで2重カウントになっていた(タグアシスタント黄色:Same web property ID is tracked twice.)だけでなく、下のほうにあるタグのIDのほうは計測すらされていない(タグアシスタント赤色:No HTTP response detected)状態。
最悪です。これで何ヶ月も気づいてなかったそうです。
でも"Same web property ID"ではないんですけどね。なぜでしょう。

f:id:ummmmmmm:20160516164509p:plain


そんなこんながありまして、ちょっと仕様が気になったので、いくつかのパターンでテストしてみることにしました。結果は以下のとおりです。

  1. 別IDのユニバーサルアナリティクス(analytics.js)のタグをbody内に2つ。
    ⇒NG(黄赤)
  2. 別IDのユニバーサルアナリティクス(analytics.js)のタグをhead内に2つ。
    ⇒NG(黄赤)
  3. 別IDのユニバーサルアナリティクス(analytics.js)のタグをhead内とbody内でそれぞれ1つずつ。
    ⇒NG(黄赤)
  4. 別IDのユニバーサルアナリティクス(analytics.js)のタグをbody内に2つだが、マルチトラッキングのカスタマイズ。
    ⇒OK(青青)
  5. 別IDのユニバーサルアナリティクス(analytics.js)のタグをhead内に2つだが、マルチトラッキングのカスタマイズ。
    ⇒OK(緑緑)
  6. 別IDのGoogleタグマネージャー経由のタグとanalytics.jsのタグをbody内に1つずつ。
    ⇒NG?(緑黄?)
  7. Googleタグマネージャー経由で別IDのタグをbody内に1つ。
    ⇒OK(緑緑)


以上のような結果でした。もう疲れてきました。

上記で「黄赤」などと書いてあるのは、ID別のタグアシスタントの表示です。

黄色は今回、大体が"Same web property ID is tracked twice."(同じプロパティIDが2回計測されているよ!)で、
赤色は"No HTTP response detected"((不適切なタグの実装やGAのオプトアウト等により、GAサーバーにトラッキングリクエストを送信する)HTTPレスポンスが検出されてないよ!)、
青色は"Code found outside of <head> tag"(トラッキングコードがheadタグの外にあるよ!)や"Non-standard implementation"(通常仕様のタグの実装じゃないよ!)
等になります。

ちなみに、通常の仕様だと、ユニバーサルアナリティクスはhead内(</head> 終了タグの前)Googleタグマネージャーはbody内(body の開始タグの直後)にタグを設置することが推奨されています。
(※注意:Googleタグマネージャーのタグの仕様が変わったようです。headとbodyで分けて設置するなんてどうなんでしょうか。変更しなくても直ちに影響は無いと思いますが…。
【注意!】Googleタグマネージャーのコンテナスニペット(タグ)の設置方法が変わりました。 | 運営堂 )

異なるプロパティIDのタグが複数あると、計測上問題はなくても、"Multiple Google Analytics tags detected"(複数のGAタグが検出されたよ!)と出るようで、上記パターンではすべてで出ました。

これらの表示は、タグの書き方やGTMの設定の仕方にもよると思います。
タグアシスタントで黄色や赤になってたら、計測状況を確認してみてください。

 

そもそもこのGoogle公式ヘルプの言葉がちょっとわかりにくいのもよくない感じですね。
ユニバーサルアナリティクスでは複数タグ入れても大丈夫みたいにも読めます。
support.google.com


まあ、そのページの下部にマルチトラッキングについて書いてあるページにリンクされていますけども。

複数のトラッカーを使用する

Creating Trackers  |  Analytics for Web (analytics.js)  |  Google Developers

ga('create', 'UA-XXXXX-Y', 'auto');
ga
('create', 'UA-XXXXX-Z', 'auto', 'clientTracker');

ga('send', 'pageview');
ga
('clientTracker.send', 'pageview');

 
以上、GAでタグを複数入れるとダブルカウントになっちゃうから気をつけよう!というお話でした。


★今日のまとめ(突然ですね)
「ひとつのページで複数のトラッキングIDを計測したい場合はマルチトラッキング(multiple tracking)のカスタマイズかGoogleタグマネージャーを使おう!」

デジタルマーケターとWeb担当者のためのGoogle&Yahoo!タグマネージャーの教科書【タグ実装仕様書サンプルPDF付き】

デジタルマーケターとWeb担当者のためのGoogle&Yahoo!タグマネージャーの教科書【タグ実装仕様書サンプルPDF付き】

 
実践 Google タグマネージャ入門 増補版

実践 Google タグマネージャ入門 増補版

 

 

注目記事
 

Googleアナリティクスでは同一ドメイン間のページ遷移で前のページにタグが入っていないと参照元がノーリファラーになっちゃうよ問題

どうもこんにちは。八方塞がりーマンです。

今日もアクセス解析、特にGoogleアナリティクスについてのお話ですが、内容はタイトルのまんまです。

言いたいことはそれだけなので、ここでもう終了させてもいいかもしれません。

でもそれではブログではなく、ツイッターになってしまいます。なので、だらだらと無駄な文章を書き綴ろうと思います。


ノーリファラー問題って、サイトを分析する人たちを悩ませますよね。

基本的な原因は衣袋先生の記事の通りです。

web-tan.forum.impressrd.jp

参照元なし」になる場合の例
  • ブックマークによる閲覧
  • URLをアドレスバーに直接入力して閲覧
  • ショートカットアイコンをクリックして閲覧
  • アプリケーション(メールソフト、Microsoft Word、ExcelRSSリーダーなど)に記述されたリンクをクリックして閲覧
  • セキュアサイト(URLが「https:」で始まるサイト)内のリンクから非セキュアサイト(URLが「http:」で始まるサイト)を訪問した場合
  • ブラウザの設定で参照元情報を削除してアクセスした場合
  • アクセスの際にプロキシサーバーやセキュリティソフトで参照元情報を削除されて訪問した場合
  • 参照元を引き継がないリダイレクトによる訪問

最近だと、

  • ブラウザのアドレスバーのURLサジェストでアクセスしたり、
  • スマホアプリからのアクセス

もノーリファラーの原因になるようですね。

さて、経緯は先日来、とあるサイトのGoogleアナリティクスの参照元を見ていると、やたらと「(direct) / (none)」(直接アクセス/ノーリファラー)が多いな~と思って調べていたところでした。

そのサイトは下記のようなページ遷移がされていました。

XXX.com/A.html ⇒ XXX.com/redirect.html ⇒ XXX.com/B.html
          (リダイレクト!!!)

これはリダイレクトのせいでノーリファラーになってるのかな~と思っていましたが、リダイレクトでも、JavaScriptやメタタグのリダイレクトは確かにノーリファラーになるようですが、上記のサイトではサーバー側のhtaccessで遷移しているようでした。

301リダイレクトだと、通常はリファラーが残るようですし、httpヘッダーを調べるツールなどで調べても、やはりリファラーは残っている(「XXX.com/A.html」のリファラーが残っている)ようです。

「タグが抜けてるページからのアクセスはノーリファラーになる」というページや書籍もあったので、それかな~とも思いましたが、公式ヘルプなどではそのような記述が見つからず、確信が持てずにいました。

なんとも困ったということで、頼みの綱として、「Google アナリティクス 公式コミュニティ」に質問。

www.ja.advertisercommunity.com

 いくつかのやり取りの末、やはり下記のように、同一ドメイン間のページ遷移でタグが入っていなかったためという確信が持てました。

XXX.com/A.html ⇒ XXX.com/redirect.html ⇒ XXX.com/B.html
(タグなし)  ↑ (タグなしリダイレクト)  (タグあり)
        ↑
   ノーリファラーで計測!!!

なぜわかったかというと、SEM Technologyの山田さんに

ga('create', 'UA-XXXX-Y', {'alwaysSendReferrer': true});

といった設定があることを教えていただき、そこから検索して、公式開発者ページでそのような記述を見つけたからでした。

参照 URL を常に送信
analytics.js のフィールド リファレンス  |  ウェブ向けアナリティクス(analytics.js)  |  Google Developers

デフォルトでは、トラフィック参照元の関連付けに使用される HTTP 参照 URL は、参照元サイトのホスト名が現在のページのものと異なる場合にのみ送信されます。

まあ、普通に使っていれば当たり前といえば当たり前ですが、なんとなくタグが入ってなくても、自サイトのドメインリファラーになりそうな気がしていましたので、盲点でした。

同一ドメインでもサイトの構造上、別IDのタグが入ってたりするサイトもあるかと思いますので、ご留意いただければ幸いです。

それではまた会いましょう。

 

注目記事
 

小保方晴子さんの?ホームページ「STAP HOPE PAGE」のアクセス解析

こんにちは。八方塞サラリーマンです。
これまで年1回のブログでしたが、もう少し書いていこうと思います。

やはりウェブ解析、アクセス解析関連の話でやっていったほうがよいでしょうか。
まあでも、ネタはすぐになくなりそう、と言いますか、飽きそうなので、すでに気が気ではありません。
気が気でないっておそらく初めて文字で打ちましたが(書いたこともないかも…)、
よく見るとなんかすごい言葉ですね。気が気でないって。気でないなら、なんなのでしょうか。
気≠気? 気≒気?
日本語っておもしろいですね。


それはさておき、少し前の話になりますが、数年前に世間を騒がせたSTAP細胞の件、先日、小保方晴子さんのものと思われるサイトが公開されましたね。
STAP細胞の作成方法について公開しているようです。

stap-hope-page.com

STAP細胞の是非については、これまでいろいろなところでいろいろな方が書かれているので、もちろんこちらでは言及しません。わかりませんし…。
なので、上記のサイトの内容についてもよくわかりません。英語ですし…。
いや、読めば多少わかりますよ?私だって。英語くらいわかりますよ?でもあまり読む気がしないので読みません。(この辺がうだつが上がらない原因)

「HOPE PAGE」ってダジャレかな?とか、そういうことも気になりますが、今回は、アクセス解析のブログということで、サイトの計測がどうなっているか、見てみようと思いました。
ソースを見ると、Googleアナリティクスを使っていますね。

そして、タグで気になったのが、下記の一文。

ga('set', 'forceSSL', true);

 

SSL の使用(HTTPS

高度な設定 - ウェブ トラッキング(analytics.js)  |  ウェブ向けアナリティクス(analytics.js)  |  Google Developers

デフォルトでは、Google アナリティクスによって外部リクエストの送信時にホストページのプロトコルのマッチングが行われます。セキュリティで保護されていないページ(HTTP)からの送信も含め、常に SSL を使用して Google アナリティクスのデータを送信するには、以下のように forceSSL フィールドを true に設定します。

 
ほほう。通信のセキュリティを保つために、httpでサイトにアクセスされた際も、GoogleアナリティクスのデータはSSLで送信される、ということでしょうか。
それほど、この「STAP HOPE PAGE」は通信のセキュリティに気を使われているということかもしれません。
(最初にこのサイトを見たときはhttpsSSL常時接続サイトかと思っていたのですが、Googleで「STAP」で検索するとhttpのサイトがインデックスされていますね。httpsへのリダイレクトはしないのでしょうか)


余談ですが、乙武さんのホームページの計測も気になりましたね。
乙武さんのところもGoogleアナリティクスを使っていますね。
すんごい瞬間風速的に莫大なアクセスが来たんだろうなあと。

ototake.com

サーバーが落ちないように、AWSを使って負荷を分散させていたなんて分析もあり、興味深かったです。

fukuyuki.net


危機管理としてのウェブサイト運営というのも、これから重要になってくるのでしょうか。

それではまたお会いしましょう。

あの日

あの日

 
五体不満足 完全版 (講談社文庫)

五体不満足 完全版 (講談社文庫)

 

まじブログとかなんなの?

こんなん書けるわけないよね。ブログとか。
そんなおもしろおかしいこと書けないですよね。
でも、がんばってやっていこうと思います。
よろしくお願い致します。

私は現在インターネッツ関連の仕事でアクセス解析等をやっているので、このブログは当初、アクセス解析等の情報を提供するブログにしようと思いましたが、やめました。
私の中の奥深くで沸騰しているマグマのような、あらゆるものをなぎ倒していく嵐のような、そんな私の日常風景をお送りできたらと思います。
よろしくお願い致します。

あぁ、ふざけて生きていきたい。
でも難しい。
ふざけて生きるのがいちばん難しい。
応援よろしくお願い致します!