( ウェブ開発 ) :: ハブろぐ - havelog.ayumusato.com

Mar 05, 2010携帯向けGoogle Analyticsの計測異常(au, softbank)

Category : ウェブ開発

Tags : Google Analytics

計測異常

今回は以下のエントリーのシリーズ編です。

そいで、前エントリーあたりで言及していた計測異常について。

au: 直帰率が100%・新規セッションも100%・ページビューは1
softbank: 見あたらない。(not set)とかいうのがソレっぽい

なーんかauとsoftbank取れてないなー。おかしいなーと思っていたら只の間違い探しでした。

ga.phpがお茶目すぎた

端末情報ちゃんと食ってるよねぇ〜？と、ga.phpの140-149行目を見てました。

    $guidHeader = $_SERVER["HTTP_X_DCMGUID"];
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_UP_SUBNO"]; // えっ？
    }
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_JPHONE_UID"]; // えっ？
    }
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_EM_UID"]; // えっ？
    }

ん？

$SERVERってなんやねん。

    $guidHeader = $_SERVER["HTTP_X_DCMGUID"];
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_UP_SUBNO"];
    }
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_JPHONE_UID"];
    }
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_EM_UID"];
    }

こうでしょ！

ってことで、たぶん解決。

どうしたGoogle！　大丈夫かGoogle！

ga.phpの140-149行目における、$SERVERになっているところを、$_SERVERに修正してください。（アンダースコアが足りてない）

これでたぶんdocomo以外の計測も正常に行われるようになるんじゃないでしょーか。きっと。おそらく。清々しいケアレスミスだけど、それが大公開されっぱなしって、Google先生ほどの大家になると誰も突っ込んでくれないのかな...。

うまくいったよー、っていう人とかいたら教えてくださいまし。

Mar 04, 2010携帯電話向けGoogle Analyticsを導入

Category : ウェブ開発

Tags : Google Analytics 携帯

携帯電話とったどー

昨年の後半発表された、Google Analyticsの日本の携帯電話対応。絵文字のユニコード化といい、なぜかGoogleは日本のガラパゴス技術にも積極的な取り組みを見せてくれています。

今回、それを使って携帯電話のアクセスがなんとなく取れました。なんとなく取れたのでメモ。

でもスクリーンショットを見ると分かるとおり、Softbankっぽいキャリアが見あたりません。単純にいないだけなのか、取得できていないのか謎なので、もうちょっと調べる必要がありそうです。

=> 解決編追記@携帯向けGoogle Analyticsの計測異常(au, softbank)

携帯電話向けのGoogle Analyticsトラッキング

通常のGoogle Analyticsはga.jsを挿入することで、ユーザーがブラウザを開いたときにJavascriptが起動して、Googleにアクセス情報を送信します。

しかし、日本の携帯電話のほとんどは依然としてブラウジング時にJavascriptが使えないため、同じようなアクセス解析はできません。そこで携帯電話向けのGoogle Analyticsは以下のような、一見して回りくどいプロセスでトラッキングを行います。

(1)アクセス情報を飛ばすPHPファイル(ga.php)を設置: Google Analyticsからga.phpをダウンロードしてきて、公開ディレクトリのルートに配置します。これが、Googleにアクセス情報を飛ばす処理の本体です。
(2)ユーザーアクセス時に、(1)のPHPを起動するための下準備: HTMLファイルの先頭にトラッキングURLを生成する関数を記述。bodyタグの終了直前に、src属性が前述の関数が出すURLになっているimgタグを記述。
(3)ユーザーからのアクセスによってga.phpが起動: ユーザーがページにアクセスすると、ページ下端に仕込まれたimgタグが読み込まれます。imgタグのsrc属性がga.phpにアクセスするようなURLになっているため、ブラウザは画像を求めてga.phpにアクセスします。アクセス情報はsrcにあるURLのGETクエリーとして乗っています。
(4)ユーザーにダミー画像を Googleにはアクセス情報を: アクセスされたga.phpは、ユーザーには1x1ピクセルのダミー画像を返し、GoogleにはGETクエリーに乗ってきたアクセス情報を送ります。

普通にphpなどのプログラムを貼る必要があるため、慣れない人やHTMLオンリーな人は戸惑いを感じるかもしれません。とはいえやってること自体はコピペ天国です。

ナマのHTML+PHPなら大体こんな感じ

