イベントデータの構成要素は何ですか？

公開: 2022-05-12

これは、顧客データに関する5部構成のシリーズの第4部です。これがパート1、2、および3です。

顧客データは、イベントデータとエンティティデータで構成されます。パート1（顧客データとは何ですか？）を完了していれば、これはすでにご存知でしょう。

このガイドでは、イベントデータのコンポーネント、イベントを定義するための推奨される命名規則、エンティティデータのカテゴリ、および2つの主要なタイプのエンティティについて学習します。

イベントデータ

あなたはおそらくオンラインで物を購入したので、eコマースの例から始めましょう。

eコマースアプリ（ウェブまたはモバイル）を操作する場合、通常、商品をカートに追加し、チェックアウトに進み、支払いを完了することで商品を購入します。これらは、商品の購入プロセスを実行するときに実行するイベントです。アプリ。

ただし、バイヤージャーニーはそれほど単純ではなく、次のような他のいくつかのイベントが発生する可能性があります。

商品が表示されます
カートが表示されます
商品がカートから削除されます
クーポンが適用されます
アドレスが選択されます
お支払い方法を選択
注文が完了しました

等々。

[カートに追加]、[チェックアウトに進む]、[支払いを行う]などの一般的なイベントがすぐに思い浮かびますが、ユーザーの行動を理解するには、上記のような他のイベントも追跡する必要があります。

追跡するイベントを決定し、適切な命名規則を使用してイベントに名前を付けることは、イベントデータを収集するプロセスの最初の2つのステップです。

次の2つのステップは何ですか？

よろしくお願いします！

各イベントには、イベントに関するより多くのコンテキストを提供するイベントプロパティ（またはイベント属性）が付随しています。イベントに関連付けるプロパティを決定し、それらのプロパティに名前を付けることは、イベントデータを収集するプロセスの次の2つのステップです。

名前って何？

データに関しては、すべてです。

適切な命名規則または分類法は、良いデータを悪いデータから際立たせ、利害関係者が自分が見ているものを理解できるようにするものです。一方、標準化された分類法を維持しないことは、データセットが冗長性を伴って歪んだり肥大化したりする主な原因の1つです。

また、顧客データを操作する場合、イベントやイベントプロパティに名前を付けるときに大文字と小文字を統一しないことは、発生する可能性のある最大の間違いの1つであり、長期的な影響を与える可能性があります。適切な命名規則には、常に厳密なケーシングガイドラインを伴う必要があります。

理由は次のとおりです。

カートに追加、added_to_cart、productAdded、カートに追加、カートに追加、製品追加は、同じイベントを定義するさまざまな方法です。

これらはいずれもそれ自体が間違っているわけではなく、イベントやプロパティの命名に関しては決まったルールはありませんが、従うことを検討する必要のあるベストプラクティスがあります。

オブジェクトアクションの命名規則は、ほぼ業界標準になり、正当な理由があります。これは、すでに実行されたアクションを明確に説明しています。 製品の追加とは、オブジェクト（製品）の後にアクション（追加）が続くことを意味します。

イベントに一貫した分類法を設定する方法の詳細をご覧ください。

イベントデータのコンポーネント

イベントには、エンティティ（1つ以上）とイベントプロパティの2つの主要なコンポーネントがあります。

user_idなどのエンティティデータをイベントに関連付けると、イベントを実行したユーザーに関する情報が提供されます。

user_idのような一意の識別子がない場合、イベントデータは匿名のままになり、誰がそのイベントを実行したかを知る方法はありません。同様に、ユーザーが複数の組織の一部になる可能性があるB2B SaaSのコンテキストでは、イベントが発生する場所を知るために、 organization_idをイベントに関連付ける必要があります。

エンティティの他に、イベントが発生したときに分析とセグメンテーションを目的として収集できる情報があります。

eコマースの例に戻ると、商品を購入するときは、誰が購入したかを知るだけでなく、少なくとも、どの商品をいつ、どの価格で購入したかを知る必要があります。

これらの追加情報は、イベントプロパティの形式で収集されます。

このシリーズのパート1では、イベントデータが3つの重要な要素で構成されていることが言及されました。

起こった行動または出来事
イベントが発生したタイムスタンプまたは正確な日時
イベントに関連付けられている状態またはその他すべてのプロパティ（イベントプロパティと呼ばれます）

製品が追加されたイベント（イベントAdd to Cartのオブジェクトアクションフレームワークによる適切なケースの名前）を見て、2020年1月1日の午前10時にユーザーによって実行されたと仮定します。 イベントが発生したときに収集されたデータには、次のものが含まれます。

