代码实战：APP用户数据分析 - 全链路用户路径分析 (下)

前言

书接上文：https://blog.csdn.net/a774057695/article/details/106843586

上一篇博客中，我们介绍了用户路径分析的价值以及从客户端出发的一套“用户路径采集”解决方案的探索和论证。在上一篇中，我们提到会再开一到两篇博客来介绍：从客户端出发，如何做好“模块分析法、潜在用户需求路径分析法”；以及在客户端运用一定的算力做模型分析。

经过谨慎的思考后，在客户端运用算力处理模型分析这一部分搁置了，首先这一行为不具有普适性，而且强行写下去也只是去扯在移动端领域如何使用“tensorflow”、“Caffe2”等，模型的论证是无法展开的。

所以这一篇，我们简单的聊一聊在复杂的APP（例如电商类），当页面链路情况复杂，无法精准推测分析其背后的价值时，客户端还可以做哪些事情，支持数据分析团队精准的分析用户。

来自产品和数据分析团队的知识

先前和一些产品好友以及数据分析的同事们聊过，当APP的模块足够多且内在的模块关联性比较强时，单一用户的路径会变成分散状，在加上一些碎片化时间下多次使用操作的背景，整个用户行为看起来就像是在瞎逛。

这种情况下就要弱化链路的利用，将个别或者成组的页面看成是模块，从产品视角寻找出“引发”和“转化”。

举个例子，我们发起了一个商城项目，相比于几年前的传统电商类，还聚集了一大波带货达人，产出以“文章”、“小视频”为体裁的内容推荐各种好货。我们姑且将这些内容称为“攻略”，很自然的，我们会在攻略中给出商铺的链接，也会在商铺中给出一系列相关的攻略，那么“店铺”和“攻略”两个模块之间就是有很强关联性的。我们会引入一个叫“通道”的概念：

通道：一组页面模块；需求通道的入口即 满足需求的最早通道；需求通道的出口即 满足需求的最后通道

了解过的同学会知道，接下来会产生一个价值归因表。例如从“引发”出需求：“逛”、“收藏”、“加入购物车”会有这些通道：

需求通道入口	需求通道出口
	逛	收藏	加入购物车
首页banner推荐	45%	30%	3%
“攻略”详情	80%	40%	4.5%
搜索	95%	45%	15%

等等（以上数据纯属虚构）。数据的含义是需求满足率，即用户点击模块后产生价值次数/用户点击模块总数

而实际页面链路上，可能你看到的是用户不停的在各种推荐模块、商铺详情页、攻略详情中瞎转悠

客户端适合做哪些工作

从上面我们已经了解到了，为了支持精准运营，数据分析会需要哪些东西，当然，这些数据都是从客户端埋点和服务端埋点统计并加以计算得出的。我们知道，服务端接口的统计数据对于用户运营的数据分析来说要么意义不大，要么缺少关键维度。所以我们假设所有的数据都是通过客户端埋点获得的。

我们可以猜出来，需求通道的出口，往往都是对应了一个行为，这个行为都是可以定义“行为埋点”的。我们不去管这种行为埋点是通过“代码人工埋点”的方式、还是“自动化埋点”的方式、还是“全埋点”的方式所实现的，我们一定可以做到的一点是在埋点中加入几个关键信息：

• 时间
• 用户（或者画像信息）
• 触发行为时所在的页面点（或者行为点本身就可以区分出页面，而不再需要单独信息）
• 上一级页面（或者当前的整体页面栈）

，在经过一定的预处理（例如用户单日访问去重），这样就可以进入计算了。

在上一篇博客中，我们已经论证了这些关键信息可以正确维护和使用。那么正常来说这个话题就可以结束了，但实际情况中我们还可能遇到这样一个情况：

我们在文章类型的攻略页面提供了两个功能：

• 商品的文字超链接（单纯的蓝色高亮超链接样式）
• 商品的图文link块（有图片、商品名，店铺名，价格等）

具体样式就靠大家想像一下了。

然后从价值归因表上，我们是区分不出来这两者的数据的。都是从文章攻略页面进入的，如果有人吃了秤砣铁了心要看数据（比如要用数据说明文字超链接没有什么存在的价值了），我们尽可能还是说服数据分析从行为点号入手，多计算几次，而不要试图从“商品详情的页面入口通过率占比”出发。

如果一定绕不开这个问题，非要一次计算就能得出结果！那我们就把这种功能给实现了。即通道不仅仅可以对应页面，还可以对应到页面中的局部内容。

考虑到这部分内容及其的非常规，我们只谈一种实现思路：
在上一篇的链路维护基础上（每一个链路节点都对应“页面”），我们在链路节点中维护行为埋点序列，考虑到时效性和一些“特殊情况”，

• 这里的时效性是指需要考虑的时间很短，很短的时间能能触发的事情是极少的，例如说我先对攻略点了个赞，过了一会进入商品详情，之前的点赞行为点对于“逛”商品详情而言没太大统计意义，已经没必要维护，所以当新的行为点产生时，老的行为点就可以丢弃了
• 这里的特殊情况不是指行为触发了不止一个埋点，可能是埋点设计错误、可能是疏于维护的bug等这些应该处理掉；而是多个连续的行为导致最终结果的情况，而且出现同一结果的情况存在多个时。例如“攻略页”底部栏有举报功能、顶部栏的更多也有举报功能，点击后都有一个原因分类举报弹窗，可以直接举报或者进入独立页面填写更多的信息进行举报，就有可能产生不同情况的行为点组合。

我们仅维护有限个行为点，例如5个，在行为点触发时，我们找到页面栈的栈顶（其为当前页面的置信程度很高），其内部维护了一个最长长度为5的队列，将当前行为点塞入。

这部分内容就不在Demo中进行演示了，一方面是描述的也比较清晰了、编码应该也不复杂；另一方面是这部分的受众应该比较小，Demo中原有的代码已经足够处理绝大部分场景了。（关键是我犯懒了，而且我们一直可以说服数据分析单纯的多做几次计算就可以了😂）