# 更新可能なイベント

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

WARNING

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

# データ構造

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

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

データ型を識別するフィールド#typeに設定track_updateまたはtrack_overwriteします。この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フィールドに基づいて対応するイベントデータが存在するかどうかを調べ、存在する場合、対応するフィールドを更新します。具体的な処理ロジックは次のとおりです

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

# 2.2 track_overwriteの処理ロジック

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

このイベントに#event_id#event_id対応するデータが存在しない場合、このデータは新しいデータとみなされ、直接格納されます。
が#event_id存在する場合、このイベントデータのすべての内容が書き換えられ、一部のプロパティを更新する場合はtrack_updateを使用track_update
また、#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
  }
}

システムがこのイベントを受信すると、この#event_idすでに存在するかどうかを問い合わせ、存在することを発見すると、元のデータ(つまり最初のサンプルデータ)の#timeとcostフィールドを更新し、コストイベントのコスト金額の更新操作を完了します。

← プライバシーポリシー初回イベントチェック →