GOGEN Tech Blog
🎃

立ち上げ期の無理のない顧客データ分析(Segment + Amplitude)

masa-310
に公開
analytics
amplitude
segment
tech

はじめに

こんにちは、GOGENでソフトウェアエンジニアをしておりますmasa-310です。

私たちは、不動産売買取引の煩雑なプロセスをなめらかにするSaaS「レリーズ」の開発に日々取り組んでいます。
電子契約、本人確認、火災保険の手続きなど、取引に必要な一連の流れを一気通貫でサポートする中で、
プロダクトの改善や意思決定の質を高めるための「ユーザー行動の可視化」 の重要性を強く感じています。

今回は、そうした「ユーザー行動の可視化」を実現するために、スタートアップとしてどのように考え、どのような選択をしてきたのかを紹介できればと思っています。

モチベーション

0・1でサービスを立ち上げる際、とりあえずやっておいたほうがいい項目の一つに、利用者のデータ収集・分析基盤の導入があります。
多くの立ち上げでは人・時間・金のリソースが限られているため、非機能的な実装はどうしても後回しにされがちです。しかし、これがないとPDCAを回すためのデータ収集に後々奔走する羽目になります（DBに直接クエリを叩いてスプレッドシートに出力したり…）。

Google Analytics (GA) は最も無難な選択肢ですが、データ収集及び可視化のカスタマイズ性が低く、求めているグラフを出力することが難しかったりします。また、サイトのアクセス解析に閉じてしまい、プロダクト開発の意思決定を行うにあたっては不十分かもしれません。

一方で、サービスの行先もわからぬ状態で深く考えずにとりあえずBigQueryにデータを突っ込んだりしても、結局誰も使いこなせずに放置されるのではないでしょうか。

そういう意味で、立ち上げ当初は「等身大」のデータ収集基盤が必要で、GOGENでは CDPであるSegmentと、収集したデータの分析ツールであるAmplitudeの組み合わせを選択しています。

顧客データとは？

データと言っても色々あり、例えば以下のようなものが挙げられます。

  1. 顧客の属性
    • ID
    • ロケーション
    • デバイス
  2. 行動データ
    • アクセスしたページ
    • アクセス頻度
    • OOをクリックした回数
    • その他、業務における主要なイベント
  3. 顧客の行動によって作成された事実データ
    • 顧客の招待データ
    • 売買契約履歴
  4. その他ログデータ
    • APIリクエストの結果
    • エラー情報

実際に必要なデータは、主にKPIの項目から逆引きされるべきであり、マーケティング部門だけでなく、CSやセールスなど他部署との連携も重要です。

上記の1.および2.のデータに関してはフロントエンドから観測でき、収集にあたって何かしらの事前準備が必要な、本トピックで扱う項目です。

3.に関してもサービスの定量的なパフォーマンスの分析として必要ですが、事実データなので基本的には事前準備は不要で、DBの可視化により実現できます。弊社ではGrafanaを用いて可視化しています。

4.に関してはプラットフォームのモニタリング観点で用いられるもので本トピックとは別物ですが、こちらも収集していないと運用上困る「とりあえずやっておいたほうがいい項目」にはなります。

顧客データを用いて測定できる指標の例としては、以下のようなものがあります (もちろん、実運用上ではもっと複雑になります)。

  • 顧客の年齢比率
  • DAU・MAU
  • 月あたりの売買契約数
  • あるバナーをクリックして契約につながった顧客の割合

CDP (顧客データ基盤)

データを分析するためには、まずデータの収集・保存が必要です。
あらゆる行動データを自社DBに保存するのは堅実な方法ですが、設計・実装の手間を考えると気が進まないかもしれません。

サービスの成長に合わせて必要な要件は変わってくるので、なるべくスモールスタートで、必要に応じて乗り換えができるのが望ましいです。
そこで、CDP (顧客データ基盤) という概念があります。
定義はCDPを名乗るベンダーによってやや曖昧なところもありますが、大まかに言うと顧客データを統合管理するためのプラットフォームです。誤解を恐れずに言うと、マーケティング部門が用いるCRMのようなものです。

主な機能としては以下があります。

  • 顧客の属性の自動収集
  • 複数ソースから収集した顧客IDの一元化
  • 顧客データと外部サービスの連携
  • (サービスに依る) 顧客データの分析やセグメンテーション

とりあえずCDPに顧客データを正規化された形で保存しておけば、後々分析に必要なサービスと連携できたりと、施策を回すのに役立ちます。

CDPの一例 - Segment

