フォームの最適化について他社のフォームを真似する前に・・・

インターネットのフォームは昔から存在しながら、その改善はHTMLのバージョンやCSS、Javascriptを使った新しいUIの提案のみで大きな革新というものはあまり無いように思います。
もちろん、このような新しいUIにより大幅に放棄率などが改善するパターンもあるでしょう。


フォームの最適化というのは非常に難しい課題ですが、最近思うのは2010年に発表されたフォームデザインに関する20の指針をまずはチェックして欲しいということです。

【参考】

似たような実験はいくつかありますが、指針は以下の20項目で構成されています。
  1. Let people provide answers in a format that they are familiar with from common situations and keep questions in an intuitive sequence. 
  2. If the answer is unambiguous, allow answers in any format.
  3. Keep the form as short and simple as possible and do not ask for unnecessary input.
  4. If possible and reasonable, separate required from optional fields and use color and asterisk to mark required fields.
  5. To enable people to fill in a form as fast as possible, place the labels above the corresponding input fields.
  6. Do not separate a form into more than one column and only ask one question per row.
  7. Match the size of the input fields to the expected length of the answer. 
  8. Use checkboxes, radio buttons or drop-down menus to restrict the number of options and for entries that can easily be mistyped. Also use them if it is not clear to users in advance what kind of answer is expected from them. 
  9. Use checkboxes instead of list boxes for multiple selection items.
  10. For up to four options, use radio buttons; when more than four options are required, use a drop-down menu to save screen real estate. 
  11. Order options in an intuitive sequence (e.g., weekdays in the sequence Monday, Tuesday, etc.). If no meaningful sequence is possible, order them alphabetically. 
  12. For date entries use a drop-down menu when it is crucial to avoid format errors. Use only one input field and place the format requirements with symbols (MM, YYYY) left or inside the text box to achieve faster completion time. 
  13. If answers are required in a specific format, state this in advance communicating the imposed rule (format specification) without an additional example. 
  14. Error messages should be polite and explain to the user in familiar language that a mistake has occurred. Eventually the error message should apologize for the mistake and it should clearly describe what the mistake is and how it can be corrected. 
  15. After an error occurred, never clear the already completed fields.
  16. Always show error messages after the form has been filled and sent. Show them all together embedded in the form. 
  17. Error messages must be noticeable at a glance, using color, icons and text to highlight the problem area and must be written in a familiar language, explaining what the error is and how it can be corrected. 
  18. Disable the submit button as soon as it has been clicked to avoid multiple submissions.
  19. After the form has been sent, show a confirmation site, which expresses thanks for the submission and states what will happen next. Send a similar confirmation by e-mail. 
  20. Do not provide reset buttons, as they can be clicked by accident. If used anyway, make them visually distinctive from submit buttons and place them left-aligned with the cancel button on the right of the submit button. 

もちろん非常に一般的なことばかり述べられていますが、 中でも面白いのがこういうアイトラッキングパターン。
5番目の内容になります。

 

このサッカード数とその時間によりフォーム入力時間は2倍になるといいます。
新規に立ち上がるフォームがあっても、実はこの指針が完全に無視されたものが数多く見受けられます。
もちろん、これが正しいということではありませんが、現状では最も良い指針ではないかと思っています。

そして、もう一つ紹介したいのがFormを評価するための質問紙、Form Usability Scale(通称 FUS)の存在です。FUSは以下の10個の質問で成り立っています。

  1. I perceived the length of the form as appropriate.
  2. I was able to fill in the form quickly.
  3. I perceived the order of the questions in the form as logical.
  4. Mandatory fields were clearly visible in the form.
  5. I knew all the time which information were expected from me.
  6. I knew at every input what rule I had to stick to (e.g. possible answer length, date format or password requirements).
  7. The fill in was eased by given answers (e.g. drop-down menus, checkboxes etc.)
  8. In case of a problem I was instructed by a error message how to solve the problem. (Please check ”I can not answer this question” if there were no problems)
  9. Purpose and utility of the form was clear.
  10. In general I am pleased with the form.
単純に作ったFORMを皆で評価してから改善するという流れも良いと思いますが、事前に過去の知見をもとにFORMを作るということも大事だと思います。

日本で同じような質問紙があるのかどうかはわかりませんが、WEBにおいてとても離脱を生みやすく、ユーザーがそのサイトに定着するかどうかを左右するくらい重要なものなので、単純にFORMを作ってみた!ということではなく、考えぬかれたUIでリリースをしたいものです。可能であればユーザビリティテストを重ねて更にブラッシュアップすべきでしょう。

チェック項目をざっくり意訳で日本語化してはいますが、相当恥ずかしいので自分でFORM最適化で利用する場合は訳をしていただけるとよいかと思います。
また、原本を読むことでチェック内容に対する理解が深まると思います。

ウェブマスターツールの「Fetch as Google」に「取得してレンダリング」メニューが追加

