产品经理说「产品经理30讲」

今天给大家普及一下产品经理说「产品经理30讲」相关知识，最近很多在问产品经理说「产品经理30讲」，希望能帮助到您。

2017年入职，2019离职，2年社交产品后台的工作，让我对后台产品有了很多思考与总结；汇总成这3万字，分上中下三篇发布，此为上篇。希望能对大家有所帮助。

最近在找工作，所以利用课余时间，将最近一份工作的经历进行了回忆和整理，供多年以后自己翻看自己的成长路径。

之前主要工作与中后台系统的供给端和订单中台，小有成就与心得，如果有类似方向用人的金主爸爸也可以随时联系我。

一、企业背景

开始之前，需要稍微花一点时间看背景和业务，否则下面做的事情将不好理解。

目前我在的公司（现在是前公司了），是社交广告领域。社交广告的意思是在社交平台上利用网红做广告，像微博、微信、抖音、快手、小红书这样的平台都是社交平台，在这些社交平台上面会存在许多KOL，这些KOL也就是人们常谈的网红，但是习惯还是叫博主。

我们的定位是中介，介于广告主和博主中间，是一个双边交易平台（也就是服务于双边市场）：博主带着需求和钱来到市场的一侧购买受众的注意力，在另一侧售卖他们的注意力换取报酬；博主能够聚敛的受众注意力越多（粉丝数），广告主就越有可能在那个博主身上花钱，并且愿意花的钱也越多——我们的生意模式也就建立了。

越贵越容易被青睐——换句话说就是“被证明越有效”。所以我们面向的主要客群是中高端类的品牌客户群，像宝洁、京东、雅诗兰黛——因为他们买得起。

与之相对的，我们面向的主要博主群体也是中大型博主或MCN机构，像papi酱、办公室小野、二咖传媒、大禹文化。越大的博主越容易被青睐，也就越贵，只有越大的客户消费得起——双大的客群模式也就构成了。

二、面临问题

双大面临的问题是受夹板气：

对客户端非标的业务，客户来了想做什么都可以——我们拿到需求，进行策略匹配以后，客户选中博主，下单后执行开始联系博主端；博主端可能都不会来平台，我司对于他们而言也只是一个订单渠道商而已；本身档期很满，规矩很多，要很久再返回平台，定价没有标准，权益模糊。客户端认可后再进行支付，达成交易进入制作环节，若客户端不认可则全部作废。

从流程来讲，这是很低效的行为。而且信息越来越透明化，博主自己在简介留联系方式，社交平台构建自己的交易平台，双方很容易就能抛弃公司进行交易。

三、护城河

目前我司还没有被抛弃，核心的护城河基本上存在于3点：

高效、高质撮合需求和博主：当博主越来越多，需求也越来越多的时候，势必需要出现一家解决流程中效率问题的公司；采购方的强大：我们建立了数万家机构的商务合同条款，这让我们在商务上的效率是非常高的，因为有量在，所以我们能拿到比较低的市场价格，对客户利益有较大保障；公司的金融能力：大客户多需要账期，意味着公司需要提前垫款，而一般公司是无法承接这样大量的金融服务的。

这就是公司的3点立足的地方，也是公司可以持续十余年的原因。

随着持续大客化，问题愈发严重。

核心问题不是上述所说的私单，而是为了预防私单建立竞争壁垒的第二点价格——大客持续压价，无从喘息；再加上无数非标需求和高冷博主，交易平台效能没有被真正释放，边际成本居高，导致利润进一步削薄。

为了补救，在其它客户身上增厚利润率，导致第二点价格优势反而逐渐损失，客户逐步流失。

所以，3年前自上而下公司启动变革——这也是为什么上面说重构供给端找不到原因。

但销售端的问题十分明确的，比如除原有的客户必须来到我们平台上的模式，拓展为SaaS版，也可以通过API的形式接入到客户自身系统里，便于挑选、下单、生成财务审批单等动作。

四、业务流程

