# Tags
User tags are one of the tools offered by the system to subdivide user data. A user tag can be regarded as a property used to describe users, such as [Sex], [Age] and [Balance of Account]. In daily operations, multiple properties, such as [Sex: Male], [Age: 40-50] and [Balance of Account: over 5,000 dollars], can be used to describe a user. In the system, you can use the values of User Tags to identify users, and these tags can be further used to screen users or conduct grouped statistics for analysis.
Users can be classified into many types based on different tag values. For example, under the [Sex] tag, tag values of [Sex: Male] and [Sex: Female] are respectively used for tag users. If there is a hierarchical or numerically progressive relationship between different tag values, the tag can also be treated as a perspective for user stratification, such as the [Number of Days Since Last Payment: 1 day/1-3 days/3-7 days/...].
Compared with selecting users based on Cohorts, user tags are more like something used to tag users. Such tags have a very high re-usability. Generally, it is recommended to use abstract user properties as tags, such as [Payment Ability: Low/Medium/High] and [Active Time Interval: 11:00-01:00/2:00-4:00/...]. In the meantime, the defining and naming rules of tag values should be consistent to the common understanding within your enterprise. A created tag can be used in many scenarios.
# Create user tags
At Users - Tags, you can create a user tag in many ways. For details, please see the following table:
Definition mode | Cohort type | Description |
---|---|---|
ID set (The identifying relationships based on user and tag values are saved as tag definitions. Tags defined in such a manner almost have no changed range of identifiers). | ID tag |
|
Data condition (Computational rules identified by user and tag values are saved as tags. In each rule-based computation, conformity to the current conditions is used as the judgment criterion for identifying. By default, the upper limit of the number of projects of this kind is 200) | Behavioral tag |
|
First and last tag |
| |
Metric value tag |
| |
SQL tag |
|
When you create a tag, you also need to select user entities and timezone of the tag apart from tag conditions.
User entity
A user tag is a tool to subdivide users, while "user" identifiers are numerous, such as device ID, account ID, role ID and platform IDs. In project configuration, you may add users identifiers (properties) other than TE user IDs as user entities. These user entities can also be subdivided by user tags.
When creating a tag, user entities should be selected; the identifying relationships between user entities and tag values can be obtained from computation and the "number of users" of the tag is also the number of user entities.
Please note that when event properties are selected as user entities, a conditional tag can not use the 「have not done」condition.
Timezone
When multiple timezone switches are turned on in your project (configured in 「Project Settings」, you also need to first select the settlement timezone for your tag that is being created. When event data is used in definitions of 「behavioral tag」, 「first and last tag」,「metric value tag」and 「 SQL tag」,the time range in the defaulted event condition should be a time range under the tag timezone. If a reported event is from another timezone, the event timezone will be first converted before determining whether relevant conditions are met. For example, if the displayed timezone is UTC+10 and the condition of the definition is payment of yesterday, then we should convert the time of the payment behavior to UTC+10 before determining whether the behavior occurred yesterday.
Please note that if a different display timezone is selected when viewing dashboards and reports, the tag data being used is the results of the original timezone and the settlement timezone will not be changed accordingly.
# Update user tags
A user tag is pre-computed data (differing from ad-hoc queries). That is to say, the system will pre-compute the user tag and then use the result data in subsequent analysis and operation instead of re-computing the tag every time the tag is used. Pre-computation significantly reduces the complexity and repeatability of computation, thereby increasing the efficiency of data use. However, the timeliness of data will also be undermined. For the majority of analytical scenarios, cohorts updated with a daily granularity can simply meet the needs.
Tags defined by data conditions. The system supports multiple update modes, as described below:
Update Mode | Description |
---|---|
Auto | When creating or editing a tag, if you enable auto update of behavior, first and last, metric value and SQL tags, the system will automatically update the tag daily at the pre-scheduled time. Such an update mode is not supported by ID tags. ![](/assets/XYN6bk9DaollXox9U53cjOkWnif.png) |
Manual | 「behavioral tag」, 「first and last tag」,「metric value tag」and 「 SQL tag」can be updated manually. If you need to view the current tag data, you may manually trigger an update. ID tags are updated by re-importing new files |
Create computation | Upon the creation of all tags, a computation will be immediately executed. |
Edit computation | After changes of conditions and timezone, computation will be immediately executed. |
Please be noted that user and event data in the system are updated in real time. You can use the "Today" event condition in tag definition so that only today's data as of the time of computation is used. If you need to use the data of an entire day, please use event condition as of the previous day.
When analyzing historical data, you may need to use user tag value at a certain historical period, and the tag stores user's value at a certain date in the form of 「tag's date」. For details, please check dates of tags.
# Manage user tags
On the User Tag interface, you can edit, delete, download (only ID tags) and update tags. For details about management of dates of tag, please check dates of tags.
As a tag can be used by assets like virtual properties, reports, cohorts (created by the operation module) and alerts, modification and deletion of the tag may lead to exceptional volatility of data of these assets and even non-computability. When the deleted or edited tag is reliant upon an asset, its the scope of impact will be notified by the system and the operator should judge influences first before proceeding with the ongoing operation.
# User tag details
Click the user tag name and you will be able to view tag details. Tag detail consists of two parts: tag definition and tag data, as shown below:
Click the number of users in the data table and you will be able to drill down to the user list identified by tag value of the corresponding date.
The table displays a maximum of 1,000 lines of user data. If you need more data to be displayed, click the download button on the upper right corner of the table. A maximum of 500,000 rows of user data can be downloaded.
Please be noted that clicking the "update" on the upper right corner of the table on the user list page will only trigger re-query of tag results instead of re-computing the tag itself. However, the user property data of the tag will be updated.
# User permissions
Company Root | Admin | Analyst | Regular Member | |
---|---|---|---|---|
View tag list | ● | ● | ● | ○ |
Create new, edit and delete self-created non-SQL tags | ● | ● | △ | ○ |
Create new, edit and delete self-created SQL tags | ● | ● | △ | ○ |
Edit and delete tags created by others | ● | △ | ○ | ○ |
Description of permissions:
● Compulsory availability for roles
▲Availability by default for roles, but unavailability is allowed
△ Unavailability for roles by default, but availability is allowed
○ Compulsory unavailability for roles