# First Event Check
This chapter will introduce a special pre-defined event property: First Event Check. The first event check is a data filtering feature. A unique identification ID is added to the event data. When the system receives the data, it will compare whether the ID appears before. The data that the ID has appeared will not be stored. The data that does not appear can be stored and the ID is recorded to ensure that the event that the ID first appears will be stored.
WARNING
The performance overhead of the First Event Check is relatively high. It is not recommended to add this validation to all events, and it is recommended to use it with the assistance of TA staff.
# I. Data Structure
Using the "First Event Check" feature requires an adjustment to the data:
- Add the ID field
#first_check_id
, the type must be string, this field is to verify the ID of the first event, the data that appears in the first article of the ID will be stored, and those that appear later cannot be stored. The#first_check_id
of different events are independent of each other, so the first verification of each event does not interfere with each other
The following is a sample data, you can pay attention to the location of #first_check_id
:
{
"#account_id": "ABCDEFG-123-abc",
"#distinct_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
"#type": "track",
"#ip": "192.168.171.111",
"#uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"#time": "2017-12-18 14:37:28.527",
"#first_check_id": "123456",
"#event_name": "test",
"properties": {
"argString": "abc",
"argNum": 123,
"argBool": true
}
}
The above data #first_check_id
is "123456". If the event "test" has been stored before #first_check_id
is another data of "123456", the data cannot be stored. If it has not been stored before, the data can be stored
# II. Data Processing Logic
The TA system maintains an ID table for each event, and the ID tables are independent of each other between different events.
When the system receives event data with #first_check_id
, it will look up the #first_check_id
of the data in the ID table of the corresponding event. According to the query result, different processing will be carried out:
- If the
#first_check_id
does not exist in the ID table, the data will be directly stored after verification, and the ID table will record the#first_check_id
- If the
#first_check_id
exists in the ID table, the data will be directly discarded
If the same event uploads both data with #first_check_id
and data without the field, the data without the field will not be processed by the first event check and will be consistent with the normal data.
TIP
In addition to the above key logic, there are two points to note here:
In order to ensure performance, the system uses timed batch processing to judge, the default interval is 1 hour, so the event data using the first event check will have a default query delay of 1 hour
"#first_check_id" will not be recorded in the database after processing. If you need to record, use an event property record
# III. Best Applications
# New Device
Device add data is very suitable for using first-time event verification. You can report a "device add" event with device ID as #first_check_id
every time the application starts. According to the logic of first-time event verification, only the "device add" event with device ID appearing for the first time will be recorded, and the data appearing afterwards will be discarded. Therefore, the storage event is the first event of each device ID, which is in line with the new logic of the device.
The following is a sample of the "device added" event using the First Event Check:
{
"#distinct_id": "F53A58ED-E5DA-4F18-B082-7E1228746E88",
"#type": "track",
"#ip": "192.168.171.111",
"#time": "2017-12-18 14:37:28.527",
"#first_check_id": "device_id_123456",
"#event_name": "new_device",
"properties": {
"device_id": "device_id_123456"
}
}
This event can be reported every time the application starts, with the device ID as the #first_check_id
; In addition, other attributes can also be added, such as 'device model', 'source channel', etc., to increase the dimension of analysis. TA client side SDK or 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.