01、业务架构

从框架层来看，梳理清晰的业务架构，有助于帮助产品经理清晰的了解用户有哪些，解决了用户什么问题？产品的价值，产品的功能优先级？以及要做成这个产品需要哪些资源投入？ 

下边就由草帽小子来介绍如何采用“六层次”方法，进行业务架构的梳理。 

整个业务框架围绕着两方面展开，一方面是用户需求，用户在什么场景下使用画像服务，解决了什么问题，或是说给用户带来了哪些价值；另一方面是画像产品实现，要实现该画像产品服务需要哪些资源，需要哪些部门协同配合。 

1.用户场景价值层

明确目标用户，清晰地知道画像体系设计出来后给谁用，通常画像体系的目标用户有精准营销人员、产品经理、搜索推荐产研、用户运营人员、客服人员等。用户画像体系的应用场景上包含精准广告投放、智能运营、个性化推荐等。

a.精准广告投放

用户画像在精准广告投放过程中至关重要，画像可以完美地抽象出一个用户的全貌，为进一步精准、快速的预测用户行为提供了全面的数据基础。

早在2007年，雅虎就根据画像标签，推出了smartads广告方案。雅虎掌握了海量用户信息，如用户性别、年龄、收入水平、地理位置及生活方式等，再加上对用户搜索、浏览行为的记录，使得雅虎可以为用户呈现个性化的横幅广告。这是画像在独立广告平台上的应用。 

那对于企业来说，使用用户画像进行广告投放，可以精准触达目标用户，提升广告点击到激活转化率，降低广告投放成本。

b.智能运营

传统的运营采用无差别营销、轰炸式营销的方式，对每个潜在的用户一而再、再而三地推送同样的信息。从用户角度来看，用户对这种轰炸式营销十分反感，用户体验差；从企业的角度看，这是对企业成本的极大浪费，隐形成本开销巨大。

如何将合适的内容在合适的时间，用合适的方式推送给合适的用户？这是困扰运营的一个问题。

而用户画像平台，可利用其人群标签能力，帮助运营结合市场、渠道、用户行为，对用户展开有针对性的运营活动。其中端内触达人群，可采用个性化推荐的方式；端外触达可采用push/短信推送的方式。

c.个性化推荐

应用的运营者，可以通过个推用户画像中的性别、年龄段、兴趣爱好、浏览购买行为等标签，给用户推荐不同的内容。如今日头条上的个性化文章内容推荐、抖音上基于用户画像做的个性化视频内容推荐、淘宝上基于用户浏览行为等画像数据做的个性化商品推荐等。

2.产品运营资源层

a.产品/服务层

梳理清楚了用户在哪些场景使用画像产品，那画像能提供的核心功能也就十分清晰了，其核心在于数据采集、用户ID标识、标签体系、画像系统。

b.运营管理层

而要实现这个庞大的画像体系，需要多方协作完成。在组织层面，包含产研团队、运营团队；在绩效层面，需要对清楚组织的绩效目标，多方协作发力；在系统层面，列举出画像体系相关联的系统；在流程层面，需考虑整体研发流程，画像体系与其他业务业务系统的对接流程； 

c.资源层

考虑到哪些人来做，服务器资源成本，是否需要购买第三方数据等。 

02、产品架构

业务架构会更加宏观，并注重自上而下，从业务场景应用层面来进行整体架构的搭建；而到了产品架构这一层面则更注重于落地，自下而上盘点清楚数据现状来搭建用户画像体系，以满足核心业务场景的需要。包含数据采集、ETL数据预处理、数据分析与挖掘、画像系统建设、应用层面。

1.数据采集层

数据采集讲究大而全：要想更全面的描绘用户画像，则需要想法设法采集用户相关的所有数据。

a.业务数据：伴随着业务产生，包含用户的基础信息，在平台上的购买业务数据、评价数据等

b.埋点行为数据：通过埋点的方式，采集到的一些行为数据，如浏览、点击、停留时长等

c.日志数据: 一般是web端日志记录的数据

d.第三方数据：业务线较为单一的情况下，能拿到用户的数据也就不多，这种情况下可以考虑接入第三方数据，如个推数据等，来进一步丰富标签画像 

2.数据预处理：对一些不符合标准的数据进行清洗、转换，得到标准数据 

3. 数据分析与挖掘：对预处理后的数据进行标签建模，得到具有商业价值的标签。

a. 统一用户ID标识

很多人对用户ID标识没什么概念，在用户画像体系建设之初，往往会漏掉这个关键步骤。 

举个简单的场景，阿里是一家包含多条业务线的公司，如电商、金融、广告、文化、教育、娱乐、设备和社交等领域。若是消费者乔巴在支付宝上进行了基金理财操作，同时在钉钉里发布了自己的动态，并在web淘宝上浏览了棉花糖商品。

