プレイブック -計測-

「計測できなければ、改善できない」―ケルビン卿

計測の難しい点は、何を追跡するかを決めることです。

Dave McClureのAARRRフレームワークは、重要なメトリクスの概略を提供しています。それらのメトリクスを、例えばイベントトラッキングなどの手法を使って、インストルメントします。

AARRR

AARRRのフレームワークは以下の通りです。

  • Acquisition:獲得
  • Activation:活性化
  • Retention:再訪、継続利用
  • Revenue:収益化
  • Referral:紹介

初期段階の製品について、私たちは次のような順番で改善に取り組みます。

  1. 活性化:訪問者が、試すに値する製品と感じ、使ってみて、最短の時間でアハ体験(突然のひらめき、理解)できるようにする。
  2. 再訪、継続利用:製品がユーザによって継続的に利用され、与えられた仕事をこなし、顧客を幸せにする。
  3. 収益化:ユーザが製品に代価を支払う。
  4. 獲得:ユーザのルートを把握し、新たなチャネル(=ルート)でテストを実施することで、チャネルの取捨選択をする。見込みのあるチャネルではユーザ倍増を試みる。
  5. 紹介:ユーザが他のユーザに紹介する(理想的な獲得チャネル)。

インストルメンテーション

後でメトリクスを分析するために、アプリケーションをインストルメントして、適切なメトリクスのログを記録しなければなりません。ここで取り扱うインストルメンテーションの主な形態は、”イベントトラッキング”というものです。

どんな時でもイベントをキャプチャできるようにSegment.ioを使います。Segment.ioは、基本的には分析サービス用のAdapterパターンです。

Segment.ioを使うと、JSライブラリの1つをWebアプリケーションに、Rubyライブラリの1つをサーバ側のフレームワークに、あるいはiOSのSDKをモバイルアプリケーションに落とし込めるようになります。また、Google AnalyticsやMixpanel、Intercom、Olark、それにLocalyticsなどのサービスを交互に切り替えることも可能です。

Segment.io

Segment.io

Segment.ioのAPIエンドポイントはAmazonのCloudFrontでホストされています。そのため、稼働時間に関しては非常に有利です。また、Segmentを使ってアプリケーションのCloudFrontのログをS3バケットに送ることができるため、生のログへのアクセスが可能になります。

Semant.ioがバックエンドサービスをサポートしていない場合は、このサービスを直接使うか、もしくは適切なSegment.ioのオープンソースライブラリにコントリビュートすることができます。

イベントトラッキングにおいて最も難しいのは、イベントの粒度の選択です。従来の計測結果を再構成したのではコストがかかる上に、情報が不足しているせいで、初期段階の製品を潰してしまう恐れがあります。そこで、次の点に留意します。

  • イベントが製品に現れたらすぐにトラッキングする
  • 少ないよりも、多過ぎるくらいのデータをトラッキングする
  • 各イベントにできる限り多くの状態を含める
  • 開始時からのデータを保持する

トラッキング対象となる、一般的なイベントを挙げてみます。

  • アプリの起動(モバイル)
  • バックグラウンドで実行中のアプリアプリ(モバイル)
  • ページビュー(Web)
  • アカウント作成
  • 購入
  • コンテンツの追加
  • 友達になる
  • サブスクリプションのアップグレード
  • 友達に紹介

イベントライブラリのプロパティを使います。次のようなものが一般的です。

  • セッションID
  • all userプロパティ
  • 環境:オペレーティングシステム、アプリのバージョン、デバイスの詳細
  • 現在使用しているバッテリ、WiFi、モバイルの状態
  • セッションに入る秒数

ビジネス分析をリアルタイムに行う必要はありませんし、データのトラッキングのためにユーザエクスペリエンスを低下させてはなりません。ですから、使用可能なバックグラウンドシステムがあれば、その都度、トラッキングのタスクをバックグラウンドで処理するというやり方が、私たちのプラットフォームにおいては理にかなっていると言えます。Delayed JobIronWorkerにサンプルがあるのでご覧ください。

サブスクリプションのメトリクス

私たちは、月単位、年単位で購読するようなビジネスモデルの製品をたくさん扱っています。こうした製品に対して追跡したい一般的なメトリクスとしては、次のようなものがあります。

  • 月額定期収入(MRR)
  • アクティブな購読者
  • 顧客生涯価値(LTV
  • 各プランの月単位、年単位のチャーン

私たちは、支払いにStripeを使っているので、Baremetricsがこうしたメトリクスをトラッキングする上で最も早くて簡単な方法だと分かりました。

私たちのクライアントが投資家から資金を集めようとする場合、以下に挙げる数字が、投資を得る上での推奨条件となります。

チャーンは、特に資金調達の際には重要です。チャーンがほんのわずか変動するだけで、企業価値評価が著しく向上するからです。

CACの算出は、スプレッドシートを使って手作業で行います。算出式は、(従業員のオーバーヘッド費用+ダイレクトマーケティング費用)÷当月の新規顧客数となります。

Upcaseではこの算出作業を、社内の経理業務を委託しているAccountingDepartment.comに任せています。そして、例えばGoogle(AdWords)、Twitter、AdRollなど、ダイレクトマーケティング事業を運営しているベンダーについては、さらに補正処理を実行します。

A/B テスト

誰かが、あるページのコンテンツを見て紛らわしいと感じたり、ネットショッピングのチェックアウトプロセス(支払い処理)時に、アップセル(より高額な商品を売りつけるマーケティング)を煩わしいと感じたりしたかどうかは、ユーザビリティテストで分かります。ただし、2つのランディングページを提示したとして、どちらがより親しみやすく、財布のひもを緩める気になるかということまでは、このテストからはおそらく分かりません。

そこで私たちは、ランディングページと支払いフローについてのA/Bテストを実施しています。

価格についてA/Bテストを実行することはありません。ユーザがお互いに話し合うので、カスタマーサポートが困難になるからです。価格のテストはオフラインで、顧客インタビューを通じて実施します。

機能フラグ

ソフトウェアはその名の通り柔軟です。絶えず変化しています。私たちも、成し遂げてきた変化から日々学び続けたいと願っています。

機能フラグは、変更管理の優れた手法の1つです。Rolloutなどのツールを使うと、特定の性質を持つユーザごとに、例えば「開発チームのみ」「創業者の友人のみ」「全ユーザの10%」などのグループを設定し、各グループに限定して利用を許可する特定の機能に「フラグを立てる」ことができます。

これを使えば、機能を一般に公開しなくても、その機能に対するユーザの反応を見ることができます。この手法をA/Bテストと組み合わせて、複数の機能に対するユーザの反応を比較することもできます。