つい先日、Javascriptのエラー状況などもウェブマスターツールで見れるようにするというアナウンスがあったばかりですが、「Fetch as Google」にメニューが追加されたようです。

今まではbotがどのようにページが見えるかソースレベルで確認できたり、インデックス送信ができたりしたページですが、robots.txtやCSSなどの評価結果も見ることができるようになりました。


まだ実際にエラーパターンを見つけていないのですが。
ちなみに一週間のうちにインデックス送信できる回数が決まっていたはずなのですが、その回数表示が消えましたよね?
確かページ単位は500、ページ群が大幅に変わった場合は10が上限だったような気がしますが、回数問わず送信出来るようになったのでしょうか?

Google Analytics利用者向けの「Table Booster for Google Analytics」がイイかも

以前は違う拡張を使っていたのですが、Table BoosterというChromeの拡張はAnalytics上の数値が視覚的にパフォーマンスが分かったり、z検定も比較したいディメンションにチェックを入れるだけで、その場で結果がわかるのでイイかもしれません。


バーチャートとヒートマップと比較グラフはこんな感じで見えます。


z検定も2つのmetrics選択と、2つのdimension選択でサクッと結果が見えます。


【GTM】ウェブサイト内画像のABテストをAnalyticsのイベントを使って実施する


2014年5月25日現在、Google Tag ManagerのWEBサイト側計測の場合、ABテスト(Google AnalyticsのExperiments)を利用することは出来ませんが、海外では複雑なスクリプトを組むことで実現している方もいます。

ただ、そのソースを見ていただければわかりますが、単純に実行されるタイミングをずらしているだけだったりします。古いAnalytics(ga.js)とカスタム変数あたりを利用したソースになっているので、新しいAnalytics(analytics.js)でまずは単純な画像のABテストを実施してみました。

ただし、以下のソースの場合は単純なイベントは取得出来たのですが、「Experiments」画面にデータが反映されませんでしたので、まだ改良が必要です。

まず、ABテストを実施するために乱数を発生させます。


それから、タグでこんなソースを書きます。

var chosenVariation = {{randomNumber}} % 2;

// this does an image replace
var image_variations = [
'images/original.png', 
'images/variation.png' 
]

var pageVariations = [
function() {
dataLayer.push({'event': 'setExpCustVar'});
exp_image = document.getElementById('abtest');
exp_image.src = image_variations[chosenVariation];
if(chosenVariation==0){
exp_image.parentNode.href='images/original_large.png'; 
}
}, // Original: Do nothing. This will render the default HTML.
function() { 
dataLayer.push({'event': 'setExpCustVar'});
exp_image = document.getElementById('abtest');
exp_image.src = image_variations[chosenVariation];
if(chosenVariation==1){
exp_image.parentNode.href='images/variation_large.png'; 
}
}
];

$(document).ready(
pageVariations[chosenVariation]
);

やっていることは単純なのですが、簡単に説明すると
「chosenVariation」には乱数を2で割った時の余り、つまり「0」か「1」が入ります。
で、ABテストを実施したい画像を「image_variations」に入れておき、ページにどちらの画像が表示されたかを計測するために「pageVariations」にもオリジナルが表示されるパターンと実験パターンが表示された場合の2種類を入れておきます。

最後に「pageVariations[chosenVariation]」で画像が表示されるというものです。
今回はHTMLページ自体はこのような形で空にしておきました。


オリジナル画像が最初一瞬写ってから実験画像に置き換わるような動きがあまり好ましくないと思ったからです。
ここまで出来てしまえば、あとはイベントを拾うだけです。
「pageVariations」に、どちらもdataLayer.pushの「イベント」として「setExpCustVar」を入れました。

で、先ほどのタグのソースの「chosenVarition」をグローバル変数として定義しましたので、Google Tag Managerのマクロで値が取得できます。


「chosenVariation」の値をGTMの変数「jsGlobalVariable」に入れておきます。
次にGTMのルックアップテーブルを使って、その変数の値が「0」だったら「original」、「1」だったら「experiment1」が返るように設定をします

あとはイベントを拾うだけです。
イベントのアクションにルックアップテーブルで変換した文字列を集計できるようにします。


このあたりも、もっと応用すれば十分に利用できますね。
ちなみに今回はタグの発火条件は単純にURLのみにしています。それは「event = gtm.js」のタイミングで発火するため、その他のgtm.domやgtm.loadのタイミングで発火させる必要がないからです。


まだ、コンテンツ量が多くなると「(document).ready」回りがちゃんと動くか心配ですが、少し様子見です。

GTMでABテストが普通に実装されるのは、近い未来だと思っていますが、どうせ統計的な処理はローカルでやるのであれば、単純なイベントで取得しても良いような気がします。

あとはcreateElementとsetAttributeを使って、画像のクリック数なんかを取得してもいいかもしれません。