这个过程他登录了不同的账号，你怎么把这些行为关联到乔巴身上呢？

这里要做的就是统一ID标识，详情可以参考阿里、美团、网易这类的大厂都是怎么建设的《阿里/网易/美团/58用户画像中的ID体系建设》。

b. 用户档案

建设用户档案，前期可进行数仓主题层的建设，将与用户相关的表汇集在一起，建设一个用户集市，包含用户基础信息表、用户行为表、用户交易行为表等基础表。 

c. 标签建模

标签建模则包含不同类型的标签的计算，如事实类标签、规则类标签、预测类标签的计算。

d. 标签宽表存储

标签宽表存储主要为将标签数据统一落在几张大宽表中，如用户基础信息宽表、用户行为宽表、用户偏好宽表等。

4.服务层

服务层需描述清晰画像体系能对外提供的服务，包含业务性服务和系统性服务两大类。

a.业务服务

业务服务包含画像系统需具备的能力，分为画像看板、单用户画像、群体用户画像、相似性人群拓展、标签市场、人群洞察、标签管理如标签上下线以及标签的管理、权限管理等。 

b.系统服务

系统服务主要为接口服务，将用户分群以接口的形式对接至各个业务系统。

三、一尾抓落地计划

在绘制完浩浩荡荡的用户画像蓝图之后，接下来就需要制定切实可行的项目计划，梳理版本计划等，以申请相关资源。

01、版本计划

整体用户画像体系的搭建涉及面巨大，无法一蹴而就，应循序渐进地进行。在制定版本计划的过程中既需要结合业务当前的需要，争取快准狠的在业务上有所应用，如此才能走的更快；也需要考虑系统基础建设，如此才能走的更远。

用户画像的版本计划可分阶段进行，设定每个版本，如V1.0、V2.0、V3.0的用户画像体系建设目标，迭代的时间计划。并依照二八原则，建设MVP版本，先推出一版，快速满足业务需要。

02、项目计划

确定好产品版本规划后，基本的产品形态也就确定下来了，接下来就需要制定切实可行的项目执行计划。

乔巴：这里我感到十分疑惑，数据产品经理还需要负责项目执行计划吗，这些不是交给项目经理去做就好了？

索隆，仰天长叹一声，说道：要知在实际项目执行过程中，项目经理难以清楚掌握相关数据需求，所以在整体项目过程中，其执行粒度会比较粗糙，最后项目的执行结果通常不尽人意。

而为了达到目标上线时间，最后砍需求的事也是屡见不鲜。所以数据产品经理还是需要轻装上阵，把握好整体开发测试运营节奏，衔接好每个关键的节点，这样才能最大限度的保护好自己的需求如期上线。

如上图所示，项目执行过程中有4个关键的评审时间点。

一是立项评审，此时需要项目经理/数据产品经理输出立项PPT，主要包含业务背景需求描述、业务架构、产品架构、产品版本计划、项目执行计划、所需资源情况等。

二是需求评审，需要数据产品经理输出详细的需求说明文档，主要包含需求背景、产品流程、功能需求说明、数据需求说明、原型设计等。

三是提测演示，需要数据产品经理/前端演示开发完成的情况，演示前需要保障页面业务流程、数据上报流程可以跑通，无重大问题方可提测，否则就打回继续开发。

四是产品发布，需要相关运营同学输出运营计划，对外介绍产品功能，使用方式，收集用户反馈等。

制定清楚项目计划后，我们来看看做好用户画像整体计划需要哪些人参与，其配合关系又是怎样的。

03、人员配合流程

搭建用户画像体系的产研人员主要包含，运营/业务产品经理、数据产品经理、数据分析师、数仓工程师、算法工程师、前端工程师、后端工程师、数据测试人员、功能测试人员。

运营/业务产品经理：提出画像需求，说明清楚目标用户、场景及价值，提出明确的数据需求，包含所需的标签名、标签含义及分段逻辑。 

数据产品经理：分析业务方所提的需求，结合画像体系的整体考虑输出产品方案，并进行标签及画像系统的设计，输出功能及数据需求说明文档。特别注意的是，在进行标签设计时，需与运营/业务产品经理共同确定标签逻辑，在验收时也需与业务方协同验收。 

数仓/算法/前后端工程师：数仓工程师主要负责数据仓库结构的设计，数据表设计，以及事实类、统计类标签的计算；算法工程师主要负责算法预测类标签的计算；前后端工程师主要负责画像系统功能层面的建设。

测试工程师：主要负责系统功能层面的测试，以及标签数据层面的测试。

四、总结