# 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 amount
over 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
#type
totrack_update
ortrack_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_name
and#event_id
, and update the data; different events#event_id
are 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 #type
of an event data is track_update
or 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_update
or 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 #type
in 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_id
field. If it exists, it will update the corresponding field. The specific processing logic is as follows:
- If there is no data corresponding to
#event_id
under this event, the data will be deemed as new data and will be directly stored - If
#event_id
exists, 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 #type
in 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_id
field. 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_id
under this event, the data will be deemed as new data and will be directly stored - If
#event_id
exists, all contents of the event data will be overridden. If you need to update some attributes, you can usetrack_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_id
is 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 cost
field 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_id
needs to be consistent with the previous data, representing the update of the previous data; Updated is the cost
field, and a new cost value of 200 is passed in; Since #time
will 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_id
already exists. When it is found to exist, it will update the #time
and cost
fields in the original data source (that is, the first sample data), which completes the update operation of the cost amount of the cost event.