小程序现在火了。但是应该如何监测小程序的数据呢？相信这是一个大家都关心的问题。这篇文章对这个问题进行解答。

一共包括两个部分：

一、如何获取符合业务需求的数据？

在数据监测中分为两大部分，常规数据监测和自定义事件数据监测。

常规数据监测是指不管小程序是什么类型的，我们都需要获取的数据，除了基础代码还包括来源、页面与页面路径、分享、用户属性等数据。

自定义事件监测是指一些具有特殊业务场景的数据监测，比如含有交易功能的小程序，在提交订单时需要监测订单里的商品、数量、金额等数据。如果小程序内有广告位，还需要监测广告的曝光和点击数据。

接下来介绍常规数据监测和自定义事件数据监测具体的监测方法。

先讲解一下基础代码的部署。

在部署代码之前，你需要注册一个小程序的账号，然后在账号后台添加合法域名，每个监测工具的域名不一样，具体域名可以咨询你使用的工具厂商。

添加域名示例

添加完域名后要引入JS，将下载的SDK文件放入 util 目录下，然后在 app.js 第一行添加js代码。SDK文件和JS代码在工具厂商那都能下载到。

其次是来源数据监测，这里先说下小程序都有哪些入口，有哪些能直接监测，有哪些不行。

小程序的入口接近70个，包含发现栏小程序主入口、顶部搜索框的搜索结果页、朋友圈广告、搜一搜结果页、发现栏小程序主入口搜索框的搜索结果页、聊天会话中的小程序消息卡片等，详细入口列表，可以查看小程序开发文档的链接：https://developers.weixin.qq.com/miniprogram/dev/framework/app-service/scene.html。

这些入口中，有些是我们可以加参数监测的，比如小程序的二维码，这里说的二维码也是用一段url生成的，和网站监测原理一样。在做网站来源监测的时候，我们会在url上添加link tag来区分不同的流量渠道和广告类型等。

比如投放到新浪上的banner广告，我们可能就会加上参数?

utm_source=sina&utm_media=banner&utm_campaign=cwa（这是谷歌分析的标准格式），同样在小程序里也能用这种方式实现，只是每个工具的参数标识不一定一样，有些是兼容utm的，有些有自己的标识。

比如nEqual的及策用md标识来源类型，用pl标识来源详情，这个链接pages/index?md=Qr_code&pl=mendian_a代表的是来自A门店的二维码。和网站来源参数另一个共同点是这些参数可以只写一个，也可全都不写。

有些是无法加参数监测的。无法添加参数的来源类型需要工具从微信那调取场景值。前面提到小程序有接近70个入口，每个入口都有相对应的场景值，监测工具可以通过调用小程序定义好的场景值来判断各种来源带来的用户数据。

来源场景报告

第三个常规监测是分享的监测，这也是小程序数据监测区别于网站数据监测的地方，在微信的生态里让分享监测成为可能。分享监测主要是要获取三个数据：分享的位置、分享页面的标题和分享路径。这样我们能够看到某个页面被分享到群里还是发给朋友了。

有些朋友问，我想监测页面A被某人分享出去后带来多少人访问，是否能实现。这种场景是可以实现的，需要我们做一些自定义事件监测。

以及策这个工具为例，在 path 后动态加上用户动作名称的昵称，这样就可以统计该分享者最终带来多少用户了。

一个需要介绍的字段是$share_depth，这个属性值会记录分享的层级：如果某个小程序页面被A、B和C三人依照 A -> B -> C 的顺序进行分享，则 A 的分享会被标记为1级分享，B的分享会被标记为2级，C 则为3级。 如果某用户打开自己分享的页面不会增加 $share_depth 的值。通过这个字段可以看到某个页面被分享的层级有多深。

另一个常规监测就是用户属性的数据，当用户打开你的小程序并且使用微信登录，会调用以下方法回传用户数据。

关于用户id打通，因为涉及到用户id，这里延伸介绍下监测小程序的工具根据哪些id来判断用户，当用户在未登录的情况下，工具会给用户随机生成一个id，相当于网站监测里的cookie，只是每家工具的叫法不一样，神策的叫uuid，易观方舟的叫originallid等。（是否有官方叫法）这种id极不稳定，如果你换了设备或者删除小程序，这个id随之重新生成或者消失。

