首页运营攻略（中） ：首页资源规划与管理

作为首页运营，你是不是也为了业务线对首页资源轰轰烈烈、奋不顾身、前赴后继、永不停歇的激烈争夺而苦不堪言？

下面聊聊我在几个大平台的首页管理中所总结的首页资源分配体系与流量分发策略，希望有一些帮助。

本篇技术含量和复杂度都比较高，读起来可能有点烧脑，大家喝罐红牛，静心阅读。

一、资源位规划与流量分发

首页的一个重要使命是做好流量分发，为业务线给到匹配营收目标的流量。这对业务至关重要，然而，从首页运营的角度，这又非常难做。因为，除了内部分配协调难度极高，同时流量背后又是一个个鲜活的消费者，有明确的需求和品类偏好。并不是我们把资源按业务占比分配好，消费者就会按我们期望的比例来点击和购买的。

为了解决流量分发这个难题，首先我们根据一个复杂完整的实例，来看看资源位怎么进行分配，这是流量分发的基础。

1. 资源位规划详解

我加入亚马逊的时候，公司正在做年度业务规划，每个业务线都做出了自己的下一年度的营收预期，市场部也给出了流量预测。从流量到营收，大致的漏斗模型如下：

流量分发模型

我们可以看到，模型的两端是流量和营收预期。

市场部负责渠道端引流，结合主动回访的老客以及自发流量，共同构成平台总流量（顾客数到流量还要乘以平均访问频度）。

我负责的产品和运营的重要任务，就是把流量按营收占比分发到各个业务线（流量分发），并尽可能多地转化为业务线商详页PV（引导效率），再转化为商品销售数量（转化率），最后乘以业务线的商品均价，成为业务线营收。

这里有三个关键环节：

1. 流量分发：这个决定各业务线获得平台流量的配比

2. 引导效率：这个体现把顾客带到商品面前的能力，是导购频道的核心能力

3. 转化率：体现从商详页到购物车到结算页到支付完成的漏斗效率，是主购物流程的核心能力

我们都知道，流量永远是不够的，营收预期永远是激进的。这三段共同构成从流量到营收的桥梁，不但难度非常高，且难点各不相同。

流量分发的主要难点如前述，顾客及其需求占比受平台特性影响而相对稳定，很难有效操纵。

下面先说说我在资源分配上的实践，这是流量分发的核心与基础。

第一步，计算上年度各条线的销售商品均价、向业务线获取下一年度的预估的商品价格浮动、以及下一年度的营收预期，计算各条线下一年度需要完成的商品销售件数。

下面的红色字为本步输出，蓝色字为通过BI、业务线获取的输入，或上一步的输出，后同。下面以计算A业务线为例，算法覆盖所有业务线。

A业务线预计单品均价 = 上年度A业务线单品均价 * （1+A业务线价格浮动百分比）

A业务线预计销售件数= A业务线营收预期 / A业务线预计单品均价

简单说，就是通过各业务线营收预算和单品均价计算出需要完成的业务线商品销售件数，如下：

第二步，把销售按件数预期分到App、Web、PC三平台（注：此处忽略微信或站外销售，这部分销售与站内资源分配和流量分发无关）。

考虑到顾客迅速转向移动端，还要根据过去几年流量在三个平台上的迁移趋势和整个行业状况，做出下一年度三平台占比变化预测，然后根据这个新占比重新分配各平台销售量。

App端预计销售件数 = A业务线预计销售件数 * App端上年度占比*（1+预估占比增幅）

也就是把销售件数分到三个平台，逐个计算。Web和PC的方法相同，下面仅以App为例。

第三步：通过上年度的单品平均转化率（销售商品数/商详页浏览量），计算出要达到销售预期，需要在各平台给到的业务线商详页流量（商详页PV，亚马逊称为GV）。简化起见假设年度转化率不变。

A业务线需要的App GV = A业务线App端预计销售件数 / 上年度A业务线App端转化率

把所有业务线的GV需求均逐一进行计算，并求和，就得到了GV需求总量。

App GV需求总量 = ∑ 各业务线App GV需求