简单讲一下我们的整体业务流程，让大家有一个大体的认知：

我们的系统都是2B的系统，客户都是内部注册制，注册登录后会进入客户的后台页面，然后进入需求描述。

和一般2C类的知道搜索内容不一样，2B类一般不知道搜索内容，但是他们知道要做什么——比如在什么平台，什么品牌，找博主做怎样的事，这也就是我们所谓的需求描述。

需求提交后会有匹配模型进行匹配，这是整个公司的灵魂；之后的流程近似电商，先根据需求，出现博主列表（商品搜索结果页，非派单制非标性导致），进入博主详情（商品详情页），可以加入选号车（购物车），也可以立即下单，下单必须选中商品的SKU，进入支付信息确认页（商品信息核对页）。

后面的流程和电商不一样了：

先支付保证金，支付后订单正式进入交易流程，执行中心首次介入（执行中心整个的作用是负责这笔订单的沟通/协调/制作/发布的护航）；博主回复对这个需求的确定制作价格，或者觉得我做不了取消订单，若取消客户可以免责收回保证金；博主回复价格后，客户支付尾款，客户若支付，博主根据客户需求拍摄或者创作，执行中心持续跟进。

在支付前客户也可以提出驳回，也就是再次协调，一般都是明确费用明细和压价；支付前客户也可自己取消，也可能博主取消，若客户自己取消，需要客服中心判定客户责任，也许会从保证金中扣除部分为平台服务费。

客户支付后也创作完了，客户进行验收，博主发布至社交平台；客户进行确认或者投诉，客户确认后进行评价，订单结束，推送至财务结算流程。

客户也可以不确认，觉得不满意进行投诉，相当于电商的退货申请，客服中心介入进行处理；三方协商后进行退款或驳回等动作，订单完结，推送至财务中心。

——这就是我们大体的流程。

通过流程讲解可以知道：我们的商品是博主，所以供给端产品的主要定位就是为销售提供子弹——博主，核心功能为梳理入库流程、评估不同博主的能力，审核、上架，分门别类进行售卖，不断给前端销售这把枪提供源源不断可消灭别人的子弹。

五、采购概述

供给端最重要的功能之一就是采购。

基于我们的业务形态，采购指的是和博主或博主所属的机构，建立商务合作联系的过程。入库指的是将博主信息，放置在平台上，可以供广告主进行挑选，下单。

所以我们和电商所指的采购是不一样的：没有实体货物往来，也就没有钱款的往来，采购的过程基本就是入库博主的过程。

而后面也有仿照电商的一些系统模块，比如库存管理、采购预警等，但比电商简单得多。

比方说库存管理，库存就不用完全锁死，我们只需要提示客户风险就好，毕竟交易权最终还在博主手上——也就不用做超卖、调度层、仓库层、增减冻结状态消耗解冻等；对采购预警来讲，也不会有传统电商麻烦——下了采购单，还要走调度、仓库管理、财务、库存等流程。

供给端的主要用户是外部的博主以及内部的博主采购和博主运营，被动采购渠道就是外部的博主注册、录入自己的信息，主动采购渠道就是内部博主采购在市场上进行搜索，代替注册，后续接手的博主运营进行审核、评估、联系、上架工作，后期的运营进行包装标签、客情维护等长期工作。

回顾项目之初，项目并没有报很高预期，项目是自上向下驱动的，定位是仅仅完成政治目标抄前任。因为系统已经9年多了，需要接入更多的订单，压力无法承受，所以定位仅仅是重做一遍原需求迎合新技术架构就好。

但是我不太甘心——不能为了重构而重构，务必要解决实质的业务问题。

数据的理性思维解救了我。

六、做事节奏

接下来我就要切入供给端重构这件事了。

一般我做一件事，需要4个环节：定位分析、需求分析、框架结构分析和表现落地。

