阅读指南

受众人群：B端初级产品经理

阅读收获：

B端产品需求挖掘的一些技巧；
了解用户标签/画像的一些业务知识。

手上负责一个和数据方面有关的B端系统，在日常的产品规划当中，没有关于“用户标签”方面的规划，突然接到一个需求：需要考虑如何在现有的平台中，新增用户标签的业务，让用户在分析当中使用这部分数据(得，又是一句话需求，是多少有点懵逼的)。

Fine，那就开始梳理吧。下文将从“前期调研”、“需求分析”、“产品策划”及“效果追踪“等关键步骤进行说明。

一、前期调研

1.1 概念定义

首先，我们先明确一下，这次的需求涉及的概念有哪些。为什么要了解呢？因为对于需求的挖掘是建立在对任何事物的认知保持清晰和统一。如果对于需求涉及的理念不熟悉且认知有偏差，那么后续的任何分析都有问题的。(敲重点！！)

很明显这次需求要在现有的数据分析平台中，引入用户标签的数据，并以功能化的方式，辅助业务用户使用。而这里有几个关键概念：

(1)数据分析平台：此次需求的载体是基于这样的产品系统去思考。

(2)用户标签：需要了解“标签”到底是什么，业务流程是什么。在此之前因为兴趣了解过“标签”的一些知识，但要真说出来它到底是什么，我还真说不出所以然。那么我应该怎么先去确定概念呢？

行业分享：通过网上获取，初步对“标签”有了一定的认知。
调研访谈：行业有行业的说法，但真正了解的，就是应该从原来提供这个业务的同事去了解。所以采用了访谈的形式，分别从技术、产品及业务类型的同事去了解。
用户标签：就是用户某一特征的具象描述，比如性别、学历等。而标签因子就是基于这些特征标签建立的判断要素，又比如“是否为男”、“是否为大学生”等等。

(3)功能化：意思就是要产品策划输出功能方案

(4)业务用户：明确此次需求的目标业务对象是谁，他们怎么用。

1.2 业务调研

确定了概念，接下来就需要先了解一下业务的一些基本状况，包括业务的流程及原有工具的能力。

(1)业务流程

显然我们最核心的，就是要去还原业务在使用“用户标签”过程中的每个流程，知道他们是基于什么原因去使用，期间是怎么操作的，最终的效果又是怎样，以及整个链路涉及了哪些环节，都需要一清二楚。

动因：了解客户的标签属性，进行精准营销或推荐。
操作：预先基于业务加工标签规则，然后客户的关键信息传到后台，通过调用接口实时判断当前客户是否符合标签规则，并给出“得分”，符合条件则反馈给业务，告知该客户属于什么类型，接下来业务就可以基于这个结果进行下一步的策略执行(比如广告投放、客服营销等等)。

(2)业务对象

业务人员：提供业务诉求，对目标负责；
产品人员：对接服务，并基于诉求整理标签加工规则；
程序员：根据既定规则进行数据清洗、加工标签；
广告人员：基于标签结果数据对客户进行广告营销，实现业务诉求。

(3)业务平台状况

由于是协调团队外部资源来实现需求，所以业务的资源能力(即天花板)，确定了可以实现需求的上限。经过一系列访谈，我拿到了这些关键信息：

标签数据量：涉及10几大类、20几个细分类别、以及接近上万的标签因子；
标签准确度：每个标签因子都提供了不同客户类型的饱和度；
标签用户：目前现有的标签库是用多个数据来存储客户的信息，比如客户ID、交易ID等等。

1.3 竞品调研

了解竞品，是需求分析当中不可缺少的一个环节，这里可以从3点出发：

一个是目前常观察的竞品对手，是否也做过类似业务；
第二个就是单独了解“用户标签”在市场上的产品表现状况；
业务平台：此前一直提供此服务的业务平台，本质上也是竞品对象之一，只是作为参考对象进行了解。

1.4 调研结论

经过一系列的调研分析，已经有了一些初步结论，对“用户标签”具备足够的信息储备，那么来看看目前的需求已经“丰富”到什么情况。

“OK，一些调研内容已经差不多了，是时候整理并进行下一步的需求挖掘。”

二、需求分析

2.1 需求定义

核心需求：为日常数据分析提供更多维度的分析能力，形成小中台的能力。提高对客户的精准识别和对运营手段的优化，比如提高留存、转化效果。
核心用户：业务、运营和市场人员。
业务目标：主要在于提升客户留存、转化，提高营收。

2.2 需求痛点

跨平台使用服务，操作体验不便；
跨平台服务导致数据跟踪中断，无法持续分析。

2.3 需求价值点

(1)优点

对接多个平台，提供更多增值服务；
最大程度上保持数据在一个平台的流转，减少失真。

(2)缺点

从功能的全面性而言，无法匹配任何一个独立系统的核心服务；
各个环节的服务类型相对单一，且没那么灵活、自定义。

2.4 需求风险

如何确保数据口径的统一性？
用户为什么要使用这个服务(这也是作为产品常常思考的问题)？原本已有这样并且成熟的服务，根本上无法可以完全替代的，所以更多的思考如何在平台上提供这样的一些增值服务。

2.5 需求结论

拟建立画像、推送等功能模块，完成目标用户识别、精准营销；
仅作为功能辅助之一，短期内无法建立成一个平台化的全服务(也就是我这边资源有限，要想完整多个服务使用还是用老通道吧，我尽力了)。

三、产品策划

3.1 产品目标

B端产品和C端产品的最大差别在于，目标思维不一。B端产品注重价值思维，其功能服务能提升业务效率，继而增加效益。而C端注重流量思维，吸引广大用户使用。所以，在确定此次需求的产品目标时，也是基于“价值思维”的立场，也就是切身地站在业务角度。

针对客户分群，筛选更有价值的标签用户
提供标签分布的可视化，整体了解分群的特征表现
连接多个服务平台，提供基础的闭环服务。

3.2 产品规划

因为这样的需求不是短期内完成的，通常情况就是策划一个产品全景图方式，有步骤、计划地完成。至于如何完成，初步可以在第1、2个版本完成基础功能和闭环服务，后续版本在此基础上引入更多的增值服务。

比如：1、2期进行标签数据引入、基础功能规划，3期进行一到两个服务平台的接入等等。

3.3 产品设计

(1)系统设计

广义的B端产品设计，其实是一个线上线下全流程的设计，所以“系统性”的业务设计至关重要。在B端产品设计过程中，需要了解涉及哪些环节、需要提供什么样的基础服务和增值服务，简单的说，就是业务每使用一个服务的时候，接下来都会做什么，一环扣一环，最终满足全链路的服务体验。

(2)设计思量

数据统一：由于“标签数据”对现有系统而言，属于外部数据，我们需要思考的是如何实现兼容，只有两者做到真正的唯一对应，这个需求才是真正成立的。那么需要如何实现兼容呢，可以从2个地方入手，一个是内部团队是否有这个资源，可以打通两者数据的关联。第二个就是通过业务入手，沟通是否业务本身就存储这样的关系表。
使用价值：一定程度上降低了使用跨平台带来的不便性；提供了基础的全链路服务，能在一个平台以“数据”的方式持续跟踪不同服务的表现；批量处理目标客群数据；