# Updatable Events

This chapter will introduce the special data structure of TA system-the usage of updatable events. Updatable event is a kind **of special event data **, which can update the event attribute values in the data. It is suitable for recording event data containing variable state values or variable cumulative values, such as cost events, and can update the attribute cost amountover time.

WARNING

In order to ensure data processing efficiency and query performance, it is only suitable for events with a small amount of events and strong update requirements in special business scenarios. It is strongly recommended to use it with the assistance of TA staff

# I. Data Structure

Using the TA client side SDK or the server level SDK, you can view the access guide for the corresponding SDK. The "Updatable Events" and "Rewritable Events" sections of the guide will provide detailed interface invocation methods

Using the "updatable events" feature requires two adjustments in the data:

Set the field that identifies the data type #typeto track_updateor track_overwrite, which respectively represent how two events are updated: updating some properties and overriding all properties
Add a field #event_id, which is the unique identifier of the event; when updating the attribute, it will find the corresponding event data according to #event_nameand #event_id, and update the data; different events #event_idare independent of each other, so each updatable event has a separate unique identifier system

The following is a sample data, you can pay attention to the location of #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"
  }
}

# II. Data Structure

Updatable events are very different from ordinary event data in processing logic: **Please note that if the **#type**of an event data is track, the data cannot be updated later **; if the #typeof an event data is track_updateor track_overwrite, it will be regarded as an updatable event, and then you can use either of the two types of data to update the attributes.

The TA system will have different processing methods when it receives track_updateor track_overwrite. This section will describe the processing logic of these two types of data in detail.

# 2.1 Track_update Processing Logic

When the #typein the data is track_update, the processing logic of the data is the event attribute update. When the system receives this type of data, it will find out whether the corresponding event data exists according to the #event_idfield. If it exists, it will update the corresponding field. The specific processing logic is as follows:

If there is no data corresponding to #event_idunder this event, the data will be deemed as new data and will be directly stored
If #event_idexists, the event attributes in the new incoming data will update the previous value. If there are new attributes, the new attributes will also be added. Attributes that are not included in the new incoming data will not be updated, so you only need to pass In the attribute to be updated
In addition, #time, that is, the event time, will also be updated by the new data, so the time in the new incoming data needs to be reasonably set according to the actual business scenario

# 2.2 Track_overwrite Processing Logic

When the #typein the data is track_overwrite, the processing logic of the data is event override. When the system receives this type of data, it will find out whether the corresponding event data exists according to the #event_idfield. If it exists, it will delete the data and write the new event data to the system (equivalent to replacing the deleted data). The specific processing logic is as follows:

If there is no data corresponding to #event_idunder this event, the data will be deemed as new data and will be directly stored
If #event_idexists, all contents of the event data will be overridden. If you need to update some attributes, you can use track_update
In addition, #time, that is, the event time, will also be updated by the new data, so the time in the new incoming data needs to be reasonably set according to the actual business scenario

# III. Best Applications

# Advertising Cost

In the analysis of advertising effectiveness, the ROI Return on Investment of Computational Advertising or materials is often needed, that is, the ratio of user value to user cost. The user's value, that is, the sum of the value generated by direct payment and other methods, is easy to record. The cost data will depend on the data rules of the advertisement delivery end, and the general cost amount will be continuously updated, which is not suitable for recording with general event data.

Since cost data will continue to change, advertising cost data is very suitable for recording by updating data. When recording advertising cost data for the first time, you can upload the following data:

{
  "#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
  }
}

The above data will add a cost updatable event, where the #event_idis made up of the splicing of date, channel, activity name, Ad Group, and advertisement name, as the unique ID of the cost. Logically speaking, this is also the cost event Updatable finest grain; the costfield records the cost of the advertisement at this time 100 yuan.

With the passage of time, the advertising media buy channel pushes new cost data. If the new advertising cost is 200, the following data can be sent, of which #event_idneeds to be consistent with the previous data, representing the update of the previous data; Updated is the costfield, and a new cost value of 200 is passed in; Since #timewill also be updated by the new data, it needs to be consistent here, and the date of the cost (converted to time type) is passed in. Other fields, such as channels, activities and advertising spots, may not be filled in in the data because they do not need to be updated.

{
  "#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
  }
}

When the system receives the event, it will query whether the #event_idalready exists. When it is found to exist, it will update the #timeand costfields in the original data source (that is, the first sample data), which completes the update operation of the cost amount of the cost event.

← Privacy Policy First Event Check →