月別: 2014年1月

滞在時間？離脱率？いらなくない？？？

ウェブ解析が市民権を得、「KPI」や「PDCA」ということが業務内でも頻繁に用いられるようになった昨今。

それ見て何すれば良いんですか？

っていうレポートがたまにあって、戸惑うことがたまにあります。

それが「平均ページ滞在時間」と「離脱率」の二つ。

vainmetrics

上記のとおり、Google Analyticsではデフォルトで表示されるこの二つの指標。

必要ですか？ そのページの滞在時間とか見て、何が分かるのでしょう？？

 

というのが、本稿の問題提起です。結論から申し上げると、私個人としては「いらない」と思ってますし、絶対使わない指標の一つです。なぜなら、上に挙げた指標というのは、計測定義上の問題や、前提としての用途の問題、使う場合の複雑さの問題などなど、多くの課題が存在するためです。

以下、その辺り掘り下げていきます。なお、「私個人」の立ち位置は、BtoCサービスを運営する事業者側（notウェブ専業・コンサル）のウェブ分析・改善担当者です。基本的にウェブの指標等は、見る人の立場によっても変化するものだと思うので、「上記のような分析・改善担当者の場合は」という観点のお話だと捉えていただければと思います。

 

《[滞在時間]指標の問題》

まず[滞在時間]の計測定義については、GAやSiteCatalystをご利用の担当者であれば概ね理解されていることだとは思います。滞在時間は基本的に、「当該ページと次ページのタイムスタンプの差分」によって計測されます。そのため、ノンカスタマイズの場合、訪問者が最後に訪れ離脱したページの滞在時間というのは取得されません。（GAの仕様の詳細が追いきれてないので断言できないですが、変更されてなければ今でもそうだと思います。）

そのため、そもそも直帰したユーザーの滞在時間は取得されていないので、LPが一枚完結型で画面遷移を促さないページなどは、直帰率が高まると同時に滞在時間も計測されないケースが増えます。また、例えば特定ページを開いたまま途中でトイレに行くなりなんなりで15分ほどウェブブラウザを放置した後にサイト内のページに遷移すれば、滞在時間には15分加算されたりします。実際は1分しか見ていなくても。

ということで、まず本指標の第一の問題として、

・滞在時間は訪問者の行動に目星を付ける指標としてはあまりに心許ないものである。

と言えます。

また、「滞在時間って伸びると良いの？短いと悪いの？」という問いにも答えられない、非常に曖昧な数値になります。と同時に、滞在時間が伸びる＝「そのページが良く読まれている」なのか、それとも「書いてある内容が良く分からなくて時間がかかっている」なのかも判断できない指標です。そのため、第二の課題として、

・滞在時間は、変化に対する良し悪しの判断ができないもの。

という点も挙げられます。

以上のような事由により、個人的にはアクセス解析における[滞在時間]という指標は無意味だと思っています。（ただし、高機能なヒートマップツール等における[滞在時間]や、ターゲティングツールにおける反応速度出し分けの等については、意外と面白いものが導けるので、それはそれとしてまた後日書こうと思います。）

 

《[離脱率]指標の問題》

続いて離脱率のお話ですが、これまた困ったもので、先に結論を申し上げると、重要なのは「離脱率」ではなく「遷移率」でしょ。というのが私見です。

と、ここまで書いておきながら、もう疲れたので一旦筆を置きます。

離脱率についてはまた後日追記します。（飽き性なもので恐縮・・・。）

 

（2014/2/2）追記しました→「滞在時間？離脱率？いらなくない？？？part2」

ソーシャルボタン計測と、表示数値がズレる理由

ソーシャルが日常化し、ウェブサイト上でもFacebookやTwitterのソーシャルボタンというのはよく目にするようになったと思う。それに伴い、Google AnalyticsやAdobe Analyticsでソーシャルボタンの利用数を計測している企業も増えている。

ただ、アクセス解析で計測している数値と、実際にウェブページ上で表示されている数値が合わない！ということをウェブの担当者から言われることがあり、少々困ったりもする。

各ソーシャルの仕様等もあり面倒なので、ソーシャルボタン計測については予め「あくまで参考値だからズレるよ」ということは言うわけだが、なんだかんだで「アクセス解析側の設定ミスなんじゃないか」とか言われることもあるので、数値が合わない理由をザッと書こうと思う。

