月別: 2014年2月

めんどくさいぞ！ウェブとオフラインデータの繋ぎこみ！！

ウェブと基幹や各部門のDBにあるオフラインデータを繋ぎこみましょう！というのはよくある話かと思いますが、実際にやってる人ってあまり見たことがないな。と思っていたら、私自身がやることになった。今やってます。かれこれ二ヶ月ほど。

超メンドクサイっす！！

なにがメンドクサイって？

  • ウェブで取ってるプロダクトIDと基幹側のプロダクトIDが違う。
  • SKUのような共通商材IDが無いので、DB毎に同一商材異表現が散在する。
  • 基幹のキャンペーンIDとウェブの広告トラッキングパラメータが違うので突き合わせられない。
  • データに疎い部門のDBのカラム構成がしょっちゅう変わる。
  • そもそもウェブ上のディレクトリ構成がおかしいので、商材カテゴリページ群の流入数と基幹の実申し込みデータを結びつけようとすると、ウェブデータの方をゴリゴリに加工しなきゃいけない。
  • 基幹にはあるけどウェブでは取ってないデータフラグが存在し、そのフラグの有無がビジネス上の重点項目だったりする。

などなど。

えぇ、そうなんです。ウェブと基幹や電話データ等々の繋ぎこみって、実際やるとめちゃくちゃ障害多いっす。まともにやろうとるすと、ルックアップテーブルが無限増殖します。

 

問題は無数にあるとは言え、おそらく一番の問題はウェブ側の実装設計だと少し思い始めました。ウェブ側の実装が基幹データの構成を無視して作られてるケースがほとんどではないかと思います。なぜならウェブの計測は自由度とカスタマイズ性が高く、オフラインデータとの結合は設計時にはほとんど考えません。むしろ参照する時の都合（見やすさ）を優先するので、当然オフラインデータとのズレが生まれます。

このあたり、ウェブ計測設計時にシステム部門の協力の下、基幹からデータ引っ張って商品ID等をアクセス解析に流し込んでる場合はきっと比較的上手くいくのでしょう。また、URL構造が綺麗なツリー構造、もしくはウェブ型でもタグ付けがオフラインDBとの整合性を考慮されていれば、きっと素敵なデータ連携ができます。

けどそんなのできてる会社、どれだけあるの？というお話。

 

メンドクサイです。非常に。マジ。

本気でウェブとオフラインのデータ統合を目指すなら、ウェブデータ一回全部捨てて、統合する前提での設計をガッツリすべきだな、と思いました。このあたり、多分プライベートDMPの構築の際にも出てくる問題なのではないかと個人的には想定してます。だから「DMPは設計フェイズが重要！」と言われるわけですね。なるほど。

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

前回の投稿（「滞在時間？離脱率？いらなくない？？？」）が意外にもトラフィックを集めてビックリです。すいません、ありがとうございます。ちなみに流入元はa2iとfacebookで半々です。

続き書きます。続きまして、「離脱率」についてです。（「コンバージョンフローの最後のページは離脱率が高くても良い」、みたいな無粋な話は省きます。）とりあえず離脱率について書きますが、それだけじゃ若干面白く無いので、ついでに「直帰率」とInformation Architechtsの話にもちょこっと触れてから締めます。なお、本稿もあくまで一企業のウェブ担当者たる個人の私見ですので、悪しからず。

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

さて本題です。「離脱率」ってなんですか・・・？指標としての定義で言えば、「そのページが訪問セッションの最後のページになった回数」なわけですが。

SiteCatalystで言えば、30分以上の無操作状態、もしくは12時間以上の継続的な操作でもセッション終了（離脱）になります。GAはデフォルトが30分ですが、セッションタイムアウトは自分でも設定変更可能っぽいです。以前はブラウザ閉じたらその時点で離脱（セッション終了）になってた気がしますが、今は分からんです。

で、話を戻しまして。「このページは離脱率が高いですね」。と言われたとします。

だから何だっていうんですか？？？

