6.1 APP

6.1.1APP下载监测的方法和最佳解决方案

APP用户来源追溯方法有多种的，不同的分类方法可能得出不同的数量，在本节，首先介绍国内跟踪的现状和常用的原理，让大家在选择第三方工具的时候心里有个底。

1．国内跟踪的现状

由于Google Play不能在大陆使用，现在国内安卓应用市场是百花齐放，这给跟踪增加了不少难度。在正式进入正题之前，我们先来了解一下广告主和APP下载跟踪的整个流程，看这个流程主哪些参与者能够获取数据，如图6-1所示：

图6-1 广告主和APP下载跟踪的整个流程

首先是广告主，广告主通过广告平台去投放广告，吸引用户单击跳转到应用市场下载APP，然后用户激活使用，在这个过程中，广告平台可以知道广告的展示和单击，应用市场可以知道下载，最终的激活这个数据就需要做跟踪才有的，激活的数据可以传递给前面不同的几个参与者，如应用市场，这个通常是操作系统本身才有的，如苹果的APP Store和Google的Google Play，另一个是广告平台的，广告平台有些是用于目标优化或使用Look alike这个功能，需要回传一些数据，最后一个就是广告主的，非常关心整个流程的转化、投入产出、ROI等，一般会使用第三方工具做监测，也就是我们这本节要讲到的。

目前手机操作系统主要是Android和IOS，虽然仍有部分使用微软的WP（Windows Phone，简称WP）或其它Linux类的操作系统，但主流是安卓和苹果，可以说，手机系统，不是安卓就是苹果了。这两个系统对应的跟踪方法有如图6-2所示：

图6-2 Android和IOS对应的跟踪原理

安卓的话，官方有个应用市场Google Play，一般内置在系统里面，国外用户下载APP都是通过Google Play下载，APP的跟踪继续沿用WEB的逻辑，Google Play能够传递传递Referral参数，能够跟Google Analytics无缝对接。

但是在国内，由于谷歌的这部分服务不能在大陆使用，国内的用户无法使用Google Play，这个机遇催生了很多的应用市场，这给跟踪带来的一定的难度，目前采用主要形式是渠道包，也就是每个渠道打一个包，内嵌一个ID，通过ID去识别；另一种方法是模糊匹配了，这个是比较少用的。

IOS的话，绝大部分的用户下载APP都是通过APP Store，只有部分越狱用户通过第三方市场去下载，现在越狱的已经很少了，所以这里主要讲解APP Store的跟踪方式，IOS是个比较封闭的系统，所以你能跟踪什么，能跟踪多少，取决于苹果开放了多少，目前苹果主要有3种跟踪方式

1）IDFA IDFA就是广告标示符，广告平台将用户的IDFA回传给第三方工具，用户下载后激活APP是也会回传IDFA，两者再进行匹配，这是目前主流的跟踪方法。

2）Cookie 用户单击推广链接的时候，链接上有广告参数，App在后台打开Safari，然后将链接上的广告参数写入到Cookie，然后跳转到App Store下载，用户打开APP的时候，会沿用之前的Cookie，实现广告参数的传递与回传。

3）模糊匹配，下载激活前后获取用户设备的指纹，如IP、User Agent、 IDFA等，然后使用算法进行匹配

2．跟踪原理详解

所有的应用下载平台都会有提供下载数据的，但大部分的应用平台提供的数据比较简单，不能做详细的分析；其次是平台只提供该平台的数据，不能从宏观上看APP的下载情况，以及下载后面的转化，行为等；最后就是下载平台的数据可能造假，营造用户多的假象，吸引更多的开发者上传APP和用户去下载该平台，总之，平台既是运动员又是裁判的节奏，总觉得不靠谱，所以需要使用第三方工具去监测。

下面来看看每种方式的具体实现原理,首先来看看安卓平台的。

（1）Android—Google Play

Google Play的广告参数传递有一个完善的机制，这个机制也可以被第三方工具使用个，我看到国内有些工具也对这个原理做了测试并开发出监测工具，下面以GA讲解Google Play如何实现广告参数传递的，原理如图6-3所示：

图6-3 Google Play的广告参数传递原理

