WordPress LOGOはい、ごめんください。

wp_is_mobile は 3.4 移行から使える、モバイルからのアクセスを判別する便利な関数です。
例えばスマホ用に見せたい物がある場合や、表示を変更したい場合に、下記のように使えます。

wp_is_mobile のモバイル判別方法

wp-includes/vars.php の 101 行目で、下記のようなコードがあります。

つまり、ユーザーエージェントに下記の文言が含まれていると、モバイルと判断されます。

Mobile, Android, Silk/, Kindle, BlackBerry, Opera Mini, Opera Mobi

WP Super Cache のモバイル判別方法

そしてキャッシュ機能として有名なプラグイン、WP Super Cache 。
これはモバイルにも対応していて、モバイルからのアクセスがあった場合にはキャッシュしないという機能があります。

下記がモバイルと判断されるユーザーエージェントのリスト。これらが含まれていると「モバイルからのアクセスだ」と判断されます。(2013.2.15 ver1.2)

2.0 MMP, 240×320, 400X240, AvantGo, BlackBerry, Blazer, Cellphone, Danger, DoCoMo, Elaine/3.0, EudoraWeb, Googlebot-Mobile, hiptop, IEMobile, KYOCERA/WX310K, LG/U990, MIDP-2., MMEF20, MOT-V, NetFront, Newt, Nintendo Wii, Nitro, Nokia, Opera Mini, Palm, PlayStation Portable, portalmmm, Proxinet, ProxiNet, SHARP-TQ-GX10, SHG-i900, Small, SonyEricsson, Symbian OS, SymbianOS, TS21i-10, UP.Browser, UP.Link, webOS, Windows CE, WinWAP, YahooSeeker/M1A1-R2D2, iPhone, iPod, Android, BlackBerry9530, LG-TU915 Obigo, LGE VX, webOS, Nokia5800

同じく下記も設定されていますが、接続ネットワークでも見てるのかな?

w3c , w3c-, acs-, alav, alca, amoi, audi, avan, benq, bird, blac, blaz, brew, cell, cldc, cmd-, dang, doco, eric, hipt, htc_, inno, ipaq, ipod, jigs, kddi, keji, leno, lg-c, lg-d, lg-g, lge-, lg/u, maui, maxo, midp, mits, mmef, mobi, mot-, moto, mwbp, nec-, newt, noki, palm, pana, pant, phil, play, port, prox, qwap, sage, sams, sany, sch-, sec-, send, seri, sgh-, shar, sie-, siem, smal, smar, sony, sph-, symb, t-mo, teli, tim-, tosh, tsm-, upg1, upsi, vk-v, voda, wap-, wapa, wapi, wapp, wapr, webc, winw, winw, xda , xda-

モバイルとパソコンの表示を変えたい時、管理画面の「詳細」タブから、「詳細」項目の Mobile device support. (External plugin or theme required. See the FAQ for further details.) という部分から設定を確認できます。

チェックが入っていれば、モバイルからのアクセス時にはキャッシュを生成しません。
これによって、「モバイルとパソコンの画面デザインを分けている」かつ「キャッシュ機能を有効にしている」場合でも、キャッシュを作るのはパソコン用画面のみとして対応しているわけです。(モバイル用のキャッシュも作れればいいんだろうけどなあ…)

iPad はパソコン?モバイル?

さて、タブレット端末の場合、私はパソコン用の画面を見せるのが一番良いと思っています(今のところ)。
そのため、iPad での表示はパソコンと同じ物を想定していました。

iPad のユーザーエージェントは下記のようになっています。(Chrome で iOS5 のエミュレートした場合)