当用户用微信登录小程序的时候，我们会获得用户的open id，有可能的情况下会获得union id，在之前我讲公众号用户运营的文章里有详细讲过这两种id的区别，如果你有多个公众号、小程序的时候（在同一认证主体下），假设有一个用户关注了你三个公众号并且登录过一个小程序，每个公众号和小程序都会给这个用户记录一个open id，并且都不一样，这对于你来说是不符合你的业务需求的，你还是希望能把这个用户识别为一个人，这时候微信就提供另一个id叫union id来将这个用户的open id进行统一标识，所以在你的平台上，一个用户对应一个union id。

除了用户登录后的open id或者union id，还有一个id是你收集到的用户手机号或者邮箱，通过这个用户id你可以将用户访问你网站、APP等平台的数据统一整合进来。

讲完常规部署，接下来讲解一下进阶的部署内容。小程序和网站一样，除了页面、渠道来源等数据，我们还有很多更为复杂和重要的数据，比如特定交互的监测，我们称之为事件监测；比如订单数据监测，我们想知道某用户提交的订单里包含多少商品、商品的名称都是什么、一共多少金额等，我们需要用到自定义变量的事件监测；另外如果你在其他小程序里有广告投放，你还想知道广告位的曝光和点击次数的数据等等。

为了解决好这些业务场景的数据监测问题，以下内容主要会和大家介绍特定交互监测、自定义变量监测、广告位曝光点击监测。

特定交互监测（事件监测）

拿我最常用的小程序举例，因为每周都要组织大家打篮球，要确定大部分朋友打球的时间，所以会用到投票的小程序。

腾讯投票小程序

如果我们监测腾讯投票的小程序，我特别想知道页面上点击单选投票和多选投票的点击数量是多少，这时候我们需要部署小程序事件的代码，还是以及策为例，分别给这两个按钮部署事件代码jice.track(‘danxuan’)和jice.track(‘duoxuan’)，这样就可以实现对这两个按钮的监测。

那有朋友就问了，如果我不仅仅想监测这个按钮的点击次数，我还想监测这个按钮里的文字内容呢？这就涉及到了自定义变量了，为了更好地解释这个问题，我直接引到自定义变量监测模块。

自定义变量数据监测

当我们想要监测很多特定的动态数据的时候，比如订单信息、注册信息等，因为每个用户购买的商品五花八门、注册提交的手机号等信息具有唯一性，所以无法用简单的事件来监测，而是要监测更为详细的动态信息，所以才有自定义变量存在的可能性。

比如下图中的订单信息，用户购买了酒店的单人餐，两份。我想要在用户点击“确认下单”按钮的时候，把订单里商品名“盘古七星酒店因缘庭单人餐”、数量“2”、总额“200元”等数据监测回来，我们需要用这样的代码

当用户点击“确认下单”的时候即触发数据收集，其中“商品名称”、“数量”和“合计金额”替换成订单里的详细数据。

美团订单信息

接下来给大家介绍一下小程序内曝光和点击的监测，如果你的小程序在其他小程序里投放广告，你想知道曝光和点击的次数，你需要详细了解下如何实现。

广告位曝光点击监测

要实现广告位数据的监测，首先要在监测工具中添加作为渠道方的小程序，然后嵌入基础代码以及需监测的事件代码、用户属性代码（这些代码前面都有详细介绍），同时需在工具中添加广告主的小程序，最后将以下代码部署在广告位上。注意：代码中appid为广告主的appid，即工具生成的应用id。

好了，数据监测的部分已经讲完了。

二、案例：拿到数据该如何优化业务

接下来和大家讲解三个案例：漏斗分析、表单分析和自定义变量事件分析。

漏斗分析是很常见的做转化流程、表单等业务分析的模型，在宋星老师的大课堂上有介绍过漏斗的主要形态，如下图。

漏斗图

最理想的状态当然是没有流失，全部都转化了，但这是不可能的嘛。正常的流程都会存在一定的流失率，但是有些严重的泄漏点是值得我们关注的，这些严重流失的用户到底去了哪里，找出原因也就找到了优化的方法。