首先是用网址构建器对APP的下载链接添加广告参数，需要注意APP的网址构建器跟Web的网址构建器是不同的，APP带有特别字段Referral，而且中间还会带编码，所以需要通过特殊的网址构建器去生成着陆页。Referral后面的参数就是用来区分广告系列的一系列参数，用户在从Google Play 下载APP的时候，BroadcastReceiver会发送一条带有Referral的广播给APP，用户打开APP的时候，前面的广播就会发给GA，GA的接收器就接收到这个Referral，这个用户就带上了对应的渠道标签了。

GA 和Google Play都是谷歌的产品，整个过程可以无缝链接的。

（2）Android—国内应用市场

众所周知 Google Play 无法在中国使用，所以国内 Android 市场被数十家应用商店如豌豆荚、百度助手、酷市场、360手机助手等占领，应用市场可以分成两个阵营，一类是大型互联网公司，如腾讯的应用宝，百度的手机助手，360的360应用市场，另一个阵营是手机厂商的，如华为，金立，Vivo，Android 渠道追踪主要围绕上述渠道展开。一般是采用内嵌ID的形式去跟踪，原理如图6-4所示：

图6-4内嵌ID的原理

具体来说就是开发者为每一个渠道生成一个渠道安装包，不同渠道包用不同的 Channel ID （渠道标识）来标识，这个ID一直跟APP绑定；当用户下载了 APP之后，ID会随相关的数据发送回来，从而实现渠道的识别。

这种方式完全是为了适应我们的特殊情形的，如果要上传的应用市场多的，意味着需要打很多的包。

这种方法有个天然的缺点，就是只能定位到应用市场，不能做更细的广告系列划分。

（3）Android—模糊匹配

安卓平台的模糊匹配跟IOS的模糊匹配的原理是一致的，这部分放到IOS里面讲，基本上模糊匹配不会用在安卓上的，因为可行性很低。

IOS的发行渠道则与安卓有很大的不同，除了少数越狱的机器之外，大部分用户的APP都是从 App Store下载的。iOS的“渠道”其实通常是指那些在其它APP者网页内部，提供到App Store的链接的页面。因此，在IOS中追踪发行渠道，主要是追踪进入App Store相关页面的渠道信息。

但IOS的渠道追踪面临着一道无法逾越的鸿沟，正因为IOS的渠道分发都有跳转到App Store这一步，对于整个流程的可以分为三个步骤：在某个渠道单击下载链接并跳转到App Store > App Store内下载App >用户激活App，而苹果本身是不会提供太多信息给开发者，这整个过程能获取到的信息的多少。取决于苹果开放了多少。目前苹果提供以下三种方式去跟踪：

（4）IOS—IDFA

通过IDFA进行追踪：IDFA 的全称是 Identifier for Advertisers ，即广告标识符的含义，这是苹果专门给各广告提供商用来追踪用户而设的标识。这个方案一般用在APP里面打开下载链接这种推广方式。通过非APP投放广告也是可以跟踪到的。具体的原理如图6-5所示：

图6-5 IDFA跟踪原理

原理是：广告主在不同的媒体平台上投放广告的时候，媒体（例如微信，这里就是媒体1，2,3）会详细记录哪个IDFA单击了推广APP的链接，如果APP有打开激活，那么APP也会记录具体的哪个IDFA激活了推广APP，两者都将记录下来的IDFA上传至指定的服务器，进行对比匹配，即可确定下载来源。在用户不重置系统，不还原广告的情况下，这种方式精准度比较高。

这种方式依赖于媒体平台回传IDFA，如果媒体平台不提供，那么自然就跟踪不到。

GA跟踪在IOS系统的跟踪是通过IDFA去跟踪的，在GA里面需要开启IOS的广告跟踪功能，单击GA中选择“管理”→“媒体资源”就可以看到如图6-6所示：

图6-6 IOS广告系列跟踪

剩下的就是开发者去部署SDK了。

（5）IOS—Cookie

基于Cookie的方式，iOS 9中新增的SFSafariViewController，这个类的API允许在APP内打开一个Safari浏览器，而不是一个APP内部的Webview。这个APP内的Safari和外面系统的Safari是同一个，共享同一个沙盒，可以操作同一个Cookie，也就是说它可以跨App与Safari实现共享Cookie，具体原理如图6-7所示：

图6-7 基于Cookie原理

