NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

アクセス解析の落とし穴!ー「データ分析」を「データ整理」で終わらせないためにー

本記事は  Design Week 2023  2日目の記事です。
🌈  1日目  ▶▶ 本記事 ▶▶  3日目  💐

アクセス解析の落とし穴
こんにちは。Webディレクターの菊地です。 気が付くと、この職についてもう10年以上になります。 これまで、金融系・メーカー系など様々なWebサイトの運用・改善に携わってきました。

Webサイトの改善にあたっては、ヒューリスティック調査、ユーザーテスト、競合分析、アクセスログデータの分析など、様々な観点でサイトの課題を見つけ出すことがスタート地点になります。
この記事では、その中でもアクセス解析についてお話ししたいと思います。

この記事の目次

アクセス解析の落とし穴

クライアントワークをしているWebディレクターや、事業会社のWeb担当者など、Webサイトの運用に携わる方なら、担当サイトのアクセス解析資料を作成したことがあるのではないでしょうか。

そこで、皆さんにご質問です。
こんな経験、ないですか?

  • ある日突然Google Analyticsのアカウントを渡され、「このデータをなにかに活用したい。分析してほしい」と頼まれた。
  • 一生懸命、日別のPV数の推移や、ランディングページ、デバイス別のアクセスなど、いろんな数値を取って、結構時間をかけてきれいに整形して、資料を提出した。

  • なのに、なぜか、それをみたお客様(あるいは上司)の顔が、「・・・で?」になっている!?

・・・

ええ、なんで?
あんなに頑張ったのに・・・!涙

大丈夫、安心してください。
涙しているのはあなただけではありません。

今回はこの悲しいすれ違いの原因を、紐解いていきたいと思います。

そのアクセス解析、なんのため?

そもそも、アクセス解析の目的とはなんでしょうか。

  • ユーザーが、どれくらいサイトにアクセスしているか、を把握すること?
  • どんなページがどういった順序でよく見られているかなど、ユーザーの行動を観察すること?
  • どんな性別や年齢のユーザーがサイトに訪れているかを知ること?

こうした情報はもちろん、サイトの現状を把握し、整理するために役に立ちますが、アクセス解析の本来の目的ではありません。
アクセス解析の目的とはずばり、「事業成長につながる『気づき』を得ること」にあります。

すなわちアクセス解析とは、ログというデータを利用して分析を行い、その結果から、Webサイト(あるいはアプリ、SNS、広告など)のどこを改善すれば、ビジネスグロースに結び付くのかというアイデアを得る、その一連の流れを指しているのです。

サイトの現状把握のために実施される「アクセス解析」は、単なるログの整理にすぎません。
データが整理されていても、それをビジネスに活かす道筋が見えないのであれば、お客様や上司の顔が「・・・で?」になってしまうのも無理はないですよね。

では、アクセスデータから、事業成長につながる気づきを得るためには、具体的にどうすればいいのでしょうか?

この後の章では、アクセス解析を、ログの整理で終わらせないための必須のステップを、わかりやすくご説明していきます。

アクセス解析の正しいステップとは

アクセス解析を、ログの整理で終わらせないためにます意識すべきなのは、下記の2点です。

・データ分析から始めないこと

・データ分析で終わらないこと

アクセス解析とは、アクセスログというデータを起点にして、その分析を実施することだと思われがちですが、それは間違いです。
データ分析というステップは、目標設定・仮説設計・改善施策の実施までの一連の改善PDCAサイクルの中の、一部分にすぎません。データは起点ではなく、歯車の一つなのです。

図にするとこんな感じです。

改善PDCAサイクルの全体像
改善PDCAサイクルの全体像

アクセス解析の事前・事後のステップを意識せずに、「ログデータ」起点で考えてしまうと(つまり、「ログデータ」があるから、そこからなにか意味のある答えを導き出せるはず!というスタンスでプロジェクトを進めてしまうと)、それは結局、ただの膨大な整理作業で終わってしまうのです。
そんな悲劇を避けるために、アクセス解析・データ分析を実施する前に必須となる目標設定・仮説立案のステップと、実際に現場で取り組んでいく際のポイントについて、もう少し詳しく解説していきたいと思います。