【関連】
Google Tag Managerに関する利用方法まとめ

【GTM】クリック箇所を限定したリンククリックイベントの取得方法

海外でjQueryを使ってゴチャゴチャやっていたけど、実は単純に実装できるよ!というパターンです。
まずはページのソースですが、例えばこんな状態だったとします。

【ソース例】




で、このulタグの中のリンクをクリックしたイベントだけを取得したい場合、Google Tag Managerの設定は一工夫必要になる場合があります。

この例の場合、
Auto Event VariableでElement Classを設定した後に

event = gtm.linkClick
elementClass = blogroll

の条件ではリンクのクリックイベントを取得できません。
こういうネストしている状況でリンククリックのイベントを取得する場合、aタグにElementが指定されていれば良いのですが、そうではない場合マクロにdataLayerを指定する必要があります。

即ちdataLayerの値をこういう設定にします。
gtm.element.parentElement.parentElement.className

クリックされたaタグから見て、2つ親のノードのクラス名を指定する必要があります。

event = gtm.linkClick
gtm.element.parentElement.parentElement.className = blogroll

という指定方法をすることでクリックイベントが取得できるようになります。
実際にはマクロ名が長すぎるので、全然違う名前を付けることになります。

こういうものはChromeまたはFirefoxのFirebugで調べます。
一旦gtm.linkClickをページで発動させた後にChromeのコンソールを見てみます。


gtm.linkClickというイベントが発動しているのが分かります。
それと別に、gtm.elementの下に色んな値があります。そこを調べてみるとどのような値を設定すればイベントが取得できるかが分かります。

gtm.element.parentElement.parentElement.className

【関連】
Google Tag Managerに関するまとめ

20日からパンダアップデート4.0が開始

様々なところで話題になっていますね。

これに絡むかどうかはわかりませんが、SERPsに著者情報(Authorship)が表示されるものが非常に多くなったという報告もあります。

海外でもこの点に言及があるものもありますが、検索ランキングに著者情報は利用されていないと再度言及がありましたので、まだ噂の段階です。

「マウスカーソルはなぜ傾いているか」を記載した記事が面白い

海外のマウスポインターの記事、結構面白かったです。
GUIはもともとXEROXの「パロアルト研究所」で生まれた事は有名なお話ですが、カーソルに関するドキュメントも1981年に記載されていたということです。

元々マウスポインターは傾いておらず垂直デザインだったようですが、当時の画面解像度が低いディスプレイ上では視認性が非常に悪く、現在のデザインに至ったという内容が書かれています。


広告サイズ標準が次の世代に?IAB Rising Stars

IABが新しくRising Starsという新しい広告ユニットポートフォリオを発表しました。
新しい広告は以下の6つ。
  1. Billboard
  2. Filmstrip
  3. Portrait
  4. Pushdown
  5. Sidekick
  6. Slider

リッチな広告の方がより、目をひきやすくクリックされやすい訳ですが、今回発表されたRising Starsの各広告サイズごとにサンプル動画がありますので、ぜひ直接サイトでご確認ください。

次のサイトレイアウトを考える時や、広告とは言わずとも自社コンテンツの魅力的な見せ方としてこれらの広告方式を真似るのはとても意義があると思います。

かなりリッチであることは間違いないのですが、個人的にはFunnelを意識したFilmstripの事例はとても面白かったです。



モバイル版Rising Starsも合わせてご確認ください。
とはいえ、これらの広告は完全なコンテンツ乗っ取りなので議論を呼ぶことは間違いないかも。

流行っているウェブサイトをUXの教材として集めている「User Onboarding」が面白い

海外の「User Onboarding」というサイトが見ていて結構面白かったのでご紹介。


書籍も出しているようですが、例えばPinterestであれば会員登録のステップ数は3段階


マウスオーバーで自動的に画像が拡大されるようになってもいます。
そして、各ページで何がどのような効果があるか、どういう印象なのかなどが細かくメモされています。


ぜひ面白いので見てみてください。

User Onboarding

Google Chrome Canaryバージョンで、「ビーコン」が有効化可能になった

去年からWEBの高速化に対するパフォーマンス系APIの勧告認定やら色々と動きが慌ただしいのですが、Google ChromeのCanary版で2014年2月に編集者草案となっている「ビーコン」が有効化できるようになったようです。(flagsページで有効化)

via Ilya Grigorik


今後、勧告認定されるかどうがは現状分かりませんが、最近の動きを見る限りはその可能性は高いような気もします。

こういう技術回りは専門ではないので詳しい説明は他の方に譲りたいのですが、僕の理解では今までWEB解析系のタグをやりとりするためには同期的なXHRが発生していたため、ユーザー側へのウェブ表示を遅らせる可能性がありました。また画像を使い遅延ロードで解析をした場合もデータの信頼性が揺らぐなどのマイナス影響があったのですが、それを解決する仕様が、この「ビーコン」です。

