メインコンテンツまでスキップ

更新可能イベント

最終更新 2026/10/03

このセクションでは、AEシステムの特殊なデータ構造である更新可能イベントの使用方法を説明します。更新可能イベントは特殊なイベントデータで、データ内のイベントプロパティの値を更新できます。変化する状態値や変化する累積値を含むイベントデータの記録に適しています。例えばコストイベントでは、時間の経過に応じてプロパティcost（コスト金額）を更新できます。

警告

更新可能イベントは保存と処理のパフォーマンスへの負荷が大きいため、データ処理の効率とクエリのパフォーマンスを確保するために、イベント量が少なく、かつ特殊な業務シナリオで強い更新ニーズがあるイベントにのみ適しています。ThinkingAIの担当者のサポートのもとで使用することを強くお勧めします

1. データ構造​

AEのクライアントSDKまたはサーバーSDKを使用する場合は、対応するSDKの接続ガイドを参照してください。ガイドの「更新可能イベント」と「上書き可能イベント」の章で、インターフェースの詳しい呼び出し方法を説明しています

「更新可能イベント」機能を使用するには、データに次の2つの調整を行う必要があります：

  1. データタイプを示すフィールド#typeをtrack_updateまたはtrack_overwriteに設定します。この2つのデータタイプは、それぞれ2種類のイベント更新方法を表します：一部のプロパティの更新と、すべてのプロパティの上書きです
  2. フィールド#event_idを追加します。このフィールドはイベントの一意の識別子です。プロパティを更新する際は、#event_nameと#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"
  }
}

2. データ処理ロジック​

更新可能イベントは、処理ロジックの面で通常のイベントデータと大きく異なります：注意：イベントデータの#typeがtrackの場合、そのデータは後から更新できません。イベントデータの#typeがtrack_updateまたはtrack_overwriteの場合は更新可能イベントとみなされ、後から2種類のデータのどちらを使用してもプロパティを更新できます。

AEシステムは、track_updateとtrack_overwriteのどちらを受信したかによって異なる方法で処理します。このセクションでは、この2種類のデータの処理ロジックを詳しく説明します。

2.1 track_updateの処理ロジック​

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

  1. そのイベントに#event_idに対応するデータが存在しない場合、そのデータは新規データとみなされ、そのまま格納されます
  2. #event_idが存在する場合、新しく送信されたデータ内のイベントプロパティで以前の値が更新されます。新しいプロパティがあれば、それも追加されます。新しく送信されたデータに含まれないプロパティは更新されないため、更新したいプロパティだけを送信すれば十分です
  3. また、#time（イベント時間）も新しいデータで更新されるため、実際の業務シナリオに応じて、新しく送信するデータの時間を適切に設定する必要があります

2.2 track_overwriteの処理ロジック​

データの#typeがtrack_overwriteの場合、データはイベントの上書きとして処理されます。システムはこのタイプのデータを受信すると、#event_idフィールドに基づいて対応するイベントデータが存在するかどうかを検索し、存在する場合はそのデータを削除して、新しいイベントデータをシステムに書き込みます（削除されたデータを置き換えることに相当します）。具体的な処理ロジックは次のとおりです：

  1. そのイベントに#event_idに対応するデータが存在しない場合、そのデータは新規データとみなされ、そのまま格納されます
  2. #event_idが存在する場合、そのイベントデータのすべての内容が上書きされます。一部のプロパティだけを更新したい場合は、track_updateを使用できます
  3. また、#time（イベント時間）も新しいデータで更新されるため、実際の業務シナリオに応じて、新しく送信するデータの時間を適切に設定する必要があります

3. ベストプラクティス​

広告コスト​

広告効果の分析では、広告枠や素材の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
  }
}

上記のデータにより、コストの更新可能イベントが1件追加されます。#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がすでに存在するかどうかを確認します。存在する場合は、元のデータ（つまり1つ目のサンプルデータ）の#timeとcostフィールドを更新し、これでコストイベントのコスト金額の更新が完了します。

このページは役に立ちましたか？
このページの内容