サイト構造とサイト内検索機能、そして自らウェブサイトの解析をしにくくする人達

ウェブサイトの設計、データ設計、SEO、広告、解析。このあたりは基本的に切っても切り離せない関係にあるという事は恐らく大部分の人に納得いただける漠然とした共通理解だと思います。でも実際にはページやサイト、部署が別れていたり依頼するベンダーが別れていたりして、全く意思疎通がとれていないパターンがあります。

ウェブサイトの構造は様々ですが、よくあるパターンが左のようなTOPページからのツリー構造。

この構造を構築する場合、サイトの構造とユーザの理想となる動きは一致している必要があります。
よく言われる「カスタマージャーニー」とは異なるので以下の図は不適切かもしれませんが、ウェブサイト構造が末広がりのツリー構造となっている場合、ユーザストーリーに合わせてサイトの構造を作る必要があります。


サイト構造とユーザのストーリーを一致させようとウェブ担当者は頑張ってファセットの文言を調整したりナビゲーションを調整したり、UIの変更を計画していく訳ですが、新規にサイトを構築する、ページを構築する時に考えるのが「予期的UX」だったりします。


予期的UXを利用しつつサイトを構築していく過程でアクセス解析側の視点では、この予期的UXから構築されたウェブサイト構造の各導線の数値を計測し次の予期的UX側へのフィードバックをするか、また別の構造を検討したりページを追加する等の施策に繋げていきます。


更にこの一つ一つの計測数値(metrics)に対し、「アルゴリズム」という軸を掛け合わせていくと「パーソナライズ」という新しい側面が発生します。metricsパターンはパターン同士が交差する場合もあると思いますが、そのパターンから協調フィルタリングやらルールベースやらが発生したりします。


話は少し変わり、ウェブサイト構築後の集客という視点で見ると1ページあたりのアクセス数としては、サイト名・ブランド名でランディングするトップページや、カテゴリ名や分類名などでヒットするミドルワードでアクセスされやすい2階層目、3階層目ページのアクセス数はサイトの中でも1ページあたりの集客力は高めになり、逆にコンバージョンに繋がりやすいけどピンポイントで商品名や1サービス名でランディングするような末端ページは1ページあたりのアクセス数は少なくなる。そんな平行四辺形の構造ができあがります。


サイトページ群ごとにターゲットとするキーワードや逆にランディングさせたくないキーワード群というものを設定していると、さらにウェブサイト構造を「サイト内検索」機能によって最適化・補助する事が可能となります。


理想としてはサイト構造のみで、どのページにランディングしても適切にその下層へ導ける状態が良いのですが、そのページにランディングした時のユーザ側のモチベーション、そのモーメントにおけるコンテキストはバラけるため、metricsで見る向上にはある程度の上限を意識せざるを得ません。

そのmetrics部分はGoogle Analyticsでも見れますが特定のページまたはページ群からどういうユーザの動きをしているかによって判断するなど、全体を俯瞰して判断すれば良いと思います。

(画像はGoogle結果ですが、本来は運営ウェブサイトの各ページ群)

能動的な行動ではありますが一般的に軽視されがちな「サイト内検索」は、この部分にアプローチする1手段となりえます。



「サイト内検索」のクエリからランディングする階層を紐付けてあげてユーザを導いてあげることでランディングした人を適切なページへ誘導する事が可能となるだけでなく、ウェブ運営側の想定とOff-Page側、特にGoogle頼みな部分との差を埋める1機能として位置づける事ができます。

サイト内検索に関しては計測と改善は可能なのですが、非常に軽視される部分なんだなと最近は凄く感じるようになりました。

こう考えてみると、集客としてページ内のターゲティングワードを考えるという行為とサイト内検索を紐付けて、より「サイト内検索」機能自体が意味のあるものとなるだけでなく、ウェブサイト内のショートカットとしての機能が発生してくるという事が何となく分かるのではないかと思います。

サイト内検索はよく末端ページを探す道具、あとは絞込やソートで頑張るUIを検討しがちですが、そうではなくキーワードによってサイト内でランディングすべき階層を意識する事が一つの重要なキーとなります。