W3CにはsendBeacon methodの例としてこのようなソースが書かれています。

window.addEventListener('unload', logData, false);

function logData() {
    navigator.sendBeacon("/log", analyticsData);
}

Firefox側もnavigator.sendBeaconへ取り組んでいるようですし、次の展開が非常に気になるところです。

【GTM】ルックアップマクロを使って仮想ページビューを生成

結構これは簡単な例ですが、実際設定していて「マクロ」の「ルックアップ」を知るにはとても良い教材のような気がしました。

黒塗り部分が多くて申し訳ないのですが、ある特定URLを別のURLへと「ルックアップ」を使って置き換えて、置き換えたURLをAnalyticsの「仮想ページ遷移」に代入するだけです。


この設定だとマクロが2つ入っているのですが、1つは「dataLayer」で元々ページに仕込んであるもの、もう一つが今回設定したルックアップマクロです。ただ今のところ両方とも値が入ってくることが無いので、こんな設定にしていますが今後値が入ってくるとしたらタグ自体を2つに分ける必要が出てくるかもしれません。
現状、この辺りの条件分岐などがGTMで組めないのがツラい所です。

【参考】
Google Tag Managerに関するまとめ

当たり前といえば当たり前。でも注意したいユニバーサルアナリティクスでのユーザーレベル条件

海外の投稿でこんな事例がありました。
ユニバーサルアナリティクスで特定の日付、例えば5月1日にUser Idをもった「Aさん」が「ページ1」にアクセスをしました。
それをAnalytics画面から"「Aさん」で、かつ「ページ1」を見た"という条件でユーザーレベルの条件を表示させます。


表示期間に5月1日を含んでいた場合は、確かに正しく「ページ1」を見た「Aさん」のセッションが確認できます。


しかし、一方で5月1日を含まない期間で検索をした場合、確かに「Aさん」は「ページ1」を閲覧したユーザーであるにも関わらず、データは0件となります。


たしかに期間内に「Aさん」は「ページ1」を見ていませんので結果は正しいと感じますが、効果検証を行うにあたって期間を長くすれば長くするほど該当ユーザーが多くヒットし、効果が高いと判定されてしまったり、単純に営業日サイクルで検証したりした場合、本当に見たいデータが見えない、もしくは結果の見方を誤ってしまう可能性を秘めています。

したがって、期間選択には注意が必要となります。
ユーザーレベルでの分析ではコホート分析などに利用すると最も良いと思いますが、Analyticsの解析レベルを再度意識する事が大事だなと感じました。

【GTM】タグマネージャとjQueryを使ったEFO(フォーム改善)

所謂エントリーフォームオプティマイゼーション(Entry Form Optimization)というやつですが、Google Tag Managerを使ってサクッと出来たので、今回はテスト結果の共有です。
事前にjQueryを読み込んでいる前提でこんな感じのScriptを組んでみました。

var now;
 (function($) {
 $(document).ready(function() { 
  var clientId = ga.getAll()[0].get('clientId'); //"User ID"があれば"Client ID"よりもそっちを使うべきかも。
  //    var clientId = "{{utma}}"; //ga.jsの場合は個を特定する値としてutmaをファーストパーティクッキー経由で取得する。
  $(':input').focus(function () {
   now = new Date();
       dataLayer.push({'event': 'form', 'eventAction': 'focus', 'eventLabel': $(this).attr('name') + ',' + clientId + ',' + now.getTime()});
   });
  $(':input').blur(function () {
   if($(this).val().length > 0) {
   now = new Date();
       dataLayer.push({'event': 'form', 'eventAction': 'completed', 'eventLabel': $(this).attr('name') + ',' + clientId + ',' + now.getTime()});
   } 
   else {
   now = new Date();
       dataLayer.push({'event': 'form', 'eventAction': 'skipped', 'eventLabel': $(this).attr('name') + ',' + clientId + ',' + now.getTime()});
   }
  });
  },
 function newDate(){now = new Date();}
  );
 }
 )(jQuery);

やっていることは、Google Analyticsで必ず発行される「clientid」を取得してきます。
あとは、フォームの入力ボックスにフォーカスしたタイミング、離れるタイミングのそれぞれでイベントを飛ばします。ユニバーサルアナリティクスの場合はUser Idを入れると完璧ですよね。

Submit時にもClient Idを入れたり、エラーを検知したり、もっとデータを追加してもイイかも。

<追記>
凡ミスでjavascriptの呼び出し部分を変更しました。
あと、時刻をnow.getTime()にしているのでミリ秒表示です。

【参考】
Google Tag Managerに関するまとめ

「コンテンツ・マーケティングとコンテンツ・ストラテジーは違う」という考え方が面白い

SEJにコンテンツ・マーケティングとコンテンツ・ストラテジーの違いという内容の記事があがっていました。