定位分析包含：需求是解决什么问题的，服务谁，有怎样的价值；需求分析是大体的功能分析：操作流程，角色流程，定义优先级和roadmap；框架结构分析是具象的功能，由什么页面构成的，页面上的信息结构是怎样的；最终是表现落地——画原型、写PRD、沟通研发、沟通UE等；所有完成以后持续跟进直至上线，上线后的数据持续收集反馈，再优化。

——这是整体的做事流程。

定位分析：供给侧产品对公司定位非常清晰，服务外部博主和内部运营，用于帮助内外的高效变现；但是供给端需要重构，解决的问题在当时并不明确——到底是这次重构有明确需要解决的问题和目标，还是抄前任，重做一遍迎合新技术架构，新系统方案就好？

为了明确需求，唯一的手段就是理性数据分析。

1. 数据呈现

动销率是跟供给端最相关的数据。

当时的月动销率大约是0.3%，数据量级是几十万的博主，有卖出动作的大概是几千。

（这个动销指的不是交易完成；如果是交易完成会更低，仅仅指的是有下单行为的，后续还有可能被取消）

无论怎样，0.3%的动销率都不是一个正常的数据——正常情况下一个良好的仓库，动销可以做到30%-50%。

基于此数据，可以分析出的单边结论是：博主没有经过有效的筛查，被批量进入库内，导致分母太大，动销率不理想。

通过回顾前两年的政策佐证了此猜测结论：在前两年，公司的战略为抢占市占，抢占市占取决于抢客户。当时公司是销售导向公司，对客户需求把控较弱，并不能预测客户端需求是什么。

也有时局因素——当时社媒广告刚刚兴起，一切都在摸索，怎么玩都是未知的。为了能让客户的需求可以随时被反馈，也就先入进来再说了。对应地，在前两年的采购部核心KPI是入库数量，完成KPI的驱使下，有如此巨量的入库，也就不难理解了。

当大分母因素，通过逻辑去掉的时候（过去一年内有过交易行为的博主），再去看动销，果然上升至12%左右了，但是距离合理情况的底线仍有很大的距离。

再来从交易流程中数据看：从表达需求到下单，再到支付，再到制作完成发布，再到确认。

首先是需求到结果集准确率：一般情况下我们的准确率能在50%左右，也就是假定出现100个搜索结果的博主，有50个左右会被有效点击查看，有效点击的意思是页面滑动、停留时间、有点击交互行为。

翻页使用情况基本和准确率相符：翻页中位数在17左右，搜索结果集总页数中位数在27页左右，深度在63%左右。

筛选使用频次较高：单次使用后，准确率能提升到60%左右，翻页中位数降为6左右，搜索结果集总页数中位数在13页左右，深度在46%；组合筛选后更为降低。

综上可以推断：我们的核心撮合匹配模型的效率是很高的，对于客户需求的画像和博主画像较为精准，客户基本上有一半的博主都被有效查看。

继续向下验证此结论：

加购率（我们也有加购率）：假定分母是100个博主，一般加购中位数在60个左右（这个和需求强相关，我只是举某一类需求的样例，需求和平台/预算/玩法/档期等强相关，可能需求出来博主都没30个，可能客户会加购十来个）。当时分析的时候是“分需求等级，均看一遍的”——针对上述这个需求类别，所以我们的加购率中位数在60%左右，很高了。

最终转化为待支付状态的订单：从加购到下单看，下单率18%左右，也就是18单；总体的下单决策时间中位数在3-4小时左右，包含了加购时间和加购后下单时间，惯性习惯都是看到差不多的资源惯性加购，在购物车里精选，这个时间会比较长，所以对于一个商业行为的决策，相对还是很快的。

由此基本可以验证：出现的博主是没问题的，供给端的梳理似乎抄就可以了。

最后我们又看了一下订单层面的数据，发现了问题：

在业务重构前，下单后执行中心就会接手进行服务联系博主，无偿下单。博主会告诉执行人员这个需求多少钱，修改订单价格后客户可以进行支付，支付后订单真正生效。

这时候看到一组数据：