そんなサイト構造や機能、集客について考えつつウェブサイトを設計・構築していく訳ですが、最近気づいたのが自らサイトの解析をしにくくする人達が多少なりともいるのではないかという点です。
よくSEO界隈だとGoogleの「検索エンジン最適化スターターガイド」に書かれているこの部分で重複コンテンツの対策で301やらcanonicalやらを設定する訳です。


が、これと同じ問題を解析側もかかえる事があります。全く同じコンテンツなのにそのページに様々なURLが発生してしまっているというパターンですね。
もちろんフィルタやグルーピング、URLのrewriteを解析ツール側で設定して同一ページ複数URL問題を解決したり、不要なパラメータを登録したりすることで解決は出来ます。

しかしながらサイトを運営していると、よく分からないパラメータが知らず知らずのうちに付与されていて、いざ解析しようとした時にそれらにマッチングするように正規表現を書いて~と解析を始めるまでに何故かデータのクレンジング処理と言いますか、前処理が必要となることが発生する事が往々にしてあるのです。

あまりに面倒すぎて、バーチャルURLで全部解決してしまえ!というのは流石にやり過ぎな気がしますが、canonicalを設定するんだったらcanonical URLをバーチャルURLとして登録しても良いんじゃないか?と時々ふと思うのです。
なんでSEOは頑張ろうとするけど解析側は放置なんだろうか…と。

更にはサイト構造を見ればちゃんと解析しているかどうか分かるんじゃないか?という考えもあります。解析コストなんてそんなに気にする額でもないというサイトもあるでしょうし、特段議題としてあげる必要も無いのかもしれません。

近々ウェブ解析はAIで自動だという記事もポツポツ出てきていますので、気にする必要が無くなる事を期待しつつw
そしてAIで解析~という系のものに関しては自然言語でバシバシ質問を投げて解析結果が返ってくる、または解析segment情報や計算式を提案してくれるWatson系が一番イイなぁと思います。私自身、毎日見ているmetrics以外のspot分析をする場合はまず疑問から入る事が多いので。(余談)
その一部は月1回とか毎日とかのデータ分析に組み込む事がありますのでschedule機能も。

駄文失礼しました。

Intersection Observerが導入されvisibility計算やウェブの高速化が進む?

今年に入ってからポツポツと「Intersection Observer」の話が出てくるようになりました。
まだDraftの仕様ですが、GoogleですとChromeのバージョン51から導入されております。

  • 広告やコンテンツにおけるVisibility評価
  • コンテンツ読み込みをコンテンツ領域が実際に"表示された"タイミングで開始することでページ読み込みを待つ必要がない
などのメリットがあります。(下のイメージはGoogleページから)
 

実際のdemoとしてはまだchrome betaかchrome devでしか見れませんが、画像のロードとしてdiv領域が50%に到達した時点で読み込む事を見せている、こちらのページでしょうか。

広告のvisibility評価が正確になるだけでなく、コンテンツ運営側にとっても実際読まれているの?という部分が明確化されるのと同時に、スマートフォンにおけるコンテンツ表示の評価にも役立つものになると思います。


4月下旬にはFinancial Timesが「ページ表示スピードは回遊に影響があるよ」と発表しております。

Intersection Observerに関して、gitにおいてある説明はこちらです。
他のブラウザ対応が少しずつ進んできたら一気に導入が進むかもしれませんが、Chromeのstableに導入されたタイミングでsample dataとしてデータを取得してみるのも良いのかもしれません。

読み込まれたタイミングでpingを飛ばしたり、GAのeventを飛ばしたり、広告入稿とひも付けたり。
個人的に結構やりたいことは沢山あります。

Google FusionTables x Chart API で社内(個人)用BI ダッシュボードは作れなくはない…

# 概要
Google FusionTablesとGoogleのChart APIを利用して社内(個人)用BI ダッシュボードを作る。