同一視されがちな両者ですが、簡単に言えば
コンテンツ・マーケティング
ユーザーとのエンゲージメント構築する事を目的とし、サイトと関連性の高いコンテンツでユーザーから何らかの反応(Call To Actionでも良いと思う)を生み出すもの。
コンテンツ・ストラテジー
見込み客に対してより魅力的なコンテンツを生み出しす戦略を立て、組織全体の戦略を反映したコンテンツ群を生み出すこと。
といったところでしょうか。
確かにこの2つは合わせて語られることが多いのですが、見込み客を引っ張るストラテジーと、ユーザーを育てるフェーズのマーケティングは分けて考えると、より「コンテンツ」というものに対して理解が深まるような気がします。

もちろん両方の意味を含んでいたり、ストラテジーとして構築したページにランディングした人が、実際は、より知識的に進んだマーケティング目的で構築したページの内容の方が魅力的であるという場合もあると思います。

両輪がうまく噛み合って回るサイト構造、コンテンツ作成を意識的に行っていきたいものです。

Google Analyticsに「アクティブユーザー数」が追加

Google Analyticsの「ユーザー」レベルに新しく「アクティブユーザー」という項目が加わったようです。

恐らくヘルプはここに該当するんだと思いますが、まだ利用者の間では「なんだ?」といった反応が多いようです。


ヘルプはとても丁寧なのですが、文章が長い!と言う人も多い気もしますが、こんな内容が細かく理由とともに書かれています。

【結局】
・期間のみ指定して「アクティブユーザー」を表示した場合はデータがサンプリングされない。
・ブラウザを指定したり、参照元を指定したりした場合はサンプリングデータとなる。

ただ、今のところなぜ「アクティブユーザー」という名称になったのかが凄く謎です。
例えば30日間のユーザー数と「アクティブユーザー」の「30日間のアクティブユーザー数」は同一の値になっているはずですが、今までの「ユーザー数」と基本的に内容は変わらないのでは?と思わざるを得ません。

今後色んなアナウンスが出てくると思います。

Analytics APIのセグメントでシーケンスを利用したパターン

Google AnalyticsのAPIで利用できるセグメントは色んな実際のパターンを使いながら覚えていこうと思いますが、単純なパターンでのテストです。

まずはユニバーサルアナリティクスで同一User Idを用いてPC → モバイル → モバイルとアクセスをしてみます。
PCはChrome、スマートフォンはAndroidのChromeです。


Analytics画面で見ると1ユーザー、セッション3と計上されています。


User Idもテストでカスタムディメンションに入れていますが、こちらもちゃんとデータが計上されています。


■テスト

セグメントの指定でこの5パターンはキレイに値が取得できました。全て同じ結果が得られます。

  • users::sequence::ga:deviceCategory==desktop;->ga:deviceCategory==mobile
  • users::sequence::^ga:deviceCategory==desktop;->ga:deviceCategory==mobile
  • users::sequence::^ga:deviceCategory==desktop;->ga:deviceCategory==mobile;->ga:deviceCategory==mobile
  • users::sequence::^ga:deviceCategory==desktop;ga:browser==Chrome;->ga:deviceCategory==mobile;ga:browser==Chrome
  • users::sequence::^ga:deviceCategory==desktop;ga:browser==Chrome;->ga:deviceCategory==mobile;ga:browser==Chrome;->ga:deviceCategory==mobile;ga:browser==Chrome



スコープも利用してみた感じですが、同じ値が得られたものはこんな感じです。

  • sessions::condition::perSession::ga:pageviews==1
  • sessions::condition::ga:browser==Chrome;condition::perSession::ga:pageviews==1
  • users::sequence::ga:deviceCategory==desktop;->ga:deviceCategory==mobile;condition::perSession::ga:pageviews==1


実はまだScopeも指定してコンディションとシーケンスの合わせ技は、安定して取得できていませんので、もう少しちゃんとヘルプを読んで理解する必要がありますが、使いこなせればコホート分析は結構楽になりますね。

WEBサイト巨大化によるTTI(Time To Interact)悪化

恐らく4月にradwareから発表された記事の影響だと思いますが、ウェブパフォーマンス系の記事が増えたような気がしています。

(参考)
New findings: Retail sites that use a CDN are slower than sites that do not*

この記事タイトルもかなり衝撃的ですよね。
CDNを利用しているサイトなのに、利用していないサイトと比較してページ速度が遅いと。記事内ではCDN利用サイトの方がよりコンテンツがリッチであったり、サードパーティScriptが利用されているとか、色んな要因が書かれています。最終的にはやはりFront-End Optimization(FEO)であると。

一般的にWEBサイトは10秒以内にコンテンツが表示され、ファーストビューで目的のコンテンツや感情に訴えかけるものがなければユーザーは離脱すると言われています。


