标签：自动 存在 联网 联系 list 脚本 完成 用户 item
用户行为分析在现在这个时期已经是一个比较常见，使用很广的一个词，在互联网公司，有大数据团队的基本上都会提供这样一套分析系统，以及近年来也出现了很多专门提供这类服务的公司，提供用户分析，分群分析，用户画像，智能运营等。在运营产品中也经常会听到这一类的概念，术语，指标等。下面主要介绍我所接触到的内容。
用户行为分析采用的数据模型是比较常见或者业内的一个通用的概念，事件行为+用户基础信息。用事件event表示用户的一个行为操作，用事件中的众多属性表示用户一个行为的细节描述。
简单概括，何人(who) 何时(when) 在何处(where) 用何种方式(how)做何事(what)
what何事可以用事件event表示，何人who就是用户标识ID可以进一步关联用户基础信息，何时就是事情发生的时间，何处where发生的地点可以用属性表示，何种方式how也可以用属性表示，类推。
所以数据模型可理解为：用户行为 = 事件 + 属性(众多) + 用户ID。只要拥有最全量的事件数据便可做到你想要的分析。多维度，多条件，多模型的分析。
埋点一般分为可视化/全埋点/无埋点，和代码埋点。这两种各有优缺点，这里只做一个简单的介绍，第一种下面就统称为全埋点。
全埋点是前端的一种埋点方式， 在产品中嵌入SDK，最统一的埋点，通过界面配置的方式对关键的行为进行定义，完成埋点采集，这种是前端埋点方式之一。
优势：
可视化展示宏观指标，满足基础分析需求，如PV，UV，每个控件的点击联系
使用和部署较简单，只需要嵌入SDK，避免了很多因为需求变更，埋点错误等导致需要重新埋点（这个深有体会）
用户友好性强，触发埋点之后自动向服务器发送数据，避免人为失误
劣势：
作为前端埋点会存在一些天然的劣势
只能采集用户交互数据，对于一些关键行为还是需要代码埋点
兼容性问题
数据采集不全面，传输问题，时效性，数据可靠性
代码埋点，这个也是目前我们使用的埋点方式，代码埋点分为前端代码埋点和后端代码埋点，前端埋点类似于全埋点，也需要嵌入SDK，不同的是对于每个事件行为都需要调用SDK代码，传入必要的事件名，属性参数等等，然后发到后台数据服务器。后端埋点则将事件、属性通过后端模块调用SDK接口方式发送到后台服务器。
我们采用的是代码埋点，分为前后端。埋点是一个特别重要的过程，它是数据的源头，如果数据源头出现问题，那么数据本身就存在问题，分析结果也就丧失了意义。
由于我负责日志检测，也就是埋点后的事件日志的检测告警，并通知对应的埋点开发人员，运营方，产品方，所以也就遇到了过其中存在的很多坑，大部分是流程方面的。
事件属性是有一套元数据管理系统，业内的一些服务也是这种结构。一般是先定义事件、属性，后埋点的方式，原因是事件日志数据是需要经过检查的，需要检查事件是否存在，属性是否缺失，数据是否正常等等。
遇到的坑：
运营产品未定义，开发便已经埋点上线
运营产品和埋点开发的需求文档有问题或者沟通问题或开发未按照规范
导致事件对不上，属性字段对不上，缺失或格式存在问题
开发埋点漏埋点，埋点不全，或者埋点逻辑有问题出现重复埋点，出现重复数据
属性数据对不上
元数据定义，运营人员的理解和给开发的需求以及开发的理解可能不对应，但最终检测逻辑只会按照定义的情况判断
数据不对，这种情况很难检测出来，需要运营产品在分析中发现，这也是就难受的一点
事件数据是存储在机器上的日志，这里的采集是指将机器日志文件存放到HDFS系统中的过程。业内有很多这种采集功能，filebeat，flume，Python脚本等都可采集。当前前面说的事件埋点也可以算是数据采集中的一部分
ETL，将事件日志，一般都是json格式的日志进行解析，写入hive库中，事件表中，这里就不做过多说明了
这部分属于分析功能，也是我主要负责的部分。业内常见的分析模型有事件分析，漏斗分析，留存分析，路径分析，渠道分析、分布分析等等。目前实现了前面四种、事件、漏斗、留存、路径
标签：自动 存在 联网 联系 list 脚本 完成 用户 item
原文地址：https://www.cnblogs.com/lrxvx/p/13381111.html