支付率，下单18单，只有2单被支付，支付率占比下单数的11.1%。

那问题出在哪儿？

详细拆解来看：

第一轮博主可能会取消订单（博主取消率大约是20%左右，还剩15单会回给广告主），15单里最终只有2单进行了支付，因此客户原因的取消占比80%。

博主端取消率的20%里，主动取消的大概占70%，被动取消的占比30%（主动取消就是这需求我做不了，不接；被动取消就是订单过期自动取消了）。

详细访谈博主和博主运营后，得出以下两条关键结论：

我司只是博主的接单渠道之一，他们在市场上有非常多的订单；我们对博主端的约束力出现问题，约束力主要取决于订单多少，而当巨量资源的时候，需求还是还是那么多的时候，后果可想而知。

再回过来，客户80%取消比例——所以这里到底发生了什么，下单的动机是什么，回复后的订单满足了怎样的下单动机？

结合内部访谈执行和访谈客户，可以归因出2个最大的原因：

客户通过需求联系一下博主，其实并不是真的要下单，有点像发消息没回复，电话震一下，后面才有真正需求跟上；下单到支付，比例大约只有10%，大量订单被取消。

这是很严重的问题——因为我们的业务是很特殊的，业务有着很强的非标性，导致少不了人的沟通和参与，而且我们还是To B的企业，这个属性更被加剧。所以，客户在下单后，就要马上有执行人员介入（负责联系沟通三方，非标需求的一单一价），公司成本非常高（从来到回大约要2天，而且可能是多个执行，订单被取消后的效能损耗会非常高）。

这是对三方都非常不友好的行为：

浪费了平台的系统和人员资源，没有有效降低平台的边际成本；浪费了客户的时间，也浪费了博主的积极性——可能优质的博主每天都被过度打扰，时间久了就可能被动从高配合度变成低配合度。

第一个问题的解题思路，相对简单，也就是清洗。针对这个问题，与运营一起设计博主评估模型和博主巡检模型，分别在入库前拦截不值当的博主和在入库后清洗卖不出去的资源，以保证库内博主的优质和降低系统维护成本。

第二个问题的第一个原因相对简单，就是失去对博主约束力了。当博主约束力持续下降的时候，客户对这件事的印象才会持续上升，直到到达某个临界点，变为客户印象中的必然事件。所以对于约束力不足的问题，解决思路的一个方向是把因果关系的因去掉，利用已经实现的评估模型和巡检模型，将博主自身变量因素降为最低（也就是自营签约博主，毕竟再计算好也都是别人的）。

不过这个自营目前应该被放弃了——因为签约好博主成本太大，签差的博主，客户不会用，卖不出去就是白养着。

目前对约束力的调控，是在于增加约束力——也就是让外部博主多接些订单，单多了约束一定强，就是评估模型和算法策略之间的互相服务了。

第二个原因，有两个方向：一个是提升支付率，一个是降低下单率。

提升支付率是行不通的，因为客户的预算cover在这里，无论你怎么引导他支付顺滑，毕竟和2C不一样；那就剩下的一个方向——降低下单率。

所以我们继续思考：究其客户下单的动机是什么，有什么一定要通过下单？满足下单动机。

所以只能选择后者——降低下单率。

如何可以有效降低下单率而对整体收入不受影响？

从原理进行分析后发现：我们之前由于业务的非标性，卖的都是非标品；非标品的特性是不稳态的，当商品也就是流程终点不稳态（有多种可能性的话），意味中间的过程只能通过堆砌数量而获取期望结果，也就侧面造成了表象层的数据结果，那么问题会急剧收敛。

稳态下的标品到底是什么，长什么样子？

回归到客户行为层面不难发现：通过下单选择非标商品，服务后返回的信息客户会进行最终决策，这是符合标品化之后稳态特征的——服务后返回的信息与服务前信息差导致商品从非标变为标准商品。

举个例子：