また、先ほどのradwareのサイトでは1秒遅くなる度に以下となると書かれています。

  • 直帰率の8.3%増加
  • ページビューの9.3%減少
  • コンバージョンの3.5%減少
  • カート投入金額(cart size)が2.1%減少

cart sizeは金額で良いのかどうか分からないのですが、マイナス要因であることに違いはありません。

別の調査ではそこまでキレイな数値はでていなかったのですが、ページ表示速度が8秒から5秒に短縮されるとページ価値が18%向上するというデータもあります。


恐らくここでいう価値は、Google Analyticsのページ価値と同じような考え方ではないかと推測しています。

ショッピングユーザーの場合ページ表示時間に対するユーザーの期待は2秒以下だとする記事やKissmetricsのインフォグラフィックなども印象的なものがあります。

ページスピードに関するアドバイスはGoogleのものが一番優れていると思いますが、画像の最適化だけでなくJavascriptやCSSのブロッキング、gzip系とか色々とありますが、最近こういうページ表示の話とCDNやインフラ系の話題をよく聞くようになったと感じています。

どちらにしてもユーザーにとってページを利用できるようになるまでの時間であるTTIが短くなるに越したことはありません。この問題は常につきまとうので、次にどういう方向へ発展していくのかが少し楽しみな気がします。


PC側Gmailのデザインがモバイル的なものに変更されるかも

今朝はGeek.comのデスクトップ版Gmailリーク画像が話題になっているようです。


タブ系のデザインは無くなって、メニューはスライド表示がされるようです。


ニューヨーク・タイムズサイトのデザインだったり、Timeのサイトなど、モバイル的なデザインがデスクトップでも増えてきました。
一つは自国だけでなくグローバルに閲覧される可能性があるということは、発展途上国も含めスマートフォンしか持たず、日常的にスマートフォンインターフェースに親しんでいるユーザーが増えており、今後も増加すると予想されます。

またレスポンシブサイトが増え、単なるレスポンシブサイトではデザイン統一までは必要ありませんが、恐らくスマートフォンサイト側の学習がPCサイトで働かないというリスクを減らすためではないかと考えていますが、PCサイトとスマートフォンサイトで似たようなデザインに統一するという動きもあると思っています。

スマートフォンでよく利用するサイトなのにPCサイトに訪れたら、あたかも初めて来たウェブサイトのようにインターフェースが全く違うというのもナンセンスです。

この辺りのウェブデザインの流れは今年から来年にかけて、もっと面白い動きがあるかもしれませんね。

Google SpreadsheetのAddon「Google Analytics」は大量データでも動いて素晴らしい

既に色んな方が利用されていますが、Google SpreadsheetのAddon機能にある「Google Analytics」 ですが、大量データでも普通に動いて凄いですね。


Google公式ということもあって、最近あったAnalytics APIのMetrics系の名称変更も、変更当日からAddon側も新しくなっていました。
ただ一点心配なのは、Reportのレイアウト変更です。レポート設定を変更することでレポートレイアウトが変更されることはありますが、Google起因で変更されないかが個人的に心配だったりします・・・

「アドオン」メニューから「Google Analytics」を探してみてください。


「+ FREE」でインストールしてください。


今まではGoogle Apps側で書いていたのですが、大量データの場合データが全部取得できずタイムアウトエラーになることもしばしば。
少ないリクエストなら全然問題なかったのですが、今回マーケティング系の社内向けレポートのデザイン変更を期にアドオンへ変更。

基本パターン

早速一つレポートを作ってみます。
Spreadsheetの「アドオン」メニューからレポートを作成します。

「レポート名」 : シート名にもなります。

「アカウントインフォメーション」は、Analytics画面のこの部分になります。
※ちょっと小さい画面でゴメンナサイ。



ちなみに、今回の内容とは異なりますが、URLにアカウント番号やプロパティ番号、ビュー番号が書かれています。

Analyticsを見た時のURLですが
visitors-overview/a999999w99999999p99999999/

a : アカウントID
w : ウェブプロパティID(web property)
p : ビューID(Profile)

です。

「Metrics」、「Dimensions」 : こちらから取得したい指標を探す
このMetricsとかDimensionsあたりが、取っ付きにくい部分だとは思っています。

例えば・・・セッション数のデータを特定期間で日ごとに見たい場合、
Metrics -> ga:sessions
Dimension -> ga:date
となります。

例えば・・・ブラウザごとのセッション数を見たい場合、
Metrics -> ga:sessions
Dimension -> ga:browser

となります。

Metricsが実際の計測数値、指標です。Dimensionは切り口ですね。
レポート設定が終わったら、また「アドオン」からレポートを作成することになります。
例えばレポート名で「Rollup」を作っておくと、新規シートに「Rollup」が追加されます。



※レポートは必ずアドオンから追加しないとダメのようです。勝手に追加をしてもレポート作成で失敗します。

応用パターン

レポートを一つ作成してみると分かると思いますが、もっと色んな値を指定できます。指定できる値と入力必須項目は以下の通りです。

