“坑位运营”：数据分析与场景实践

小提示：您能找到这篇{“坑位运营”：数据分析与场景实践}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的“坑位运营”：数据分析与场景实践内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

本文为大家分享了“坑位运营”的详细内容，其中包含了坑位运营的起源、数据分析、如何运营、实践案例等。

主要内容如下：

• 坑位运营起源；
• 数据分析与坑位运营；
• 如何进行坑位运营；
• 实践案例。

开始分享之前，想了解一下在座各位在工作过程中，是否分析过以下几个问题的答案北京全托管的微信朋友圈广：

• 第一，过去一个月，产品首页 Banner 位置，给您的产品带来多少直接收益？
• 第二，在运营人员投放的位置当中，哪一个可运营的位置带来的收益最高？
• 第三，推荐商品位置中，哪个顺序的位置的收益效果是最好的？
• ……

如果大家对以上问题的答案都是否定的，那么接下来的内容会对大家有较高的价值。我将针对这些问题，与大家分享“坑位运营”的内容。

一、坑位运营起源

目前，在网上通过搜索引擎搜索“坑位”发现，并没有关于“坑位”的明确定义，能搜索到的相关信息大概都来自于淘宝，即搜索结果下面的内容展示区域或聚划算等活动的商品展示位置，被称作“坑位”。

但这些在我们其他应用的运营中，适应范围较窄，所以，神策数据需要给“坑位”一个更广义的定义——可以承载内容信息并且可以运营的位置区域。

举例来说，常见产品中的很多位置区域，比如 Banner 位置、搜索位置、品牌推荐位置、商品分类位置甚至推荐位置，这些位置内容很多都是可运行和可更改的，我们把这些称作为坑位。

1. 一个用户典型的购买路径

对于坑位，我们需要了解其在用户的购买路径中会产生哪些影响，当一个用户从落地页进入到首页，通过 Banner 进入到活动页面，发现活动页面并无自己想要的东西，随即跳出，通过搜索位置寻找想购买的东西，但又发现搜索结果也无法满足需求。

过程中虽然他进入商品详情页，但发现推荐的相关产品中并无自己喜欢的商品，遂又返回产品首页。

之后他将想要购买的商品加入到购物车，又因为凑单、满减等营销信息返回购买页面添加更多商品，于是搜索各类评价，最终加入购物车完成结算，这中间 Banner、活动、搜索、推荐、凑单、满减等都可以算做坑位。

如果我们将用户实现购买路径的过程分成发现落地页、发现商品、了解商品、完成购买决策 4 个阶段，我们会发现坑位大多数时候都出现在发现商品这个阶段，至此，我们可以理解坑位多数时候是辅助用户发现商品的。

我喜欢将用户在产品中价值实现受到的影响因素分成三种：流量质量、产品功能、流量引导。

我们可以用现实生活中的商场来比作是你的产品应用，那么：

• 流量质量：当用户站在商场门前时，她本身是否有钱、是否有强的购买欲望决定了她踏进商场时，购买的可能性高低。
• 产品功能：就像一个商场中的基础设施，能决定在整个商场中购物是否顺畅。如一个提供了电梯功能的商城比一个只有楼梯功能的商场体验就好很多。
• 流量引导：商场中的地图和抬头看过去的指示牌，就像地图，都在告诉每一个顾客喜爱的商品应该去哪个方向购买。

当我们了解这些之后，回过头来看，我们发现坑位特别像影响用户中实现价值要素中的流量引导因素，故此，我们先将坑位核心目的定位为“流量引导”。

2. 坑位运营的目的

当流量进入，我们需要引导其完成购买任务，以实现流量价值最大化，因为在当前互联网的现状下：

1. 流量价格非常高，只有实现将每一份流量的价值最大化，才能改变烧钱现状从而获得盈利。
2. 争取在每一份流量的总体价值中，占据更大的比重，是一种新的竞争优势，比如淘宝不能和京东、拼多多等平台比拼用户增长，提升流量价值可能是最佳选择。

