埋点的spm和scm模型

spm和scm是埋点中定义传入参数的一种模型，其本质还是埋点的属性通过一定的规范进行传输，只是一种传参模式。那么如何搭建SPM方案呢？ 以及如何更有效的体现其业务价值呢？

从百度统计上看到有很多人访问了我这篇文章，说明还是有一定数量的人在关注这块儿，以前写的过于随意，所以就更新了下。

1. updated 2021-11-03

2. updated 2021-12-04

背景

首先引入一个问题，如何用一句话描述app的所有内容？简单来说，就是用户+物品+事件的集合体，这也是神策分析底层的数据模型，user+item+event模型，这里的事件指的就是用户的行为，我们对事件的追踪也叫用户行为采集，就是我们常说的埋点，那么如何描述用户的行为？4w1h的逻辑

具体来讲，what代表的是event，where代表位置，在app的初始阶段，我们可能只需要关注到页面粒度，即event发生在某个page，但是随着业务的发展以及对精细化分析能力的要求，where的关注粒度可能需要进一步下沉，在app上，体现的就是不仅仅要知道event发生的page，还要细化到改page下具体的楼层和具体的点位，也就是具体的评估指标从页面级精细化到楼层和坑位级别，这也是我们引入spm这一套方案的目的。

在查阅spm资料的过程中，发现阿里推出过一款数据产品Quick Analytics Plus（现已改名Quick Tracking），这款产品的文档里有对应的埋点管理模型描述，如下图。其内部的埋点管理逻辑是位置 > 事件，我称之为位置优先的埋点模型，在该模型下，事件是限定在位置下的事件，意味着其内部可能有着成千上万的埋点事件……

两种模型的对比如下表：

当然，也有可能是由于埋点模型的不同，阿里当年做spm的目的可能仅仅只是做一套位置规范化，将散落于how中的位置参数统一，并不是我说的只到页面粒度的问题。

一、spm是什么

做过埋点的应该都了解过阿里的那套spm模型，全称超级位置模型(Super Position Model)，之前一直觉得这套规范应该极其深奥，毕竟是能够支撑亿级别DAU的埋点规范。在我之前公司的业务场景下，DAU有限，并且业务对用户行为数据的分析还并未深入到点位的粒度，所以也仅仅只是了解，并未深入研究。

目前阶段主要做数据产品，在当前业务场景下终于有机会能够深入研究这块儿的内容。深入了解之后，发现spm模型的本质还是通过参数来区分位置信息，只不过是通过一套统一的规范约束楼层、点位的命名与上报。

spm叫超级位置模型，最早是受到土地户籍制度启发而设计的位置系统，目的应用于页面的统计、追踪页面的来源等场景，通常在埋点时作为埋点参数上报到数据后台。其编码形式采用A.B.C.D四层级进行组合，分别代表了业务、页面、页面区块、区块内的点位。

以上其实还少了个E参数，通常取值是行为发生的时间戳，用来区分同一用户在同一位置的点击行为。

阿里在使用时spm时，通过spm-pre来标识上级来源页面的上级页面，通过spm-url来标识上级来源页面，通过spm-cnt来标识当前页面，其关系见下图，使用该逻辑在不进行join的情况下可以追踪用户当前行为的前2级页面具体点击位置，通常而言，追踪前一级页面就能够满足绝大多数的使用场景。

二、为什么要做spm

从技术角度而言，其最重要的价值就是统一数据采集的规范和认知，减少上下游的沟通和开发使用成本，产品和研发能够快速get到需要的数据怎么埋，下游能够快速获取到所需要的正确合理的数据。

在精细化运营及算法推荐等应用场景下，需要非常精确掌握行为发生的位置场所。如果每个业务都自定义一套标识方式，那么每次分析及埋点工作都需要重新开发，无法复用逻辑，这将极大的浪费开发资源，因此需要制定出统一的位置规范。

但是从业务角度，其能够实现流量的统一标记和管理：

1. 流量实现精准定位
2. 位置和内容分离，使得二者可以分开评估，且位置的评估可以到具体点位级别（这条在事件模型中，二者本身就是分离的）
3. 建立以资源位为中心的数据体系和运营体系

以上第3条是业务方更加关注的点，也是spm这套体系对业务最终的价值点，所以如果要推动spm规范，其核心产出应当明确为建立以资源位为中心的数据运营体系。

其对业务方可感知的产出应当如下：