基于SFSafariViewController控件，当用户在APP中通过它打开渠道页面时，我们可以将渠道信息写入Cookie中，并设置生效时间。当用户安装并激活 App后，再次使用SFSafariViewController上报激活信息，同时将Cookie中的渠道信息上传，通过匹配，便可确定下载来源。由于渠道信息保存在设备本地，因此匹配是100%准确的。

但是基于SFSafariViewController这种方式也有一定的弊端：首先，这个方案只能支持iOS9及以上版本的设备，但覆盖了绝大部分用户，此外，对于目前业界主流的一些推广渠道，如微信、朋友圈，它们尚未在App中使用SFSafariViewController控件访问网页，因此这部分渠道也无法使用精准匹配的方案。

（6）IOS—模糊匹配

图6-8 模糊匹配原理

模糊匹配，原理如图6-8所示，单击下载链接，会跳转到App Store页面，这个过程会触发一个服务端的请求，服务器来记录这次单击的设备信息，包括IP地址、机型等。同时，被推广App这边，也可以记录用户激活APP时机器的一些基本信息，并上传至服务器。结合下载和激活的时间差，再结合设备的IP地址和机型等信息，通过算法可以识别出同一个用户先单击了下载链接，再激活了App，从而确定下载渠道。这种方式的精确度取决于前后两次数据收集的完成程度和算法。

市面上的做法有的是上述三种方式单一出现，有的是两两组合，总之不管是通过哪种方式，这都是我们想象出来的间接的方式，只能说是尽量的去接近准确，但不能做到100%准确

。

（7）越狱的

参考Android的内嵌ID/渠道打包

3.各自优缺点及国内可选的方案

下面来看看各种跟踪方式的优缺点，如图6-9所示：

图6-9 各种原理的优缺点

Google Play的UTM跟踪方式是非常精准的，缺点是做国内市场的应用不适用。

国内应用市场一般是采用渠道包的形式，缺点是只能跟踪到应用市场级别的数据，不能继续细分。

对于IOS而言。

IDFA的准确度是非常高的，但是用户可能会关闭IDFA权限，重置系统、还原广告，数据会丢失；

Cookie的准确度也是很高的，但是IOS9以上适用，微信公众号广告、朋友圈广告仍然无法实现追踪；

模糊匹配，这的很多厂商都在使用的一种方式，都强调倒高识别率，但是这个严重更依赖于两次收集的数据与算法；

一般来说数据会是IP、User Agent、 IDFA等信息，基本上，按优先级来说，第一个信息就能够匹配掉很高的比例了，收集多一个字段的信息，能够匹配更多，如IDFA已经能够匹配八成的用户了，如果你用算法，可能是9成，也可能是6成，这个看你算法选型和调参的能力的，对于大部分人来说，这个是黑匣子的，即使第三方工具只是做了一个简单的优先级去匹配，然后对完宣称通过大数据，人工智能的方式去匹配，你也不知道的。

4.各工具跟踪方式对比

下面看看几个工具的采用的跟踪方式，如图6-10所示，下面的数据主要是通过官方网站去找的，可能存在部分工具已经对跟踪方式做了优化调整的了，只是作为参考。

图6-10 各工具跟踪方式对比

Google Analytics 采用Referral和渠道包的方式，两种方式都有，所以国内也是可以用的，IOS的话是采用IDFA的方式

Adobe Analytics IOS端采用模糊匹配的形式

Umeng的安卓采用渠道包，IOS采用模糊匹配

GrowingIO 安卓是采用IMEI，苹果的话是优先采用IDFA，如果这个为空就采用模糊匹配

诸葛IO安卓采用的是渠道包，IOS的话有限采用IDFA，其次是IDFV，IDFV是提供给APP开发者的唯一标示。

神策的话，安卓采用渠道包方式，IOS的话是采用Cookie和模糊匹配的形式

可以看到后面的三家，在IOS的跟踪上都是采用两种方式的节奏，尽可能的去匹配准确，具体效果怎么样，只有它们知道了。

你要问哪种哪种比较准确，我也不知道，我只能说，目前各第三方工具爆出来的数据，很多是公关数据，就高不就低的。

5.关于如何选型的：

预算够的，找有售后服务的，有问题，找乙方处理；免费的找功能强的，用户群多的，遇到问题容易解决；只是看看数字，随意用个第三方工具就行。

6.1.2APP用户行为监测：埋点与事件监测