二、数据分析与坑位运营

从上一节，我们了解坑位的定义和其必要性，那么在现实的坑位运营中，大家曾遇到什么问题？数据分析在解决这些问题的过程中又能起到什么作用呢？

我们将回到解决问题的基本思路过程上，会发现问题大多出现在评估环节上，我们可以做出各种 Banner 运营计划，但很多时候，却无法对其产生了多少最终收益进行评估，也很难针对该位置的针对性改进。

从我了解到的一些客户里面，曾使用过单因素变量控制的方式对坑位效果进行评估，这种方法在一定程度上不失为可选方案。

（1）单因素变量控制并不容易做到完全可控，如果产品处在增长期，产品增长本身就是一个影响因子，很容易忽略此类因素的影响。

（2）评估方式低效，如果 2 天内只控制 1 个坑位变动，那么评估 20 个坑位内容改变就需要 40 天时间，这样的效率任何企业都无法接受。

现在，我们希望用数据分析中归因的方式解决坑位运营中评估的问题。

1. 坑位归因

定义：将产品的最终收益的功劳分配给转化路径中各个不同的坑位上；

目的：效果评估。

2. 常见的归因模型

为了实现归因，我们需要了解一些常用的归因模型，而归因模型是指一种或一组规则，用于确定如何将利益功劳分配给转化路径中的接触点。

（1）末次触点归因

最后一个点击的接触点将获得 100% 的销售功劳；这是一个最典型的归因方式，在常见的网页分析报告及报告工具中几乎都可以看到这样的归因结果。由于完全不考虑整个过程中消费者到底接触过多少个触点，该模型完全忽视了漏斗上层和中层部分的行为对转化的影响。

（2）首次触点归因

如果用户没有机会了解商品，就永远不可能购买商品。与末次触点归因相反，指哪些坑位第一次将用户带入商品页面，就将 100% 的功劳归功于其。该模型会高估单个触点的影响力。这种情况下，首次触点归因模型就会过分强调驱动用户认知的、位于转化漏斗最顶端的触点，但以上两种方式都相对简单直接，有时会引起异议。

（3）线性归因

在线性归因模型中，转化路径中的每个接触点将平分销售功劳（图例中每个均获得 20%）。

线性归因模型的优点是它是一个多触点归因模型，因此会将功劳划分给转化漏斗中各个不同阶段的坑位触点。缺点是它无法正确衡量各种营销触点的不同影响。

（4）时间衰减归因

在时间衰减归因模型中，最接近销售或转化时间的接触点将获得最多的功劳。该模型基于一个假设，该假设认为触点越接近转化，对转化的影响力就越大。这种假设的问题是它永远也不会给位于漏斗顶部的触点一个公平的分数，因为它总是距离转化最远的那个。

（5）位置归因

将末次触点归因和首次触点归因折中，首次、末次各取 40%，中间 20% 平均分配给中部。

另外，还有比较复杂的自定义、算法归因模型等。

3. 渠道归因 VS 坑位归因

由于归因模型的概念起源于渠道效果评估，所以我们需要了解渠道归因和坑位归因的一些相同和不同点。一些信息点简述如图，其中需要注意几点：

首先，二者都采用动态评估。

• 动态评估：只要有新的数据进来，就可以重新做一轮评估。
• 静态评估：如传统营销学的“4P”营销理论，一次评估需要耗费很长时间，做评估的时间可能数月，甚至一年。

第二，二者的影响级别不同。

渠道归因是访问级别的归因，坑位归因是事件级别的归因，二者的影响级别或者影响程度不同。

第三，二者所需周期不同。

渠道评估的是质量，一个用户从某个渠道来到平台，需要时间了解商品，一个用户的质量并不能单靠一天的数据进行评估，渠道评估最好需要积累一周左右的数据以增强评估的准确性。但坑位评估是流量导向，导向效果是立马显现的，所以只要有一天时间，就可以对坑位进行评估。这是二者在评估方面展现的极大差异。