# TL;DR
* 全くオススメできない。可能か不可能かで言えば可能というだけ。
* FusionTablesとChart APIの組み合わせのオフィシャルドキュメントはFusionTablesのPublic Dataしか利用出来ないので社内データには利用出来ない。
* Google Apps Scriptを利用してウェブページを生成することで解決可能。ウェブページ生成のオフィシャルドキュメントはこの辺。


# 一応作ってみた
HTMLのデザインなどなどはテキトー




# Google Drive内でウェブページを生成する
## Code.gs

function doGet(e) {
  var template = HtmlService.createTemplateFromFile('index');
  return template.evaluate()
.setTitle('stats')
.setSandboxMode(HtmlService.SandboxMode.IFRAME);
}

function fTables1(){
  var tableId = '';
  var sql = "SELECT * FROM " + tableId;
  var res = FusionTables.Query.sql(sql);
  return res.rows;
}

## index.html
codeを実行する部分だけ抜粋。


<head>
<script type="text/javascript" src="https://www.gstatic.com/charts/loader.js"></script>
<script type="text/javascript">
google.charts.load('current', {'packages':['line']});
google.charts.setOnLoadCallback(drawChart);

function drawChart(){
google.script.run.withSuccessHandler(contentGetWeek).fTables1();
}

function contentGetWeek(data){
var chartData = new google.visualization.DataTable();
chartData.addColumn('string', 'date');
chartData.addColumn('number', 'Performance');
chartData.addRows(data);

var options = {
width: 900,
height: 500,
legend: {position:'none'}
};

var chart = new google.charts.Line(document.getElementById('line_top_week'));
chart.draw(chartData, options);
}
</head>

<body>
<div id="line_top_week"></div>
</body>

仕組みとしては…
ウェブページ(index.html)を開いたタイミングでCode.gsのfTables1を実行し指定のFusionTablesからデータを取得する。そのデータをindex.html側で受け取ってチャートを描画しているだけです。

Code.gsの実行は最初
google.script.run.fTables1()
で書いていたのですが、データ取得が成功したらcontentGetWeek関数を実行するという書き方に変更しました。

実はコレ。ほぼ完成したソースだけど、もうひと手間必要。

# !落とし穴!
* 現在この方法で取得するFusionTablesのレスポンスデータは全て文字列で返ってくる

これ以外にも色々ツッコミどころは満載な訳ですが、コレほど腐った仕様も無いよなーと思いながら、実現するためにはデータでチャート化したい部分をIntなどに無理やり変換しなければならない…

# 終わりに
Google FusionTablesとか、ここまで放置されているサービスということはそのうちサービス終了するんだろうなーと思ってガクブルしているw
Spreadsheetに入り切らない大き目の数値データをゴロゴロ保管しているので。

ここまでするんだったら別のやり方あるよね!という意見は正しい。
でもまぁ、今ある資源だけでサクッと作れるんだったらそれでも良いよね。

スマートフォンのGAチェックはChromeのリモートデバッグを活用しても良いかも…

ChromeのDev Toolを利用する機会は多い方もいらっしゃると思いますが、スマートフォンサイトのGAだったりInspectorを見る時などは、GAのリアルタイムデータなどを見る程度で済むかもしれませんが、リモートデバッグを利用するのも良いかも…と最近思っています。

Remote Debugging Devices - Google Developers

必要環境

  • Chrome 32 or later installed on your development machine.
  • A USB cable to connect your Android device.
  • Android 4.0+ and Chrome for Android.


詳細な設定方法はGoogleサイトを確認してもらえれば良いと思いますが、リモートデバッグは所謂「スクリーンキャスト」なのでPC側でドラッグすればモバイル側もドラッグされますし、クリックや右クリックなども全て端末と同期します。

SublimetextやIllustratorとかでも似たようなPluginはあったような気はしますがブラウザで確認したいということもウェブ運営では多いはず。

試しにアディダスNMDサイトを表示しながらリモートデバッグ。


GAにデータを送っているところもちゃんと値が見えますよね。
iPhoneのSafariでも設定でWeb InspectorをONにした状態でデスクトップ側のSafariを利用したデータチェックも可能です。iPhoneの設定も先ほどのGoogleサイトにやり方が書かれていたりします。

