【GTM】6月29日に「ウェブ解析士横浜会議で、ベーシックな内容で簡単に登壇しました。

GTMの内容でお話するのは2回目ですが、既にタグマネージャを何かしら利用されている方にとってはベーシック過ぎる内容かもしれません。

誤表記)
pushstateがHTML5の技術のように書かれていますが、正しくはAjaxですよね。

【Web解析士 横浜会議】タグマネージャ & GA / UA from Yukihito Ikoma

相変わらず人前で話をするのは苦手だなぁ。
特にGTMの応用事例みたいに、Javascriptの話とか簡単な内容でも技術的な部分に触れるようなものだと、一気にマーケターさん達の眠気がマックスになるのが分かるしなぁ。
僕自信、面白く話せるキャラでもないんでねｗ

【GTM】jQueryなどのフレームワークに頼らずGTMの機能だけで「onclick」「onblur」「onfocus」などのイベントをトラッキングをする

GTMには「Auto Event Tracking」機能が備わっているにも関わらず、それを活かそうと様々なイベントトラッキングを検討していくと、実は制約も大きい事に気づきます。
その制約を乗り越えるために、今までは単純にjQueryを利用することで回避してきました。

その一つが以前簡単に紹介したGTMを使ったEFOを行うためのカスタムHTMLです。

フォームにフォーカスがあたったり、外れたりした時にdataLayer.pushを使ってGoogle Analytics側にイベントを飛ばすというものです。

このソースの場合はページ内にjQueryの呼び出し文が無かったので、カスタムHTMLの中でjQueryを呼び出していますが、やっぱりどう見てもオカシイ訳です。

「だってGTMでしょ！」
というツッコミを海外で頂きまして紹介されたページがこちら。
これは目からウロコといいますか、「確かに！」と納得しました。

普通にjQueryのようなフレームワークを使わずに、通常のjavascriptのみでGTMの「Auto Event Variable」系イベントを作り出しています。

詳しい説明はそちらのサイトを見て頂きたいのですが、inputに対して「blur」イベントを取得したい場合、こんなカスタムHTMLを組みます。

このカスタムHTMLの発火条件を「{{event}} equal gtm.dom」で読み込めば完成。

実際にテストをしてみたのですが、まずは単純なフォームを読み込んだ時点でのdataLayerを見てみると、

こんな感じで、いたって普通なのですが「onblur」イベントを発生させると4つ目のイベント、「gtm.blur」が発生します。これが先ほどのcallbackで発生したイベントです。

このイベントを発生させられれば、もう勝ったも同然ですよね。

その発生イベント自体をキーにしても良し、イベントの中身のelement系のデータをキーにしても良しで、Google Analytics側にデータを食わせれば良いだけですね。

確かに考えてみれば、GTMの自動イベント系タグもgtm.clickだったり、gtm.linkClickだったり、同じことをやっていますよね。

最近海外で見る不思議なイベントは、この仕組みを使っていたのですね。

色々と応用ができるし、今後GTM側に吸収されているイベントも沢山出てきそうだなと思いました。

【参考情報】

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

Google Analyticsのページ解析がChrome拡張で登場

Googleから公式の拡張が出ました。
Google Analyticsのページ解析の拡張です。

自分の管理しているサイトで立ち上げれば、リンククリックの割合などページ解析としての通常の表示がされるだけでなく、リアルタイムの訪問者数やページビューなど数値の期間比較も可能です。

ワンクリックでAnalyticsを開くこともできるし、これはイイ拡張ですね。
僕個人の環境だと、ページ解析は新規ウィンドウで開かないといけない、恐らくCookie系のエラーだと思いますが、その事象が発生することが多いので、管理サイトを開いたまま、その場で数値チェックやクリック比率チェックが出来るのはうれしいかも。

Page Analytics (by Google)

Google Analyticsのチャネルグループにブランド名登録画面が追加される予定

Google Analyticsのビューレベルで、チャネル設定箇所に「Manage Brand Term」というものが追加されるようで、ヘルプも既に追加されております。

ブランド名キーワードでの流入分析がひと目で分かるようになったりしそうです。

【GTM】Chromeのdevツール、「Source」の「Event Listener Breakpoints」を利用したクリック系デバッグ

もしかすると使えるかも？というレベルですが、最近強制的にjavascriptのクリックイベントを発生させて検証したいと思うことが多くなり、Chromeの機能のみで実現できることを知りました。

Chromeで「F12」キーを押すと出てくるDevツールの「Source」です。

ソースを開くと右側に表示されるメニューの中にあるのが「Event Listener Breakpoints」で、ここでマウスクリック等による検証が出来ます。

例えば、簡単ですがこんなソースを一つ用意します。

GTM側ではリンクをクリックされた場合に検知する単純な発火条件でGoogle Analyticsのイベントを設定しておきます。

で、実際に検証する場合ですが。
計測対象のリンクをクリックすると、ブレイクポイントでイベントが止まりますのでその過程で「gtm.linkClick」イベントが発火される表示になる事を確認できるという訳です。

凄く単純ですがChromeは痒いところに手が届く感じで良いですね。

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

【SEO】Googleのキーワードサジェストが見えるツール「keywordtool.io」サイトは良いかもしれない

たぶん最近新しくリリースされたばかりのサイトだと思いますが「keywordtool.io」というサイトは海外サービスでも日本語限定で、google.co.jpサイトのみを対象にサジェストを見ることが出来る。

この手のサイトはいくつかあるのですが、一括でクリップボードにコピーしたりできるので、調査サイトの一つに加えました。

ぜひ使ってみてください。

keywordtool.io

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

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

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

【参考】

Simple but Crucial User Interfaces in the World Wide Web: Introducing 20 Guidelines for Usable Web Form Design

似たような実験はいくつかありますが、指針は以下の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最適化で利用する場合は訳をしていただけるとよいかと思います。

また、原本を読むことでチェック内容に対する理解が深まると思います。