也就是通过转化率的计算，把商品销售件数再换算为份平台的商详页PV。

注：转化率有两种定义，一种是Order/UV，一种是Units/GV，前者为全站顾客到订单的转化率，后者为商详页流量到销售单品的转化率。因为顾客的购买行为是跨品类的，而商详页是分品类的，因此如果针对业务线来流量需求，必须把流量按业务线分开，因此取后者进行后续计算。

第四步：我从市场部流量团队拿到了下年度的流量预期。这个流量是UV，而不是GV。然后，通过上年度各平台的人均GV，计算下一年度可以得到的总GV（假设流量质量不变）。

App端上年度人均GV = 上年度App端总GV / 上年度App端总UV（日活）

App端总GV预估 = 下年度UV预估 * App端预计占比 * App端上年度人均GV

也就是把GV分到各个平台分别计算UV层面的流量需求。

这一步得到的总GV是引流渠道的流量输出，跟上一步得到的业务流量需求相比，会有不小的差距。这就是理想和现实之间的距离。

作为副产品，在这步计算中我看到，App端人均GV比PC端高22%，比Web端高84%，这体现了App端的顾客更爱逛，一次到访会浏览更多的商品，而web端则非常缺乏可逛性。这更加证明了全力发力移动端的合理性。

第五步：设法弥补第三步得到的流量需求，和第四步的流量预估之间的差距。有五个思路：

1）要求各业务线下调营收预期……好吧，留到最后一步再干这个，比较容易被CEO大刑伺候。

2）要求市场部提升流量。这如果不配合流量采买的经费增加（流量极其昂贵），可能会逼得流量团队去投放劣质渠道或刷流量，也要小心。

3）全力把流量向移动端迁移，充分利用移动端人均产出GV更高的状况，提升同样流量的GV产出。

有两件事可以做：

1. 与市场部沟通，调整投放计划，把更多的引流渠道放在移动端；
2. 在产品端和运营端发力（如推进Deeplink，设置移动端抽奖或专享活动），把PC端和Web端的用户向App迁移。

4）通过产品和运营的协作，大力建设导购频道和个性化推荐，提升人均产生的GV数量。

5）通过产品端的努力，提升转化率。转化率当然也可以通过让业务线降价或者准备更好的选品来提升，但这方面留给业务线，我们先看产品能做的事情。

1、2两个方向都与产品和运营的工作基本无关，我们的目标，自然放在3，4，5，内部挖潜，先看看能不能有机会弥补差距，避免迫使公司下调营收预期或为市场部大幅增加费用。

当然这是个三年前的项目，对于今天的中国互联网来说，第3点，迁移移动端，基本上是一个已完成的工作，PC以及Web端基本是存量经营。

第六步，这是最难的一步 – 仔细计算产品和运营的工作，能够提升的转化率和人均GV。

1）产品端计算：产品主要是通过新项目为平台提升流量效率。当时我的产品策略是“All in App”，所有的产品改造全部针对App端。

• 转化率提升项目：计算可以优化的购物流程环节能带来的转化率提升预期，随后根据销售预期，计算由于转化率提升而可以减少的GV量。这步计算后相应下调GV需求总量。
• 新导购项目：对标竞品类似频道CTR，估算该项目可能获得的Click Mix，并根据该项目特性估算该项目预计带给每个顾客的人均GV，结合首页日活预估，计算GV增量。
• 导购功能优化：根据当前功能对应的GV产出，估算优化后的GV提升幅度。
• 移动端迁移：在自然迁移的基础上，计算产品做法可以带来的App端迁移增量，并计算这部分增量可以带来的GV增量：（App端人均GV-PC端人均GV）*迁移增量

通过上述产品效果计算，一端下调了GV需求量，一端提升了GV产出量，差距被大幅度缩小。

有哪些项目可以提升这些方面，是一个非常广的领域，大家可以参考我在#

徐霄鹏，微信公众号：产品遇上运营。。亚马逊高级总监，产品、中央运营及增长团队负责人，前京东、携程高级产品总监。精通前台产品、运营及用户增长等领域。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！