そもそものソーシャルボタンのアクセス解析での計測方法については、いろいろなブログ等で紹介されているので、適当にググっていただければ幸い。一応参考までに、Twitter公式のツイートボタンのAdobe Analyticsでの計測方法だけ載せておきます。

/* sample:こんな具合でs_code.jsに書いておけば計測できる */
if(typeof(twttr)!='undefined' && typeof(twttr.events.bind)!='undefined'){ twttr.events.bind('tweet',function(event){
s.linkTrackVars="events,eVar1";
s.linkTrackEvents="event1";
s.eVar1="tweet";
s.events="event1";
s.tl(this,'o',name);
});
}

 

本題に戻りまして。

TweetCount

ソーシャル上での表示とアクセス解析ツールの数値が合わない理由はいくつかあるが、大きく分けると「タイミングの違い」と「データの引っ張り方」が大きな要因だと思う。

《計測のタイミングの違いについて》

  • Facebookやmixiについては、クリックのタイミングでアクセス解析に計測される。（ソーシャル上に投稿されなくても）
  • TwitterやGoogle+はクリック後、各ソーシャル上に投稿されてからアクセス解析に計測される。

まずSNSの種類によっても上記のように計測タイミングの違いがある。

例えばFacebookいねボタンの場合、一度クリックされるものの、その後に投稿しない、もしくは取り消し操作を行った場合はアクセス解析側には”１”という数値が計上されるものの、サイト上でのいいね数は”０”になっている、ということが往々にして起こりうる、ということである。

一般的「ではない」タイプのボタンであればTwitterやGoogle+でもクリックのタイミングで計測できるタイプに変更可能なため、FB等と同じ計測タイミングに変更することはできる。ただ若干画像を用意したりと、手間がかかることもあるので、その辺りは好みに応じてやれば良いと思う。

何はともあれ、上記についてはまず解消できない課題なので、数値のズレは起こるものと理解の上、「アクセス解析上で計測されたソーシャルの数値は、それ相応の活用方法で用いる」、というのが正しい考え方だと思う。なお、下線部についてはいずれ気が向いたら書こうと思う。

《データの引っ張り方》

これは特にTwitterの公式ボタンについてなのですが、ツイートボタンの横とか上に出る数値は、「ボタンを使ってツイートされた数ではない」ということ。多分ここに表示される数字は、Twitter上で当該ページのURLが含まれたツイートがどれだけあるか、という数値だと思われる。

実際、数値の部分をクリックしてみると表示される投稿群を見てみると、URLコピペで貼ったツイートもあれば、当該ツイートに対するリプライ上にURLが含まれるケースも表示される。ということで、このボタンの隣にある数字は、「ボタン利用数」ではなく「Twitterプラットフォーム上での話題数」になるので、当然アクセス解析ツール上での計測とはずれるし、そもそもの読み方が誤解されている可能性もある。 ちなみにFacebookのLikeなどは多分ボタン利用数に近いと思うけれど、これもこれで不安定な動きをすることがあるのでよく分からんす。

 

とりあえず「ソーシャルボタンの利用数をアクセス解析ツールで計測する場合は、計測タイミングをちゃんと理解しよう」、そして「ボタンの横の数字の意味を理解しましょう」ということ。

その上で、ウェブ解析上でのボタンデータの使い方は、流入数との相関や、広告タグやターゲティングデータとの組み合わせでより価値を出していくべし、というのがザッと個人的に思うところです。


マイナスを0にすることは難しい

「もっと問題解決型の取り組みを – U-Site」

この記事を読んで、面白いなぁと思ったので一筆。事業者側のウェブの中の人からすると、強く共感できる部分がある、と同時に少し違和感を感じる部分があったので。

記事内容は読んでいただくとして、僕が気になった部分は大きく三つ、下記に抜粋させていただく。

抜粋１：“マイナスを0にする、つまり問題解決型のアプローチと、0からプラスにのびてゆく、つまり着想育成型のアプローチを区別し、関係者の関心は後者に集まりがちだけれど、前者をマイナスのままに放置しておいて、プラスになった面だけを嬉しがってはいけない”

→非常に共感する部分。

抜粋２：“魅力は人を引きつける。そして魅力を向上させれば商いとして成功する。このような短絡的な発想が、基盤となる当たり前品質への取り組みである問題解決型のアプローチに目を向けない結果につながっているように思う。”