宝马汽车客户来了，说要做个case，通过我们的需求匹配模型，算出来papi酱可能适合他，但是这时候能证明的就是这个博主适合，真能做否，没办法知道，只有博主自己知道。所以客户只能下单，说papi酱，需要你给宝马汽车做一个植入的软广，能做吗？多少钱？我能拿到你的肖像授权吗？然后在执行问过一轮之后回来之后的信息是：能做，10万。这时候客户可能觉得，有点贵，算了，导致订单被取消。

拉高前置决策成本，减轻后置决策，减少信息经过交易系统的浪费，对于下单率可能同样会有骤降，原理是一样的。

还有关键指标是预算消耗度，也就是——客户预算是否被有效、高效地消化完毕了。别到时候下单率是降低了，但是钱也不花了。

所以数据预期，最核心要观察这3个指标以验证整体方向的正确与否（当然博主端的取消，客户端取消率，同样要看作为参考）。

上述所有数据均为模拟数据，并非真实数据。

2. 执行 To do

根据数据和分析最终汇总，可以总结出几个核心的事件：

非标品转为标品，收敛不确定性，用于满足下单后取消的情况。标品信息应当包含订单内的确定性信息和与需求相关的高度不确定信息，代表的就是价格，所以确定性信息要完整展示，不确定信息要尽量精准通过模型预测；强约束博主，如果不能通过订单约束，看能否通过自营签约约束——后续成本过高几近放弃；通过建立分级模型，将库内巨量博主重新清洗，将不值得被维护的博主清洗下架、冻结，降低系统消耗；目标性采购工具，结合分级模型和市场的新增博主，予以采购的决策建议，提升真实动销率；有偿执行需求，也就是保证金制度，发布需求有偿化，对应的服务也就有偿化了，会让系统的无效损耗有人买单，也会降低博主被打扰的频次。3. 落地节奏

公司对于第一个问题并不是没有察觉，但是只是当时采购方过于强硬，没有人驱动。

我最终可以驱动的原因是利用同理心，深入敌方内部：

先协调运营变更KPI（如果KPI不变啥都白搭），先将入库数量拿掉，拟定变为动销以考察采购的入库质量，但现阶段执行只会引起强烈反抗；范围性质达成一致，比如和采购商议，持续3、5年都没成交过的博主，就下架了吧，真卖不出去，而且你看KPI也变了；打成一片，掏空采购同学智慧，比如评估一个博主是通过几个方面评估的，如何感知到这个博主肯定能成单，有经验的采购一眼便知；根据采购的智慧，得知博主的内容质量与商业度非常重要，内容质量越高的，他入库以后的商业素质也会比别人好，卖出去的概率变大；协调AI进行模型的打分，并且用库内的博主测试一下，直到与大多数人相符，阶段性目标一致；利用AI输出的模型数据为基础，实现分级模型，将博主有效评级，继续用库内博主测试，仍与大多数人达成一致后；开始清洗资源，因为这个结果是和大家达成一致后才推行的，故此阻力小很多，但还是有，是为以后的业绩而顾虑；改装枪没收了，劣质子弹销毁了，那也要提供之前没有的利器才能让整体效率更高——那就是市场的爆款博主监控和竞品监控：当工具发现市场上哪些内容传播蹭蹭上涨时候，但是这博主还没入库，就会进入内容评估模型进行评估，达到入库标准后给采购提供精准打击的利器；以及监控竞品平台与我方博主交集和非交集，着重开垦非交集区域（当然也要予以评估后进行入库决策，没准竞品也只是为了KPI入库）； 最后，问题基本圆满解决；这时候再尝试将动销率列为KPI去观察，最终成功推行。

从第一件事里对我最重要的帮助不是成功落地推动了，而是服务第二件事；第一件事相比第二件还是小，与采购同学打得火热，调频一致，获取信任，大家在一个战线向前冲的，所以第二件事相对就容易很多。

