数据埋点方案
数据埋点方案分为三个部分
- 触发条件的设置
- 映射关系的管理
- 采集上报的规则处理
神策数据埋点方案学习
对于神策数据来说，底层数据模型用的是"Event+User"的事件模型，因此埋点在神策数据这里称为事件。埋点需求文档称为事件设计。
事件(埋点)设计的三个核心
- 将事件拆分成用户单个的点击和浏览动作
- 将需要分析的目标动作转化成事件
- 结合分析的业务目标，设计事件
1.数据模型
传统互联网时代用Page View(网页浏览量)来进行产品分析，衡量产品好坏，但现在PV已经远远无法满足产品和运营人员的要求了。
- 每个产品有其独特的衡量指标，例如对于一个视频软件来说，视频播放量比较重要，而对于一个电商App来说，商品浏览量和下单量比较重要
- PV过于粗粒度，现在的产品需要更加精细的分析
事件模型就可以更加契合当前产品的要求。
事件模型包含五大要素：
- Who:用户是谁，用唯一ID来标识用户，对于登陆用户，用后台的标识，对于未登录用户，用设备号、cookie等等
- Where:事件发生的位置，根据不同的需求来记录事件发生的位置，可以是通过GPS定位得到的地理位置信息，或者粗粒度的国家、省份信息，又或者具体到某个小区的信息等等。
- How:用户从事事件的方式，这里的概念比较广，可能包含用户的设备、用户使用的浏览器、操作系统的版本，渠道等等。
- When:事件发生时间
- What:根据不同的事件记录不同的信息，例如搜索事件，记录搜索关键词、搜索时间、搜索类型等等，又例如加入购物车事件，记录加入的商品和商品类型等等。
2.客户端埋点VS服务端埋点
神策数据建议在服务端埋点，理由如下：
- 很多事件在前端拿不到完整的信息，而后端通常可以获得最全的信息
- 服务端埋点方便快捷，而App端每次都需要发版后才能增加新的埋点事件。
- App端埋点有丢失风险，为了节省用户流量，App端一般都是在网络环境良好时，应用程序位于前台时，才会将数据上传，这就有可能导致数据不及时或者丢失的情况。
2.结合场景设计事件
例如提交机票和提交门票订单，在设计事件时是否设计成同一场景还是分开处理？
两种设计思路：两者场景相差不大且分析场景时通常会整体分析，可以设计为同一事件；各事件场景相差很大，分析时多场景分析，可以设计为不同事件。
3.Session分析
对于网站而言，用户的一系列行为，是一次访问，称为一次Session.
对于用户行为我们一般记录4W1H模型：Who谁在访问，When什么时候访问，Where地点，What用户在做什么，How如何访问的
基于这样的用户角度的行为记录，无论是一个商场，还是一个网站，商家都能知道用户做了什么，比如什么时候进入网站，什么时候买了什么东西等等。
但对于一些类似这样的需求，例如用户平均会来几次，平均每次停留多长时间，平均每次逛了几个页面等等，这些需要连续性消息的分析，就需要将用户的单点行为串联成一个整体。
Session分析中的重点包含两个方面，
Session应该包含哪些行为事件
Session如何切割：设置切割时长，即相邻事件之间的间隔大于时长，则进行切割。
例如一个用户首先打开了电商网站首页，然后进行了搜索，进入了商品页，最终将商品加入购物车，产生订单，最后支付订单等等。
传统统计工具只会采集页面浏览动作，所以Session的组成只包含首页、商品页和订单页三个事件，而神策数据可以采集全部的事件，包括首页、搜索、商品页、加入购物车等等，所以在计算用户在商品页的停留时长时，可以将加入购物车时间与商品页时间相减，得到准确的停留时长。
传统统计工具中的切割时长是固定的，例如PC端是30分钟,APP端是1分钟，假设用户打开首页后，切换至后台，再经过一定时间回到APP,例如两分钟，则此时Session被切割成两段，打开首页的那次切换停留时长为0，而切割时长根据业务、行业的不同而需要相应调整，神策数据提供了切割时长的配置。
例如对于视频网站而言，假设Session切割时长为30分钟，当一个用户先浏览了网站10分钟，然后打开了一个视频，边与女朋友打电话边看视频1个小时，结束通话后又继续浏览网页。
这时计算用户的Session时长就会偏短，记录深度不足。
而如果此时Session的切割时长为40分钟或者1个小时时，则能更加真实体现用户的访问情况。
