数据采集

数据采集方式

线下

行业数据报告、问卷调查、用户访谈、市调调研等

线上

1、APP端：数据埋点

埋点：在用户使用产品的过程中，对他们的一系列行为数据进行收集，以优化产品和运营
而大多产品自带服务和盈利性质，那么想要实现转化，引导购买就需要将“点”埋到具体的交互组件上，然后对PV、UV、停留时间、跳出率、购买率等指标进行量化

代码埋点

应用程序集成埋点sdk后，在启动的时候初始化埋点sdk，然后在某个事件发生的时候调用埋点sdk提供的方法来触发事件 优点：可以精准控制埋点位置；可以更方便、更灵活地自定义事件和属性；可以采集更丰富的与业务相关的数据；可以满足更精细化的分析需求 缺点：前期埋点成本相对较高；若分析需求或事件涉及发生变化，则需要应用程序修改埋点并发版

全埋点（无埋点、无码埋点、无痕埋点、自动埋点）

无需应用程序开发工程师写代码或者只写少量的代码，即可预先自动收集用户的所有或者绝大部分的行为数据，然后再根据实际的业务分析需求从中筛选出所需行为数据并进行分析 优点：前期埋点成本相对较低；若分析需求或事件设计发生变化，无需应用程序修改埋点并发版；可以有效地解决“历史数据回溯”问题 缺点：由于技术方面的原因，对于一些复杂的操作，很难做到全面覆盖；无法自动采集和业务相关的数据；无法满足更精细化的分析需求；各种兼容性方面的问题

可视化埋点

在全埋点部署成功、已经可以获得全量数据的基础上，以可视化的方式，在对应页面上定义想要的页面数据，或者控件数据 场景： 默认情况下，不进行任何埋点，然后通过可视化的方式指定给哪些控件进行埋点（指定埋点） 默认情况下，全部进行埋点，然后通过可视化的方式指定哪些控件不进行埋点（排除埋点）

2、网页端：网络爬虫

人工确定爬取信息的维度→分析目标网站URL构成→确认爬取工具→编写程序语言→获取数据→保存于本地→后续进行数据挖掘

数据埋点

埋点工作流程

• 梳理业务方需求
• 确定埋点需求
• 评估埋点合理性
• 开发测试上线
• 建表维护：事件、类型、位置、触发行为、参数、备注等

  埋点分类

  1、前端埋点
  包括但不限于APP客户端、H5、微信小程序、PC网页，是指对具体的功能场景（如加载成功、浏览、点击等）进行明确的定义，由前端触发，采集上来的数据，相比于全埋点，更准确、稳定，且通过变量字段，能够实现更细颗粒度数据的拆分、聚合和下钻
  2、后端埋点
  触发了服务端接口调用（如：接口回调成功触发）的事件埋点，如最典型的注册成功事件、付费成功事件。后端埋点对数据的准确度要求更高，同时也可以通过变量字段的扩展支持数据拆分、聚合和下钻。需要强调的是，后端埋点一般采集的是已登录状态下的用户行为，如果想使用后端埋点事件作为流程分析的其中一环（如漏斗分析），则可能出现未登录的用户会漏掉的情况

  埋点文档

• 序号
• 事件名称：为统计事件命名，例如：商品详情页分享按钮点击数
• 事件英文名
• 事件类型：比如点击事件、浏览事件
• 事件ID：每一个埋点都对应唯一一个事件ID，可以通过事件ID去后台取数使用。事件ID的命名规范各个公司不一样，但一定要明确详细，通过限制区分保证页面ID的唯一性和有效性，可参考：页面功能动作_类型
• 事件位置：用于描述X产品形式X功能模块内的X位置，比如APP商品详情页分享
• 事件触发规则：定义什么情况下触发埋点，例如：在商品详情页点击一次记录一次
• 事件描述：每一个完整的页面埋点或者按钮点击的埋点都需要加一个描述字段进行业务解释
• 属性值类型：字符串、时间、日期、string、数值
• 属性值说明
• 埋点形式：前端、后端
• 备注：用于描述当前埋点：什么时间新增（谁新增）、什么时间修改过（原因、谁修改）、什么时间被删除（原因、谁删除）等信息记录，为了信息的完整性和可追溯性最好每一次变动都要备注

埋点检验

统计到一些功能的详细数据，用来验证这个功能/项目对关键指标是否真的有帮助，或者是否还有提升的空间

• AB测试
• 灰度测试
• 直接发版