Basic data verification

This step is to be completed by the testers, and the tasks to be completed are as follows:

• Validate the integrity and data type of events and properties.
• Verify user association information
• Verify that the App and H5 are integrated (assuming integration has been implemented).

Event and property integrity checks

Access the Sensors Analytics page, click on [Metadata], and view the meta-events and attribute fields. Note that the event and attribute names are still displayed in English at this time; they will need to be uniformly changed to the corresponding Chinese names later. The following items should be checked:

Check whether the events and names are consistent with the "Data Acquisition Plan".

Are there any outstanding or newly added events? If there are newly added events, they may have been generated during developer testing, and the developers need to confirm that the relevant event tracking code has been removed. If there are outstanding events, they may have been missed or tracked but no data has been transmitted.

Select the event name and check if its properties are complete and if the name and type are correct.

Are there any leftover or newly added attributes? Leaving behind attributes is quite common; they might have been missed.

Does the attribute value type match the data acquisition scheme? If not, please have the developer correct the variable type in the code, and then contact technical support to modify the variable type. Only after the type is corrected can the data be successfully entered into the database. Alternatively, you can choose a different attribute name, and the data can be directly entered into the database.

Verify user association information

Before starting the validation in this section, please read step 2: How to accurately identify users and ensure you understand the concepts and schemes of user association.

This step requires using the "Custom Query" function in Sensors Analytics. The verification aims to achieve three goals:

1. Check if there are any abnormal values for first_id, and whether there is any erroneous operation that writes second_id into first_id;
2. Check if the value of second_id is abnormal and whether there are any normally associated users.
3. Check if the user ID association process is normal.

Check the value of first_id

Query the `users` table to check if `first_id` in the query results is a device ID and if there are any anomalies. Below are the default device IDs used by various SDKs; you can roughly determine if the `first_id` value is normal based on the ID format.

 查询 sql： select * from users limit 1000

Common scenarios that may exist in the above query results include:

• The situation where first_id = second_id is normal. If the developer has logged in with multiple accounts on the same device, in addition to the first account that is logged in being associated normally, the other accounts will be associated with each other, resulting in the situation where first_id = second_id = account ID.
• The actual value of first_id is not the device ID, but the account ID, while the value of second_id is empty. This means that second_id was mistakenly written as first_id. You can check this further using the SQL below.

 查询 sql：SELECT u1.first_id, u1.second_id, u2.first_id, u2.second_id FROM users u1 JOIN users u2 ON u1.first_id = u2.second_id WHERE u1.second_id IS NULL;

If the above query returns results, the reasons may include, but are not limited to, the following:

• The $SignUp event failed to be transmitted, resulting in no successful association.
• The backend did not set the is_login_id parameter to true when sending distinct_id;
• The login function was mistakenly called instead of the anonymous ID, replacing the login ID with the anonymous ID.

Check the value of second_id

Query the `users` table and observe whether the value of `second_id` is the default `user_id` or another unique user identifier. Note that in a test environment, it's normal for `second_id` to be mostly empty; the developers may have only experimented with ID association on a small number of test accounts.

Check if there is a normal association, i.e., first_id is the device ID and second_id is the user_id.

Check if the user ID association process is normal.

In the query results of the users table, select the id (id field of the users table) of a normal association case and query the behavior record in the events table.

 查询 sql：select * from events where user_id = "选取的id不用加引号" order by time

The key observation point in the query results is that before and after the initial triggering of the $SignUp event, the distinct_id field in the events table changes from device ID to user_id. This indicates a normal association process exists. If you are using a many-to-one association scheme, please contact your analyst for assistance in verifying this aspect.

Verification App and H5 integration

This verification step is only required if the app and H5 pages are integrated.

For developers, go to the Sensors Analytics page, click 【Event Tracking Management】->【Real-time Data Import Query】, select “$pageview” as the event name, and click 【Start Refresh】 to check the specific event and attributes in real time to ensure they are correct. On your mobile phone, open the app and go to the H5 page. Check the attributes of the “$pageview” event. If fields such as “$wifi”, “$network_type”, “$app_version”, and “$carrier” are present, it means the app and H5 are successfully integrated. (Alternatively, after enabling SDK debug logging, check the event log information output in the developer tools' console.)

You can also find the Web browsing page event in the event analysis and check whether the event attributes include device ID, application version, whether it is WIFI, network type, and carrier.