PCだとアドオンを使ってデータを見たりもすぐに出来ますが、スマートフォンでも実はスクリーンキャスト機能サマサマな感じで、データを見れたりしますのでぜひ活用してみてください。

GA / mixpanel / new relicの数値をSlackに通知してくれる「Google Analytics Bot for Slack」

Google Analyticsの数値をslackに通知してくれるという「Google Analytics Bot for Slack」を導入してみました。


slackを普段から会社で利用している人も多いと思いますが、プライベートでも様々なbotを導入しながらslackというチャットUIで天気をbotに質問して天気情報が返ってきたりと活用されている人も増えてきています。

このbotはウェブの数値を気にする方向け(?)で。


コマンドを叩けばサクッと画像だったりテキストだったりで数値を返してくれます。
もちろんレポート設定もできて、お試しに「サマリ」データを毎日送ってよというやり取りをしてみました。


このブログのサマリデータを毎日朝8時に通知よろしくと。
細かい分析する時はどうせGUIだったりAPIを叩いて色々データを漁るんで、slackの通知はこの程度で良いんですよね。

他にもコマンドなげればサクッと返事が。



タブローサーバとか使ったことないけど、そのうちslack通知でも複雑なデータを返してくれたりとかするようになるのだろうか?

Google Analytics Bot for Slack

hreflangとcanonicalの同居は現在推奨されていない…

久しぶりにSEOまわりのサポートをお願いされタスクで溢れかえっているのですが、グローバルに展開されているサイトでhreflangとcanonicalってどう実装するんだっけ?と調べてみたところ…Googleのヘルプ上で両方を一緒に説明しているページが存在していない。(たぶん前から)

じゃあ、日本語でhreflangとcanonicalを同時に併用することを説明しているサイトは何かというと、GoogleのオフィシャルWebmaster blogを引用していた。

以前書かれていたのがこの記述。
Optionally, for pages that have substantially the same content in the same language and are targeted at multiple countries, you may use the rel="canonical" link element to specify your preferred version. We’ll use that signal to focus on that version in search, while showing the local URLs to users where appropriate. For example, you could use this if you have the same product page in German, but want to target it separately to users searching on the Google properties for Germany, Austria, and Switzerland.
即ち同一言語サイトならば重複コンテンツとなるため、canonicalで1サイトを特定できるよと。
例えば全く同一の英語コンテンツだけれどもイギリス支社とアメリカ支社でURLが異なり、売上の計上の仕方もイギリスとアメリカでそれぞれ行っている、そして内容は一緒みたいなパターンの場合、所謂カニバリズムが発生するのですね。同一会社が運営するサイトにも関わらずアクセスを食い合って、結果売上も食い合うような。

従来の指示では、例えばbotに対してアメリカサイトを正として、イギリスサイトを副とし、ただしイギリス国内からのアクセスに関してはイギリスサイトを表示してね!と指示を出します。
即ち、アメリカサイト側にcanonicalを指定し、アメリカサイト・イギリスサイトともにrel="alternate"でhreflangを指定してあげると。

その後blog記事の訂正がかかっています。
Update: to simplify implementation, we no longer recommend using rel=canonical.
なるほど。hreflangを利用する場合はcanonicalは指定してくれるなと。
事故の元でもあったので結構反発もあったのかもしれないですね。

以前canonicalとhreflangを両方キレイに導入されていたのはredbullサイトですが、現状はhreflang側を全て削除し、canonicalを選択しました。個人的にもそっちの方が良いと思っています。重複コンテンツのほうが致命的ですし。
redbullさんのhreflang、とてもキレイだったんですけどね。

[雑文]セッション概念についての最近の違和感

Wiredにあった「ウェブ関係者よ、PVの話をするのはもう止めよう」という記事を読んでいて、"PVに関しては何度も話題に上がっては沈んでを繰り返していたりするよね"と思ったりしたわけですが、そんなPVに代わる指標として
「滞在時間」や「スクロール深度」、「エンゲージメント」や「回遊率」「シェア」「読了率」
など記事内で用語が色々と出てきています。もう指標として利用し始めているよという方もおられると思います。その記事を読んでいて2015年中感じていた違和感を思い出しましたので、今回はそれについて書きたいと思います。

