【GTM】Universal AnalyticsでUserIdとカスタムディメンションの両方に同じ値を入れてみる

テストでサイト内に一意のユーザーを特定するコードをdataLayerで埋め込んでおき、Google Tag Managerでまずは値を拾ってみます。


Chromeで見ても値がちゃんと取得できているのが確認できました。


で、次にGTM上の設定で、カスタムディメンションの1番と、UserIdを入れ込むために「Fields to Set」に「&uid」をセットします。


もちろん、事前にAnalytics側のカスタムディメンションをセットしておきます。


この 段階でもう一度ページを見てみると、「&uid」(UserId)の値と「&cd1」(カスタムディメンション)の値に同じデータが埋まっているのが分かります。


結果的には問題なくデータが取得できていましたが、もう少し複数のアクセスをさせて様子を見る必要がありそうだとも感じました。


ただ、UserIdを特定する値はファーストパーティクッキーの値をそのまま取得するなどすれば事前にページに値を埋め込んでおく必要はありませんし、ユーザー単位の追跡やその他ユーザーグループも一緒にデータとして読み込んだり、そのデータを更に別の値にルックアップして他の値を返す(document.writeとか)事で、WEB上のコンテンツを更に動的に変更させるなど、面白い使い方が色々おもいつく、夢の広がるものだと思います(笑

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

Twitter経由でAmazonのカートに商品を入れられるAmazonCartが面白そう

米Amazonが新しく開始したAmazonCartがとてもおもしろそうですね。
事前にAmazonアカウントとTwitterアカウントを紐付けておいて、プロダクトリンクとハッシュタグ「#AmazonCart」をつぶやくと自動的にカートに入るというものみたいです。



とりあえずアカウントをリンクさせてみました。

そうすると商品詳細ページについているツイッターアイコンを押すと自動的に「#AmazonCart」がついた呟きになりました。
リンクさせたからなのか、そうでもなく必ずつくのか。。。

たぶんやり方は間違っていないはずですが、リアルタイムですぐにカートには入らないみたい?


TwitterとAmazonが組んでソーシャルコマースへの大きな一歩を踏み出している点はとても大きなサービスですね。
Twitter経由でカートへ入れられる。

Twitterのプロダクトカードを使って、Twitter上に商品写真や価格情報を表示しつつ、Twitter経由でカートへ入れるとか、決済が出来るようになると更にユーザビリティは良くなるんでしょうね。

SEO業者が言う”バスりやすいコンテンツ”という内容は名簿業者から名簿を買っているのと実質一緒

インハウスでWEBディレクションやら解析設計やらSEOやら色々やっているわけですが、SEO担当者だと言われることがとても嫌いです。社内でそう言われる事もありますが、SEOに関しては基本の考え方を押さえることが重要で、特にURL(ディレクトリ)とサイト内のリンク構造には注意を払う必要がありますが、これはWEB担当者全員の基礎知識的な部分になるべきだと思います。
時々SEOを得意とするコンサルタントさんがお話をする、ユーザーはこういうコンテンツをよくシェアするとか、「いいね」がクリックされるとか、そういった話を聞くたびに「世も末だな・・・」と思ったりするわけです。

「SEO」という言葉を嫌う人はネットを見ていても、ある程度存在しているかなと思ってはいますが。

SEOのURL設計と情報設計は一緒

これは何回でも言いたいのですが、SEOと名を打つこともなくURL設計と情報構造設計は全く一緒です。
では、まずはGoogleが公開している検索エンジン最適化スターターガイドでURL設計に該当しそうな部分を見てみましょう。

9ページ目。

Google先生はおっしゃいました。「ディレクトリ構造を簡潔にせよ」と(笑)
そして、10ページ目。

最後に11ページ目。

Google先生はおっしゃいました。「URLの階層構造もちゃんと考えよ」と。

次に、こちらは僕がとあるサイトの解析設計をする際に作ったハイレベルサイトマップの形です。

こういうのを作らないと、KGIの達成に必要なKPI設計だったり、ナビゲーションが不明瞭になることがあります。
特に大規模なサイト群になると、ある程度頭に入れておく必要があると思っています。

解析ツールでディレクトリごとにデータを集計するのも、この図があってはじめて意識的に利用できるようになります。

そしてWEBディレクション過程における情報設計に分類される内容は概ね以下で構成されています。
  • 情報分類
  • サイト構造設計
  • 情報ラベル設計
  • ナビゲーション設計
  • 画面内情報設計
  • モックアップ
サイト構造設計は解析設計と被りますが、その他の情報分類などにしても、結局のところSEOのディレクトリ設計と一緒であることはわかると思います。

SEO的側面から考えるコンテンツ設計とWEBディレクション過程におけるコンテンツ設計

「Content is King」と言われて久しいわけですが、どんなコンテンツを作成すれば良いのでしょうか?
バズりやすいコンテンツや、思わせぶりなタイトル、書き方などを追求するのもイイのですが、それは一般のブログで行われることであって、ビジネスサイトで行うべきではないと思っています。

とあるサイトで、見られるコンテンツ、読まれるコンテンツを作成するには、こんなチェック項目を用意したらどうか?と何十個も掲載していましたが、これも本質的ではないなと思っています。
  • 考えぬかれたタイトル
  • サブヘッドラインなども用いて読みやすくなっているか
  • フォントや行間、サイズは読みにくくしていないか
  • 1段落が長くなっていないか
  • ボールドやイタリックは適切に配置されているか
  • 説得力を持つ"パワーワード"はあるか?
もしもコンテンツに関してチェックリストを導入するとしたら、コカコーラのものが最もしっくりくると最近感じています。
  1. Does it answer the “Why Should I Care” test?
  2. Does it surprise you?
  3. Does it have universal appeal?
  4. Does it generate interest in what you have to offer?
これです。(参考)
即ち、そのコンテンツ自体がシェアしたい内容となっているかどうかや、なぜそのコンテンツを読まないといけないのかといった事だったり、人を驚かせるような、何か新しいものまたは興味深い点がちゃんと含まれているのかどうかなどコンテンツ自体の内容をちゃんと検討していることが大事だというものです。

ただ、3番目の「universal」という点もそうですが、コカ・コーラのような一般的にどんな人にでもアプローチできる商品ではないというパターンも往々にしてあると思いますが、ここでWEBディレクションやWEB構築フローにおけるペルソナ設定が出てきます。

ビジネスのターゲットユーザーやステークホルダー、ユーザー種別・分類分けがちゃんと意識されていますか?

この部分がハッキリしなければ、ナビゲーションやWEBのディレクトリ構造、URL構造もしっかりとまとまってこない場合もあります。
ただ、この部分はWEBディレクション過程において、ユーザーを可視化するという部分で設計に入る一つ前の段階で必要となる部分ではありますので、SEO担当者がSEOだけをもってサイトを構築・設計するというのは非常に危険だと感じているところです。

話を戻すと、このターゲットができていればコンテンツ作りはだいぶ楽になるのではないかと思います。
昨今、海外でバズワード的に語られることが多くなってきておりますが、所謂「マーケティングオートメーション(マーケティングの自動化)」が注目されていますが、それはあらゆるユーザーとの接点で見込み客化する、または「ユーザーを育てる(nurturing)」という事を目的としていますが、コンテンツに関してもユーザーとの長い関係構築を目的としているわけです。

となると、コンテンツ作りはそのユーザーを育てるという点を意識することになりますが、そのターゲットとなるユーザーが感じる質問は何でしょうか?

例が悪いですが、例えば右の図のように「有価証券って何ですか?」と質問を検索ボックスに入れる人は少ないかもしれませんが、それぞれの分野でよくある質問や、次にくる質問というものはある程度予測されると思います。

予測されるのであれば、それに対してピンポイントのページやタイトル、コンテンツの見せ方やわかりやすさ、情報のまとめとなるようなページとしてページ構成を考えれば良いと思います。

BtoBであれば、さらにそのページにKGIとなるようなCall to Action系ボタン、例えば読み終わった人向けの一般的な「資料請求」や、ランディングをしたものの、あまり書いてある内容に興味はなく提供するツールなどに興味のある人向けにサイドカラムにツール紹介ボタンを設けたりする事になると思います。その過程において資料請求した人の名前や所属、メールアドレスを取得したりしてビジネスへつなげていきます。

つまるところSEOって何なの?

これは僕にとっての。。。という内容になるかもしれませんが、SEOの領域はもっとbot向け・bot領域の内容で、botに理解されやすいソースレベルやjavascript・Ajaxなどのコードレベル、そしてリクエストパラメータなどの設計に関して、各種SEO関連のツールを使いこなしながら改善を繰り返すものではないかと思っています。

「ツール」という点に関してはもしかすると、専門で分かる人が一人居たほうが良いかもしれませんが、ペルソナやサイト構成、よりユーザー中心のWEBサイト設計はディレクションフローやWEB解析を行うものが日常的に行っている、または行うべきものであり、そのような人がSEOの基本的な知識を携えていたほうが良いと感じています。

 こう書いていると、昔の「カウンセラー」という専門家を作るべきか、「カウンセリングマインド」を広く一般的に普及させるべきかのような議論を思い出したりしますが、SEO担当者やWEBディレクターやWEB解析士それぞれが独立して動いているのに、実は全く同じ事をしているという事態は異常だなと感じる今日このごろです。

また、同じくWEBの世界の広告にしても、コンテンツを作る側にしても、WEBサービスを提供する人が目指す未来は僕は同じだと思っています。即ちその人が望むコンテンツを望むタイミングで望む場所で提供されることです。そのためのDMP技術であったり、マーケティングのオートメーションだったりといった話です。

ビジネスという観点ではもちろん、それでも他社よりも自社にアクセスを!と思うのは至極当然ではありますが。それでもやっぱり未来 - それは近い未来かもしれませんが - は同じ場所を目指して様々な角度からアプローチしているに過ぎないと思います。

そういえば、楽天の三木谷さんが直接投資をしている「Cxense(シーセンス)」さんの動画もDMPの標準機能なのかもしれませんが、なかなか面白い世界を感じました。

今日からGoogle Analyticsの通知機能ベータ版が来ました

Google+と同じベル通知機能、ついにGoogle Analyticsにもきました。(私のアカウントへのリリースタイミングが早い部類なのかは分かりません。)
Analyticsでデータクォリティに問題がある場合にGoogleから通知が来ますので、通知が来たら何らかの対応をするというものです。


まだベータ版に申込をしていない方はこちらから申し込みをしてみてください。
いくつか試しに見ていますが、プロパティごとに確認をしないといけないみたいですね。全体のまとめ的な通知が欲しいところ。。。


(追記)
早速色んな通知がきてますw

ウェブサイトユーザビリティ評価のためのSUS(System Usability Scale)

海外でSUS(System Usability Scale)を利用すればウェブユーザビリティの数値的な評価が可能だとする記事があったので少し内容を調べてみました。

そもそもSUSはJohn Brookeが1986年に開発したもので、当時あった文字ベースのPCの評価に使われていたようですが、その後携帯電話やハードウェア、IVRなどの評価軸としても活躍してきたというものです。

海外で行われた評価ではオリジナルのSUSがそのまま利用されたようですが、日本語バージョンは直訳的なものしか見つけられず、モノが対象になっているような印象だったので、少し文言を付け加えてウェブサイト評価的にしてみました。

SUSをウェブ用に編訳版

  1. このウェブサイトをしばしば利用したいと思う
  2. このウェブサイトを利用するには説明が必要となるほど複雑であると感じた
  3. このウェブサイトは容易に使いこなす事ができると思った
  4. このウェブサイトを利用するのに専門家のサポートが必要だと感じる
  5. このウェブサイトにあるコンテンツやナビゲーションは十分に統一感があると感じた
  6. このウェブサイトでは一貫性のないところが多々あったと感じた
  7. たいていの人は、このウェブサイトの利用方法をすぐに理解すると思う
  8. このウェブサイトはとても操作しづらいと感じた
  9. このウェブサイトを利用できる自信がある
  10. このウェブサイトを利用し始める前に知っておくべきことが多くあると思う

                  解答は5段階


                  【集計方法】
                  奇数項目 : 回答番号から1を引く
                  偶数項目 : 5から回答番号を引く
                  すべての項目は0から4で評価し、足しあわせた合計数値を2.5倍して0から100のスケールへ変換する。
                  ※質問を見ての通り、奇数項目がポジティブな質問、偶数項目がネガティブな質問となっているため。

                  オリジナルの質問項目

                  1. I think that I would like to use this system frequently.
                  2. I found the system unnecessarily complex.
                  3. I thought the system was easy to use.
                  4. I think that I would need the support of a technical person to be able to use this system.
                  5. I found the various functions in this system were well integrated.
                  6. I thought there was too much inconsistency in this system.
                  7. I would imagine that most people would learn to use this system very quickly.
                  8. I found the system very cumbersome to use.
                  9. I felt very confident using the system.
                  10. I needed to learn a lot of things before I could get going with this system.
                  海外記事によれば、#4と#10はそのウェブサイトに対する理解度、その他の項目はユーザビリティを評価していると理解でき、またウェブサイトの新規ユーザーとリピーターを比較した場合、スコアに11%の乖離が見られたということです。

                  記事で少し残念だったのはウェブサイトの新規とリピーターの乖離の部分でユーザビリティ面とウェブサイトに対する理解度に分けてどのくらい差が出たかが示されていなかった事くらいです。

                  恐らく理解度が上がりユーザビリティ側の評価値は改善されていないのではないかと感じます。

                  今後の課題

                  言うまでもなくウェブサイト評価用に勝手に訳したSUS自体の妥当性評価が必要です。
                  SUSは非常に簡易な評価なので得点が高いからといって改善する必要がないというものではありませんので、新規にサービスやサイトを立ち上げる際のモック評価などに利用し、少数の人でさっと評価してみるという使い方も良いかも知れません。

                  海外でコマース系スマートフォンアプリのユーザビリティ計測に関して、下記の項目ごとに評価をしている事例がありましたが、やはり最終的な評価・改善はそのサイトの特徴に合わせて項目ごとに行われるものなので、改善・リリース後の大規模な質問紙評価的な利用でもよさそうですね。

                  • ホームページレイアウト
                  • 検索・検索結果ページ
                  • ナビゲーション
                  • 商品の探しやすさ
                  • 商品説明・商品画像
                  • カートへの入れるプロセス
                  • 配送方法の選択
                  • 決済
                  • 問い合わせ窓口
                  • 店舗の場所検索
                  • 返品情報

                  【GTM - macro】Lookup Table(ルックアップテーブル)

                  あるマクロの返り値に応じて特定の値をルックアップし、新しいマクロ名で扱える、条件分岐ができます。
                  これも使い方によっては本当に重宝します。


                  例えば、上の例の場合はデバッグモードがONの時とOFFの時でGoogle Analyticsのトラッキングコードを変動させています。

                  他のやり方としては、月の数字をJanuaryなどの文字列に変換したり、ダウンロードファイルタイプによってイベント名を替えたり。そして一番驚いたのは・・・こういうものです。


                  確かにマクロを指定できるのですがこれは完全に頭がこんがらがりそうな感じです。
                  文字列がクリックされた場合はElementのタグを返して、リンクがクリックされた場合はリンクのURLを返す、Submitフォームの場合はそのSubmitされたidを返す。

                  確かに面白いですよね。
                  こんな面白い使い方ができてしまうのが、このルックアップテーブルです。

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

                  【GTM - macro】Constant String、Container Version Number、Custom Event(カスタムイベント)

                  Constant String(定数文字列)は固定値をマクロに入れておくだけの箱です。


                  Analyticsコードや、カスタムHTMLなどの中にif文で分岐させて、特定の条件を満たした時だけ固定値を埋める。その他ルールで条件を指定しても良いかもしれません。

                  他にもDOM操作とともにinnerHTMLを操作するとか、Analyticsのイベントラベルに埋め込むとか。単なる箱といえばそれまでですが、システムリリースを待たずにサクッとリリースしてしまうという点ではとても良いですね。

                  Container Version Numberはプレビューモードで現在のコンテナバージョンを返しますので、例えばコンソールログへ吐くなどの設定が出来ます。

                  カスタムイベントは、デフォルトで「event」が用意されているものです。


                  通常タグを発火させるルールを作る時に、{'event' : '●●●'}という値をdataLayerで引き渡しますが、その「event」の部分を違う文字列で作成することができます。
                  これはGTMに無くてはならないものですね。

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