# 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_idof 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_idis "123456". If the event "test" has been stored before #first_check_idis 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_idof 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_iddoes 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_idexists in the ID table, the data will be directly discarded

If the same event uploads both data with #first_check_idand 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_idevery 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.

← Updatable Events →