第一个原因解决起来相对容易，实际就是失去博主约束力了。当平台对博主约束力持续下降的时候，客户对这件事的印象才会持续上升，直到到达某个临界点，变为客户印象中的必然事件。所以对于约束力不足的问题，解决思路一个方向是因果关系——把因去掉（也就是利用我已经实现的评估模型和巡检模型，用于将博主自身变量因素降为最低）；采购还自驱动的往另一个方向努力，控制约束力，也就是自营签约博主（毕竟再计算好也都是别人的）。

不过，这个自营目前应该被放弃了——因为签约好博主成本太大，签差的博主，客户不会用，卖不出去就是白养着。目前对约束力的调控，是在于增加约束力，也就是让外部博主多接些订单，单多了约束一定强，就是评估模型和算法策略之间的互相服务了。

第二个原因通过聚焦后发现，不稳态的是账号，将内部服务后获取的所有信息用一个词可以概括成：服务能力，所以让不稳态的商品变为稳态的是博主的服务能力，比如上述papi酱的汽车客户的植入广告创作能力。

问题截止到这个阶段，就很具象了；服务能力有哪些，如何获取，怎样落地，可以逐步解题了：

掏空运营脑子、抽象历史订单以及供给端的访谈等手段，挖掘结构，因不同渠道、立场、能力的原因，无法结构化表述，产品能力必须要结构化整合；根据第一步的结果，设计商品信息架构，最终其实发现和电商商品信息结构很像，我们也就借用了电商系统商品信息的结构形式，SKU SPU——我们把SPU设计为商品，也就是博主的账号，非标；在此基础上，新增服务能力也就是SKU，继续收敛，将第一步获取的信息按照架构设计塞进去；A/B测试用于验证结果，也就是协调采购补全一部分的博主SKU属性，其它其实都有，没好关系真干不了，是出人出力；结果返回超预期，向上汇报确定最终重构方向，达成一致后，构思开始落地；协调入库抓取服务、AI模型，建立入库流程，根据采购智慧设计博主估值模型，当SKU SPU 价格 库存信息完整后，联调测试，抓库内号进行调整；由于商品特殊性，信息分为2类，一类是确定性信息，一类是不可确定信息。确定信息是客观呈现不可变的；不可确定信息是与需求本身高度相关的。以我们的业务为例有2个，一个是价格，一个是档期，也就是库存。所以对于确定性信息，尽可能前置化，准确、完整、多维的呈现，对于不可确定信息，我们结合历史数据和相关维度比如周期性、库存量，设计相关预测模型解决，也就是博主报价模型和库存模型。由于这两个信息的特殊性，没有把它放在SKU和SPU里了。最终上线后重组成博主信息结构，完全满足客户所需。最终上线完成博主信息标品化的工作，考察关键性数据，下单率、支付率、预算消耗度。

后面整体我按照入库流程进行落地的表述，评估、巡检等解决第一个问题的手段，均串行在整体流程中。

4. 信息结构

上述已经说过了，我们的SPU是博主，标准化产品单元。比方说papi酱，SKU是papi酱下面的一个服务能力——快消饮料的搞笑植入广告；SKU最终定义是由博主的“基本信息 分类 供应商 属性”构成的。

其中：

基本信息就是你能看到的一切，像头像、昵称、简介、粉丝数等；分类是机器清洗出来的这个博主的分类，共8大类目，美妆、汽车、母婴、快消、游戏、知识教育、美食、vlog、其它；供应商是指的这个博主是哪个供应商提供的，或者是MCN，背后挂着的是供应商一系列信息，后面再详细说供应商管理的细节；属性分为销售属性和非销售属性，销售属性对应着规格信息，是最核心最重要的，销售属性也叫能力，包含玩法，平台，行业，玩法运营抽象收敛的固定几类，比如种草、开箱、评测、换头像等，这个是销售直接相关属性，不可修改。比方说客户要微信上的种草玩法，客户是美妆客户，那么就按照这个条件去匹配符合这个销售属性的货品，对应的输出规格信息。规格主要包含业务强相关的通用规格有物料、权益、制作周期，非通用规格有位置（微信）、形态，备注。物料就是物料的一些规格，你做什么需要提供怎样的图片，几张/大小/需求描述等；权益就是你在交易过程中，能改几次脚本，改几次内容，有没有内容分发版权，我是否承诺效果之类的；制作周期是博主去制作这个案例要几天的时间。非销售属性一般是比较通用的，与本次需求无关的了。目前有是否提前下单锁档期，是否必须提前给钱，是否有竞品协议，行业、品类、品牌等。