さて、2015年中はGoogleが「Moment」概念を広く推し進めていたというのもありますが、その影響か分かりませんが、この「Moment」というやつが「セッション」概念と相性悪くて仕方がないとずっと考えています。

特にスマートフォン。

恥を忍んで書くと今までPCサイト側の解析ばかりでモバイル環境への知見が浅く、昨年からの新環境で全く真逆のモバイル環境(WEB中心)の解析を行うようになり、PCサイトの延長上のようにGAを使ったり概念を適用したりすることが多かったように思います。

もちろんベースとしては良いとは思います。
ゴール概念にしろ、マイクロコンバージョンの概念にしろPCでもモバイルでも基本的には同様に活用しながら解析したり、ユーザベースで様々解析出来ます。

ただタイトルにもしたとおり「セッション」に関しては、日常的に活用しつつも違和感しか感じず、新しい概念を導入すべきなのだろうか?とずっと考えています。
  • Moment Focusで考えるとブラウザのアクティブ <-> 非アクティブの状態変化でセッションを切るべきなの?それって可能なの?
  • Moment Focusで考えた場合のセッションスタート的なMoment Startという概念は成り立つの?数値だとどう見ればいいの?
  • GAでutm_nooverrideを使う機会を再考する必要はあるの?
とかとか。
いや、Momentという概念は主に広告側でしょ?と整理してしまうということも出来ないかなと…以下Google先生のリンク
第 1 回: マーケターにとって見逃せない瞬間「Micro-Moments」とその活かし方
第 2 回: Micro-Moments を活かして認知を獲得し検討を促す
第 3 回: Micro-Moments を活かしてコンバージョンを増やす
第 4 回: Micro-Moments を活かしてリレーションシップを強化する
「(何かを)知りたい」「(どこかに)行きたい」「(何かを)買いたい」などの"~したい"というコンテキストを考慮してMicro-Momentを意識したインパクトのある広告を出す。たしかにモバイルとの相性は良いですよね。

これ当たり前ですがウェブ上の行動も一緒のはずなんですよね。
もちろん「広告」視点で見ればutm_campaignなどが入れ替わるタイミングでGAはセッションが切れるので別に気にする必要は無いんです。たぶんね。

水平思考の世界凄く当たり前の話なのですが、WEB上でのユーザ行動、特にMicro-Momentから次のMicro-Momentまでの行動は「ロジカル」なんですよね。セッションとしては1つかもしれませんが。
この辺りは「水平思考の世界 」のセレンディピティ辺りを読んでいて改めて実感。

少し話はそれますが、今のウェブってMicro-Momentを無視したユーザ単位での行動、更にHit的なマイクロ概念のPVからウェブ中の「レコメンド」サービスが生成されているわけです。
まぁボリュームとか統計で云々という話もあるわけですが…

このMicro-Momentという概念は「セッション」概念を崩壊させるのではないかと勝手に考えていたりします。

そう思いつつも、ある一連の行動を抽出した場合、それはロジカルな流れを辿っており、意図したユーザ行動を導き出せていない、または離脱が多いなどのデータからユーザが考えているロジカルな動きとウェブ運営側が考えているロジカルに差が生まれる…。そういう意味では"そんな細かい事気にするな"と思わなくもないわけです。


ちなみにWiredで提示されている指標もスコープレベルはちゃんと認識しておいた方がよいですよ(苦笑
以下は一般例として。微妙なのもありますからね。
  • エンゲージメント : ユーザ
  • 回遊率 : セッション
  • 読了率 : セッション
  • 滞在時間 : セッション
  • スクロール深度 : ヒット
  • シェア : ヒット
2015年はそんなことを考えながら良い意味では基本に忠実に、悪い意味では進歩のない1年だったかなと反省しておりますが2016年もよろしくお願い致します m(_ _)m