menu
Is this helpful?

# 更新可能なイベント

当ドキュメントでは、TEシステムの特殊なデータ構造である更新可能なイベントの使用方法を紹介します。更新可能イベントは特殊なイベントデータ、データ内のイベントプロパティ値を更新することが可能で、可変状態値または可変累積値を含むイベントデータ（※例：コストイベントなど）を記録するのに適しており、時間の経過とともにプロパティコスト金額を更新することができます。

WARNING

更新可能なイベントの保存と処理の性能オーバーヘッドが大きく、データ処理の効率とクエリの性能を保証するために、イベント量が少なく、特殊なシナリオで強い更新ニーズがあるイベントにのみ適用できない為、都度TEスタッフへお問い合わせください。

# データ構造

TEクライアントSDKまたはサービス側SDKを使用すると、対応するSDKのアクセスガイドが表示され、ガイドの「更新可能なイベント」および「書き換え可能なイベント」の章で詳細なインターフェイス呼び出し方法

「更新可能イベント」機能を使用するには、データ内で2つの調整が必要です

  1. データ型を識別するフィールド#typeに設定track_updateまたはtrack_overwriteします。この2種類のデータ型はそれぞれ、2種類のイベントの更新方法を表します。部分プロパティの更新とすべてのプロパティの書き換えです
  2. フィールドを追加#event_id、プロパティを更新すると、#event_nameと#event_id対応するイベントデータを検索し、データを更新します異なるイベントの#event_idは互いに独立しているため、更新可能なイベントごとに一意の識別子体系

以下は、#event_idの#event_idの位置に注目できるデータサンプルです

{
  "#account_id": "ABCDEFG-123-abc",
  "#distinct_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
  "#type": "track_update",
  "#event_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
  "#time": "2020-08-18 14:37:28.527",
  "#event_name": "test_event",
  "properties": {
    "argString": "abc"
  }
}

# データ処理ロジック

更新可能なイベントは、処理ロジックと通常のイベントデータに大きな違いがあるので十分にご注意ください。イベントデータの#typeがtrackの場合、そのデータは後で更新できます。イベントデータの#typeまたはtrack_overwriteまたはtrack_overwrite、更新可能なイベントと見なされ、その後、2種類のデータのいずれかを使用してプロパティを更新できます。

TEシステムがtrack_updateまたはtrack_overwriteを受信した場合、処理方法は異なります。ここでは、これら2つのデータタイプの処理ロジックについて詳しく説明します。

# 2.1 track_updateの処理ロジック

データの#typeがtrack_updateの場合、データの処理ロジックはイベントプロパティに更新されます。システムがこのタイプのデータを受信すると、#event_idフィールドに基づいて対応するイベントデータが存在するか否かを確認後、存在する場合、対応するフィールドを更新します。具体的な処理ロジックは次のとおりです

  1. このイベントに#event_id#event_id対応するデータが存在しない場合、このデータは新しいデータとみなされ、直接格納します。
  2. #event_idが存在する場合、新しい受信データのイベントプロパティは前の値を更新し、新しいプロパティが存在する場合、新しいプロパティも追加され、新しい受信データに含まれていないプロパティは更新されないので、更新されるプロパティの受信のみが行われます。
  3. また、#timeつまり、イベント時間も新しいデータへ更新されるため、実際の利用シーンに基づいて、新しい受信データの時間を合理的に設定してください。

# 2.2 track_overwriteの処理ロジック

データの#typeがtrack_overwriteの場合、データの処理ロジックはイベントに書き換えられます。システムがこのタイプのデータを受信すると、#event_idフィールドに基づいて対応するイベントデータが存在するか否かを確認後、存在する場合、該当データを削除し、新しいイベントデータをシステムへ書き込みます。(削除されたデータを置き換えることに相当します)。

  1. 当イベント#event_idに対応するデータが存在しない場合、このデータは新しいデータとみなされ、直接格納されます。
  2. #event_idが存在する場合、このイベントデータのすべての内容が上書きされ、一部のプロパティを更新する場合はtrack_updateを使用されます。track_update
  3. また、#timeつまり、イベント時間も新しいデータで更新されるため、実際のビジネスシーンに基づいて、新しく受信されたデータの時間を合理的に設定してください。

# ベストプラクティス

# 広告コスト

広告効果分析では、多くの場合、広告ビットや素材のROI入出力比、つまりユーザー価値とユーザーコストの比を計算する必要があります。ユーザーの価値、つまり直接支払いと他の方法で価値を生み出す合計は、記録しやすいコストデータは、広告配信側のデータルールに依存し、一般的なコスト金額は継続的に更新され、一般的なイベントデータで記録するのには適していないです。

コストデータは継続的に変化するため、広告コストデータは更新可能なデータで記録するのに適しており、初めて広告コストデータを記録する場合、次のようなデータをアップロードできます。

{
  "#account_id": "admin",
  "#distinct_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
  "#type": "track_update",
  "#event_id": "2020-09-01_google_7-Tier1-0527_adset1_adname1",
  "#time": "2020-09-01 00:00:00.000",
  "#event_name": "ad_cost",
  "properties": {
    "channel": "google",
    "campaignid": "7-Tier1-0527",
    "adset": "adset1",
    "adname": "adname1",
    "cost": 100
  }
}

上記データは、#event_id日付、チャネル、イベント名、広告グループ、広告名のスプライスで構成されるコストの更新可能なイベントを追加します。コストの一意のIDとして、論理的にはこちらもデータのコストイベントが更新可能な最も細かい粒度です。costフィールドはこのタイミングでの広告のコスト100元を記録します。

時間が経つにつれて、広告配信チャネルのプッシュは新しいコストデータをプッシュし、新しい広告コストが200であれば、次のようなデータを送信することができ、その中の#event_idは前のデータと一致する必要があり、前のデータを更新することを表しています。更新したのはcostフィールドで、新しいコスト値が200に入った#timeも新しいデータへ更新される為、ここでは以前のデータと一致する必要があり、コストの日付(時間タイプに変換)が入ってきます。他のフィールド、例えばチャネル、イベント、広告ビットは、更新する必要がないので、データに記入しなくても問題ありません。

{
  "#account_id": "admin",
  "#distinct_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
  "#type": "track_update",
  "#event_id": "2020-09-01_google_7-Tier1-0527_adset1_adname1",
  "#time": "2020-09-01 00:00:00.000",
  "#event_name": "ad_cost",
  "properties": {
    "cost": 200
  }
}

TEがこのイベントを受信すると、この#event_idすでに存在するか否かをリクエスト後確認し、存在することが確認できた場合、元のデータ(つまり最初のサンプルデータ)の#timeとcostフィールドを更新し、コストイベントのコスト金額の更新操作を完了します。

← 初回イベントチェック →