1.什么是埋点？

埋点就是定点，定时的数据采集，跟踪用户行为，给后续的产品优化和用户运营提供数据支持。

更通俗一点就是，你为采集数据所做的部署就是埋点，如用户的单击，屏幕的浏览，这些都需要预先做一些部署，这些部署通常是实现什么时候触发，什么时候发送什么数据，这样才能采集到这些数据，这些部署工作就是埋点。

2.埋点方案的选择

根据部署的位置可以分为客户端埋点和服务端埋点，而客户端埋点可以根据埋点工具的方式划分，可以分为三种类型：代码埋点，可视化埋点和全埋点，现在市面上三种实现方式的工具都有，都各有弊端。具体的各种埋点方法的分类与优缺点如下图6-11所示：

图6-11 埋点方案

（1）代码埋点

这是目前最为人所知的一种类型，也是使用最广泛的，包括Google Analytics和友盟在内的一些第三方工具都是使用这个方案。

原理是：部署完SDK后，在需要采集数据地方添加跟踪代码，APP启动的时候会初始化SDK，你单击或触发数据采集位置的时候就会调用SDK对应的数据接口把数据发送出去。例如：我们要对某个位置的单击做埋点，也就是该按钮被单击的，这个按钮对应的OnClick就会调用SDK提供的数据接口去发送数据。通常来说，为了避免消耗用户的流量，一般是多条数据压缩后发送，而不是一条就发一次。

优点：

准确度高：可以精准控制触发条件，什么时候才触发，准确统计某一事件；

自定义强：可以自定义很多丰富的数据数据传递到服务端；

缺点：

工作量大：需要跟踪的地方都添加对应的跟踪代码，需要埋点，因此工作量会比较大；

用这个方案，版本更新的代码大，容易造成混乱？这是不存在这样的问题，版本更迭根本不用对旧版本的埋点做重新部署的，只有说，放弃旧版本框架，完全重写一个APP的时候需要重新部署，当然，新增页面或需求的时候，会需要添加新的埋点，这个的工作量并不算大的，如果你内部有一个比较好的反馈机制，这个很快的。

这个有性能影响？使用第三方SDK，肯定会消耗内存，带宽，这是避免不了的，至于说传递数据，现在大部分的第三方都不是实时发送的，都是累计压缩数据后，等网络比较好的时候才发送数据的；最后一个是，现在的手机，处理能力可能都不亚于一些旧的台式电脑的，如果说影响性能，那你的APP得有多大或你现有的架构有多复杂。

至于数据传输的不可靠，只要涉及到网络，都可能会有网络延迟或丢包出现的，是通病来的，也有很多解决方案：加锁、重发或回调。

（2）可视化埋点：

就是开发者无需再对追踪点进行埋码，而是脱离代码，只需面对应用界面圈圈点点即可追加随时生效的事件数据点。将核心代码与资源配置分开，当APP启动的时候从服务端更新配置和资源，APP根据新的配置和资源上报数据，整个结构有点类似GTM的，配置都是在GTM，用户每次打开加载到的是最新的GTM配置，那么GTM上部署的触发条件有可能被触发，从而实现数据收集。

原理：Web和APP的页面都有类似的结构，在部署完SDK后，SDK会自动获取页面各个层级的关系，在Web是dom结构，在APP是UIViews，当你用可视化页面设置埋点的时候，服务器能够自动知道元素的位置，并且将这些配置保存到服务器，用户打开的时候，就会加载这些配置到客户端，当用户触发该元素的位置时候，就会将相关数据发送出去。

优点：

部署简单，能大大节省人力成本；

对于不同代码的产品和运营，可以通过可视化界面进行配置；

缺点：

不灵活，不能自定义获取数据属性,部分可视化的位置可能覆盖不全;

每次启动都会加载服务端最新的配置资源，浪费流量。

（3）全埋点：

全埋点也叫无埋点，就像字面说的，不需要埋点，已经尽可能的收集所有控件的数据，最早是在2013年，由Heap提出的。

原理：SDK利用CSS选择器技术和监听控件的事件触发技术，在APP中嵌入SDK，这个SDK就会将APP中尽可能多的操作都采集下来，可以通过可视化操作界面对采集的数据做分类，基本上是先收集，后筛选的节奏，可能会出现数据噪音的情况。