<?php
  // Copyright 2009 Google Inc. All Rights Reserved.
  $GA_ACCOUNT = "MO-0000000-0";
  $GA_PIXEL = "/ga.php";

  function googleAnalyticsGetImageUrl() {
    global $GA_ACCOUNT, $GA_PIXEL;
    $url = "";
    $url .= $GA_PIXEL . "?";
    $url .= "utmac=" . $GA_ACCOUNT;
    $url .= "&utmn=" . rand(0, 0x7fffffff);
    $referer = $_SERVER["HTTP_REFERER"];
    $query = $_SERVER["QUERY_STRING"];
    $path = $_SERVER["REQUEST_URI"];
    if (empty($referer)) {
      $referer = "-";
    }
    $url .= "&utmr=" . urlencode($referer);
    if (!empty($path)) {
      $url .= "&utmp=" . urlencode($path);
    }
    $url .= "&guid=ON";
    return str_replace("&", "&", $url);
  }
?>
<html>
<head>
<title>タイトるんるん♪</title>
</head>
<body>
<h1>まことにもうしわけありません</h1>
<p>ろれむいぷさむらりるれろ ろれむいぷさむらりるれろ ろれむいぷさむらりるれろ ろれむいぷさむらりるれろ ろれむいぷさむらりるれろ</p>
<?php
  $googleAnalyticsImageUrl = googleAnalyticsGetImageUrl();
?>
<img src="<?= $googleAnalyticsImageUrl ?>" />
</body>
</html>

拡張子htmlのまま動かしたい場合は、.htaccessに下の記述を加えればいいです。

AddType application/x-httpd-php .html

携帯向けサイトを作る機会がある方はぜひ。カスタムレポートとかちゃんと設定すれば、Google AnalyticsひとつでコンテンツへのPC版等と比較しながら検討できて便利です。サービスが分散しないのはいいこと。

a-blog cmsはテンプレート上でphpが使えないので、GETモジュールにしてあげる必要があります。次回、そのGETモジュールをまるまる公開予定です。

Feb 19, 2010OAuthについて（OpenIDとは違うのだよ）

Category : PHP < ウェブ開発

Tags : php OAuth API

OAuth

OpenIDが、あなたは本人ですか？ねぇほんと？ねぇ？的な身元証明の技術であるのに対して、OAuthはこの人に合い鍵渡していい？ねぇ？ほんとにいいの？的な私財へのアクセス許可の技術です。

現在、Twitterの他にもYahooやGoogleのAPIもOAuth認証に対応しています。FlickrもOAuthのベースになってるような認証だった気がするけど、今はどうなんでしょうね。

とりあえずベーシック認証よりは、よっぽどセキュアというわけですが、詳しいメリットや成り立ちなどは、下の参考URLでもご覧くださいまし。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そのプロセス

コンシューマー登録: アパートの管理人（サービスプロバイダ ex.Twitter）に、合い鍵収集業者（コンシューマー）として登録し、業者ID ( コンシューマーキーとコンシューマーシークレット ) を得ます。
リクエストトークンの請求: アパートの住人（ユーザー ex.Twitterユーザー）に、合い鍵くれとリクエストを送ります。その際、業者IDをユーザーに渡して、OKなら業者IDを管理人に渡してくれ、と頼みます。
ユーザーの認否: ユーザーは管理人のとこに行って、この業者に合い鍵を渡すかどうかを判断します。（Twitterとの連携サービスとかをやると、良く出てくるアレです。許可・不許可の。）
リクエストトークンの発行: ユーザーがOKを出してくれると、合い鍵業者は、管理人に合い鍵を請求するための委任状（リクエストトークン）をもらえます。
アクセストークンの入手: 委任状を手に入れた合い鍵業者は、それを携えて管理人に、そのユーザーの合い鍵（アクセストークン）をもらいに行って、それを受け取ります。
合い鍵が変わったら？: 合い鍵はたまに変わってしまうかもしれません。そのとき、合い鍵業者は委任状と前の鍵を持って、もう一度管理人に会いに行きます。委任状が今でも有効なら、新しい合い鍵を受け取れます。すでに無効なら、それは住人が、あなたとの縁を切ったということです。

逆にわかりづらい？

抽象化したら逆に分かりづらい気がする。そうでもないか？まあ、そんな感じでトカゲのしっぽを切れる程度の便利認証でござる。一晩だけの関係とかでもいいわけですよ。合い鍵業者とか訳の分からないことを言わずに、夜這い業者と訳した方が良かったか。

前エントリーで述べたような、HTTPリクエストの実装よりは、よっぽどハマりポイントはありません。仕様に従って作れば一通り問題ありませんでした。OAuthで重要なのは、その意義（使い所）とプロセスを理解することです。

RFC3986の形式でちゃんとエンコードしないとダメとか、そういうのはありますが、コンシューマー側を作る分には、そこまで大変ではありません。サービスプロバイダー側を実装するのは結構面倒くさそうな...。

「OAuthについて（OpenIDとは違うのだよ）」の続きを読む