可口可乐继昵称瓶、歌词瓶、台词瓶之后，应用小程序推出社交活动：密语瓶。这个活动的玩法是用户通过扫描小程序的二维码进入小程序页面后选择喜欢的密语，然后上传照片与密语结合后生成图片分享给好友，最终达到娱乐与传播的目的。

在这个活动中，其中有一个流程是：打开首页-点击“蜜语从哪来”按钮-输入密语-确认提交-生成图片分享。

通过数据积累，我们构建了以下漏斗。

密语制作分享转化漏斗（柱状条右边的数据被隐去了，实际上是有具体数据的）

从上图可以看出用户从首页点击“蜜语从哪来”进入密语定制流程的用户流失率较高，只从这个数据来看，首页的流失量是很大的，对于这个营销活动，最重要的目标是引导用户定制自己的密语然后分享。后来我们从另一个漏斗数据里看出没有进入以上漏斗的用户中除了一部分直接退出小程序，另一部分进入了“密语表情DIY”，进入了另一个定制密语的流程里。所以虽然从漏斗里看出流失率大，但是并不是坏事。

第二个需要注意的泄漏点在最后的分享，最后一个环节的转化率非常低，这个数据引起我们的注意，我们需要分析是不是页面分享引导出现问题，后来经过排查发现是因为不支持分析朋友圈导致很多用户无法分享。

找到泄露的原因，也就找到优化的方法。

在表单分析中，有几个核心的指标需要重点关注。

接下来看下看个汽车行业客户在投放广告后如何通过数据发现表单问题的。大家知道汽车广告投放最主要的目的有预约试驾、申请手册、购车意向等，这里面都涉及到了让用户提交个人信息。所以提交个人信息的表单设计变得尤为重要。

这个表单在用户进入表单页面尝试填写到点击提交，有将近三分之二的用户离开了，我们想知道到底是哪些因素导致用户流失。

在大量数据中，我们发现了几个有意思的数据。其中一个是下图中展现的，用户在放弃填写前最后互动的表单，此图可以分析出用户是因为哪个表单项离开的。

用户放弃填写前最后互动的表单项

大家可以看到“经销商”这个表单项是导致用户离开的最主要的因素，结合重填率分析结果，发现用户在选择经销商时平均重复填写超过两次，重填率接近一半。

带着对这些数据的好奇，我体验了一下表单流程，发现在选择经销商的时候表单选项中只有经销商的名称，但是我并不知道经销商的位置到底离我有多远，我还需要通过地图APP去查看经销商的位置，这样势必造成用户的重复填写和流失。

经销商选项下拉列表

有朋友就问了，那怎么办呢？要不要在小程序里添加个地图功能或者跳转到地图的功能？这样处理的话明显把问题复杂化了，这样要增加多少开发和产品的工作量？有个比较简单的办法是填写经销商简称，并在简称后添加“近某条路”或者“近某地铁站”之类的大致位置信息，让用户大概了解哪个经销商离自己近即可。

在前面可口可乐的案例里，在制作密语瓶的流程中，有一个环节是让用户提交自己想要写的密语。那我们如何能获取到用户提交了什么密语？这里就要用到前面提到的自定义变量的事件监测方法了。

我们需要在密语提交页面的提交按钮上部署事件代码，代码示例如下：

部署后即可监测用户提交了哪些密语、提交的次数等。

密语提交内容事件报告

密语内容分布

从数据里面可以看出这个活动面对的人群很大一部分是鹿晗的粉丝（为了做这个分析，专门查了“LH7”是啥意思，暴露年龄了）。有些密语对我这个“上年纪的人”确实有些费解，大家看到有好玩的可以教我下是啥意思，帮我填补下鸿沟哈哈。

好了，具体的分析案例不多做介绍了。相信这篇文章可以帮助大家梳理小程序数据监测的基本方法。而案例部分，大家会发现与以往的网站分析、APP分析并没有特别本质的区别，而考验你的地方在于对业务与用户的理解以及数据的定义与解读。

关于小程序的文章就先写到这，如果大家有想交流小程序方面的，可以联系林森老师（微信ID:linsen1203）。