• 基于位置的流量及转化评估模型，告知业务方，每个页面及页面下坑位的流量效率具体是多少
• 一个以资源位为中心的管理运营平台

三、如何实现spm

3.1 具体流程

首先进行spm的边界限定，spm只做位置的追踪，不进行该位置下展示内容的追踪。

2个我总结的关于埋点采集的原则：

1.业务最小侵入原则，比如utm链路，比如归因，比如spm，都要尽可能少的减少业务侵入

2.埋点参数最小化满足原则，只有必要的数据才需要进行获取

目前业界常用的埋点体系大多是基于事件的埋点体系，在该埋点体系下，传输参数只需要放在ext字段中即可，但是spm模型规范中最重要的部分是对位置体系的划分，站点->页面->区块->点位，如何在不过多侵入业务的基础上低成本的实现这套位置体系才是重点，但是看了下相关文章，spm肯定会侵入到页面发布的相关流程。

设计的具体流程：位置划分 —> 客户端埋点上报 —> 流量归因模型处理 —> 资源位数据运营体系

3.2 位置划分平台

通常而言，app上的页面会随着版本逐步变化，所以区块和点位的划分也会随着版本逐渐变化，如果每个区块和点位的划分都通过文档之类的更新势必会造成混乱，所以需要一个完善的平台来对区块和点位进行划分，这种划分应当是可视化的形式。

3.3 区块信息同步到埋点中

这一步其实也是我非常困惑的一步，简单来说，如果每一个坑位的spm信息都需要通过研发使用代码进行埋点，那这套方案的ROI就实在是太低，所以一直在想是否有更加低成本的同步方式。

比如，能否通过技术手段，关联spm的位置划分系统，将定义的位置信息自动同步到对应代码里，然后事件上报时获取对应的位置信息即可。

四、如何划分spm

通常而言，app页面的搭建我们可以理解为搭积木，再复杂的页面都可以拆解为一个个控件和元素，其内的可能性总归是有限的，我们只需要进行层层拆解，就可以实现这套位置追踪模型。

• 元素：设计的最小层级，通常是图片、文字、几何元素和图标
• 控件：由最基础的设计元素组合而成，是执行特定操作和功能的单位，使用app时最基础的操作组件
• 组件：由控件+元素组合而成，包含相对独立且完整的功能和信息的app模块
• 区块：由多个组件+控件组合而成的区域
• 页面：由区块拼接成的页面，理论上只由区块内的组件组成

基于以上认知，我们可以考虑进行spm层级的划分。

4.1 站点(app)的划分

站点就是我们通常意义上说的app名称，可以用id，也可以用包名，还可以唯一写定一个固定值。

4.2 页面(page)的划分

页面是站点的下一级，常规的埋点体系中，对位置的追踪只做到了该级别。

在原先的基础上，考虑到页面的迭代更新、AB测试，我们还应当引入页面版本(pageVersion)和页面状态(pageStatus)这两个参数来区分该页面的具体版本以及逻辑判断下的具体状态。

pageVersion：主要针对页面的更新迭代来做数据回溯，不同于app版本，此处的页面版本仅代该页面的历史更新。不同页面版本间的页面区块展示可能是完全不同的，比如2018年的淘宝首页和2021年的淘宝首页虽然都是同一个页面，但是里面的区块分布有着非常大的差异。

pageStatus：针对逻辑判断场景下的不同页面展示数据不同，例如登录页面，未登录状态、会员状态、普通用户状态三种状态下展示的区块内容会有差异，也可能会现在动态推荐场景下，人群a和人群b看到的页面区块分布存在差异，所以用该字段来区分不同的页面状态。

基于pageVersion和pageStatus两个参数才能唯一确定当前区块(area)的分布。

4.3 区块(area)的划分

以淘宝首页为例，此时已经明确app=淘宝，page=淘宝首页，那么接下来，需要对页面中的区块(area)进行划分，area包含2部分组成，前1部分代表区块名称，后1一部分代表区块顺序，用@进行分隔，如图，从上到下分别划分区块为搜索区块(search@1)、banner楼层(banner@2)、金刚位区块(kingkong@3)、瓷片区区块(porcelain@4)、猜你喜欢区块(recommend@5)，注意，这里区块的划分依据是从上到下按照区块划分。