4. 短期偏见

无论是渠道归因还是坑位归因，都容易出现短期偏见，即追求短期利益，在进行数据分析的同时考虑产品价值定位、战略发展等因素，才能围绕长期目标进行发展。

比如在一款内容产品中镶嵌一些游戏元素，可以让用户停留更久、数据表现更好。但从长期来看，这种行为破坏了整个产品的价值定位，因为内容产品原本提供的是内容并不是游戏，产品也不并是为了追求用户停留时长而是为了实现价值。这是两者都存在的短期偏见。

5. 坑位运营工具

神策分析是国内第一款提供坑位归因分析功能的产品，下图为坑位归因的分析界面，可以看到转化事件、归因事件、归因模式，当选择完所有的条件，点击查询即可得到各个不同坑位的效果。

三、如何进行坑位运营

坑位由两个要素构成，一个是坑位位置本身，另一个是坑位里面的内容，我们能优化的事情与之对应，一是优化位置本身，一是优化里面的内容。

如果把产品里面的坑位看作现实空间里的土地，坑位里面承载的内容就是土地上面种植的庄稼。那么可以将坑位运营的问题转化为以下问题：

• 坑位投放何种内容——同一片土地上，种植哪一种庄稼收成高？
• 内容投放到哪个坑位——某一种庄稼种植在哪片土地上，比别的土地要好？
• 坑位的内容轮换——何时在土地上进行下一季庄稼的种植？
• 位置优化——土地上收成不好，是否可以改版土地形式？
• 流量导向——土地上收成好，是否可以将土地面积做大？
• 人群特征——不同土地之间的收成有什么不同的特点？

关于如何从数据中洞察问题这一点，许多客户都特别希望直接从数据里面找到洞察信息。如此，很容易陷入误区，因为很多时候仅仅只靠定量数据，并不能提供真实的洞察。

比如有研究表明现代人癌症发病率是 2000 年以前人类癌症发病率的 100 倍以上，拿到数据之后会想什么？很多人第一反应是环境变差以及食品安全等类型的解答。但如果了解癌症的话，会发现癌症最大的原因是随着年龄的增长，癌症发生的概率会越来越高，现代人的寿命可以延伸到七八十岁，而古代人只有 7.7% 的人能活过 60 岁，所以现代人就比 2000 年前更有可能触发癌症。

理解到业务上也是一样，只有在更懂了业务之后，才可能获得更多真实有效的信息；而在真实的数据分析场景中，定性数据所提供的信息也是不可或缺的一部分。

把活动投放到坑位里面，可以根据数据采集评估结果，我们需要使用何种指标去评估坑位运营的效果呢？这里，我们需要提及坑位运营需要重视的就是坑位产出=单位流量成交金额。

假设我网络营销和网络运营作为产品方，分配给运营人员一个流量，平均一个流量带来多少钱，这就是坑位产出。

具体公式如下图：

现实总是和理想有一定的距离，比如我们拿到准确的曝光点击率的成本是很高的，很多公司都不能实现好这个指标的计算，所以可以利用上述公式中的一些额外指标，同时要考虑偏差、综合指标等。

四、实践案例

以下是我和一个客户一起合作的关于坑位运营的例子，我们一起从数据采集准备开始，到利用归因模型进行归因发现优化点，并在优化之后对具体效果进行了评估。

1. 数据准备

在和客户做数据采集的时候，多数埋点人员不愿意将来源信息的参数不断向后续动作传递，比如将数据源从 Banner 位置带到商品详情页，再继续带到购物车，之后要把来源信息一直存在购物车里面，最后再带到结算订单，这种方式比较麻烦，同时也很难避免遗漏和丢失，整体比较难做好。