目標設定(KPI設計)のキーポイント

前述の一連のフローの中で最初に必要となるのが「目標設定」というステップです。
これを実施する手法として、いわゆるKGI(事業目標)をロジックツリーで分解し、最終的なKPIを組み立てていく、というロジックツリーフレームワークが良く知られています。

例えば、とあるECサイトの例なら、こんな感じです。

とあるECサイトのKPIツリー図(例)
とあるECサイトのKPIツリー図

ここでKPIとして設置された項目が、Webサイトの改善指標として定点観測していくべき、現場の目標数値となります。
このように、KPIをKGIからブレイクダウンし導き出すことで、事業成長に貢献しない数値を追うという無駄な労力が削減できます。また、個々のKPIが事業目標に結び付いているということを意識することで、個々の担当者の当事者意識・目的意識を生みやすくなるなど、様々なメリットが得られます。

ただ、実際にこれを現場で運用しようとすると、うまくいかないことも多々あります。

例えば、下記のようなケースです。

  • 手の届かない目標を立ててしまう

(PV数を半年で2倍にする?広告予算もないのに、無茶じゃない?)

  • 大量のKPIで手が回らなくなってしまう。

(目標が多すぎて何をすればいいのか途方に暮れる・・)

こうした事態に陥らないために、KPIを定める際に確認していただきたい点が2つあります。

1. KGI(事業目標)に貢献するか?

例えばページのUIUX改善という施策を念頭に置いた場合、人気のない商品の購入率アップをKPIに据えるよりは、メイン商品の購入率アップをKPIとしたほうが、同じ工数で期待できる事業へのインパクトはより大きいはずです。
もちろん逆に、今は不人気だが今後力を入れたい特定の商品がある、人気商品への対応はやり切ってしまったため、その他の手段で成長加速させていきたい、などの別の事業目標が存在するであれば、それにフォーカスするべきです。
何をKPIとするべきかはケースバイケースですが、 いずれにしても、それがKGI(事業目標)と強く結びついているかどうか、ということをまずは意識しましょう。

2. コントロール可能な指標か?

たとえば、PV数などの指標は、広告などの外部影響によって大きく変動します。自部署が広告出稿含め、外部への露出を全て掌握している場合は別ですが、そうでない限り、現場でコントロールできない項目をKPIとするのは避けたほうが賢明です。
そのような場合はPV数の代わりに、サイト改善効果として結果が見られるサイト内での回遊率や、コンバージョン率のアップなどをKPIとして設定するなど、自分たちでコントロールできる指標を設定しましょう。

なお、上記2点に加え、もう一つお伝えしたいのは、最初に完璧なKPIをそろえる必要はない、ということです。
サイト改善のPDCAを実施していく中で、KPIとして定めた指標に立ち返り、調整していくことも大事です。
KPIとは、仮説や改善施策を考えるうえでの、羅針盤的な存在です。実行する施策が、事業の方向性から 大きくぶれていないか、それをチェックするために存在している、とお考え下さい。
ガチガチに「KPIを設計しよう!」と意気込まずに、まずは一つでも二つでも、現場で取り組めそうな目標を立ててみることをお勧めします。

仮説設計ステップで気を付けること

前段の目標設定が完了した後は、「仮説設計・分析」のステップに進みます。
このステップでは、KPI改善の障害となっている課題が何かを仮説立て、その仮説が本当かどうかを分析していきます。

前述のECサイトを例にとると、例えばこのような仮説が立案できるかもしれません。

商品Aの購入率UPをKPIとした仮説立案の例
商品Aの購入率UPをKPIとした仮説立案の例