考虑到即使是同一版本同一状态的同一页面，也会有针对其内的某个区块(floor)进行更新修改，所以引入区块版本(floorVersion)变量，考虑到某个区块(floor)的逻辑判断场景，所以还需要引入区块状态(floorStatus)。

pageVersion和floorVersion的关系：pageVersion>=floorVersion，

pageStatus和floorStatus的关系：pageStatus>=floorStatus，

那么在实际应用中，什么时候选择区块，什么时候选择页面呢？依据最小化原则，能用区块进行版本和状态划分的，就不要用页面。

4.4 点位(component)的划分

当区块划分完成之后，接下来就需要继续对区块内的点位进行划分，点位依然是两部分组成，前1部分代表元素名称，后1一部分代表元素位置，通过@区分。

考虑到较为复杂的情况，如淘宝首页瓷片区聚划算点位，下方带了2个图片，为了区分哪个图片的点击，我们需要用「.」符号来将element字段一层一层标识到最细粒度，如下方聚划算的「划算好货」的点位element=”porcelain@1.img@2”，如果某区块下的点位还能往下细分，那么可以继续追加「.」，直至到最小粒度的元素。

注意：在某些场景下，如瓷片区区块，会存在动态推荐的情况，虽然用户a和用户b点击的都是位置2，element=porcelain@1.img@2的瓷片，但是他们实际上点击的可能一个是聚划算，一个是淘宝直播，SPM在这里是不区分的，具体点击内容会放在业务参数中。这样既能够对SPM和业务参数做交叉验证，还能够解耦SPM与业务参数采集。

4.5 spm埋点采集的数据

在埋点采集时，参考阿里的做法，预留3个字段给到spm，分别是spm_pre，spm_ref，spm_cnt，分别代表上级来源页面的上级页面点击点位，上级来源页面的点击点位，当前页面(如无点击则为null值)，每个字段用「_」连接app标识(app)、页面标识(page)、区块(floor)和点位(element)标识不同的位置，如果不涉及到某个字段则用0填充，如「从淘宝首页聚划算进入到聚划算主页再进入到商品详情页」此时在商品详情页上报的典型事件数据如下：

当然，如果当前阶段数据分析的粒度没有那么细，不准备采用spm这一套规范，那么数据只需要上报到页面级别即可：

五、spm点位可视化

spm的主要目的还是为了方便下游的使用，那么在做好元数据管理的基础上，一个完善的点位查询平台就是非常必要的了，能够统一上下游认知，减少沟通成本，压缩花费在查找具体埋点上的时间。

从功能上来说，应当由两个主要功能，第一是页面可视化，期望达到的效果是在网页端展示一个app页面，用户可以选择页面进入，来查看该页面的具体floor及element分布，以及当前页面存在的具体埋点，其次是通过spm点位以及具体的事件名称来搜索到对应的页面。

下面随便画了2个demo：

demo1:淘宝首页的搜索框

demo2:淘宝首页的金刚位第4个icon

六、流量归因模型

具体参考另一篇文章，主要目的就是在数仓层面建立一套统一的流量归因模型，统一口径，为下一级的资源位管理平台提供有力支撑。

流量归因模型

七、以资源位为中心的数据运营体系

还没想好，待定。

理想产出应当是一套资源位管理平台。

八、扩展–scm模型

scm叫超级内容模型，用来标识唯一一块内容的模型，在埋点时scm模型的数据作为埋点参数上报到数据后台，其编码形式和spm一样也是通过A.B.C.D四个层级进行编码，只不过四个层级记录的信息与spm有所差别，分别是：内容来源、投放算法、算法版本以及对应的人群，还以上面的内容为例：

内容来源(content_source)：shop

投放算法(algorithm)：cf

算法版本(version)：3.3

对应人群（crowd）：woman

spm针对的是用户位置分析，而scm针对的是内容分析，通过内容来源、投放算法、算法版本、对应人群四个参数标识当前用户的feed流推荐内容来源，再针对性的计算不同类型的CTR就能够做到数据追踪与复盘。

以上查阅到的资料应该少了具体的内容id参数。

九、最后

spm、scm其本质还是一套埋点规范，将分析需要用到的信息通过参数上报，其难点是在页面区块及元素的统一标识上，需要一套完善的元数据管理系统来支撑。

这套方案太侵入页面发布流程了，和之前的埋点成本最小化原则其实是相悖的，在做这套方案的时候，还是需要考虑到实际的ROI，去评估这套方案是否能够真正的带来价值。