目录
此内容是否有帮助?

# 更新可能なイベント

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

WARNING

更新可能なイベントの保存と処理の性能オーバーヘッドが大きく、データ処理の効率とクエリの性能を保証するために、イベント量が少なく、特殊な業務シーンで強い更新ニーズがあるイベントにしか適用できないので、TA スタッフの協力を得て使用すること

# I.データ構造

TA クライアント 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 種類のデータのいずれかを使用して属性を更新できます。

TA システムが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#event_id対応するデータが存在しない場合、このデータは新しいデータとみなされ、直接入庫
  2. が#event_id存在する場合、このイベントデータのすべての内容が書き換えられ、一部の属性を更新する場合は track_update を使用track_update
  3. また、#timeつまりイベント時間も新しいデータで更新されるため、実際のビジネスシーンに基づいて、新しい着信データの時間を合理的に設定

# III。ベストプラクティス

# 広告コスト

広告効果分析では、多くの場合、広告ビットや素材の 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フィールドを更新し、コストイベントのコスト金額の更新操作を完了する。

← 最初のイベントチェック →