Name Required
Report Name no
Type no
View (Profile) ID / ids yes
Start Date yes
End Date yes
Last N Days no
Metrics yes
Dimensions no
Sort no
Filters no
Segment no
Sampling Level no
Start Index no
Max Results no
Spreadsheet URL no

まだちゃんと利用したことのないものもありますが、「Sampling Level」と「Spreadsheet URL」以外は昔から使っていました。

■Report Name

Addonで設定作成時に入力
シートの名前にもなります。動きとしてはレポート名称がシート名として存在しない場合はシートが新規に作成され、存在している場合はそのシートにレポートが出力されます。
逆に言うと、レポート名を修正したら、それに対応するシート名も一緒に修正してあげれば無駄なシートが増えることもなく、そのシートにちゃんとレポートが出力されます。

 

■Type

※デフォルト「core」で出力
値は「core」か「mcf」が入ります。基本的には「core」で問題ありませんが、マルチチャネルファネル系のAPIを利用する場合は「mcf」を指定して、mcf専用のAPIを利用する必要があります。

例えば・・・アシストコンバージョン数をソースごとに出力する場合は
Metrics -> mcf:assistedConversions
Dimension -> mcf:source
を指定します。

View (Profile) ID / ids

※Addonで設定作成時にプルダウンで入力


Start Date / End Date / Last N Days

※設定を作成すると自動的にLast N Days欄に「7」が入ります。これは前日を含めて、その前7日間を示します。
動きとしては、「Last N Days」に数値が入っていた場合そちらが優先され、入っていなかった時のみ「Start Date」と「End Date」を見るようです。

「Start Date」と「End Date」は「yyyy-mm-dd」の形式で入力するか、「today」「yesterday」、「7daysAgo」のような相対的な表記で入れます。

当日1日の期間内にタイムセールを行ったりと、機動的なマーケティングを行うのであれば「today」を入力してDimensionで「ga:hour」を入れて時間ごとのアクセス数を見るのもイイかもしれません。

僕の場合はいつも「yyyy-mm-dd」の形式で入れたりしているので、たとえば数式で

=text(today()-2,"yyyy-mm-dd")

と数式を埋め込んで動的に動かしていたりします。

■Metrics

Addonで設定作成時に入力
取得したい数値指標を設定します。セッション数(ga:sessions)とか直帰数(ga:bounces)とか。複数の指標を一気に取得したい場合はカンマ区切りかセル内で改行をして指定します。Typeでcoreを選んでいる場合とmcfを選択している場合で入力可能な指標が異なるので注意!


レポートが増えるとデータの取得に時間がかかるので、できるだけ一度に全て取得するようにしましょう。
上の例は「ユーザー数」「セッション数」「平均サイト滞在時間」「ページビュー数」の例です。

Tips
平均サイト滞在時間など、一部「秒」で返ってくる値があります。それを時刻へ変換するには出力された値を以下の様な計算式で変換してみてください。

=text(time(0,0,[秒数]),"hh:mm:ss")

■Dimensions

Addonで設定作成時に入力可能
取得したい切り口を設定します。ブラウザー(ga:browser)とかブラウザーバージョン(ga:browserVersion)とか。複数の指標を一気に取得したい場合はカンマ区切りかセル内で改行をして指定します。Typeでcoreを選んでいる場合とmcfを選択している場合で入力可能な指標が異なるので注意!


例えば、上の例は「ユーザー数」「セッション数」「平均サイト滞在時間」「ページビュー数」を日次(ga:date)で出力するという設定です。
「Last N Days」で「7」と入力されていた場合、昨日までの7日間、日次で各項目の数値が出力されます。

■Sort

出力されたデータの並び替え(昇順・降順)を指定します。例えば日付順であれば「ga:date」、セッションの昇順であれば「ga:sessions」ですが、逆の降順は頭に「-」をつけて「-ga:sessions」となります。

また、ソートする指標を複数指定することもでき、カンマ区切りかセル内で改行をして指定します。

■Filters

MetricsやDimensionsに対してフィルタをかけることができます。僕はいつもDimension側に正規表現でフィルタをかけてしまうことが多いのですが、例えばランディングページURLが「/index.html」で終わっているページを指定する場合はこんな感じです。

ga:landingPagePath=~^/index\.html$

MetricsとDimensionでかけかたが変わりますので、以下を参考にしてみてください。

Metricsのフィルタ
Operator Description
== 等しい
!= 等しくない
> より大きい
< より小さい
>= 以上
<= 以下

Dimensionのフィルタ
Operator Description
== 等しい
!= 等しくない
=@ 含む
!@ 含まない
=~ 正規表現一致
!~ 正規表現に一致しない

■Segment

アドバンスセグメントや、ダイナミックセグメントを指定しますが、これは非常に強力な機能である反面、かなり難しい部分でもあります。
まずは簡単なアドバンスセグメント(Built-in系)指定です。