っていう。「このページは離脱率が高い」。・・・。それのどこが問題なのでしょう？？？？「このページは離脱率が高いので改修しましょう！」まで言われた日にはもう、

はぁ・・・？？？？

ってな具合です。それはなぜか。例を挙げて考えるため、下記のようなケースを想定します。

  • 三つのタイプのページ、「Site Top」「Product Category」「Product Detail」があるとします。
  • Product Categoryは複数で比較するため、1と2で単純に比較できるようにします。
  • Aさん、Bさん・・・Eさんの5人が以下のような行動を取った仮定します。

A：Top>Category1>Detail>Detail>Category1

B：Top>Category2>Detail>Category1

C：Category2>Category1>Detail>Top

D：Category1>Detail>Category2>Category1

E：Categry1>Detail>Detail>Category2>Detail>Top

この場合、各項目の指標は下記の通りになります。

訪問回数 離脱数 離脱率
Site Top 4 2 50%
Product Category 1 5 3 60%
Product Category 2 4 0 0%
Product Detail 4 0 0%

さて、上記の表を見て、「離脱率」が高い＝悪いページと仮定して良し悪しを判定しようとすると、Product Category1が悪いページになります。

が、実際は違う、ということが分かるかと思います。なぜなら、Categoryページの役割はあくまで商品詳細ページへ誘導するための一覧ページにすぎないからです。なので、本来は商品詳細ページへどれだけ遷移させているかを判定基準として用いるべきです。その辺りを加味して見ると下記のようになります。

訪問回数 Detail遷移率 離脱率
Site Top 4 0% 50%
Product Category 1 5 80% 60%
Product Category 2 4 25% 0%
Product Detail 4 – 0%

この結果を見ると、Category1はDetail（商品詳細ページ）に80%遷移させていますが、Category2は25%しか遷移させていません。そのため、むしろ問題なのはCategory2、ということになります。

以上のようなことを考えていくと、

  • 「離脱率」だけを見てしまうと、本来の成果を読み違える

ということが起きてしまいます。これが最大の問題だと個人的には思っています。

また一方で、サイトの性質にもよりますが、例えばFAQページなどの収益ではなくコストを生む可能性があるサイトでは、逆に出来の悪いページほど離脱率が低くなる、というのも考えられると思います。

例えば、「保険を申し込みたいけど、申し込み方が分からない・・・」みたいなケースだと、サイトで調べるために流入し、サイト内検索から答えを見つけ出そうとする、というようなことがあると思います。サイト内検索する＞一番上位表示のページに遷移＞求めてる答えじゃない＞サイト内検索結果一覧に戻る＞二番目のページに遷移＞・・・みたいな。こういったことを想定すると、逆にユーザーの質問に回答できていない悪しきページほど離脱率は低くなることになります。ただし、離脱率が高いからといって、良いページ、ということも言えないのは自明かと思います。

つまるところ、

  • 「離脱率」もユーザーの行動を推し量る指標には成り得ない

ということが言えると思います。そして、私が「離脱率」たる指標が不要だと思う理由もこういったあたりにあります。

 

さて、このあたりで最初に予告したとおり、「直帰率」やInformation Architechtsの話にも少し触れます。

上の方でもサラッと記述したとおり、サイトのタイプやページグループの役割によって見るべき指標は変化します。

「直帰率」という指標も、今回記述した「滞在時間」や「離脱率」あたりの数値よりはページを評価するにあたってずっとまともで利用に価する指標だとは思ってますが、それでもサイト構成やページ構成を踏まえずに数字だけ追ってしまうと間違った判断をしかねない指標だと思っています。

結局そのあたりの判断指標、所謂KPI的なものの設定については、サイトの設計に基づいて適切な指標を定義する必要性があるのだと考えています。つまるところ、Information ArchitectsやConcept Diagramといった考えに基づかない限り、アクセス解析における指標を正確に判断していくことは難しいというか、ミスリードが増えると思います。

ということで、いずれ暇な時にでも、その辺りについて少し深く掘ってみようと思います。