——这组信息共同构成了一个货的SKU。

我们的页面展示是以SPU为维度的，也就是切换SKU，页面也不会变；所以SPU在上述基础上，只增加了对博主的运营包装和评价。

包装一般是人工运营标签，会对应一些动作：

可能是专题的聚合，会给到客户一张专题页比方说本月最佳的母婴博主，尽量让客户从这里去选择；特殊的页面呈现，比方说SKU变红字了，或者页面特殊位置增加了一些描述语，页面的样式之类的变化；机器的包装标签，系统根据一定的规则运算出一个标签，呈现在博主的搜索列表和详情页上，就没有像人工那么丰富了；当然也会有都没有的。

评价是在交易结束后收集的重要信息，对商品中心的重要意义在于完整商品信息，稍后详细介绍。

构想后，基本可以将原有的非标品转化为标品，从而收敛不确定性。

papi酱可能有美妆种草、美妆开箱、游戏植入、快消植入能力，客户选中游戏植入服务能力。客户点选后，需要客户提供的物料规格（几张图、多大、必须包含什么、需求明细等），以及客户能获得的权益，同时我制作这个内容需要多久时间。

但是对于商品来讲，少两个东西：价格和库存。

这两个已经说过是不可确定信息，稍后再讲。

5. 通用库

介绍完商品信息架构，也要介绍实现商品信息架构的底层通用库。

从整个商品库而言，我们没有做通用库像属性库，我们业务来讲能力（SKU）数量还是有限的，虽然SPU一大堆，但是SKU也就顶天了几百个。我们目前只有供应商库、分类库、规格库、标签库是属于通用库，这个是属于服务性质的，不太参与业务；供应商库我在稍后详细介绍，规格库上述基本也有大概介绍，剩下的就是分类库和标签库。

本质来讲这两个是最重要的，如果没有它，啥也没法干。

分类库和标签库原先都是在标签库里的，只不过分类太过重要，把它拆出去专门列为分类标签进行维护和展现。主要包含标签的类别，分为风格、业务、品牌、品类、分类几个类别：

风格目前有剧情搞笑、温情、MC喊麦、励志、科普等；业务包含业务线比方说非标业务、标准业务、外来合作业务等；品牌标签就是品牌了；品类标签目前包含2层，美妆，修容，眉笔，意图是找到每个博主都做过哪些品类的内容，供推荐引擎推荐博主和标签引擎打标签；分类目前就8大分类 其它，和品类是上下级关系，分类是一级，品类是二三级。

所有的关键词必须包含：中文、英文、拼音、类别、中文定义、同义词、近义词、关联词。

关联词一开始是人工关联；随着量级越来越大，人工 机器识别参半，机器运用AI的NLP技术，将同框出现的关键词，按照频率清洗，人工核查，赋予。所有的关键词库都是最底层的服务，供博主信息维护、AI模块、推荐模型、搜索、机器打标签模块、需求画像模块和一些其它服务共同调用，以保证口径统一。

6. A/B test

当上述信息架构梳理完毕后，还不是落地，先要去做A/Btest——毕竟这是一个系统级的需求，如果错了那就傻了。

如何做A/B也是问题：A肯定是目前现有信息结构面，B是新的，如何在不开发的前提下实现B？

那就是半人工化，大体是这样做的：

