# Data Access
Data Access controls data that can be accessed by members of a project, and is capable of fulfilling data control on row and column scales.
The control capacity of data permissions can be divided into the following three parts:
- Visibility Control: Setting whether events, event properties or user properties are visible, which is suitable for scenarios where users are not allowed to view cost and ads attribution data.
- Filter Through: Filtering the scope of available data based on rules so that users can only access to data satisfying filter conditions, which is suitable for scenarios where data sources are discriminated or data are viewed by different channels.
- Data desensitization: Displaying sensitive properties that have drilled down to event or user lists and user sequences in a desensitized way to satisfy desensitization requirements set by regulators on detailed data.
Given the differences in data permissions, different members may see different results even when they are viewing the same dashboard or report. Members can confirm their data permissions in the current project from Personal Center.
# Visibility Control
Visible events, event or user properties can be set; only analysis results of selected events or properties can be used or viewed in analysis, which include:
- Selectable events or properties in query
- Whether reports shared by others can be viewed normally (if invisible events or properties are used, a notification of no viewing permissions will be prompted).
On the left side of the settings bar, you can set whether newly added events or properties are visible. By default, "newly added events (or properties) are visible", that is, users will have the viewing permissions to new events or properties that have been stored in database after visible permissions are set.
If there is a need to control the visibility of newly added events or properties, then you can disable the status. After the status is disabled, users under the data permissions will not be able to use new events or properties within the project.
If cost, ads attribution and similar fields are reported in user properties, then the specified member in the project will not have the permissions to view these properties. In this case, data permissions can be created. The aforementioned properties can be set as invisible in visibility settings and then designate created data permissions to the member.
# Data Range
To limit a member's accessibility to a certain scope of data, filter through can be selected based on event or user properties. After the setting, the member can only access to data fulfilling filter conditions, including:
- Filter through of computational results when query is conducted;
- Filter through of computational results when viewing reports shared by others.
Depending on different properties set, the rules for the filter through to take effect are as follows:
| Filter property | Filter through | Examples |
|---|---|---|
| Event property | Only event data fulfilling filter conditions can be accessed; | If filter event property [Server ID=1], then only event data with server ID being 1 can be accessed. |
| User property | Only Users user and event data fulfilling filter conditions can be accessed; | If user property [Source channel = Huawei App Store] is filtered, then only users coming from Huawei App Store and event data generated by these users can be accessed. |
It is commonly used in the following scenarios:
- Businesses involving joint operations, such as game distribution through multiple third parties; if you want set filter through as distributor from channel A, then only user data from channel A can be viewed. You can create data permissions and set user filter, for example, filter (source channel =A) data and assign data permissions to members from the distributor to fulfill data isolation.
- If the Admin wants to gradually open data usage permissions to a newly included member, for example, the permissions to use data of the past 30 days, then he can set an event filter (event time falls in -30 - 0 day in relation to the current date) in order to control the scope of data to be queried.
# Data desensitization
Event and user property fields that need to be desensitized can be selected. Desensitized fields only act on detail information, including drill-down list (including event and user lists) and user sequence. Fields that has been set to be densensitized will be invalidated using special characters (*).
# Deleting data access
When deleting a data access, members that fall in this access settings can be removed to other data permissions.
# Special rules on tag creation and metric alerts
To ensure availability to different members, special rules apply to data access during tag creation and metric alerts:
- Tag creation: For members with different data permissions, tags are computed invariably by "all data permissions", which exerts control only when different members view computational results of tags based on their corresponding data permissions. For example, Member A has the data permission of [only accessing user data coming from the source channel of Huawei App Store] in project A, then when member A creates tags, the tag values will be computed based on full data. However, when member A views tag details or view tag data from dashboards, he can only view tag data and details corresponding to users from the source channel of Huawei App Store.
- Metric alerts: As the creator needs to create alert trigger rules based on metric performance characteristics, the scope of computation of metric data should be consistent with the creator's data permissions. When creating metric alerts, the creator's filter through conditions will be automatically included.