Segment は上記のCDPの一つで、データソース（サービス開発なら自社Webサイトなど）から顧客データを正規化された形で収集し、連携先のチャネル（分析サービス、ストレージ、Webhookなど）にデータを流し込むためのハブとなるサービスです。

以下、最初にsegmentを用いたデータ連携フローを簡単に図示します。

システムのフロントエンドにSegmentのSDKを導入して、Segmentが定めたプロトコルに従ってデータを送信します。
トラックされたイベントはSegment内でフィルタリングを行ったり、連携先サービスのデータにマッピングを行ったりと仲立を行います。
これにより、サービス間のデータの違いを吸収してくれ、連携サービス事に異なるSDKを導入する必要がなくなります。

また、Segment自体はストレージを備えておらず、後から連携先を追加した場合はその時点からのデータのみ連携されます。S3などのストレージを連携先にしておくことで、(手動になりますが) 以前のデータを連携することができます。
ベンダーロックインを心配せずに「とりあえず」導入できるという点がミソです。

あと、スタートアッププランがあり、立ち上げ期の懐に優しいです(意外と重要)。

導入方法 (例: NextJS)

Next.js用のSegment SDKは、npmパッケージとして提供されています。導入の詳細はこちらを参照。

1. パッケージのインストール

pnpm add @segment/analytics-next

2. Segmentを用いたデータ収集ライブラリの実装

Segmentは顧客情報収集のためのいくつかのAPIを提供します。

その中で主に用いられるのは以下になります。

  • Identify: 顧客情報を記録
  • Track: 顧客の行動を記録
  • Page: 顧客のページアクセスを記録

なお、今後Segmentを使用しなくなったときのために、データ収集の処理はインターフェースだけ提供しておき、裏側の実装をすげ替えられるようにするのをおすすめします。

src/lib/analytics.ts

import { SEGMENT_WRITE_KEY } from '@/constants';
import { AnalyticsBrowser } from '@segment/analytics-next';

const analytics = AnalyticsBrowser.load({ writeKey: SEGMENT_WRITE_KEY });

// 顧客の属性
type UserProps = {
  id: string;
  firstName?: string;
  lastName?: string;
  email?: string;
  //... その他顧客の属性
};

// ユーザーを特定
export const identify = (user: UserProps) => {
  analytics
    .identify(user.id, {
      //... ユーザーの属性
    })
    .catch((e) => {
      console.error(e)
    });
};

// イベント名
type EventName = keyof EventParams;

// イベントパラメータ
type EventParams = {
  click_banner: {
    banner_id: string,
    //...
  }
}

// 顧客の行動を記録
export const trackEvent = <T extends EventName>(eventName: T, params: EventParams[T]) => {
  analytics.track(eventName, params).catch((e) => {
    console.error(e)
  });
};

// 顧客のページビューを記録
export const trackPageView = () => {
  analytics.page().catch((e) => {
    console.error(e)
  });
};

