- 収集するデータを明確に定義したいすべての実務者の方
- Product Analytics (製品分析)に興味のある方
- イベントデータを処理して活用する方法を知りたい方
こんにちは！ HEARTCOUNTの Analytics Engineer、Jadenです。
今年の7月から、GAの以前のバージョンであるUAは本当に歴史の中に消えてしまいます。
GoogleアナリティクスがUAからGA4に変わり、大きな変化がありました。
顧客の性別や年齢などの人口統計を中心としたセッションベースの分析から、
サービスプラットフォーム内で作る行動ベースの分析にパラダイムが変わったのです。
まさに「Product Analytics」の登場です。そして、このような行動ベースの分析を行うために、Product Analytics製品はイベントベースの測定を行います。
したがって、Product Analyticsで自社製品を発展させるためには、このイベントをうまく設計する必要があります。今日はこのイベントを設計する方法、イベント分類法(Event Taxonomy)について説明します。
イベントとイベント分類法とは何ですか？
皆さんは、データ分析を始める前にまず何をしますか？ それは、データの構造と内容を把握することでしょう。
どのようなデータが収集されているのか、それぞれのデータの意味を理解すること、これがデータ分析の第一歩と言えます。
企業が収集するデータの大部分を占めるのが「イベントデータ」です。Webサイトのクリックからモバイルアプリの起動、オンライン購入に至るまで、ユーザーのすべての行動がイベントデータとして記録されます。
問題は、このイベントデータが非常に非定型的で膨大であることです。
時には一つのイベントに数十個もの属性が含まれることもあります。このようなデータをどのように理解し、活用することができるのでしょうか。
そこで登場するのが「イベント分類法」です。
イベント分類法とは何ですか？
イベント分類法は、ビジネスプロセス上で発生する様々なユーザー行動データを一貫性のある構造化された方法で定義し、分類する体系を指します。
簡単に言えば、顧客のすべてのアクションを意味のある「イベント」に変換し、それをカテゴリー化することです。
例えば、EコマースプラットフォームであるAmazonのケースを考えてみましょう。ユーザーがWebサイトを訪問した瞬間から購入完了まで、次のような一連のイベントが発生する可能性があります。
- ウェブサイト訪問 (Page Viewed)
- カテゴリページの閲覧 (Category Page Viewed)
- 商品検索 (Product Searched)
- 商品詳細ページの閲覧 (Product Page Viewed)
- カートに商品を追加 (Product Added to Cart)
- チェックアウトプロセスの開始 (Checkout Started)
- 決済完了 (Order Completed)
例えば、Amazonの「Product Added to Cart」イベントの場合、商品ID、商品名、商品カテゴリ、商品価格、数量などの属性を含めることができます。
このように体系的に定義されたイベントデータは様々な分析の基礎になります。商品別、カテゴリ別売上分析からユーザーセグメント別購入パターン分析、ファネル分析、コーホート分析に至るまでですね。
イベント分類法が重要な理由
1.データドリブンな意思決定を支援
イベント分類法は、ビジネスコンテキストを反映したデータ収集を可能にすることで、データの品質を向上させます。一貫性のある正確なデータを確保できるようになり、これはデータの活用度向上につながります。
体系的なイベント分類法により、ユーザー行動に対する深い理解が可能になります。これを基にデータドリブンなインサイトを発掘し、迅速かつ正確な意思決定を行うことができるようになります。
さらに、イベント分類法は組織全体のデータリテラシーを向上させます。マーケティング、製品、エンジニアリングなど様々な部門がデータに対して同じ言語でコミュニケーションできるようになり、部門間のコラボレーションとコミュニケーションが円滑になります。データのサイロを解消し、組織が一つの方向性を見ることができる基盤が整うのです。
2.顧客中心のサービス革新を加速
イベント分類法の設計の出発点は「顧客経験」です。
顧客に価値を伝える瞬間(Aha-Moment)と顧客のニーズ(Pain Point)を深く理解することで、真の顧客中心のインサイトを得ることができます。
これは顧客ニーズに基づいたサービス革新につながります。単に数字を追跡するのではなく、顧客の問題を発見して解決する方向に進むことができるようになるのです。パーソナライゼーションとターゲティング能力も強化することができます。
Airbnbの事例がこれをよく示しています。彼らは「予約」という結果だけでなく、宿泊施設の検索、ホストとのコミュニケーション、実際の宿泊経験など、顧客の旅程全般をイベント分類法に反映しました。これにより、顧客価値を最大化する方向にサービスを持続的に発展させています。
3.ビジネスの俊敏性と革新性の確保
今日のビジネス環境は、かつてないほど急速に変化しています。このような状況で企業が生き残り、成長するためには、変化に迅速に適応し、革新を重ねなければなりません。
よく設計されたイベント分類法は、このようなビジネスの俊敏性の土台となります。サービスの変化をイベント分類法に迅速に反映することで、常に最新のデータを確保することができるためです。
新機能のリリース後、その効果を即座に測定し、マーケティングキャンペーンの成果をリアルタイムで追跡し、顧客の不満要因を迅速に把握して解決するなど、データと密着した意思決定が可能になります。これにより、企業は変化の流れを素早く検知し、先制的に対応できる俊敏性を確保することができるのです。
グローバル企業の事例
Netflix (ネットフリックス)
Netflixは、ユーザーの視聴データに基づいてパーソナライズされたコンテンツのレコメンデーションを提供することで有名です。彼らは「視聴開始」、「視聴完了」、「評価提出」などの様々なイベントデータを収集しています。
Netflixは、機械学習アルゴリズムを使用してこのようなイベントデータを分析し、ユーザーごとのコンテンツのレコメンデーションはもちろん、新規コンテンツ制作の意思決定にも活用しています。
Uber (ウーバー)
Uberは膨大な量の乗車データをリアルタイムで処理し、分析してサービスを最適化します。 彼らは「乗車依頼」、「ドライバーの割り当て」、「乗車開始」、「乗車完了」などの各段階のイベントデータを収集しています。
特に「乗車依頼」と「乗車開始」間の時間差は、顧客満足度に直結する重要な指標です。Uberはこの指標を最小化するために、リアルタイムデータ処理パイプラインを構築し、機械学習ベースの需要予測と最適配車アルゴリズムを適用しています。
Airbnb (エアビーアンドビー)
Airbnbは、膨大な宿泊予約データとユーザー行動データを活用して、パーソナライズされたレコメンデーション、需要予測、価格最適化などを行っています。彼らは「宿泊施設の検索」、「予約リクエスト」、「予約完了」、「レビューを書く」などの様々なイベントデータを追跡しています。
特に「予約リクエスト」と「予約完了」間のコンバージョン率は、ホストの応答性に直結する重要な指標です。Airbnbはこの指標をホスト評価に反映してプラットフォームの信頼性を管理しています。また、「レビューを書く」のイベントデータは自然言語処理と感情分析を使用して処理され、パーソナライズされたレコメンデーションと検索ランキングに活用されます。
イベント分類法を設計する
内容の方向性に技術的な深さを少し追加してみましょう。
イベントの構造: オブジェクトと属性
イベント分類法を設計するためには、まずイベントの構造を理解する必要があります。イベントは大きく「オブジェクト(Object)」と「属性(Attribute)」で構成されます。
オブジェクトは、イベントの主体となる核心的なビジネスエンティティを意味します。Eコマースでの「商品の照会」イベントの場合、「ユーザー」と「商品」がオブジェクトになります。
{
"event_name": "Product Viewed",
"user": {
"id": "u123",
"name": "Alice",
"email": "alice@email.com"
},
"product": {
"id": "p456",
"name": "Nike Air Max",
"category": "Shoes"
},
"timestamp": "2023-06-15T10:30:00Z"
}一方、属性はイベントやオブジェクトの詳細情報を表わすメタデータです。上の例では、user の email、product の category などが属性に対応します。
オブジェクトと属性を定義する際には、データ型、形式、制約条件などを明確にする必要があります。
例えば、user オブジェクトと product オブジェクトの属性を次のように定義することができます。
| オブジェクト | 属性 | データ型 | 説明 |
|---|---|---|---|
| user | id | STRING | ユーザー固有の識別子 (必須) |
| name | STRING | ユーザー名 | |
| STRING | ユーザーのEメールアドレス、Eメールの形式である必要があります | ||
| product | id | STRING | 商品固有の識別子 (必須) |
| name | STRING | 商品名 | |
| category | STRING | 商品カテゴリ | |
| price | FLOAT | 商品価格 |
Google Analytics 4のイベントベースデータモデル
Googleは次世代アナリティクスである Google Analytics 4 (GA4)でイベント中心のデータモデルを採用しました。GA4ではページビュー、クリック、スクロールなどすべてのユーザーインタラクションをイベントとして扱い、各イベントは「パラメータ」という属性を持ちます。
例えば、GA4の「purchase」イベントは次のような構造を持ちます。
{
"name": "purchase",
"params": {
"transaction_id": "T12345",
"value": 25.42,
"currency": "USD",
"tax": 4.90,
"shipping": 5.99,
"items": [
{
"item_id": "SKU_12345",
"item_name": "Stan and Friends Tee",
"affiliation": "Google Merchandise Store",
"item_brand": "Google",
"item_category": "Apparel",
"item_category2": "Adult",
"item_category3": "Shirts",
"item_category4": "Crew",
"item_category5": "Short sleeve",
"item_variant": "green",
"price": 9.99,
"quantity": 1
}
]
}
}このように、イベントパラメータにより、取引ID、価格、通貨、税金、配送料などの取引関連属性とともに、購入された商品の詳細な属性まで豊富に含めることができます。
このようなイベント中心のデータモデルは、ユーザーの行動をより細かく、柔軟に追跡することができます。また、ユーザー属性とイベント属性を組み合わせた分析を可能にします。これは、ユーザージャーニー分析、コホート分析、ファネル分析など、様々な分析シナリオで強力な力を発揮します。
イベントベースの代表選手、GA4
GA4データの構造と特徴
GA4はユーザーの行動データをJSON形式で収集して保存します。
JSONは階層的で柔軟なデータ表現が可能という利点がありますが、同時にデータ分析の過程で複雑さが増大することもあります。
ネストされた構造をフラット化し、必要な情報を抽出するなどの前処理作業が必要なためです。
例えば、以下はGA4で収集したEコマースの購入イベントのJSONデータです。
{
"event_name": "purchase",
"event_params": {
"transaction_id": "T12345",
"value": 25.42,
"currency": "USD",
"items": [
{
"item_id": "SKU_12345",
"item_name": "T-Shirt",
"item_brand": "Google",
"item_category": "Apparel",
"item_variant": "Black",
"price": 12.99,
"quantity": 1
},
{
"item_id": "SKU_67890",
"item_name": "Socks",
"item_brand": "Google",
"item_category": "Apparel",
"item_variant": "White",
"price": 4.99,
"quantity": 2
}
]
},
"user_properties": {
"customer_id": "C12345"
}
}上記のデータには、購入取引に関する情報(transaction_id、value、currency)とともに、購入された商品の詳細情報が items 配列に含まれています。 また、user_properties フィールドには顧客IDが別途格納されています。
このようにネストされた構造と繰り返されるデータ要素を持つJSONデータを効果的に分析するためには、それに最適化されたデータウェアハウスとクエリ方式が必要です。
BigQuery の ネストされたフィールド(Nested Field)
Google BigQueryはネストされたフィールド(Nested Fields)や繰り返しフィールドを使ってJSONのような半構造化データを効果的に処理することができます。
標準SQLにいくつかの拡張文法を追加して、ネストされたフィールドを柔軟に扱うことができます。
ネストされたフィールドは、一つのレコード内に別のレコードが埋め込まれた構造を指します。BigQueryではこれを STRUCT データ型で表現します。
上記のGA4データの例では、event_params と user_properties がネストされたフィールドに該当します。
まず、ネストされたフィールドにアクセスするためにはドット(.)表記を使用します。
例えば、上記のデータから transaction_id と customer_id を抽出するには、次のようにクエリを作成することができます。
SELECT
event_params.transaction_id,
user_properties.customer_id
FROM purchase_eventsイベントベースのJSONデータ、RDBでの活用方法
JSONのような柔軟なデータモデルは、Webやアプリで発生する様々なユーザーイベントをよりきめ細かく捉えて分析することができますが、同時に、既存のRDBベースのデータインフラとの統合には困難をもたらすこともあります。
特に、データの視覚化とレポーティングの面でのRDBの重要性は依然として大きいため、GA4のJSONデータをどのようにRDBに変換して活用するかは、多くの組織が直面している課題です。
では、JSON形式のデータをRDBで活用できるのでしょうか？
大きく2つのアプローチが考えられます。
1.ETLによるデータフラット化
最初の方法は、ETL (Extract, Transform, Load)プロセスを通じてJSONデータをフラット化してRDBテーブルにロードすることです。
JSONデータをRDBテーブルに変換するためには、まずネストされたフィールドをフラット化する必要があります。ネストされたフィールドは別の列に抽出し、繰り返しフィールドは別のテーブルに分割するのが一般的なアプローチです。このプロセスでデータの階層構造は消滅します。
例えば、次のようなJSONデータがあるとします。
{
"name": "John Doe",
"age": 30,
"address": {
"street": "123 Main St",
"city": "Anytown",
"state": "CA",
"zip": "12345"
},
"phoneNumbers": [
{
"type": "home",
"number": "555-1234"
},
{
"type": "work",
"number": "555-5678"
}
]
}それでは、Pythonを使って上記のJSONデータをフラット化してRDBテーブルにロードするプロセスを見てみましょう。
import json
import psycopg2
# JSON データロード
with open('data.json') as f:
data = json.load(f)
# RDB 接続(ここではPostgreSQLを使用)
conn = psycopg2.connect(database="mydb", user="myuser", password="mypass", host="localhost", port="5432")
cur = conn.cursor()
# users テーブルにデータを挿入
cur.execute("INSERT INTO users (name, age, address_street, address_city, address_state, address_zip) VALUES (%s, %s, %s, %s, %s, %s)",
(data['name'], data['age'], data['address']['street'], data['address']['city'], data['address']['state'], data['address']['zip']))
# phone_numbers テーブルにデータを挿入
for phone in data['phoneNumbers']:
cur.execute("INSERT INTO phone_numbers (user_id, type, number) VALUES ((SELECT id FROM users WHERE name = %s), %s, %s)",
(data['name'], phone['type'], phone['number']))
conn.commit()
cur.close()
conn.close()上記のPythonコードは data.json ファイルからJSONデータをロードして、PostgreSQLデータベースに接続します。そして、users テーブルと phone_numbers テーブルへデータを挿入します。
この時、phone_numbers テーブルの user_id は users テーブルの id を参照します。
このようなETLプロセスによりJSONデータを正規化されたRDBスキーマに変換することができます。データを一貫した形式で保存することで、データの整合性を保証し、SQLによる効率的なクエリが可能になります。
2.RDBのJSON機能の活用
2番目の方法は、最新のRDBが提供するJSONサポート機能を活用することです。PostgreSQL、MySQL、Oracleなど多くのRDBがJSONデータ型をサポートしているため、JSONデータを別途変換せずにそのまま保存することができます。
上記のJSONデータをJSON列に保存すると、次のようなテーブル構造になります。
- usersテーブル
| id | info |
|---|---|
| 1 | {"name": "John Doe", "age": 30, "address": {...}, "phoneNumbers": [...]} |
これで、JSONクエリ関数を使って目的のデータを抽出することができます。例えば、PostgreSQLでは次のようにクエリすることができます。
SELECT info->>'name' AS name, info->>'age' AS age
FROM users
WHERE info->'address'->>'state' = 'CA';この方法のメリットは、JSONデータの階層構造を維持しながら、SQLを使ってクエリができることです。また、スキーマの変更にも柔軟に対応できます。
しかし、この方法には短所があります。
クエリのパフォーマンス: JSON列に対するクエリは、一般的なRDBのクエリに比べてパフォーマンスが低下する可能性があります。JSONデータはテキストで保存されるため、クエリ時にJSON解析のオーバーヘッドが発生します。また、JSON列にはインデックスを直接作成することができないため、複雑なクエリのパフォーマンスが低下する可能性があります。
データの一貫性: JSON列にはスキーマが強制されないため、同じ列内でも各レコードのJSON構造が異なる場合があります。これによりデータの一貫性が損なわれ、データの品質管理が難しくなります。また、JSONデータへの参照整合性を保証することは困難です。
したがって、JSON列を使用する際には、これらの短所を考慮する必要があります。データの性質と使用パターンによってはJSON列の使用が適切でない場合があります。
データの視覚化とRDBの重要性
ここまでGA4のJSONデータをRDBで活用する様々な方法について説明してきました。
では、なぜRDBでこのようなデータを扱う必要があるのでしょうか？
1.データの正規化と整合性
RDBの最大の強みの一つは、データを正規化された形で格納することです。正規化とは、データの冗長性を最小限に抑え、各データを独立したテーブルに分割して格納するプロセスを指します。
例えば、「顧客」データと「注文」データを別々のテーブルとして管理し、2つのテーブルを「顧客ID」でリンクさせるような方式です。これにより、データの一貫性と整合性を維持することができます。
これは、データを視覚化する上で非常に重要な前提条件となります。一貫性があり整合性のあるデータは、正確で信頼性の高い視覚化を生み出すことができるためです。
もしデータが重複していたり、形式が一貫していなければ、視覚化の結果も歪んでしまいます。グラフの軸が合わなかったり、間違った合計値が表示されてしまうといった可能性があります。
2.SQLの強力なクエリ機能
データ視覚化におけるもう一つの重要な要素は、データに対する柔軟なクエリ機能です。ユーザーは様々な条件や基準に基づいてデータをフィルタリング、集計、比較することができなければなりません。
この時、SQL (Structured Query Language)は非常に強力で表現力豊かなツールになります。SELECT、WHERE、GROUP BY、JOINなどのキーワードを使用して複雑な分析クエリを作成することができます。
ほとんどのデータ視覚化ツールは、このようなSQLクエリに基づいて動作します。
Tableauの場合、ライブ接続(Live Connection)機能を使用して直接SQLクエリを実行し、その結果を視覚化します。Power BIでもDirectQueryモードではデフォルトでSQLを使用し、複雑なクエリの場合はSQLビューやストアドプロシージャを利用することもあります。
つまり、RDBとSQLはデータ視覚化において、データクエリの核心的な基盤となるわけです。
結論＆まとめ
結論として、イベント分類法は、ユーザーの行動データを体系的に定義・分類し、データの品質を高め、分析の基盤を築くための重要なツールです。
これにより、組織はデータドリブンな意思決定能力を強化し、顧客中心のサービス革新を加速することができます。ビジネスの俊敏性と革新性を確保するためにも、イベント分類法は重要な役割を果たします。
GA4のようなモダンアナリティクスプラットフォームの導入により、イベント中心のデータモデルがより重要になっています。これを効果的に活用するためには、適切なデータウェアハウスとクエリ方法を選択することが重要です。
特に、BigQueryなどのプラットフォームを使ってJSON形式のイベントデータを効率的に分析し、RDBとの統合を通じて様々なBIツールとの互換性を維持することが必要です。
したがって、イベント分類法をうまく設計して運営することは、データ分析の成功のための出発点となります。企業はこれにより、データの価値を最大化し、変化するビジネス環境で競争上の優位性を確保することができます。
参考資料
- Amazon「Product Added to Cart」イベント → Amazon Web Services Documentation
- Googleアナリティクス4の新しいイベントドリブンのデータモデルの紹介
- GA4 Ecommerce Events