所以，神策数据推出另外一种解决方案，即为所有坑位运营营销事件单独埋点，只要触发就立刻记录，购买商品做归因的时候在时间轴上往前追溯，追溯到详情页或者加入购物车的前一个坑位，再通过计算方式来实现坑位归因。

相当于把以前埋点的方式实现的信息采集通过计算的方式进行了解析。虽然增加了神策分析平台的计算成本，但极大地减轻了工程师做埋点的成本，这是工具所带来的便利。

2. 坑位归因

根据坑位归因的结果，我们进行了进一步的分析，发现有的页面流量大，但转化效率低，有的页面转化效率高，但流量较小。同时，一些坑位也具有类似的情况。

我们也很好奇，一个用户在一个商品购买中，需要经历几个坑位，从图中可以看出，54% 的用户只从某一个坑位到商品里面后，就已经作出购买决策；30% 只经历 2 个坑位，经历过 2 个坑位当中的，又有 60% 实际上经历的是同一个坑位。

整理来说使用单触点末次归因的方式，能将 72% 左右的收益效果进行准确归因，所以，我个人更偏爱末次归因模型，因为它简单实用且计算量较小。

关于推荐位位置，我们总容易以为排在第一位的位置一定是最好的，但实际该客户的数据上看，第二、三位贡献的最终收益反而是更多的，这是一个让人很意外的信息。

另外可以与大家分享一个细节数据，在该客户的产品中，大概达到 100 个位置之后的转化效果就会出现锐减的情况，可能用户下拉刷新的位置在这个数量级上。大家可以结合此数据并考虑自己的产品在实际中的情况。

3. 有效信息提取

根据坑位归因的结果，整理了很多推进产品改进的有效信息，在此，列出几点示例：

（1）收入的主要来源是商品详情页的推荐，但该位置推荐的次数转化率低，若能提供更好的推荐，或更有效利用推荐位，将极大提高用户的购物效率。

（2）CrossBar 吸引大量用户，但实际坑位转化率较低，大量用户在此做了很多无效点击，分散用户的注意力。

（3）搜索作为目的性最强的一种商品搜索手段，成单转化率低于预期，有较大的优化空间。

（4）购物车位置的推荐、促销活动、包邮加车等转化效率最高，适合多做与购物车中商品打包的活动。

（5）208、555 品类排序效果好，收入高，919 品类转化高，但曝光量相对不足。

4. 优化坑位

由于 CrossBar 和分类功能有重叠，且表现效果不好，易分散用户注意力，所以产品决定去掉 CrossBar，页面简洁了很多，流出更多的设计空间给其它坑位，同时也让用户更多的注意力使用在更好的分类功能上，以期提高分类转化效果。

同时，去掉效果并不好的“我的页面商品推荐”，产品本身靠的是人工推荐而非自动推荐，拿掉一些推荐位之后，不仅减少了用户注意力的分散，同时也一定程度上降低了运营成本。

5. 优化内容

要求运营人员每周整理一些经验优化的规则，每周做实验优化推荐效果，这是在没有自动化推荐下做的事情。

6. 优化效果

大部分坑位在调整了之后都取得了上升的效果，只有少数出现了效果下降的情况，但整体而言，效果仍然是上涨，相对于坑位运营修改前两周的情况，整体收益提升了 37.6%。

以上就是我的分享内容，谢谢大家！

最后，告诉大家一个好消息：

为了帮助在运营进阶路上，执着前进的伙伴们能够更快速的提升，我们联合了腾讯、百度等拥有10年以上经验沉淀的实战派导师，推出了【运营总监修炼之道】，至今已帮助5000多名运营管理者和进阶者，掌握了更加系统全面的运营专业知识和管理思路，在处理类似运营战略规划、不同渠道运营策略和流量变现、品牌营销玩法、数据分析等实际问题时有更清晰的解决方向！

扫描二维码添加小助手了解详情，还可以回复“笔记”领取【运营总监课程学习笔记】哦！

再犹豫，机会就没啦~

本文由 @神策数据 于。，

，基于CC0协议