環境変数として、 writeKey が必要です。`
これは、ダッシュボードのSettingより確認できます。

3. アプリケーションで実装したライブラリを利用

3.1 identify

identifyは、顧客の情報が特定/変化されたときに呼び出す必要があります。

Segment recommends that you make an Identify call:

  • After a user first registers
  • After a user logs in
  • When a user updates their info (for example, they change or add a new address)

これにより、今後記録する顧客の行動データの文脈として顧客の属性を紐づけることができます。

細かい点として、ログインの前でユーザーにIDがない場合は、Segmentが匿名IDを付与してくれます。ログイン後に自社で発行したIDを明示することでトラッキングの文脈を保持することができます。

/pages/login.tsx

import { identify } from '@/lib/analytics' 

//...

const handleLogin = () => {
  const user = fetch("https://api.example.com/login").then(res => res.json());
  identify({
    id: user.id,
    firstName: user.firstName,
    lastName: user.lastName,
    email: user.email,
    //... その他ユーザー情報
  });
}
 
//...
3.2 trackEvent

顧客の行動分析の肝で、パフォーマンス計測に必要なイベントを顧客のアクションに仕込みます。

データとしては、イベント名とイベントを特定するのに十分なパラメータを入れておく必要があります。

/pages/home.tsx

import { trackEvent } from '@/lib/analytics' 

//...

const handleClickBanner = (bannerID: string) => {
  //...
  trackEvent('click_banner', {
    banner_id: bannerID
  });
  //...
}
 
//...
  <button onClick={() => handleClickBanner(bannerID) />
//...
3.3 trackPageView

ページ遷移した際に呼び出すことで、ページビューのイベントを記録します。

実装はフレームワークやSPA, SSRなどで異なりますが、例えばSPAでは以下のhookをトップページに仕込んでおけば機能します。

/hooks/useTrackPageView.ts

import { trackPageView } from '@/lib/analytics';

import { usePathname, useSearchParams } from 'next/navigation';
import { useEffect } from 'react';

export const useTrackPageView = () => {
  const pathname = usePathname();
  const searchParams = useSearchParams();

  useEffect(() => {
    trackPageView(pathname);
  }, [pathname, searchParams]);
};

なお、イベント収集が正しくできているかどうかは、ダッシュボードのデバッガーより確認できます。

ストレージとの連携 - S3

その後の連携は必要に応じてで良いのですが、イベントデータのバックフィリングや将来的に別のサービスに乗り換える可能性を残しておくために、S3等のストレージに連携を最低限最初にやっておくべきかと思います。

連携方法はドキュメントを参照してください。

分析ツール連携 - Amplitude

Segmentに流したデータをアナリティクスツールに流し込むことで、本トピックの本来の目的が実現できます。

KPIの計測は非正規化されたイベントデータの集計で実現されますが、複雑なものは集計ロジック的な側面と可視化のUIの側面でフルスクラッチをするのは簡単ではなく、なかなか立ち上げ期にできるタスクではありません。
そのためのサービスとして、開発初期でのとっつきやすさとカスタマイズ性を備えているAmplitude というサービスがあります。

通常のWebサービスのパフォーマンス測定というよりも、グロースハックにおけるプロダクト分析に焦点を当てており、複雑なコンバージョン計測、可視化のための豊富な機能が提供されています。

  • ファネル分析、リテンション計測といった、ロジックを組むと複雑だが重宝されるプリセットを備えており、非エンジニアでもSQLを書くこと無く可視化ができる

    例: 会員登録後にバナークリックをした顧客の割合を出力するためのファネル分析
    例: 会員登録後にバナークリックをした顧客の割合を出力するためのファネル分析

  • 顧客データを集計してユーザーのセグメンテーションができる。セグメントデータはAmplitude上でのデータソースのプリセットとして用いることができるほか、通知プラットフォームなどのマーケティングサービスと連携が自社で顧客のセグメンテーションの実装をせずに実現できる。

  • 1年間のスタートアッププランがあり、フリープランも立ち上げでは十分のquotaがある (詳しくはpricing参照)

Amplitude導入にあたって

GAやExcel/スプレッドシートと異なり、経験上、非エンジニアにとってAmplitudeを使いこなすのはやや敷居が高いと思っています。

うまく運用していくためには、マーケティングやCS等の該当部署とプロダクト・エンジニア部署での密接な連携や手ほどきが必要です。特に、以下のプロセスが実現できると望ましいと思います (参考: https://amplitude.com/docs/jp/how-to-assemblgge-an-implementation-team, https://amplitude.com/docs/jp/what-events-will-i-need)。

  • 定期的なミーティングを行い、必要とされているKPIやPDCAを回すために観測したい指標のヒアリングを行う
  • 指標の導出のために必要なイベント及びそのパラメータを洗い出し、フロントエンドの実装を行う
    • Amplitudeには、イベントを管理するための機能があるのでこちらを使いこなせるとより便利です
  • プロダクト・エンジニア部署が、実装されたイベントを用いて簡易的なチャートを作成し、説明を行う

また、実装は非機能的なものでバグがあっても動作に影響はないですが、通常の開発と同様に適切なコードレビューやQAを行うことが望ましいです (計測が間違っていると、最悪プロダクト開発の意思決定を誤ってしまうことに繋がります)。

参考: https://amplitude.com/docs/jp/getting-started-with-amplitude-data-best-practices

まとめ

サービス立ち上げ初期において、将来の拡張性を考慮したデータ収集・分析基盤は意外と重要です。意思決定を先送りできる柔軟なCDPであるSegmentを活用し、とりあえずデータを集約・正規化することで、将来的な分析基盤を確立できます。

さらに、発展的な分析ツールであるAmplitudeと連携することで、より高度なグロースハックに役立ちます。

GOGENではエンジニアを募集しています！

現在、プロダクトを共に開発していくソフトウェアエンジニアを募集中です！

https://herp.careers/v1/gogen/vkCF0UKhKF-u

GOGEN Tech Blog
GOGEN Tech Blog

「あたらしいやり方で、人々によりよい不動産を」をミッションに掲げるスタートアップです。不動産取引をなめらかにするためのSaaS「レリーズプラットフォーム」を開発・提供し、電子契約や本人確認、火災保険、住宅ローン手続きといった煩雑な業務のデジタル化を通じて、時代に合った、よりスムーズで安心な取引体験の実現を目指しています

Discussion