本文深入探讨了用户增长框架中的SKU管理策略，分享实战经验，旨在帮助你优化产品组合，提升运营效率，希望对你有所帮助。
请先看完前几张的框架结构。现在我们继续讲到SKU层。一般非自营电商平台，同一个叶子类目下面，比如口红，可能会有几千到几十万个商家发布的商品，有的团队习惯叫detail，有的叫detail page（缩写dp），我统一称之为item。
很多团队误以为item或者item下一层就是SKU，大错特错。这也导致了大量后续的问题。起因很可能是差评或者技术团队把自营的技术结构用到了非自营平台业务。SKU的基本定义我就不科普了。
请记住我们要解决的是两件事：
下图的零食消费场景，解决方案有膨化食品、饮品等。每一个格子都对应一个系列的SKU，再按照配方分到SKU。
我的思维框架如下：
根据经验，一种常见的item，最多有20个商家重复发布，也不足为奇。借助算法的能力，可以自动聚合90%+的item比如对于SKU=色号19的这款口红，有6个不同商家的重复发布。但是解决的用户需求是一模一样的。
很多业务就是这样没有做业务逻辑，直接借助算法团队的能力调优。如同让用户绕过了样板间直接进入库房去挑选商品。且这个仓库包含了所有行业，所有商家。算法团队面临的问题复杂度增加了几个维度，但是效果却大打折扣。
最可怕的是流量管理的问题。下图中流量分配策略，可以视为渠道媒体，也可以视为自有流量的算法策略。一般我们都会设定一个目标，回传/收集所有用户行为的过程数据，向目标归因，得到一个最佳分配方向。定期更新，更新周期以内是固定的。但是由于item的服务能力动态变化，用户的体验不一定是最优的。变化的因素包括但不仅限于：
比如下图中第一个item，被策略选中，优先引流，占了总共的85%。作为商家，发现流量突增后，由于库存是有限的，无法立即捕获，最佳策略是不是应该马上涨价？那么这个item还是最优解么？
如果这个流量策略来自媒体，本质上是把流量分配权从自己手里交出去了。有些业务是用Google Shopping/Facebook Catalog的数据结构做投放，一个item花费超过1000美金，突然下架，是常有的事情。循环跑起来，可以说90%的预算都是无法积累数据的。狗熊掰棒子，太贴切了。
更可怕的是更新的周期可能是按周计算的。大部分平台最细颗粒度都缺数据，但是N个item，决策用的数据也被分了N份，数据更稀释了。再牛的算法，也做不出好的成果。
采用我的框架就可以解决这个问题。因为所有的item都提前聚类为SKU，分流的目标是SKU，解决了用户的需求。下一层逻辑才是考虑内部如何分流。
本文由 @达太 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。