13518219792
android埋点主要是为了采集数据，
站在用户的角度思考问题，与客户深入沟通，找到坡头网站设计与坡头网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：做网站、成都网站制作、企业官网、英文网站、手机端网站、网站推广、域名注册、网络空间、企业邮箱。业务覆盖坡头地区。
ab测试也需要在移动/h5上埋点采集重点业务数据，
这样测试才能有的放矢，吆喝科技的AppAdhoc
AB Testing可
以实现快速简单的android代码埋点。
加入XCode工程，实现基本使用 导入SDK 下载Analytics_iPhone_SDK_1.6.4.zip并解压缩 解压缩之后可以看到如下2个文件: MobClick.h libMobClickLibrary.a 我们在编辑SDK时，使用的设置为 Base SDK：iOS 4.2，iOS Depolyment Target: iOS 3.0，因此该版本的SDK支持从iOS 3.0 ～ 4.2的设备使用，在工程中引入友盟统计SDK时，推荐设置Base SDK为最新的iOS SDK最新版（当前最新版为iOS 4.2)导入插件 请在你的工程目录结构中，右键点击Classes文件夹，选择Add-Existing Files...选择这两个文件。或者将这两个文件拖入XCode工程目录结构中，在弹出的界面中选择Copy item
一，神策埋点
// 集成神策
[self initSensorsAnalyticsWithLaunchOptions:launchOptions];
2.集成友盟
//集成友盟
[UMConfigure initWithAppkey:@"5d54c7fa4ca3573ff2000f66" channel:@"App Store"];
[MobClick setScenarioType:E_UM_NORMAL];//支持普通场景？？
//开发者需要显式的调用此函数，日志系统才能工作
[UMCommonLogManager setUpUMCommonLogManager];
在继承模版里的生命周期中编写，
}
电商类APP列表页，用户上下滑动，列表页中的item显示在屏幕中，此时数据分析上来看，item的显示（比如滑动停止或者停止1s），都认为是一次数据的曝光，此时会根据曝光率（曝光率= 点击量 / 曝光量）来分析用户（比如用户的喜好推荐数据的统计）
willDisplayCell 和cellForRowAtIndexPath对比：
先执行cellForRowAtIndexPath再执行willDisplayCell，cellForRowAtIndexPath一半用于 数据填充 ，willDisplayCell可用于 自定义分割线 ，对于实时性的埋点曝光统计，可用willDisplayCell方法实现。
UIScrollVIew 停止滚动的类型分为三种：
对于滑动停止这种条件性的曝光埋点，可用UIScrollVIew滑动停止的方法实现。
对于条件性曝光埋点，采用UIScrollVIew滑动停止方法实现，具体曝光条件是
上报时机就是监听滚动停止事件，做相关的埋点上传处理
这里可以根据获取NSIndexPath的数组的cell，获取对应的NSIndexPath的CGRect，这里我们的列表是竖着滑动，我们只获取cell的origin.y和size.height这两个属性
根据上面视图，cell可见可分为三类：
currentRect = tableView.convert(previousCellRect, to: self.view.superview)
计算相对于屏幕本身的rect属性
埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。
数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的操作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：
规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。
当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。
在埋点的技术方案中，首先要重视的，是用户唯一标识的建设。如果做不到对用户的唯一识别，那么基础的UV统计，都将是错误的。
因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID+用户ID。设备ID代表用户使用哪个设备，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，浏览器的Cookie，小程序的OpenID等。用户ID，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。
当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID，来识别出谁在对设备做操作。
其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：服务器日志、URL解析及JS回传。
浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。
除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线操作监控等，但原理都基于上述两类日志，只是在统计上有所区分。
再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较差，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的事件，“事件”是客户端日志行为的最小单位，根据类型的不同，可以分为页面事件（类比页面浏览）和控件点击事件（类比页面交互）。对于页面事件，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。
页面事件的统计主要统计如下三类信息：
埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。
有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。
笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。
第一步，需求评审。
前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。
以前文提到的4W1H模型为例，常见的记录内容如下：
最后我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。
第二步，埋点申请
当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、抖音，超级APP会承载非常多的业务，因此技术方案上会十分统一。
因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。
第三步，技术开发
当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和事件埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。
第四步，埋点验证
埋点的验证很关键，如果上线后才发现问题，那么 历史 数据是无法追溯的。
验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。
实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：
除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV，行为、事件的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。最后，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
ios埋点主要是为了采集数据，ab测试也需要在ios上埋点采集重点业务数据，吆喝科技提供的AppAdhoc
AB Testing可实现快速简单的ios埋点。