アクション：製品が追加されました
タイムスタンプ： 1577872800 （ ABZ 7.99 ( 状態： 0123 ABZ 7.99 （この例のように、追加されたイベントProductに関連付けられたプロパティは、user_id、product_id、price、およびquantityであり、それぞれがイベントに関する詳細情報を提供します。 タイムスタンプは、イベントがいつ発生したかを知るためにイベントに関連付けられています。
本質的にイベントプロパティであるタイムスタンプの名前を指定することも役立ちます。標準的な方法では、タイムスタンプをタイムスタンプとしてサードパーティツールにデータを送信するときにすべてのイベントに関連付けるため、これを行う必要はありません。ただし、タイムスタンプを格納するプロパティに個別の名前を指定すると、長期的には、履歴イベントデータを操作する必要がある場合に役立ちます。

タイムスタンプの推奨分類法は、イベント名の後に「at」が続くことです。製品が追加されたイベントの場合はproduct_added_atです。
snake_caseがイベントプロパティの定義に使用されていることにお気づきかもしれません。これにより、イベント名とイベントプロパティを簡単に区別できます。ただし、ここには事前定義されたルールはなく、自分とチームに最適なルールを選択する必要があることに注意してください。
製品が追加されたイベントに関連付けられたプロパティと、それらの各プロパティのデータ型の最終的な外観は次のとおりです。
各プロパティにデータ型を指定すると、データの一貫性が確保され、インストルメンテーションプロセスが容易になります。

補足：これで、イベントデータの収集には次の手順が含まれることが明確になります。
追跡するイベントの決定
適切な命名規則を使用してこれらのイベントに名前を付ける
各イベントに関連付けるプロパティを決定する
適切な命名規則を使用してこれらのプロパティに名前を付ける
このシリーズの次の（そして最後の）パートでは、追跡するイベントと収集するデータを決定するプロセスについて説明します。
ただし、イベントデータを確認するときに何を期待するかについては、十分に理解しておく必要があります（インストルメンテーション前の追跡計画であるか、製品分析ツールなどのデータ宛先内であるかは関係ありません）。
いくつかの一般的なイベントとそのプロパティ
先に進む前に、ほとんどのハイテク製品によって追跡されているいくつかの一般的なイベントとプロパティを見てください。

エンティティタイプ
次に、さまざまなエンティティとそのプロパティを詳しく見ていきます。まだ読んでいない場合は、このガイドを読んで、エンティティデータがイベントデータにどのように関連しているかを理解してください。
このシリーズの最初のパートでは、ユーザーが共有するデータはエンティティデータに分類されると述べました。それは事実ですが、すべてのエンティティデータがユーザー自身によって共有されるわけではありません。エンティティデータも生成できます。
エンティティデータは、エンティティに関連付けられたプロパティで構成されます。ユーザーがエンティティの場合、ユーザーに関するすべての情報はユーザープロパティの形式で収集されます。

User_idは、ユーザーを識別するために（そしてイベントの識別子として機能するために）デフォルトですべてのユーザーに対して生成されます。
とは言うものの、当分の間、イベントを忘れて、ユーザーだけに関連するさまざまな情報について考え、ユーザーの特性について説明してください。
エンティティデータの種類
エンティティデータは、次のバケットに分類できます（このシリーズのパート3でも説明されています）。
名前、電子メール、電話などの個人を特定できる情報
年齢、性別、場所などの人口統計
業界、職務、目標などのペルソナ。
ブランド、ジャンル、製品カテゴリなどの設定。
購入した製品、使用したアプリ、費やした時間、サブスクリプションの種類などの製品固有のデータ各バケットの下のデータは、ユーザープロパティに分類されます。つまり、ユーザープロパティには、ユーザーに関するさまざまな詳細と特性が格納されているため、ユーザーを識別して、ユーザーについて詳しく知ることができます。
ほとんどの情報はユーザーから直接取得されますが、特定のユーザープロパティは、製品の使用の結果として時間の経過とともに自動的に生成されます。
しかし、製品の使用によりイベントデータも生成されませんか？
確かに、ユーザープロパティは、イベントの発生時に収集されたイベントに関連する追加の詳細です。 サインアップイベントとそのプロパティを見てみましょう。
ご覧のとおり、このイベントに関連付けられているすべてのプロパティは、ユーザーに関する詳細（ユーザー自身が共有する詳細（ first_name、last_name、email、phone、country ）または自動的に生成される詳細（ signed_up_at、user_id ））を提供します。
次の点に注意してください。
サインアップやタイムスタンプと識別子を除くほとんどのユーザープロパティは変更される可能性があります。ユーザーは、名前、電子メール、電話番号、場所、業界、職務などを変更できます。ただし、サインアップの時刻（signed_up_at）または一意の識別子（user_id）をユーザーが変更することはできません。
ユーザープロパティと組織プロパティ
コンシューマーアプリでは、費やした時間、購入した製品、再生した曲、または視聴したビデオは、ユーザープロパティとして保存されたユーザーに関連付けられたプロパティであり、その値は使用量の増加に伴って常に更新されます。
B2B SaaSのコンテキストでは、ユーザーと組織が主要なエンティティであり、収集されたイベントはユーザーまたは組織（あるいはその両方）に関連付けられています。
ほとんどの生産性向上ツールの場合と同様に、特定のデータが関連付けられたチームやプロジェクトなどの他のグループエンティティが存在する可能性があります。このような場合にも、組織データを収集するプロセスが適用されます。
B2BSaaS製品に関連するいくつかの一般的なユーザープロパティを見てみましょう。
ユーザーが組織の一部である場合、多くの重要な情報はユーザーではなく組織に関連付けられます。
一般的な組織のプロパティ（グループプロパティとも呼ばれます）は次のとおりです。
Organization_idは識別子としても機能し、特定のイベントが発生した組織を知るためにイベントに関連付ける必要があることに注意してください。
次のステートメントを覚えておくと、ユーザープロパティと組織プロパティを区別するのに役立ちます。
ユーザーコホートを定義するのに役立つすべての情報（ユーザーがどこから来たのか、誰であるのか、目的は何か、製品内で何をしているのか）は、ユーザープロパティとして保存されます。
アカウントまたは組織のセグメント化に役立つすべての情報（アカウントの種類、生成される収益、使用する製品または機能、消費するリソース、またはその一部であるユーザーの数）は、組織のプロパティとして保存されます（またはグループプロパティ）。
上記を区別できるようになると、新しいエンティティ（チームやプロジェクトなど）を簡単に組み合わせることができるようになります。
次のステップ
これで、イベントとそれに関連するプロパティを定義する方法、および各エンティティ（ユーザーと組織）のプロパティを指定する方法を明確に理解できたはずです。
今日からイベントの定義とデータの整理を開始するには、無料のAmplitudeアカウントを使用してください。