首先，我们的思路肯定是通过人工录入当时系统内没有的信息——但是录入是有范围的，绝不可能所有博主均录入。那么我们就从需求端反推博主：当前怎样的需求比较多，我们应该准备怎样的博主去配合？收敛需求端和博主端。

将某类需求锚定后，选出博主，要博主运营帮我们传递给到博主（自然都是线下先问一轮回来记录的结果），最后把回来这些SKU信息手工写入这些博主库中；整个大概选了600多个博主，花了一周左右集齐。

测试阶段可以达成的效果是：当有客户来，输入需求，若需求为目标类型需求，则出现测试结果集，测试结果集至少保证600个博主，即结果集分为AB两类。

传统的A上面信息仍为原始信息，包括博主基本信息和博主过去参考价以及评价和历史案例；B上面的信息包含除上述信息外，博主有什么服务能力（SKU），也就是能帮我做什么事，我能获得怎样的权益，需要我提供什么，你制作需要多久，线下摸索回的预估报价是多少钱。

下单后的支付流程，和A其实是一样的：我们没有把参考价直接变为SKU的价格，档期因为和下单时刻相关度太高，也就没有收集，应该不会过多影响最终结果的准确率。

这样保证ab在同样的场景和条件下，被同样的决策者看到，我们去观察前期锚定的数据指标。

结果显示：同比下，a类客户基本在3.5小时左右，和之前的3-4小时数据相符；b类客户在信息前置后的下单决策时间由之前的拉长到2-3天。

后续去访谈客户得知，这段时间不是在平台上，而是将这些目标博主的情况直接导出给予领导层汇报决策了，所以时间很长，客户认为这个价格就是准确的支付价。

数据符合前期预想，但是也拿到一个tips：页面一定要突出是参考刊例价，线下测试可以把控住，但是一旦批量，都造成误会不是闹着玩的。

根据客户反馈的数据，去补了一个数据——添加购物车后的充值行为和金额，发现b类客户远远高于a类：b类几乎占比80%以上，a类占比约为0%；因为大家都习惯了，在博主反馈后再支付充值，而且也不知道充多少，b类对于平台的资金沉淀更长。

再看下一组数据：

a类客户加购率基本和之前持平，在57%，下单率占比大约为35%，与之前的30%近似相符，b类客户加购率高达79%，可下单率低至4%——数据也是和预测相符的。

加购率的提升推测有可能是由于数据的完善，导致博主都较为符合客户的需求，全部都要暂存，后面慢慢再选，客户将原来需要下单才能完成的试探比较的动作，消化为在自己的购物车内了；而下单率相比下骤减，贴合了之前的猜测结论，意味着下单变为谨慎了，下单即成单的趋势逐渐形成。

再来看很重要的预算消耗度，主要是在输入需求的时候收集了预算，最后和实付订单价作为对比即可。

可以看到：

预算消耗度可以稳定在90%-110%，甚至有些还会超出；和a组对比，a组平均只能到70%-90%。

最后辅看下支付率：

本次测试a类总支付订单数为2个，与之前认知一致；

b类支付数也为2个，意味着需求数恒定，数据可信。

先看取消率情况，计算有效单：

a类博主取消率与认知样本相符，为20%；

b类博主没有取消的情况，为0%。

而最终看的是支付率：

a类下单20，有效16，支付2，支付率为12.5%；

b类下单数为3，有效3，支付数为2，支付率为66.6%。

结合所有数据看，毫无疑问b类是奏效的。

为了避免偶发性，持续观察将近一个半月，最终进行推进的决策。

上述所有数据均是模拟数据，并非真实数据。

最后小广告：目前还在找坑，有需求的老板随时骚扰，中后台方向/供给侧/中台订单，谢谢观看。

#专栏作家#

吴邢一夫，人人都是产品经理专栏作家。5年产品经理工作经验，需求、用户、数据有深入研究。欢迎交流想法，拒绝无意义添加好友。

本文独家发布于人人都是产品经理。未经本站许可，禁止转载。谢谢合作

题图来自 Unsplash，基于 CC0 协议