→これは事実と思う一方で、なぜそうなってしまうのか？という点を考える必要があると思う部分。

抜粋３：“したがって問題は、ワークショップのテーマとして取り上げられる事柄に、そもそも問題解決型のものが設定されていないということであり、それはオーガナイザの責任であるともいえる。”

→ この点については、参加する・させる側としては若干違うな、と思う部分。

上記抜粋部分中心に、サービス提供社側のウェブマスターとしての視座から思ったことを書いてみる。なお、下記はあくまで「ウェブ」に限定してUXを考えた時の話として記述する。また同時に、下記は一般企業というよりも私が勤める会社のウェブサイトにおいての話だという前提に基づく。

《共感できる部分》

まず抜粋１の部分は強く共感する部分であり、弊社でも多々見られる傾向である。と同時に、抜粋２にあるような思考がその礎になっていることも事実だと思う。

では、２のようになってしまうのはなぜか？

一つは現場担当者とマネジメント層との視点の違い、という部分がある。非ウェブ専業企業におけるマネジメント層は年代的な影響もあるかもしれないが、まずウェブのにおける改善を理解していないことが多い。

「新しいキャンペーンサイト作りました！売上が〜〜円立ちました！」という報告は報告側にとっても管理する側にとっても非常に聞こえが良い。一方で、「これまでのサイトで分かりづらくなっていた部分を改修しました！売上が〜〜円上がりました」という話は、地味に聞こえると同時に、これまでその程度のこともやってなかったのかよ・・・という印象を上に与えることになりかねない。こと、ウェブを理解していないマネジメント層を相手取る場合には上記のような話が通じづらく、「そんなことやってないで、もっと売上が上がることを考えろ」と言われかねない始末となる。そのため、現場レイヤーは最低品質を担保するよりも、新規の施策に走らざるを得ないということは理解すべき点だと思う。そもそも、最低品質担保のための改修は、明確な金額換算がABテストをかましても出しづらい、という部分も原因の一つではある。

二つ目として、「魅力は人を引きつける」ということが既にユーザー目線ではなく、サービス提供者目線での考えであることに起因する。言い換えれば「UX」という考え方自体が欠落している状態とも言えるため、「マイナスを0にする≠UX」という構図は間違いとは言えないと思う。

ここまでが個人的に共感する部分なのだが、同時に違和感を抱く部分の根幹にもなる。特に二つ目の観点において。

 

《違和感を感じる部分》

主に違和感を抱いたのが抜粋３の部分である。

問題解決型（マイナスを0にする）のワークショップがあったとして、そこに上記のように抜粋２の状態にあるサービス提供者側を参加させたとしても、返ってくる回答は見えている。「当たり前の内容過ぎて意味なかった」と返答になるだろう。根本的なマインドとしてユーザー目線が欠けているサービス提供者にとって、最低品質を保証することなどは既に出来ていると認識（妄想）していることが多い。そういう人間にいくらマイナスを０にすることを説いても、ワークショップとしては実は身にならないことが多い、というのが個人的な見解である。

であれば、ユーザー目線での取り組みがUXの基盤だと考え、まずその観点を養うための起点としては必要ではないかと個人的には考えている。ひとまず新しいウェブサイトの企画でもいいから、まず「UX」、ユーザー目線での思考方法を植えつける。まずは起点を作るという点では、着想育成型も決して悪いものではないと思う。

では何が悪いのか。つまるところ、ワークショップで設定される「テーマ」というよりも、主にワークショップに参加する側のアフターフォローや、前提構築に問題があると思う。私自身もその手の有識者を招き入れ、社内ワークショップを企画実践することがあるが、往々にしてその場では参加者も概ね満足するし、学んだことを実践し、０から積み上げる施策やっていこうとする。当然、マイナスを０にする取り組みには繋がらない。なぜか。その実、企画の段で実は意図としてマイナスを０にする取り組みへの足がかりにする仕組み作りが足りていないが故に、結果として最低品質を保証するためのUXに成り得ていない、というところなのではないだろうか。

 

そんなこんなで、UXやカスタマージャーニーが往々にして根本的な問題解決に効かない、ということは思わないし、とは言え単純に話題が集まるところだけを見ても「マイナスを０にする」というのはもう少し緻密に考えていかないと難しいことだよなー、ということを一企業のウェブマスターとしては思う限りです。