代码实例分析报告 第1篇
在前面，我们已经介绍了代码埋点、可视化埋点、“无埋点”三种前端埋点方案，而也强调了我们一直推荐在后端采集数据。因此，在这里，我们觉得有必要比较一些可视化埋点、代码埋点与后端采集数据三种方案在数据获取能力上的差异，“无埋点”的数据获取能力与可视化埋点基本相当，在这里不再单独罗列。
(1) 代码埋点
原理：在应用App或界面初始化时，初始化埋点的SDK，在触发某个节点(如事件/页面)时调用SDK相应的方法，通过接口发送数据。通常为了减少用户上报数据时消耗过多流量，常见有两种解决方案：
(二) 非即时发送数据，将多条数据压缩打包，等待网络状况良好、或定时(5min)发送至服务端。
代码实例分析报告 第2篇
本文对diamonds数据集进行探索性分析，并做数据可视化处理，探索钻石的价格、重量分布，及钻石价格与重量、形状、切割状态、颜色、透明度之间的关系。接下来，进行非参数检验，探究不同切割类型、颜色和透明度的钻石，价格是否具有显著性差异。最后，利用钻石的各项属性，建立多元线性模型，对钻石的价格进行预测。
由探索性分析可知，
在钻石的重量分布上， 0 − 0−0.5克拉的钻石最多，超过 1.5克拉以上的钻石逐渐变少。
在钻石透明度上，I1（最差） ，SI2，SI1，VS2，VS1，VS2，VS1，IF （最好）。观察其统计数据，发现钻石透明度一般的占比最高，钻石透明度最差和最好的比例都比较低。
理想切割及优质切割的钻石占比超过一半以上。联系现实原因而言，因为钻石为奢侈品，切割水平高可以使钻石达到更好的视觉效果。所以理想切割及优质切割的钻石占比较高。
钻石总深度百分比及顶部相对于最宽点的宽度均符合正态分布。
本文建立了预测钻石价格的多元线性模型，响应变量为price，预测变量为数据集中除price之外其他变量，模型均方误差为 0.2606446（价格已取对数）。下一步可考虑使用交叉验证对模型参数进行调整，取最优方案对钻石价格进行预测。
代码实例分析报告 第3篇
在应用中嵌入SDK，通过可视化方式(即上文可视化埋点方式)，针对对象进行定义，服务端对定义的数据进行分析，后台加以展现。
优点：
缺点：
(一) 缺点与可视化埋点相同，未解决个性化自定义获取数据的问题，缺乏数据获取的灵活性；
(二) 企业针对SDK开发难度较大，一般由数据分析企业研发提供，使用第三方提供的埋点方案，有如下缺陷：
1、数据源丢失，应用上报的数据上传至第三方服务端，可能造成企业泄密或用户的关键数据丢失；
2、供应商数据丢包问题，无法根据应用特性进行改善。
(1) 当前流行的第三方数据产品体验
(一) Umeng，阿里旗下的数据分析产品，通用性功能均有覆盖，在部分特定页面上有缺失，定制化弱，适合初创起步的企业应用。
(二) Google Analytics，个人使用体验较好，对个人网页、应用所需的数据埋点都能满足，对数据结果展示较为喜欢，缺点是需翻墙查看；
(三) 神策数据。位于上海的神策公司，可根据企业部署特定服务器，针对个性化定制，并且有对应业务员、开发工程师进行企业一对一对接，服务体验较为良好；但数据分析后台非工作范围内，未详细体验、研究过；
(四) 诸葛io，国内领先、先行的数据分析公司，2013年是国内首家最早推出无埋点方案，但有运营朋友说丢包较为严重，未确认翔实与否。
其他较为知名的数据产品：TalkingData、Mixpanel未使用过，希望有大神分享，或之后使用后补充。
最后的叮嘱，数据埋点团队一定要留好数据埋点的规范定义文档，若发生团队埋点相关负责人离职，就会形成大坑。
Ps：其他思考问题整理如下：
(1) 为什么上报的数据颗粒级最好是“原子”最小化上报而非关系链上报？
虽然关系链上报对于还原用户的真实操作非常方便，服务端根据用户访问的时间序列，将事件串联，一步步分析，对于关系跳转挖掘很是方便；但对于快速迭代的应用产品，一旦产品相关逻辑变动，则所有业务分析(服务端)、逻辑关系(前端)须重写，对于前端-服务端都将是巨大的人力投入，以及新老版本的数据关系链冲突问题。
(2) 需要有专门负责人长期且稳定对代码埋点方式进行“买单”
一旦数据进行埋点，且产品运营形成数据量化结果、以数据驱动决策的习惯后，则必须进行持续维护。因为数据埋点研发团队，需花费较高的人力资源；测试点位时，要求完整覆盖性测试，确保无遗漏。
参考连接：