商品Aの売り上げをアップするために、「購入していない人」がどうすれば購入してくれるかを仮説立て、検証していくというような流れです。

ただこれも、目標設定の時と同じく、どこから着手すればよいかわからない、現実味のない仮説を立ててしまった、など現場にうまく適用できないことがよくあります。

仮説・分析のステップを意味のあるものにするには、常に下記を問いかけることが必要です。

1. 優先度の高いKPIの改善をめざしているか?
2. 一次情報と照らし合わせて違和感がないか?
3. 課題は、現場で実施できる施策で解決できるか?

一つ一つ解説していきます。

1. 優先度の高いKPIの改善をめざしているか?

言わずもがなですが、いくら「正しそうな仮説」であっても、それがKPI指標の改善に貢献しないのであれば、それを分析する意味はありません。
たとえば、「60歳以上のお客様はほぼXX地域のお客様のようだ」ということが判明したとしても、それをどのようにKPI改善に活用するかの道筋が立たないものを、仮説に仕立て上げないようにしましょう。

2. 一次情報と照らし合わせて違和感がないか?

一次情報とは下記のようなものを指します 。

  • 事業内容(ビジネスモデル、注力をしている商品など)
  • 現場の声・業務内容(各部署の業務フローや意見)
  • お客様の声(アンケートやVOCなど)

例えば、先ほどのECサイトの例なら
・今最も売れている商品はなにか?or会社が今後注力したい商品はなにか?
・現場ではどんなキャンペーンをどういった頻度で実施しているのか?
・お客様の声の中で、サイトの課題と考えられることはないか?

上記のような項目が一次情報に当たります。
ログデータという数値で見えることは限られています。このような、実際の事業・業務内容の方向性と照らし合わせることで、仮説のブレを防ぐことができます。

3. 現場で実施できる施策で解決できるか?

要は、実現可能性を考慮しましょう。ということです。
仮説・分析フェーズは、「これが課題なのではないか」と仮説を立案するだけではなく、「だとすれば、こうすれば改善するんじゃないか」と改善施策案を考えるところまでゴールです。
例えば、「地域ごとのお客様の購入状況を分析し、この地域の方にこういったプロモーションをかければよいことが分かった」としても、地域ごとのキャンペーンページを作成する余力がない、もしくはコンテンツをだし分けするようなシステムがないのであれば、その仮説を考察する意味はありません。

このように、仮説・分析フェーズでも、まずは現場で取り組めそうなこと、にフォーカスを当てて進めていくことが重要です。

おわりに

以上、アクセス解析をテーマに、目標設定・仮説設計の重要性についてご説明してきました。
理想論ではなく、極力運用の現場で役立つ形に落とし込んだつもりではありますが、それでも、こんな感想を持った方もいるかもしれません。

「そもそも、いちいちデータ分析必要なの?さっさとページをいろいろ改善してみて、結果をみればいいんじゃないの?」

正直なところ・・・ はい!そういう考え方もあると思います。

最初にお伝えした通り、アクセス解析は、さまざまな調査・分析手法の一つにすぎません。
最終的な目標はビジネスをいかに効率的にグロースしていくか、ということ。

ここで目標設定や、仮説設計の重要性をお伝えしてきたのは、やみくもに改善施策を講じるよりも、より効率的で、精度の高い改善施策を立案していくほうが、ビジネスグロースのスピードを加速させるのに有用だと感じているからです。 ただし、小回りの利く組織で、サイト改善PDCAをどんどん回せるような体制が整っているのであれば、サイト改修をこまめに実施して、トライアンドエラーで改善を進めていくほうが効率的な場合もあるかもしれません。

最も重要なのは、「アクセス解析」「サイト改修」自体を目標とせずに、それが最終的な事業目標に結び付く取り組みなのかどうか、を常に問いかけていく姿勢です。 まずは現場でできることから、一歩ずつ改善を進めていけば、おのずと道は開けてくるはずです。

それではみなさま、楽しいアクセス解析ライフを!