Mozilla/5.0 (iPad; CPU OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3

wp_is_mobile では、Mobile が引っかかるので モバイルと判断されます。
WP Super Cache では、該当するものがないので パソコンと判断されます。

ただ違うのね、で終わりではありません。

wp_is_mobile でモバイルと判断されるということは、モバイル用の画面を表示する
WP Super Cache でパソコンと判断されるということは、キャッシュを生成する

モバイル用の画面がキャッシュされ、パソコンでアクセスしても有効期限までモバイル用の画面が表示されてしまう。

という状況になります。逆なら、iPad でアクセスしたらパソコン用の画面だけどキャッシュされない、ってなるのですが。

じゃあ、どうしたらいいの?

キャッシュプラグインの内容のほうが複雑なので、

(1) wp_is_mobile をカスタマイズする
(2) 使わないで別の関数を使う

という 2 つの選択肢があります。ただし、(1) はコアファイルの修正なのでお勧めしません。必然的に (2) の選択肢となります。functions.php に is_mobile という関数を作って使うのが一番。

参考:【WordPress】User-agentを判定してモバイル用コンテンツを切り分け、検証する方法

上記コードを functions.php に書いて使います(少し修正しています)。
これでも willcom や google phone に対応できてないのですが、アクセス解析のユーザーエージェントを確認して追加していくくらいでいいのかなあと。

参考:スマートフォンUSERAGENT一覧+モバイル版クローラ | カグア!Googleアナリティクス解説Blog
参考:serbanghita/Mobile-Detect · GitHub

タブレット端末での検証もお忘れなく!

Writing Notes with Grammyはい、ごめんください。
音楽聞きながら仕事してたら、やけに捗って遅くまでテンションあがってしまったひじりです。お肌が荒れて困りますわね奥さん。

さて、お客様が WordPress を使うにあたって、プレビュー機能があるとはいえ、やはり編集画面は実際の画面に近いほうがいいよね、ということで色々カスタマイズしていたのですが、一気に便利になった方法がありました。

editor-style.css にスタイルをコピーするのがメンドクサアァァァイ!!

管理画面のスタイルは editor-style.css をテーマ用ディレクトリに作成してゴニョゴニョするのですが、クラスとか増えるたびコピーするのが面倒になってきました。最後にやる作業であることは間違いないのですが、今後も増えてくるだろうなと。
そうすると、適用されている CSS をそのまま使えたらいいのになー と、思うわけです。コピーするのがメンドク(ry

管理画面の細かいカスタマイズについては下記サイトが参考になります。
WordPressのTinyMCEをチキチキにカスタマイズする | 高橋文樹.com
WordPressテーマのfunctions.phpでは$content_widthを定義するべし | firegoby

まずは使ってる CSS を呼んで設定を足そう

editor-style.css を使えるようにするには、add_editor_style という関数を使うのですが、これは CSS を有効化するためのものではなく、読み込むための命令なんですね。ということは、他の CSS も読み込めるわけです。いくつでも良いみたいですよ。

また、テーマ内で投稿内容が反映される場所って、大抵 class や id の指定がされています。例えば、デフォルトテーマの Twenty シリーズだったら #primary とか。投稿画面=投稿内容が反映される部分 と考え、class もしくは id を設定しましょう。class は知ってたけど、ダメ元で id やったら適用できました(・ω・)

早速 function.php に下記の内容を追記。editor-style.css はひとまず空っぽのまま作っておいてください。css フォルダに置いてあるような css は、function.php からの相対パスを設定してください。

これで設定した CSS が読み込まれます。プラグイン使わないと、かゆいところに手が届いて良いですね。
編集画面を確認すれば、表示が変わったのがわかるかと。chrome などの開発用ツールで確認しても読み込まれているのがわかるかと思います。$initArray[‘body_id’] を使ったら、ちゃんと body に id が設定されました!

そして editor-style.css で調整

このままだと、「body に背景は設定してて #primary は白いんだけどなあ」という場合などに対応できていません。それを editor-style.css で差を吸収します。下記は一例です。

あとは、style.css などで設定した class などがそのまま使えるので、theme_advanced_styles(TinyMCE Advanced だとスタイルを選べる部品)とか有効にしてるとずらりっと出てきます。これは逆に使いにくいかもしれないですが…?

管理画面のカスタマイズに躊躇していた方も、ぜひ一度お試しください♪

09. 1月 2013 · [Smarty] テンプレート内で連想配列を宣言して使用する はコメントを受け付けていません。 · Categories: WEB制作 · Tags: , ,

ちょっとハマったけど地味に便利だったのでメモ。

Smarty は PHP から配列を渡すことで、ラジオボタンやチェックボックスを簡単に作ってくれる機能があります。そして、テンプレート内で PHP の関数を使用できます。

PHP から渡す値は SQL で読み込んだデータそのもの、という単純な状態の場合、簡単な連想配列を使ってラジオボタンを作りたいという状況になりました。PHP のコードは追加したくない、Smarty だけで何とかしたい…と考えて、調べてみた結果、自分が求める方法はこちらが一番近いと感じました。

Smarty のテンプレートで配列を定義する – XCL Labo

ですが、これだと連想配列が使えません。考え方を変えて、連想配列を使わなくてもいいようにする、という方法も考えましたが、PHP の関数が使える → unserialize 使えばいけるんじゃね?ということで、Smarty のテンプレート内で連想配列を使う方法を考えてみました。

PHP 側でちょっとした準備が必要です(あとで消す)

unserialize するためには、serialize されたデータがなくてはなりません。簡単な配列をシリアライズしたものを一旦画面に表示させます。

echo serialize(array(‘Y’=>’はい’, ‘N’=>’いいえ’));

すると、配列がシリアライズされて表示されます。

a:2:{s:1:”Y”;s:6:”はい”;s:1:”N”;s:9:”いいえ”;}

これを Smarty で使ってしまおう!というわけですね。このシリアライズされた文字列が取得できれば、 PHP で記述した上記のコードはもういりません。

あとは Smarty だけでなんとかするよ

さて、これを Smarty で使うためには、一度変数に格納してから unserialize する必要があります。unserialize したデータは配列になっているので、ラジオボタンやチェックボックスに使うことができます。

シリアライズしたデータを Smarty で使うにあたってのポイントは、デリミタを変数で使用すること。こうしないと正常に渡せません。また、シングルクォーテーションで囲んでしまうと変数が無効になるので、そのまま渡しても良いのではないかと。

はい、ごめんください。ひじり@雪国のウェブ解析士です。

ここ数日ぐったりして Advent Calendar を落とすどころか、ツイッターも見ていませんでした。と言っても、仕事も楽しんで、家庭も楽しんで、ネットも楽しみたい欲張りなので、気を取り直して浮上します。
WEB解析 Advent Calendar 2012 18日目の記事です。

追記:2012/12/19

GAならアドバンストセグメント「直帰以外の訪問」もオススメ
更に周辺情報も加えて提案すると説得力、納得感が増しますね。

と、ウェブ解析士協会の江尻さんからコメントをいただいたので、6. を追加しました。

さて先日、リニューアルのご相談をいただきました。

何も考えなければ営業担当が先方の話をハイハイと伺って、「じゃ、この金額でできますよ」と見積りを出す流れが少なくないのですが、雪国のウェブ解析士を名乗るからには、それで終わらせるわけには行きません。

先方は「今あるコンテンツを整理したい」(リニューアル時にはよくあることですね)というご要望があるので、実際の利用者の動向を踏まえつつ、アクセス解析から現在のニーズを調べることで、優先させられるコンテンツを提案することにしました。

アクセス解析の目的と確認ポイント

今回は現在のニーズを調べます。ついでに、現状がわからなかったので、サイト全体の直帰率や離脱率、平均PVなどをざっと確認しました(これはデータの海にハマリかねないので普段はしないほうが良く、項目を決めてちゃんと定点観測しておくべきです)。

ニーズを調べるには、下記のような項目が参考になります。もちろん、状況によってはこれに限りません。

1. PV数の多いページはどこか?

言わずもがな、需要の高いページです。
サイト全体の場合と、最初に表示するページ(ランディングページ)の場合を確認しておきましょう。
それぞれに違いが出たら、どうしてその違いが出たのか考えてみます。

2. コンバージョンのページに遷移しているページはどこか?

お問い合せや資料請求など、コンバージョンのページに遷移しているページを調べます。
実際に送信されてくる問い合わせなどのメールが少なくても、何らかの意図を持ってそれらのページにアクセスしたわけですから、その前のページがコンバージョンを喚起している可能性があります。

3. 新規訪問の割合別に、直帰率が低く、訪問別PVが高いキーワードはどれか?

1回の訪問でホームページ内を回遊するということは、その分興味があるということ。
意図しないキーワードで訪問別PVが多いキーワードは、ニーズを探れる宝箱です。
新規訪問の割合が高いキーワードは新規顧客獲得のヒント、逆に低いキーワードはリピーターへリーチできるヒントがありそうですね。

4. 直帰率、離脱率の高いページはどこか?

現状改善のヒントとして、直帰率や離脱率の高いページがどのページかを把握しておく必要があります。値が高いことを問題にするのではなく、それらのページで何が起きているのか?を考えます。

5. モバイルの場合とモバイルを抜いた場合とでは上記の違いがあるか?

パソコンとモバイルでは使っている状況が違うので、モバイル用サイトを最低限のコンテンツにする場合は、特に把握しておく必要があります。
違いがある場合は最適化する余地に気づくことができますね。

また、デザインや対応端末の判断のために、ガラケーの使用率や現在の対応ブラウザのシェアを見ておくといいですね。

6. アドバンスセグメントで「直帰以外の訪問」のみに制限してみる

つまり、1ページ閲覧しただけで帰ったユーザではなく、複数ページを閲覧したユーザのみを対象にして絞り込むわけです。そうすると、サイト自体に興味を持っている(可能性が高い)ユーザのアクセス状況がわかるわけですね。

ちなみに、新規のお客様にいきなり「アクセス解析データを見せて下さい!」と言うのはいくらなんでも無謀なので、せめてリニューアル前に現状把握のためのアクセス解析を入れてもらうこと、データがあるとこんなことがわかることなどをお伝えしたほうがよろしいかと思われます、はい。

Cookies初級ウェブ解析士のテキストで、javascript を埋め込むビーコン型のアクセス解析ツールは、主に Cookie を発行してセッションを判断していたりする、ということを学びました。javascript が無効の場合はイメージタグを埋め込んだりすることもありますね。

アクセスしたサーバが発行するクッキーが、ファーストパーティクッキー。アクセスしたサーバとは別の(第三者の)サーバが発行するものが、サードパーティクッキー

サードパーティクッキーのメリットとデメリット

メリット – 複数のサイトを横断的に解析できる

たとえば、自社のサイトとは別に、別ドメインの共有 SSL 環境を使っていたり、外部サービスのショッピングカートを使っていたりする場合などですね(サービスによっては自サイト以外にアクセス解析ツールを入れられない場合もあります)。

デメリット – セキュリティによっては無効になっている場合がある

Apple の Safari はデフォルトでサードパーティ製の Cookie を受け付けません。
これは Mac でも iPhone でも同様です。つまり、iPhone はツールによっては取得できない場合があるわけですね。

上記は MBA Safari の環境設定。ブロックする対象が知らないサイトや広告のみ=サードパーティクッキーを拒否しています。サードパーティークッキーは悪意のあるサイトも対象になるので、今後セキュリティ的にも拒否されていくかなくなっていくような。

このことから、サードパーティークッキーはできるだけ使用しないほうが無難ということですね。ちなみに、常にクッキーを無効にしている場合はファーストパーティクッキーも拒否するので、アクセスデータは取得できません。

Google Analytics はサードパーティークッキーではないの?

外部サービスなのでサードパーティー製と思ってしまいますが、ファーストパーティ製のクッキーです。

Google Analytics の導入は http から始まる外部スクリプトじゃん?スクリプトダウンロードしてないし。

というのが理由になりそうなもんですが、あくまで js が外部であって、アクセスしているサイトで発行させているので、ファーストパーティクッキーなのです。

ファーストパーティでも複数ドメインの解析ができる

そう、Google Analytics ならね。

参考:複数ドメインのトラッキング – アナリティクス ヘルプ

ちょっとコツがいりますが、トラッキングコードを取得する際に使い方に応じてコードが発行されるので、そちらを使いましょう。単一ドメイン用のコードをそのまま複数ドメインサイトには使えないのでご注意を。

GA が発行する主な Cookie

__utmb

訪問者のセッションを測定するためのクッキー。保存期間は30分(30分以内にアクセスするとその度に延長される)。30分経過するか、深夜0時にリセットされて削除される。

__utmc

ga.js では、すでにセッション管理には使われていないとのこと。昔の urchin.js のトラッキングコードを使用しているサイトとの後方互換性のために使った際、ブラウザを終了するとセッションが切れるようです。ga.js でセッション管理のために使うのは望ましくないですね。

__utma

ユニークユーザーを判断するためのクッキー。保存期間は2年です。こちらもアクセスするたびに延長されますが、基本的に自動リセットされることはありません。ブラウザごとに設定されるので、たとえば Chrome や Safari を同じ人が使ったら別人と判断されますし、社内でアクセスしたサイトに、家のブラウザでアクセスしたら、それもまた別人と判断されます。

__utmz

検索エンジンの結果や、直アクセス、外部リンク、広告やメールのキャンペーンなどの参照元とページナビゲーション(サイト内の回遊?)の情報を格納しています。保存期間は6ヶ月で、ページにアクセスするたびに延長されます。( utmcc として GIF としても使われるようです)

__utmv

このクッキーは、トラッキングコードのデフォルト設定では使われません。カスタム変数(_setCustomVar())を使用して、_setVar() メソッドを追加した場合のみ発行されます。保存期間は2年で、アクセスするたびに延長されます。( utmcc として GIF としても使われるようです)

__utmx

ウェブテスト(旧ウェブサイト オプティマイザー)のために使用されます。A/Bテストを行った際、同じ訪問者に同じ画面を見せるためなどに使われます。保存期間は2年で、アクセスするたびに延長されます。

__utmmobile

モバイル環境で使用する、__utma に似た情報を格納する。でも下記になかったので、__utmz と __utmx に統合されたかな?

参考:Cookies & Google Analytics on Websites – Google Analytics — Google Developers

WEB解析 Advent Calendar 2012 の 9日目の記事でした。

07. 12月 2012 · [GA] Google Analytics でデータをサクッと書きだして時間別グラフをつくろう はコメントを受け付けていません。 · Categories: ウェブ解析 · Tags: , ,

Google Analytics では、カスタムレポートで時間別データを出すことができます。ですが、グラフに表示するのは今のところできないようなんですね。そこで、データをエクスポートしてエクセルでグラフを作ってみましょう。

まずはカスタムレポートをつくろう

1. GA の カスタムレポート を選んで、[+新しいカスタムレポート]をクリックして、新規追加します。

2. 全般情報を下記のように入れます。[時間別レポート]のところはお好みで。

指標グループ には見たいデータを、ディメンションの詳細 には「時」を入れて下さい(時間帯ではありません)。

3. 保存すれば、時間別のデータを閲覧できます。表示が10件なので25件にしたり、時の昇順に順序変更したりするとだいたいわかります。

が、グラフは日別の推移を表しているだけで、表も数字だけでわかりにくいです。

エクセル形式でエクスポートしよう

エクセルで使うことを前提にしていますので、エクスポート から「Excel(XLSX)」を選ぶとデータを簡単にダウンロードできます。

シートが分かれていて、訪問数の日次推移(折れ線グラフの元データ)も載っていますが、今回はこのシートは使いません。もうひとつに、カスタムレポートの情報が載っていることでしょう。

指標グループで設定したデータがありますので、あとはそれをエクセルでグラフにするだけ!
うちの10月1日から12月7日までのデータを時間別にするとこんな感じです。

このグラフから見えることは?

グラフを見て、何か気づいたところはありますか?

  • 深夜の新規訪問の割合が高いですね?
  • 11時と15時頃に集中して閲覧されているようですね?
  • 22時以降はあまり見られていないようですね?

上記は現象でしかありませんが、ここから原因や訪問者像が見えてきます。

  • 割合は割合でしかないので、母数が少ないと影響を受けやすい。
    外国語圏のデータを省いていなかったので、bot以外の何か人ではないものが0時以降に来てるのかも。
  • 11時頃はブログを予告更新している時間。
  • 15時は一息ついたビジネスマンが気にして読んでくれてるのかな?
  • 夜になったらあまり見られない。ブログの内容は社会人向けだから、まあ間違ってないかな。

ということから、

  • 外国語圏のデータを省いてみよう。
    それでも深夜に新規訪問率が上がるようなら原因を考える。
  • リピーターを増やすために、11時の投稿をしばらく心がけてみよう。

なんてことを考えることができます。エクセルでデータを加工したほうがわかりやすい場合もあるので、カスタムレポート→エクセル形式にエクスポート を使ってみてくださいね。

Google Analyticsパーフェクトガイド Ver.5対応版 はボリューム満点でしかも最新の GA に対応してるので超オススメです。これはもう「辞書」と言えるでしょう。

WEB解析 Advent Calendar 2012 7日目の記事でした。

Hand Lens要するに「この指標を見れば成果に貢献してるかどうかがわかる」というもの、つまり KPI の例です。だいたいこんな目的で使うよ、という代表的なものを挙げてみました。

よくある落とし穴

間違って欲しくないのは、これらを必ず確認するべき、というものではないですし、この中に必ずあるというものでもなく、KPI は企業・団体で全部違うと言っても過言ではありません。

例えば天気。

主婦は、明日は晴れるのか、雨が降るのかを確認します。気温を見ることもあります。
船乗りは、明日の波の高さや風の強さや向きなどを確認します。
お天気お姉さんは、天気予報の原稿を確認します。
気象学の専門家は、統計なども含めて3ヶ月予想を出したりします。

これだけでも、天気に対するアプローチが全部違うというのがわかります。「明日洗濯して乾くかな、風向を確認しておこう」なんて言う主婦はいないんじゃないでしょうか。
夏や冬など、時期によっては気温を確認する人も増えるでしょうし、うちみたいな豪雪地帯は、真冬になると大雪になる日を重点的にチェックしたりします。そんなチェックポイント、上には挙がっていません。が、得てしてウェブ解析で重要視するポイントというのはそんなもんです。

それぞれの生活スタイルに合ったポイントがあるように、それぞれのビジネスに合ったポイントがあります。ECサイトなどは比較的わかりやすいですが、それ以外のホームページも少なくありません。
データから仮説を立てて KPI に当たりをつけ、検証するなどのサイクルを回してビジネスを改善していくことができるのが、ウェブ解析です。

前置き長くなりましたが、大事なことなのでもう一度

以下は、あくまでサブとして参考になりそうな指標です。メインとなる KPI は探して見つけてください。それもきっと楽しいですよ。
そしてこれらの指標を何のために使うのか、指標のデータがいつ、どうなったら仮説を検証できるのか、という視点を忘れずに。

よくある指標と使いどころ

直帰率

一番よく言われる指標ですね。英語では「Bounce Rate」と言います。ページを開いたけど、跳ね返ったように帰っちゃったよ、という比率です。
直帰率が高いと、興味を持たれずに帰ってしまった場合が多いとされ、「もっとサイトを見てもらうようにしよう!サイト内をたくさん回遊してもらおう!だから直帰率を下げよう!」というのがセオリーになっています。

検索で到達したランディングページなんかは、直帰率の高さは改善指標となりえます。
でもみなさん、ブログやニュースを読むときの事考えて下さい。はてブなどで人気が出たページを読んで、満足して、そのページを閉じませんか?これって悪いことでしょうか?意地でもなんとかしなければならないでしょうか?
ニュースサイトやブログの直帰率は高くなる傾向が強いです。関連項目出してたって、すでに読んでるような常連さんは、最新情報だけ見て帰ってしまいますもんね。

平均ページビュー数

1回の訪問で、1人がどれだけのページを見たのか、つまり、サイトにどれだけ興味を持ってくれたかがわかります。
たくさん見てくれれば嬉しいですよね。でも、ニュースサイトやブログは、1回の訪問で1ページだけ見て帰ることも少なくありません。
「平均PVを増やしたいから、ブログの記事を複数ページに分割しました」というのがどれだけ意味のないことか、もうおわかりでしょう。(読みやすくするために分割するのは別)

滞在時間

「平均で 見てはいけない 滞在時間 グラフに出して ばらつきを見よう」という標語を作りました。今。
そのページで立ち止まって、どれだけの時間興味を持ってくれたかという目安になりますが、タブブラウザが浸透している現在では、「開いたけどあとで読もうと思って読んでない」ということが往々にしてあります。
そのため、データにかなりのばらつきが出てきますが、とんでもなく飛び出た数値が平均値に影響を及ぼしている場合には、中央値が目安になりますね。

ページビュー数・セッション数(Google Analytics だと 訪問数)・ユニークユーザー数

指標になりそうでならなそうな、でも場合によっては必要な指標です。昔から言われている「アクセス数」がこれらにあたります。「アクセス数」とくくられている場合、どの値を取っているのか確認する必要がありますね。
中には「Aさんが訪れたので1、次にBさんが訪れたので2、しばらくBさんがサイトを見てたけど、やっとCさんが来て3、Aさんがもう一度来て4」なんてカウントしてたりして、使い物にならない「アクセス数」もあります。

ユニークユーザー数は、何人くらいの人が訪れたかがわかります。
セッション数は、その人たちが何回くらい訪れたかがわかります。
ページビュー数は、どれくらいのページを閲覧されたのかがわかります。

それぞれの使いどころがわかりますでしょうか。

例えば、「とにかくたくさんの人に見てもらいたい!」ならユニークユーザー数を、「できるだけ多くのページを見てもらいたい!(ECサイトの商品とか)」ならページビュー数を、それぞれ目安にすることができるわけですね。

リピート率

2回以上サイトに訪れた人の割合です。
これが高すぎるとリピート率は高いのですが、ご新規さんに届かず、少なすぎると一見さんが多くて、ファンが少ないと言えるでしょう。
そうすると「リピーターを増やす/新規顧客を集めるために、この指標を使おう!」と自信を持って言えますね。

 

他にも色々あるでしょうが、指標は選ぶのではなく見つけるもの。そして状況に応じて変えていくもの。しかもアクセス解析からでは見えない指標もあります。例えば、ホームページを見て電話をかけてきた件数とか。地図を見てイベントに訪れた人数とか。ホームページが関わっている以上、これらもウェブ解析の範疇です(「成果を出すために!」という意気込みは半端ないです)。

ちなみに、「このブログがウェブ解析に興味を持つ方の参考になったらいいな」と思う私の、このブログの KPI は、今のところ「月間PV」と「リピート率」と「特定ページにおける特定検索ワード率」などです。

みなさんも、今一度自分のサービスを見直し、何を指標にしたらいいか考えてみて下さい。わからなければ、ウェブ解析士がお手伝いいたします(笑)

WEB解析 Advent Calendar 2012 5日目の記事でした。

01. 12月 2012 · [PHP] PHP5 の strtotime の年またぎの挙動が変わってた → 時限爆弾になってハマったこと はコメントを受け付けていません。 · Categories: WEB制作 · Tags: ,

PHP
参考:PHP: strtotime – Manual

strtotime は、特定の書式の日付(文字列)を UNIX タイムスタンプに変換する関数です。
PHP4 では、下記のような引数を入れても正常に動作していました。

これが PHP5 になると、まったく動作しません。

strtotime(‘2012-13-00’) の結果が FALSE になるためです。
引数に存在しない日付を入れてるからだろうと思うなかれ、下記は PHP4 でも PHP5 でも同じ挙動です。(2012年はうるう年です)

要するに、年が増えると FALSE になってしまうのですね。これについてはこの辺が参考になると思います。

参考:PHP: 日付の書式 – Manual

注意:

シンボル dd と DD について、 オーバーフローやアンダーフローすることができます。 つまり、 0 日は先月の最終日の意味になりますし、 オーバーフローすると翌月に繰り越しになります。 このルールにより、”2008-08-00″ は “2008-07-31” と同一になり、 “2008-06-31” は “2008-07-01” と同一になります ( 6 月は 30 日までしかないので)。

また、シンボル mm と MM についても 0 を用いてアンダーフローすることができます。 0 月は前年の 12 月を意味します。 たとえば “2008-00-22” は “2007-12-22” と同一です。

もしこれらを併用し、日も月もアンダーフローした場合は次のようになります。 “2008-00-00” は、まず “2007-12-00” へと変換され、 さらに “2007-11-30” へと変換されます。 文字列 “0000-00-00” についても同様に “-0001-11-30” へと変形されます。 (ISO 8601 における -1 年は、予測的グレゴリオ暦 (proleptic Gregorian calendar) で言うところの紀元前 2 年になります。)

「アンダーフロー」というのは、0より小さくなった場合に繰り上げて処理すること、「オーバーフロー」というのは、例えば月だったら12より大きくなった場合に繰り越して処理すること。
2行目の「シンボル mm と MM についても~」という部分。アンダーフローについては記載がありますが、オーバーフローについては可とも不可とも記載がありません。

ただまあ、「使えてたから使った」というのは「無知は罪である」というのと通じるところがありますね。strtotime のマニュアルに、下記のような記載があります。

注意:

この関数を使って日付の足し算や引き算を行うことはおすすめできません。 PHP 5.3 以降なら DateTime::add() や DateTime::sub() を、そして PHP 5.2 なら DateTime::modify() を使いましょう。

「おすすめできません」とあるのだから、使うほうが間違っているのです。
上記は PHP5 以上ならという制限があるので、PHP4でも挙動が変わらない mktime を使うべきですね。こっちなら間違いありません。

これだからデザイナー上がりの自称 PHPer は!とか随所から聞こえてきそうですが、自戒を込めての post でした。

29. 11月 2012 · [WP] バナーは wp_list_bookmarks と GA でイベントトラッキングすることにした はコメントを受け付けていません。 · Categories: WEB制作 · Tags: , ,

Pretty Awesome 3D Metal WordPress Logo内部コンテンツへ誘導するためのもので、広告とは毛色が違い、URLが長くなるとちょっとイヤンな感じだったので Ad Rotate はやめました。

でもどれくらいクリックされたのか追跡したいので、管理しやすくすることも踏まえ、WordPress のリンク機能と、Google Analytics のイベントトラッキング機能で対応することにしました。

2012/11/30 追記:onClick → onMousedown に変更してみました。アウトリンクのタイムラグで取得できない場合もあるのね…なるほど。

参考:Googleアナリティクスでの外部リンククリック計測3つの手法の利点と欠点を整理してみた | Web担当者Forum

まずはリンクに登録

カテゴリーを設定し、バナー(今回はアフィリエイトリンクではなく、内部コンテンツへ誘導するものを指します)のタイトル、リンク先、画像URLを設定します。

テーマファイルに設定

リンクに登録したものは、 wp_list_bookmarks で呼び出せます。
ただ、標準機能ではアンカータグの内部に属性として値を設定することが出来ないため、PHPでちょいと置換してあげることで対応できます。ちなみに、Google Analytics をすでに導入済みであることが前提です。(ヘッダに非同期用のスクリプトが入っていること)

[CAT_ID] にはリンクのカテゴリーIDを入れてください。

$ga_tracking の [category] は、たとえば BannerClick などが良いでしょう。[action] は特に”アクション” にこだわる必要もないので、カテゴリースラッグあたりを入れておけばわかりやすいと思います。たとえば sidebar とか。

上記では p タグで縦に並べて表示させたかったのですが、設定項目は本家のパラメータを参考にしてみてください。

参考:テンプレートタグ/wp list bookmarks – WordPress Codex 日本語版

これでテーマファイルを保存すると、トラッキング用のタグが入っているのがわかるでしょうか。これで広告やバナーの管理がだいぶ楽になるのではないかなと思います。

PHPがよくわからないからどう書けばいいのかわからないーという方は、コメントくださいな。

12. 11月 2012 · [WP] posts_nav_link が WP_Query のループで動作しない理由と解決策とスニペット はコメントを受け付けていません。 · Categories: WEB制作 · Tags: , ,

Wordpress Button Closeup

結論から言っちゃうよ

  • new WP_Query でクエリを新しく作ったものには posts_nav_link が使えない
  • posts_nav_link(前後記事へのリンクを張る)を使いたい場合は query_posts を使おう
  • new WP_Query を使いたい場合は WP-PageNavi を使ってページングしてしまおう

なぜ posts_nav_link が使えないのか

参考:get_posts_nav_link (WordPress Function) – WPSeek.com

ソースを見たら一目瞭然でした。global $wp_query; として、大元のクエリをベースにしているためです。新しく作ったクエリを引数で渡せないかなと思いましたが、そのままでは無理そうですね。

その点、query_posts はメインのクエリ($wp_query)を変更するので posts_nav_link を使えるというわけです。

WP_Query × WP-PageNavi

WP-PageNavi は 1,2,3… と番号でページングしてくれるプラグインです。これにはクエリを渡せるので、下記のように使えます。

最後は wp_reset_postdata(); で締めましょう。新しく作ったクエリを消して元に戻す、というイメージで。

query_posts × posts_nav_link

posts_nav_link もループ外で使用します。

最後は wp_reset_query(); で締めましょう。元のクエリに戻す、というイメージで。

今回は結果的に、WP_PageNavi を入れたほうがスッキリしたのでプラグイン採用しましたよ。