gaid::-1All Sessions
gaid::-2New Users
gaid::-3Returning Users
gaid::-4Paid Search Traffic
gaid::-5Non-Paid Search Traffic
gaid::-6Search Traffic
gaid::-7Direct Traffic
gaid::-8Referral Traffic
gaid::-9Sessions with Conversions
gaid::-10Sessions with Transactions
gaid::-11Mobile and Tablet Traffic
gaid::-12Non-bounce Sessions
gaid::-26Tablet Traffic
gaid::-2Bounced Sessions
gaid::-28Mobile Traffic
gaid::-29Tablet and Desktop Traffic
gaid::-100Single Session Users
gaid::-101Multi Session Users
gaid::-102Converters
gaid::-103Non-Converters
gaid::-104Made a Purchase
gaid::-105Performed Site Search
※昔は自分で作ったカスタムセグメントも指定できたのですが、今はもしかすると無理かもしれません。まだ未確認です。

また、このSegment欄にはダイナミックセグメントを指定することもできます。
ある条件を満たすユーザーを指定する場合は「users::」で始まります。またある条件を満たすセッションを指定する場合は「sessins::」で始まりますが、ここで条件の設定方法を説明しますが、ここは1ページさいてちゃんと説明しないといけないほど、かなり複雑です。

★conditionについて(condition::)
例えば、最低でも一回のアクセス(セッション)がChromeブラウザからアクセスをしているユーザーのみを指定する場合は

users::condition::ga:browser==Chrome

と書きます。
Chromeブラウザを利用しているセッション数を知りたい場合は

sessions::condition::ga:browser==Chrome

と書きます。
次に、例えば少なくとも1回でもChromeブラウザからアクセスしてきているユーザーでかつ、地域が「東京」に属するセッションに絞る場合は

users::condition::ga:browser==Chrome;ga:region==Tokyo

と書きます。
ちなみに条件式の「;」はANDを示し、ORは「,」となります。
例) ga:browser==Chrome,ga:browser==Firefox

つまり、こう書いた場合
users::condition::ga:browser==Chrome,ga:browser==Firefox;ga:region==Tokyo
少なくとも1回はChromeまたはFirefoxでアクセスしてきたユーザーで、かつ地域が東京のセッションとなります。

複数のConditionを書くこともできます。
users::<condition1>;<condition2> 
users::<condition1>users::<condition2>

もちろん条件指定なので、こういう書き方もちゃんとできます。
users::condition::ga:revenue>10;ga:sessionDuration>60

慣れるまでは難しいですよね。

★Sequenceについて(sequence::)
これはユニバーサルアナリティクスをかなり意識したものになりますが、先ほどのConditionは単なるセグメント条件を指定したものですが、Sequenceを指定すると順序の指定が出来るようになります。例えばモバイルで閲覧し、次にデスクトップで閲覧したユーザーなど。

Seauenceを利用すると「->>」「->」の2つの条件が利用できます。
「->>」は単なる前後の条件を示しますが、「->」は直接の前後の条件を示します。

例えばデスクトップを利用し、次のアクセス時にタブレットを利用したユーザーのみを絞り込む場合は

users::sequence::ga:deviceCategory==desktop;->ga:deviceCategory==tablet

と書きます。
逆にデスクトップ以外を利用していたユーザーで、次のアクセス時にタブレットを利用したユーザーは

users::sequence::!ga:deviceCategory==desktop;->ga:deviceCategory==tablet

と書きます。
また、初めてのアクセス時にデスクトップを利用していて、次のアクセス時にタブレットを利用したユーザーは

users::sequence::^ga:deviceCategory==desktop;->ga:deviceCategory==tablet

と書きます。

■Sampling Level

「DEFAULT」、「FASTER」、「HIGHER_PRECISION」の3つの値をとります。これはAnalyticsの精度を優先にするかパフォーマンスを優先にするかという摘みと同じです。


■Start Index

表示する結果の開始位置を指定できます。

■Max Results

表示する結果の個数を指定できます。
例えばDimensionでブラウザを指定した場合、50個も100個も出てきてもマニアックなブラウザだったりユーザーエージェントが偽装された変なブラウザが出てくるだけだったりしますので、上位10個とか指定をしておく方が良い場合があります。

■Spreadsheet URL

レポートを吐き出す先のSpreadsheet URLを入れておくと、その指定されたSpreadsheetにレポート名でシートが作成され、レポートが吐出されます。

ざっくりとした説明ですが、Googleのヘルプはこちらです。
最も強力で最も難しい「セグメント」だけは自分で色んな条件でデータを取得してみないと、なかなか理解が進まないと思います。
ユニバーサルアナリティクスになり、だいぶアクセスしてくる順序などの取得が重要になってくるようになりました。ぜひSequence部分も押さえておきましょう。