Business tracking and data analysis are key methods for tracking, collecting and analyzing user behavior and business data, which are used to understand user behavior patterns, improve products and services, and make data-driven decisions.
The full text is 15,000 words, and the recommended reading time is 35 minutes.
Table of contents
Attribute value meaning or example
Version iteration function buried point management
Big screen for visualizing data
Establish a standardized process
Whether similar scenes are merged into one event or divided into different events
Design of Multiple Identity Users
Handling of active and passive events
Examples of social data collection solutions
Functional Interaction Data Analysis
Business point
Business embedding refers to inserting specific codes or tags into applications or websites to capture and record user behavior and interaction data. These codes are usually added by developers to key touchpoints or events such as page views, clicks, form submissions, etc. Through business tracking, you can track and record specific behaviors of users on applications or websites, and generate event and attribute data.
The importance of burial
Take a chestnut. .
Today, the product that I worked hard for half a year is finally launched. Out of seriousness and responsibility for the product, you are a little curious how many people use this product today. So I ran to my R&D classmates, so...
today? Today is not over yet, let's give an exact time frame...
How much does this refer to PV or UV?
What is the definition of a person? IMEI? udid? oaid? Or user_id or something?
How is this used? enter main page? register? Or trigger an event?
Oh okay, let's improve the requirements
For this reason, from another perspective, point burying is also an essential first step in the complete path of data analysis .
GET
- What is "buried point"? "Buried points" is a basic and widely used method for Internet products to collect data.
- Why "collect data"? Because we need to obtain data to support subsequent data analysis and ultimately drive business development.
The type of buried point
In the scenario of AB testing, the data embedding point provides data support for the effect of the experimental group, and its essence is also the basis for data decision-making.
According to the current common forms of data burying, data burying can be divided into full burying and code burying (custom burying).
full burial
Full burying means that the data collection sdk has no difference. All the page loading success events, and the browsing and click events of the controls are all acquired and saved first. When it is used, go to the specific page path and control name. Get the corresponding data.
Based on this, visual burying point refers to defining the desired page data or control data on the corresponding page in a visual way on the basis of successful full burying point deployment and the availability of full data.
advantage
- Since the collection is full amount of data, there is no need to pay attention to the logic of burying points during the product iteration process, and there will be no phenomenon such as missing burying or burying by mistake;
- Because the full burying method collects the full amount of data, it can greatly reduce the trial and error cost of operations and products, and the possibility of trial and error is high, which can bring more enlightening information;
- No need to bury points, convenient and fast
shortcoming
- The disadvantages are the same as the visual buried points, the problem of personalized custom data acquisition is not solved, and the flexibility of data acquisition is lacking;
- Collect the full amount of data without buried points, adding pressure to data transmission and servers;
- Unable to collect custom attributes and events, reporting behavior information is easily limited;
- The processing of web page data has always been bad, especially when it comes to the embedded H5 pages of APP, it is very painful.
The advantages and disadvantages of visual buried points are basically the same, and business personnel can operate according to the rules themselves, without the need for development to re-connect.
Therefore, full burying is suitable for scenarios with changing business, frequent adjustments, and relatively light analysis requirements. For general-purpose functions, the shape is relatively fixed, and the requirements for data analysis granularity, drill-down depth, and aggregation degree are relatively high, so code embedding is required
Code Buried
Code burying points are also called custom burying points, which are defined separately for desired points, and the information of burying points can be enriched through variables to support upstream and downstream analysis.
Code burying points are divided into front-end burying points and back-end burying points.
Front-end buried point:
Including but not limited to APP clients, H5, WeChat applets, and PC webpages, it refers to the clear definition of specific functional scenarios (such as successful loading, browsing, clicking, etc.), triggered by the front end, and the collected data compared to Full-buried points are more accurate and stable, and through variable fields, it is possible to achieve splitting, aggregation and drill-down of finer-grained data.
Backend buried point:
Refers to the event buried point that triggers the server-side interface call (for example: the interface callback is successfully triggered), such as the most typical registration success event and payment success event. The back-end buried point has higher requirements on data accuracy, and it can also support data splitting, aggregation and drill-down through the expansion of variable fields. It should be emphasized that the back-end events generally collect user behaviors in the logged-in state. If you want to use back-end embedded events as part of process analysis (such as funnel analysis), users who are not logged in may miss The case of falling.
Buried point summary
Based on the above, the comparison of several buried point types
| Buried program | implementation plan | advantage | shortcoming |
|---|---|---|---|
| full burial | After the developer integrates the collection SDK, the SDK will directly start to capture and monitor all the behaviors of the user in the application, and report all of them | 1. The full amount of data can greatly reduce the trial and error costs of operations and products 2. No need to bury points, convenient and quick 3. In the process of product iteration, there is no need to pay attention to the logic of burying points, and there will be no phenomena such as missing burying or burying by mistake |
1. The problem of personalized custom data acquisition is not solved, and the flexibility of data acquisition is lacking 2. The full amount of data will increase the pressure on data transmission and servers 3. Unable to collect custom attributes and events |
| Visual buried point | Using visual interaction means, business personnel can directly make simple circle selections on the page to track user behavior | 1. Low labor cost and low update cost 2. Only need to access the SDK, and the follow-up business personnel can operate according to the rules, no need to develop and access again |
1. It is impossible to customize the data acquisition, and the covered functions are limited 2. Reporting behavior information is easily restricted |
| Front-end buried point | When the event defined by the front end is triggered, the corresponding data is uploaded | 1. More accurate 2. Basically not affected by page revision |
1. There is a certain amount of development work 2. When designing new functions, it is necessary to consider the impact on the original buried point and maintain the index document. |
| Back-end buried point | When the event defined by the server is triggered, the corresponding data is uploaded | 1. Most accurate 2. Not affected by the revision of the foreground function |
1. The work of development and testing is relatively large |
Interaction, click, and browsing front-end collection are mainly used.
For core business such as payment, registration, etc., the backend is recommended.
Add buried point design
The data generated by an Internet product every day is huge and messy, and storing all of it will take up hard disk space. Moreover, data without definitions and labels is also difficult to use. Therefore, in the initial data construction stage, the first thing to do is to define the desired data, and tell the front-end development and background colleagues what data you want. The fields defining these data include but are not limited to the following fields:
| serial number | event name | event display name | attribute name | attribute display name | attribute type | Attribute value meaning or example | Event trigger timing | Buried way | Remark |
|---|---|---|---|---|---|---|---|---|---|
| 1 | regist_submit | user register |
regist_type | way to register | string | Mobile phone number/email... | Triggered when a registration result is returned | Server | |
| is_success | whether succeed | string | true/false | Triggered when a registration result is returned | Server | ||||
| fail_reason | failure reason | string | Network reasons/other reasons | Triggered when a registration result is returned | Server |
serial number
Each event has a fixed number, which is unique and cannot be modified, which is convenient for document review, backtracking, and management.
event name
For each abstract behavioral event, a Chinese name and an English name, there must be a one-to-one correspondence between Chinese and English, which cannot be repeated, and means that the meaning is consistent. For the naming of events in English, avoid confusion and use a unified standard for naming. The suggested rules are:
-
Underscore can be used to distinguish -regist_submit, or camel case to distinguish registSubmit (one or more words are connected together, the first word starts with a lowercase letter, and the first letter of each word after the second word is capitalized ).
-
Use verb_noun or noun_verb for unification.
-
If there are multiple business lines, you can add the name of the business line before the event, such as a_regist_submit.
-
Case sensitive, if you pass Name, it is not recommended to pass name.
-
The English name of a custom event cannot start with $.
event attribute name
-
The number of events for a single application does not exceed 1000 (different applications do not affect each other).
-
The number of attributes of a single event is recommended to be within 300, and the maximum is no more than 500 (different events do not affect each other).
-
The number of custom public attributes for a single application does not exceed 100.
-
The length of event name and attribute name is recommended to be within 50 bytes, the longest event attribute name is no more than 80 bytes, and the longest common attribute name is no more than 64 bytes.
-
The attribute value length is recommended not to exceed 255 bytes, and in special cases such as url, a maximum of 1024 bytes is supported.
-
When the above limit is exceeded, the excess event and attribute data may be automatically discarded by the system.
-
Preset events and properties cannot be modified. In addition, when the server is buried, the preset public attributes cannot be automatically collected, and manual transmission is required.
-
Multi-terminal transmission must unify event and attribute naming to ensure consistent transmission.
-
For each event attribute, a Chinese name and an English name, there must be a one-to-one correspondence between Chinese and English, representing the same meaning. However, the same attribute can be referenced by multiple events, such as browsing product details page events and bookmarking product details events, and attributes such as product name and product ID can be shared. When the same attribute has similar literal meanings in different events, but the actual meaning is different, it is not recommended to reuse it. It is recommended to distinguish attributes based on the actual meaning of the attribute. For example: in the event of "video loading", the attribute "duration" means "loading duration"; in the event of "video playing", "duration" means "playing duration". In such a case, it is not recommended to reuse the "duration" field, but to split it into two fields and name them separately.
Events & Property Limits :
-
Attribute naming adopts the snake naming method, that is, all words are in lowercase, and words are separated by "_".
-
The noun form is usually used when naming attributes. For example: product_type, product_id, etc.
-
The English name of a custom attribute cannot start with $.
-
The English name and Chinese name of the custom attribute must maintain a strict one-to-one correspondence.
-
Case sensitive, if you pass Name, it is not recommended to pass name.
-
attribute type
| attribute value | meaning |
|---|---|
| int | Integer values that need to be aggregated (such as sum, mean) or grouped by interval, typically age, quantity, etc. |
| float | Decimal values that need to be aggregated (such as summation, average) or grouped by interval, typically such as price, duration, etc. |
| string |
Text type attribute value type, supports calculation rules such as contains, does not contain, and equals. |
| list |
Multiple values need to be stored in one field. |
| datetime | A string that supports datetime format, "2020-06-19 17:51:21" |
Attribute value meaning or example
| attribute type | example |
|---|---|
| enumerable properties | Gender: Male Female |
| Non-enumerable properties, instantiable properties | Commodity brand: A brand, B brand... |
design elements
- when: timing
- What information is on the server: attributes
Timing is the event scenario, what happened, what happened, and who triggered it. The trigger can be the user, the system, the operator, or the system in essence, and the system is the agent of the event. An opportunity should contain the above implied information.
Common times are:
- click
- browse (visit)
- exposure
- play
- result
Events are often from the perspective of results, and their impact on business is more business-oriented. At this time, the event will not pay too much attention to the trigger scene of the buried point, and more focus on the business result. Therefore, events often have many opportunities, and multiple opportunities will generate an event.
Common events are:
- focus on
- Buy
- collect
- download
- play
- exposure
report information
- Public information: Generally, it is the user's global information, including equipment, network, personal, page, location module, time and other general information not related to business
- Business public information: generally master data information, information related to business content such as commodities, content, orders, etc., generally information shared by multiple businesses of an enterprise
- Custom information: information about business content
- Extended information: information reported in special scenarios
For example:
Buried information:
- SDK version
- time of event
- The time the server received
- time of this launch
- Sessionid
User Info:
- Account ID
- User's Nickname
- idfa/imei md5 encrypted value
- device id
- Whether to visit on the first day
- nation
- City
- province
- County
- membership level
Device Information:
- operating system
- operating system version
- Phone model
- equipment manufactory
- Device model
- screen height
- screen width
- longitude
- latitude
- dark mode
- Whether WiFi
- Network Type
- operator name
- IP
- UA information
Application information:
- Is it a grayscale version
- current channel
- App build number
- AB test logo
- Experiment ID
- Package names
- Whether youth mode
- 夜间模式
- 位置是否授权
- 提醒是否开启
- 安装渠道
界面信息：
- 当前页面
- 当前URL
- URL参数
- 当前URI
- 上一页
- 页面标题
- 形式(原生/H5)
界面层级：
- 一级
- 二级
- 三级
- 四级
模块信息：
- 模块名称
- 父模块名称
- 模块位置顺序
内容：
- 内容类型
- 内容名称
- 内容 ID
- 父内容 ID
事件的触发时机
说明每一个事件应在何时触发，如一个事件在多个时机均有可能会被触发，则需要整理出所有的触发时机。例如：“点击开始注册事件”的触发时机应为点击注册时，但注册通常有多个不同的入口，因此，业务人员需要明确地枚举出哪些注册入口是需要研发人员进行埋点的，如果有属性值的区分也要标注，避免遗漏。
| 事件 | 属性 | 属性值 | 触发时机 |
|---|---|---|---|
| 点击开始注册 |
注册入口 |
首页右上 |
|
用户表设计要素
用户表，顾名思义是记录用户信息、用户属性的表，通过用户的唯一标识（user_id）能够将事件表和用户表两张表进行关联。事件与用户实现关联，事件表里一条条的数据记录，就不会再是孤立的统计数字，而是能够与具体的用户产生关联进行分析，或者用行为来圈定用户，给用户设定分群和标签。
某日商品详情页的总浏览数据是上升的，但是总GMV没有明显提高，从事件侧分析，发现某类合作主推的单商品详页浏览数据上升，其他品类商详页没有明确上升；从用户侧分析，该类单品新增流量主要来自于渠道A。
从此得出的初步判断是：
- 对渠道A的用户拉新效果明显；
- 但是该类用户被吸引来了，但是目标群体却没有下单，很奇怪，需要确认投放落地页与站内商品信息是否一致，尤其是价格、库存等信息；
- 该类用户对平台其他商品的兴趣不高。
-
确立观察指标
-
抽象过程行为
-
补充事件属性
-
设计事件要素
-
补充用户属性
确认是否需要导入后台业务数据库、标签等数据
数据指标地图
数据能力推广的第一个难点，是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标，比如采用excel的方式进行管理，问题是指标一多起来，找起来不太方便，对于定义者来说自然很容易找到，但是对于使用者来说则不太友好。即使搜中文名称，也会存在同一个地方，大家用不同的关键词去搜索，比如：模块、版块、板块。
因此在数据指标表的第一个sheet，设计了一个数据指标地图，将不同功能模块的数据指标进行了拆解和说明，运营同学找数据指标之前，先打开指标地图大概定位，然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。
另一块就是数据仓库的各种表的定义。从数仓里自助取数时，会有以下的问题：有哪些表、表格对应的是哪块业务的数据、有哪些字段，字段的含义是什么？这个需要和数据同学一起来明确具体内容了，这个工作并不复杂，就是需要开个小会进行确认，并且约定好，新增表格时，及时更新对表格的解释。
版本迭代功能埋点管理
随着版本迭代有新功能的埋点，或者针对之前功能的优化，所以需要对之前埋点进行调整。从埋点管理的角度，新增/修改的埋点，需要整合到之前的埋点系统里，这样能够方便使用者查阅整体的埋点明细。
背景：产品迭代周期为两周一个版本，有3位功能产品经理，他们负责具体功能的设计和产品跟进，在设计产品功能时，也会提交与功能相关的埋点需求，在经过功能评审后，会和数据产品就功能埋点进行一次沟通，然后将确定的埋点需求梳理出来。
处理流程：功能在经过需求评审（=技术评审）后，基本确定了这一次要做的功能点，因此也可以梳理出要做的埋点有哪些。所以从这个节点的处理流程是：
- 功能产品经理（后称功能PM）梳理相应的埋点清单（按照符合总表设计逻辑的字段进行梳理）；
- 功能PM与数据产品经理（后称数据PM）做内部评审，评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单；
- 功能PM与开发进行埋点需求评审，数据PM可旁听。
埋点应用
可视化数据大屏
数据大屏的视觉冲击力强，对于关注整体指标的领导层来说，大屏解决了他们快速掌握全局数据的需求，另外，如果常要接待其他单位或者到外面汇报、参展，动态数据大屏绝对是曝光度最高的产品。
开源数据展示工具
数据大屏满足了展示类需求，但是定制化一点的、操作类需求，数据大屏满足不了。这时可以考虑使用别的工具，其核心就是通过该工具平台，连接数据库，读取数据后进行展现，并且可以按照一定的维度，如日期、周期、item名称等维度聚合数据，形成一个个看板。看板里的单图支持源数据下载、和简单的SQL取数。能够解决略进一层的数据展示和分析诉求。
数据应用平台
数据终究要产生业务价值的，上面提到的数据展示工具，又无法以可视化形态做业务分析。因为数据需要结合具体的业务场景，然后选择成熟的分析场景，例如：事件分析、漏斗分析、留存分析、归因分析等，以及更深度的用户画像、精准营销，才能真正赋能业务。这类数据应用工具，目前已经有成熟厂商提供了标准化产品，如果公司规模没有达到自研数据平台时，建议采购。
数据仓库
数据采集、录入，最终会落入到数据仓库中进行存储和后续使用，成为数据仓库中的“弹药”。在2019年热门兴起的“数据中台”，去掉面子，里子其实就是一个数据仓库。数据仓库汇聚各业务端的原始数据，和主题数据，其建设过程是一个随着业务发展不断更新的过程。只是做数据的ETL本身并不是数据仓库的价值，其核心是能够收录好业务侧需要使用的数据，或者在业务侧提出新的数据需求时，能够快速响应。
按照数据仓库设计的经典三层结构：ODS层、DWD层、DM层，数据产品经理在数据仓库建设中的工作职责，是：
- 约定进入ODS层的原始数据的维度、周期；
- 定义DWD层主题宽表的字段、周期；
- 设计DM层应用表的字段、周期（需要结合具体业务，设计尽可能通用的主题表、应用表）；
- 设计监控方案，ETL过程中异常需告警，并及时告知数据应用侧有污染数据。
建立标准化流程
一般无特殊情况开发可参考下图：
某些特殊情况
相似场景是合并一个事件还是分不同的事件
示例如下：
| 事件设计 | 场景示例 | 说明 |
|---|---|---|
| 设计为同一事件 | 例如相似场景下的按钮点击可合并，不必一个点击一个事件，需合并为一个事件。 | 对于全局性的事件，我们建议设计为同一事件，通过特定的属性值对特定操作进行区分，而不是针对每一个操作设计一个事件。 |
| 设计为同一事件 | 例如：点击banner、点击热门活动位，都是点击首页的推荐位，可通过增加属性区分。 | 各事件所需属性相差不大，平时分析场景多整体分析。 |
| 设计为不同事件 | 例如一个内容平台，有视频，有文章，因视频和文章所记录属性差异较大，浏览内容详情应区分为浏览视频详情和浏览文章详情 | 各事件所需属性相差很大，分析场景多分别分析。 |
| 设计为不同事件 | 例如：收藏、浏览详情，虽属性差异不大，但是收藏和浏览业务关系不大，且通常为单独分析。 | 各事件所需属性相差不大，但平时分析场景单一分析，并且业务含义区别较大。 |
多重身份用户的设计
例如，在在线教育用户中，有多重用户身份，例如老师、学生、家长等，要做好用户属性的区分，对不同身份用户的属性进行不同的设置。
主被动事件的处理
在线上行为中，很多需要记录的埋点事件非用户主动触发，为被动触发，例如平台审核、发放优惠券、被其他人关注等，所以这种场景下不存在主动事件，主动触发行为的不是用户，用户是行为的接受者，被动受到影响。但是在分析需求比如审核通过率，需要提交审核-审核通过的主体ID为一人，此时被动事件的上报主体会影响到分析结果。
曝光事件的处理
和其他事件一样，只是曝光事件的触发时机需要注意，例如某平台内容曝光事件触发时机为：
- 内容露出全部，且feed流静止状态超过2s算曝光。
- 限制单一内容一次请求只会出现一次曝光（比如上下滑动屏幕，只要不刷新发生新请求，算一次曝光）。
注意 以上仅为示例，具体的规则可根据需求和研发的实现成本灵活变动。另外，需要注意的是，曝光触发事件量巨大，一般分析CTR，或者有推荐算法数据需求时需要曝光事件，其他场景请根据需求谨慎埋点。
虚拟事件
虚拟事件是对元事件的合并和拆分，是一个特殊功能。所以在事件埋点设计时，如果虚拟事件可满足，不必增加新埋点
社交数据采集方案示例
示例来源于火山引擎-增长平台
用户表
| 属性显示名 | 属性英文变量名 | 数据类型 | 属性值说明或示例 |
| 国家 | user_country | string | 中国，美国 |
| 省份 | user_province | string | 江苏省，New York |
| 用户注册时间 | register_time | int | 用户注册时间 |
| 用户最近一次登陆时间 | last_login_in_time | int | 用户最近一次登陆时间 |
| 性别 | gender | string | 男性/女性 |
| 年龄 | user_age | int | - |
| 年龄段 | user_age_interval | string | 年龄段：18岁以下、18-25岁、25-30岁、30-40岁、40-50岁、50-60岁、60-70岁、70岁以上 |
| 会员类型 | vip_type | string | VIP、SVIP、黑钻用户 |
| 财富等级 | wealth_level | string | LV1、LV2、LV3等 |
| 星座 | star_name | string | 12星座名称：白羊座、水瓶座、摩羯座等 |
| 学校 | school | string | ***大学 |
| 职业 | job_type | string | 职业名称：销售、教师、律师、编辑、创始人、分析师等 |
| 行业 | job_industry | string | 职业领域：零售、教育、金融、影视、文化、互联网等 |
| 是否被认证真实头像 | if_real | string | 认证/未认证 |
公共属性
| 预置属性 | 属性类型 | 展示名 |
| app_version | string | 软件版本 |
| device_model | string | 设备型号 |
| brand | string | 手机品牌 |
| os_version | string | 系统版本 |
| network_type | string | 网络类型 |
| network_carrier | string | 运营商 |
| app_channel | string | 渠道 |
| user_is_new | int | 新老用户 |
| resolution | string | 分辨率 |
| language | string | 系统语言 |
| app_id | int | app_ID |
| region | string | 系统国家 |
| app_region | string | 软件国家 |
| loc_city_id | string | 城市 |
| loc_province_id | string | 省份 |
| loc_country_id | string | 国家 |
| app_version_minor | string | 四位版本号 |
部分自定义事件
| 序号 | 事件名称 | 事件标识符 | 埋点触发时机 | 前端 / 后端 |
属性名称 | 属性标识符 | 属性类型 | 属性含义 |
| 1 | 页面浏览 | page_view | 用户浏览页面时触发 | 前端 | 页面类型 | page_type | string | 注册/登陆页面、配对页面、用户详细信息页面、聊天列表页面、社区页面、会员套餐详细页、直播页面、充值页面 |
| 来源页面 | page_source | string | 页面的上一级页面 | |||||
| 2 | 导航栏点击 | navigation_view | 用户点击下方导航栏任一按钮时触发 | 前端 | 导航栏名称 | nav_name | string | 首页、直播、消息、发现、我的页面 |
| 3 | 点击注册按钮 | register_success_click | 用户点击注册按钮时触发 | 前端 | 注册方式 | register_type | string | 手机号注册,微信注册,QQ注册,其他注册 |
| 4 | 注册成功 | register_success | 用户注册成功时触发 | 前端 | 注册方式 | register_type | string | 手机号注册,微信注册,QQ注册,其他注册 |
| 5 | 注册失败 | register_fail | 用户注册失败时触发 | 前端 | 失败原因 | fail_reason | string | 网络原因,用户名已存在,密码格式不正确,其他原因 |
| 注册方式 | register_type | string | 手机号注册,微信注册,QQ注册,其他注册 | |||||
| 6 | 点击喜欢 | like_click | 用户点击喜欢时触发 | 前端 | 是否是会员 | if_vip | string | 会员/非会员 |
| 是否有共同兴趣 | if_interests | string | 有/没有 | |||||
| 是否被认证真实头像 | if_real | string | 认证/未认证 | |||||
| 星座 | star_name | string | 12星座名称：白羊座、水瓶座、摩羯座等 | |||||
| 性别 | like_sex | string | 性别 | |||||
| 年龄 | like_age | int | 年龄 | |||||
| 年龄段 | like_age_interval | string | 年龄段：18岁以下、18-25岁、25-30岁、30-40岁、40-50岁、50-60岁、60-70岁、70岁以上 | |||||
| 职业 | job_type | string | 职业名称 |
预置事件
| 预置事件 | 事件标识符 | 属性名称 | 属性标识符 | 属性类型 |
| 应用启动 | app_launch | $预置属性 | ||
| session时长 | session_duration | int | ||
| 应用退出 | app_terminate | $预置属性 | ||
| session时长 | session_duration | int | ||
| 全埋点页面访问 | bav2b_page | $预置属性 | ||
| 全埋点元素点击 | bav2b_click | $预置属性 |
数据分析
数据分析种类繁多、样式复杂，下文介绍仅为冰山一角。
数据分析是指对收集的业务数据进行整理、处理和分析，以获得有关用户行为、业务指标和趋势的洞察和理解。数据分析可以帮助回答各种问题，如用户使用模式、转化率、流失率、用户细分、产品功能效果等。
用户数据收集是指通过各种方式和渠道收集和记录关于用户的信息。这些信息可以包括个人身份信息、行为数据、偏好、兴趣、交易记录等。用户数据收集对于许多组织和企业来说是重要的，因为它可以提供有关用户行为和需求的洞察，用于改进产品和服务、优化营销策略、个性化用户体验等。
数据分析可以帮助发现隐藏在数据中的趋势、模式和洞察，为业务提供有力的支持和指导。它可以用于预测未来趋势、优化业务流程、改进产品和服务、优化市场策略等。有效的数据分析可以提供有价值的见解，促使创新和业务增长。
数据分析的作用
描述性分析
故名思义，主要是对已经发生的事实用数据做出准确的描述。比如某企业订单履约率从上月的98%下降到了95%，属于偏基础类的工作；
诊断性分析
在知道了发生什么之后，更重要的是，我们要明白为什么发生。比如经过分析，发现订单履约率下降的原因是成品生产不出来，无法完成交付；
预测性分析
基于上述两个层次的分析，我们发现了其中的规律，即原材料供应商的送货及时率会影响成品订单的履约率。假如上月某原材料供应商A送货及时率只有70%，通过建模，我们可以预测本月该供应商会使我们的订单履约率下降2%；
处方性分析
有了预测性分析的结果后，我们无需再做事后诸葛亮，而可以运筹帷幄，在事前就采取措施。上例中，供应商A会导致本月我们的订单履约率下降，我们可能采取的措施就是把A换掉，但是现在有B和C两个供应商供我们选择，该选择哪个呢？通过分析和计算得出：选用供应商B会比选C的订单履约率高1%，因此建议选择供应商B。
数据分析方法
事件分析
事件分析是对用户触发的行为事件进行多角度分析。
按照小学时代的日记写作方法理解，叙述一件事情重要的元素是时间、地点、人物、做了什么、怎么做的、为什么做、做了多少，也就等同于5W2H模型。
一个用户行为事件=时间when+地点where+人物who（单个用户、用户群）+行为what（动作+动作对象）+工具how（设备、操作系统、语言等）+指标how much（统计事件的计量方式）。
由于用户的行为是动态的，所以在前端事件分析的结果会展示过去、实时现在、趋势未来。例如实时在线人数、实时交易额等；用曲线图展示事件的发展的趋势，以预测未来的变化方向；也能够统计事件总体情况。经过细化的分层，又能够对用户进行精细化的分组，以便于精准的用户运营。
经过对事件分析的总结，事件分析是所有分析方法的前提，捋清楚了事件分析的思路和各维度参数的含义，才能进一步的去了解其他的分析方法，特别是对用户行为和用户属性的理解，如何能够全量地进行分类和局部关键行为的概括。
分布分析
分布分析主要分析两种情况：
- 洞察用户行为分布规律；
- 观察不同维度（渠道、地区等）用户分布情况。
说到底分布分析就是事件分析中分层和分组的过程，是一种非连续性变量的统计分析方法，其目的就是为了进行层间和组间对比分析，以找到产品优化方向、甄别核心用户群、实时调整运营策略。
留存分析
一种用来分析用户参与情况/活跃程度的分析模型，考察进行初始行为的用户中，有多少人会进行后续行为，衡量产品对用户价值高低的重要方法。
留存分析较其他的分析方法，更侧重于分析产品对用户的意义，只有用户觉得产品帮助自己解决了某些问题、满足了自己的需求、或者功能用起来更便捷的时候才会延用下去，否则用户一定吝啬自己的时间和手机内存的。这也是验证用户需求分析是否到位，产品设计是否合理的关键指标。
漏斗分析
漏斗分析是对多个行为进行分析，并且这些行为不仅有先后次序的，而且是一个完整的复杂事件，对漏斗的每个行为我们都很关心
漏斗分析是需要先预设好漏斗步骤和窗口期，总的来说是设计好的转化漏斗和转化周期，一般情况是对核心事件的转化行为的一个衡量方法。
漏斗分析没有强顺序，中间可以重复步骤内的行为，也可以穿插步骤外的行为，只要在窗口期内完成漏斗步骤内的行为即可。例如：窗口期为1天，漏斗步骤为“A->B->C->D->E”，在用户触发A->B ，又回到A，再回到B或F，那么只会记录A->B一次，而F行为不在漏斗步骤内，则不参与统计。
漏斗分析是衡量流量转化、页面转化的高频数据分析方法。
从产品的角度来说：
- 核心转化行为的触达在预设的步骤中是否科学合理，是否能够让用户有效触发产品的核心功能。
- 产品的核心功能在用户使用时，是否达到简单快捷，从而提高转化效率？如果不是，那么卡在哪个环节，对该环节进行深入分析。
- 获得转化周期等等
从用户角度来说：
- 在每个漏斗步骤上，既有进入下一个步骤的用户，也有在这个步骤上流失的用户，从而对用户进行更细致的分群，也获得了忠实用户群和潜在用户群，对于精细化的用户运营提供了数据支撑。
路径分析
路径分析顾名思义就是用户在产品上进行操作的过程，有些地方会用“用户旅程”、“用户动线”词汇来形容用户路径。这好比是一种数字化方式来跟踪和监控用户的所有行为，从而可以得到频繁访问路径。和漏斗分析一样，目标还是为了提升关键模块的转化率。因此，路径分析需要得出最短路径、优化最低转化环节、跟踪主流路径。
路径分析主要分为三类：转化漏斗、智能路径、用户路径。
小结
每种分析是对立而又统一的，看似目的不同，但是又是相互补充，使得产品的成长获得全面的营养素。用户网络行为数据越来越庞大，充分挖掘数据的价值是数据分析的目的，不论使用的一般的统计方法，还是机器学习等模型算法，都是为了 理解数据
数据分析切入点
产品数据分析从以下几方面入手：1、功能交互数据分析，2、竞品调研，3、UGC数据，4、KPI数据。其中“功能交互数据”是比较细节的数据分析，能直接反应功能的好坏以及交互流程是否如预期。好坏和预期的标准都是依据自己设计这个功能的目标。
功能交互数据分析
功能交互数据是比较细节的数据分析，能直接反应功能的好坏以及交互流程是否如预期。好坏和预期的标准都是依据自己设计这个功能的目标。
比如交互流程优化，目的是想通过交互流程的优化提升点击率。所以在此目标下，需要看现有的流程每一步的转化情况，那么每一步的统计参数都要加。
分析方法：转化漏斗
功能交互类的分析效果好坏，主要用的就是转化漏斗。栗子依然是分享，可看哪步流失多，也可看是否减少步骤。比如很多网站或APP由原来的统一分享按钮变为分享渠道直接暴露，减少步骤一定是可以提升转化率的，因为每一个步骤都会有流失。
竞品调研
竞品的数据情况获取主要是以下几种方式：搜集资料、可通过技术手段获取、估算。
KPI数据
KPI数据很重要很重要很重要，因为这是你一季度、半年、一年的奋斗目标，所有的工作计划都围绕着KPI进行。有条件的话可以让技术同学将重点KPI数据做成日报，每天早上发你邮箱。
- 数据日报
数据日报是将你想要看的各种数据汇集在一起，方便提升产品工作效率的一种方式。除了各类数据项的当天数据，还需要增加对比前一天、前一周、前一月等增加下降的比例，这样才能有效分析。
- 流量（PV、UV、留存率）
大多数产品应该都是这两项，PV和日活跃用户数，APP应该还会有留存数据。这是最能直接反应网站或APP的情况，也是全年提升的目标。APP的UV就是日活跃设备数，网站的则是cookie。
- PV、UV
外部来源渠道，通过拆解来源渠道分析哪种上升哪种下降、哪种还可以提升拓展；留存率更多的是与push推送相关，好的push可以大大提升留存率
- 广告收入
时刻关注变现，有了钱钱才更有话语权。主要关注项：收入钱钱、各广告位CTR、RPM、广告物料返回率。CTR高能证明广告位置以及广告相关性较好；RPM，可用来估算广告的价值以及我们接入后的收益；广告物料返回率，只有返回了物料我们的接入才有效。
数据报告流程
挑几个点介绍一下
数据清洗
在工作中，90%以上的情况，你拿到的数据都需要先做清洗工作，排除异常值、空白值、无效值、重复值等等。这项工作经常会占到整个数据分析过程将近一半的时间。
如果在上一步中，你的数据是通过手工复制/下载获取的，那么通常会比较干净，不需要做太多清洗工作。但如果数据是通过爬虫等方式得来，那么你需要进行清洗，提取核心内容，去掉网页代码、标点符号等无用内容。
无论你采用哪一种方式获取数据，请记住，数据清洗永远是你必须要做的一项工作。
数据整理
清洗过后，需要进行数据整理，即将数据整理为能够进行下一步分析的格式，对于初学者，用Excel来完成这一工作就OK。
如果你的数据已经是表格形式，那么计算一些二级指标就好，比如用今年销量和去年销量算出同比增长率。鉴于你是第一次做数据报告，建议你不要计算太多复杂的二级指标，基本的同比、环比、占比分布这些就OK。
如果你收集的是一些非数字的数据，比如对商家的点评，那么你进行下一步统计之前，需要通过“关键词-标签”方式，将句子转化为标签，再对标签进行统计。
描述分析
描述分析是最基本的分析统计方法，在实际工作中也是应用最广的分析方法。描述统计分为两大部分：数据描述和指标统计。
数据描述：用来对数据进行基本情况的刻画，包括：数据总数、时间跨度、时间粒度、空间范围、空间粒度、数据来源等。如果是建模，那么还要看数据的极值、分布、离散度等内容。这次我们是零基础做数据报告，那么就不用考虑后一类数据了。
指标统计：用来作报告，分析实际情况的数据指标，可粗略分为四大类：变化、分布、对比、预测；
变化：指标随时间的变动，表现为增幅（同比、环比等）；
分布：指标在不同层次上的表现，包括地域分布（省、市、区县、店/网点）、用户群分布（年龄、性别、职业等）、产品分布（如动感地带和全球通）等；
对比：包括内部对比和外部对比，内部对比包括团队对比、产品线对比；外部对比主要是与市场环境和竞争者对比；这一部分和分布有重叠的地方，但分布更多用于找出好或坏的地方，而对比更偏重于找到好或坏的原因；
预测：根据现有情况，估计下个分析时段的指标值。
数据敏感性
数据敏感度是业务理解力、客户理解力、数据理解力三者的综合结果。很多人误以为数据敏感度只是数据能力强。事实上，要对数据敏感，业务理解力、客户理解力、数据理解力，三者缺一不可。因为数据只是对商业行为的客观描述，只有真正懂数据背后的意义，才能解读数据，才能挖掘数据背后的含义，才能形成数据敏感。
1）看到数据后，能一眼判断数据靠不靠谱，因为很多数据本身不靠谱，有指标口径问题、有数据质量问题，也有可能搞数据的人真的不理解业务，放了个风马牛不相及的数据。
2）看到数据后，能马上思考数据本身的商业意义，有人能快速定位数据背后的原因，并找到机会，有人眼里只是一个数字。对数据的解读基于对数据的理解，对数据的理解则基于对业务、客户、数据的理解。
合法化
最后最后，切记！用户数据的收集和使用应该始终遵循以下几个原则
合法性和透明度：用户数据的收集应遵循适用的法律法规，包括隐私保护法和数据保护法。组织应该明确告知用户哪些数据被收集，收集目的是什么，并在隐私政策或其他适当方式中提供相关信息。
最小化原则：仅收集与所需目的相关的最少数据。不应该收集不必要或无关的用户数据。
安全保护：采取适当的安全措施来保护用户数据的机密性和完整性，防止未经授权的访问、泄露或滥用。
用户选择和控制：用户应该有权选择是否提供他们的数据，并可以随时访问、更正或删除他们的个人数据。组织应该提供简单和透明的方式让用户行使他们的权利。
数据用途限制：用户数据只能用于事先明确指定的目的，并且不得超出合理的范围。数据不应该用于与原始收集目的不相关的用途，除非获得用户明确的同意。
数据共享与转让：用户数据不应未经明确的同意而与第三方共享或转让，除非受法律要求或有合法依据。
---------------------------
2023.06.06