优点：

部署简单，只需部署SDK，初始化几行代码，就会自动收集数据；

自动收集很多数据，能够回溯；

缺点：

不灵活自定义数据属性；

收集的数据多，给网络传输带来压力，消耗用户的流量和电量，部分会涉及隐私问题。

可视化埋点和全埋点的是很类似的，只是它们对信息的采集和处理流程不一样而已，可视化埋点是，采集的才处理，而无埋点是先采集所有的，才选择性处理，无埋点采集的是尽可能多的数据，所以无埋点能够对数据做回溯，但是这也意味浪费流量，浪费电，坑用户。

（4）服务端埋点

在后端将数通过协议的形式直接发送数去，如MP协议，日志等，最常用的还是日志，如日志做很多个性化的定制实现数据的采集，这个工作量就大了。

前面的客户端埋单都是使用第三方工具，服务端埋点，可以理解为，自己开发一个类似的工具架构了。

3.埋点的原则

简单：埋点的方法简单，能够快速上线的，如果一个工具埋点都折腾个几个月，这就不经济了。

免费：大部分人在做工具选型的时候会着重考虑这个工具是否付费的，都想要免费的工具，现在市面上可视化埋点和无埋点的都是付费的，如果预算允许，可以考虑用可视化和无埋点的产品，但请选择大型厂家的产品。

准确：收集到的数据是准确的，才有参考价值，如果收集到的数据跟后其他其他数据有很大的误差，根本不可信的，再花哨的埋点功能也是没用的，目前准确度高的还是代码埋点的形式。

4.APP埋点跟Web埋点的区别？

APP和WEB的埋点都是需要做部署，行为都是通过事件来跟踪，都有埋点跟踪和可视化跟踪。

不同点在于：

WEB是部署的js跟踪代码，浏览是页面

APP部署的SDK，浏览的是屏幕

5.APP中的事件监测及应用方法

只要是行为，单击，都可以应用事件监测，应用上如：

注册表单：构建转化漏斗

按钮跟踪：定位僵尸按钮

全路径跟踪；路径转化

选择跟踪：用户偏好

……

还有很多可以通过事件去跟踪。

6.1.3屏幕的命名规则

屏幕的命名一般用模块划分，比如分为注册模块，个人信息模块，功能1模块，功能2模块，这样设置模块，不同层级用“.”区分，比如Auth.Register，MyProfile.PhoneVerify.SelectCountry，每个字母开头大写，从字面就可以知道对应的屏幕，方便理解。如果字母太长，用简写。

比如下面是一个用户信息模块的屏幕：

MyProfile.Main

MyProfile.ChangePasword

MyProfile.ProfileDetailIndex

MyProfile.EditInterest

MyProfile.EditSelfIntro

MyProfile.EditMatchCriteria

MyProfile.PhoneVerifyIndex

MyProfile.LandlineVerify

所有的屏幕都是归类到MyProfile里面，主界面就是MyProfile.Main，左右模块的主界面都是Main，如果用户单击去修改密码，那么屏幕就是MyProfile.ChangePasword，如果您觉得这个屏幕名称太长，可以使用简写。

6.1.4全路径跟踪

对于用户行为可以采用全路径跟踪，就是遍历用户的一个操作，用户返回的时候加*，这个需要APP通过事件传回，比如有屏幕A、B、C和D用户操作为A-B-C-B-C-D，这个传递回来的是 A-B A-B-C A-B* A-B-C

A-B-C-D 这个可以知道核心屏幕的单击来源，也可以知道用户的主流操作路径。

6.1.5其他

1．GA、AD和Google Play的用户

GA 跟踪APP中的New User是First Open，如果用户不打开，是记录不到的，而Google Play的数据是下载量，也就会出现GA监控到的数据明显会比Google Play的少的情况，Adwords的转化数据也是以First Open作为规则，所以是与GA是相等的。

2．是否需要新手引导页面

通常对于新手来说，APP的新手引导有利于让用户更好的了解您的APP，但有时会适得其反，手里就有个应用因为新手引导的页面导致跳出率高达30%，也就是大部分用户都直接就离开了，这是很悲催的一件事情来的，在去掉新手引导页面后，日活用户数量明显上升，告诉大家这个，是想让大家留意如果您的APP也有这个新手引导页，那么关注这个页面的跳出率。