如何构建好的用户画像平台？

畅谈Fintech 2023-03-17

489

导读画像平台是一个在中台侧应用非常广，在业务侧依赖很重的产品。本文将分享快看在建设画像平台方面的一些经验。

分享将会围绕下面四个方面展开：

1. 画像平台产品架构

2. 快看的建设经验

3. 画像平台应用案例

4. 总结和展望

画像平台产品架构

上图是基于快看数据中台画像平台产品的理解和定位整理出来的产品架构。

画像平台首先是服务于业务的，运营可以基于画像平台对单个用户或者人群包做画像的洞察，平台服务的业务应用层包含：

（1）个性化推荐：它对画像的使用是非常重的，能够基于每个用户的画像去做千人千面的内容分发。

（2）精细化运营：产品运营对用户做精细化营销的时候，会使用画像平台的人群圈选，依赖平台的人群洞察分析能力。

（3）精准营销：商业化侧如精准营销，会依赖画像平台，针对内容或者产品特点，精准触达一定偏好的用户，提高营销效率。

（4）获客推广：渠道获客推广对画像平台的应用也非常多，依赖也很重。

画像平台产品服务层的功能一般包含如下这些：

（1）人群圈选：指根据用户画像的标签或者特定的维度筛选出需要使用的人群包，然后对人群包中的用户做一些特定的操作。

（2）人群计算：对多个人群包进行交、差、并等操作。

（3）人群洞察：对特定的人群包基于用户的标签或者维度去分析其分布以及特点规律。

（4）人群包管理：画像平台上能够清晰有效的管理创建出的人群包，进行体系化的管理和展示。

（5）标签管理：画像平台最重要的信息就是用户的画像标签，需要对这些标签进行一个体系化的管理。

（6）Look-alike：快看数据中台在建设画像平台的时候，这方面的诉求不多，公司的广告业务自己实现了 Look-alike 功能，因此这里不做详细说明。

（7）功能 API 和画像查询 API：画像产品和业务的对接中，会收到业务侧对画像平台功能 API 和查询 API 等 API 接口的需求。有了 API，运营系统或营销系统能够便捷的接入画像平台的特定功能，使用画像平台的人群画像。

建设画像平台，需要实现对数据生产、数仓建模以及标签数据体系的管理。我们基于数据仓库模型，对画像数据进行体系化的管理，主要有三部分：

（1）数据域建模：首先基于数据仓库对多条业务线的数据进行分数据域的建模管理。主要是对公司数据进行数仓的分层，并在数仓的 DWD/DWS 偏底层的部分，对我们的业务数据域进行分域的管理，以保证不同业务线的数据能有清晰的管理存储以及位置查询。

（2）标签计算和挖掘：有了基础数据之后，需要进行标签计算和挖掘，生产标签。

（3）画像主题建模：生产的标签会存储在数仓的主题层。快看建设了专门的画像主题，画像主题对画像平台所有的标签体系以及用户标签相关的数据，进行了建模和管理。

再下面就是数据采集层，包括埋点平台、业务日志、业务 DB 数据以及三方数据。把数据采集上来，进行数据侧的 ETL 清洗提取，转化成数据仓库模型里面的基础数据。

一般来说，这是画像平台从业务侧到数据采集侧全链路的产品架构。

讨论完产品架构之后，继续探讨另外一个话题，公司内部什么样的组织适合搭建画像平台，以及它的定位是什么？

根据我的理解总结了两方面画像平台的定位：

（1）业务内自建平台。在很多公司，一些比较大的业务线，是有能力去建设自己的画像平台的，特点是画像平台建设是服务于本业务线的，在本业务线内去使用。一般要求业务线能够具备相对比较完善的数据平台能力，数据仓库建模能力以及一定的数据挖掘能力，这些是进行画像平台数据生产的基础。另外，业务内自建画像平台因为只服务于单条业务线，往往会和自己业务运营的营销系统或者 BI 报表或者数据监控平台等有相对比较重的耦合性。耦合性是指业务自建画像平台会在平台内部把运营能力（比如说配置能力或者分发能力），营销能力（比如 PUSH 或者说短信触达）以及精细化运营和精准营销的数据回收计算、指标展示、监控等功能都糅合到画像平台中。

（2）中台型画像平台。快看有自己的数据中台，各个业务也没有足够人手建设业务内自建画像平台，所以快看的画像平台是由数据中台部门建设的。它服务于多条业务线，每条业务线都可以基于自己的业务场景和诉求去使用。一个特点是平台数据源是来自于多条业务线，所以数据源的标准性和一致性不好把控；另外因为业务和业务之间的差异很大，数据差异也非常大，不同领域数据模型的差异也非常大，所以数仓建模的复杂度是非常高的；再一个特点是中台画像平台，要求平台能力尽量和业务的运营系统，营销系统或者其他的报表平台能够做功能的解耦，因为如果中台画像平台和某一个或者几个业务的业务系统能力耦合过重，扩展性就会不好，平台产品能力过于定制化是非常不利于将来的功能拓展和迭代设计优化的。

这是不同的公司在不同的阶段可能会面临的一个选择，大家可以根据自己公司实际的痛点问题选择合适的自建方式。

快看画像平台建设经验

下面介绍快看建设中台型画像平台的经验。

1. 快看画像平台建设的背景

首先来介绍一下快看画像平台建设的背景，快看成立于 2014 年，是漫画垂类下用户体量最大的平台，目前总用户量近 3 亿，主要业务有漫画阅读、二次元社区以及商业化等。

在业务需求方面：

（1）快看的业务发展非常快，业务线的数量和业务线的规模都在快速扩张，目前中台支持了十多条业务线，公司还在不断的孵化新的业务线，公司的业务规模也是不断变化的。

（2）从 2018 年、2019 年之后，移动互联网市场的用户量增长就非常缓慢了，再加上短视频行业的兴起，用户时间被短视频行业抢占了很多，移动互联网市场已经变成了一个存量用户竞争的红海市场。各个 ToC 的产品为了能够吸引用户、提升用户时长，各个业务对存量用户的精细化运营和精准营销的需求越来越多了。

前面的分析中可以看出各个业务对数据的依赖，对精细化运营操作的诉求，快看各个业务也会面临这些问题和诉求。

数据中台作为公司里面去统一承接各个业务，各种数据场景，各种数据类需求的部门，在长期的对接中，逐渐感受到大家对画像标签的依赖越来越重，因此从各个业务对画像平台的通用诉求中提炼出最常见的对于画像平台一些依赖的能力以及对标签的依赖的需求。

快看中台从 2016 年初就开始建设，大数据平台的能力是比较完善的。对于数据采集、数据 ETL、数仓建模这些方面都是有自己的模型以及方法论建设的，而且开发能力也相对比较完善。

2. 快看画像平台功能简介

上图是快看画像平台的功能以及产品的界面，因为时间有限，分享的重点不在于我们每一个功能产品设计的逻辑，或者一个功能的具体实现，而是想着重的跟大家去介绍一下我们在建设中台型画像产品的时候，遇到的 4 个比较难的问题，或者说我们认为一些关键的点。我们的产品能力前面已经介绍过了，也都是比较通用的能力，因为我们做的是中台型的画像产品，建设目标就是为了满足业务对画像平台、画像标签的通用需求。

我们平台的功能可以概括为：标签管理、人群圈选、人群上传、人群计算、人群洞察和人群包管理。

接下来分享我们在快看建设中台型画像产品过程中遇到的 4 个比较有意思的问题。

（1）实践1：弱登录类型 App 建立设备 ID 标识

第一个问题是弱登录类型 App 建立设备 ID 标识。

弱登录类型的特点是用户不需要强制登录也能够使用这个平台的一些核心产品能力产品功能，像内容型和工具型的 APP，大概都会符合这个特点。为了用户能够快速使用我们的核心功能，提高用户转化，产生用户的激活留存，很少强制用户授权登录，所以允许用户不需要登录也可以使用 APP。

但是，各个业务又希望能够对新用户以及拉活召回的用户快速的产生深度连接，让用户能够快速的产生兴趣和粘性，这就需要做精细化运营或者精准营销，而这些动作，都是要针对于非登陆用户，基于设备的 ID 做一个动作。

所以设备的唯一性识别在画像的建设中极其重要。如果设备的唯一性识别的准确性不高，将会产生比较大的问题。而提高设备 ID 的识别度，有以下的难点：

① Android/IOS 的 IMEI、IDFA、OAID 的获取受限以及频繁变更。Android 和 IOS 从系统层面对用户隐私的保护机制是越来越强。以 Android 来说，从 Android 10 之后是不允许获取用户 IMEI 的，现在的新系统都是获取不到的。以 IOS 来说，14.5 版本之后，获取 IDFA 都需要弹窗用户授权。在中国，华为、小米、OPPO、VIVO 等组成的广告联盟一起协作出了一个 OAID 作为广告标识。上面这些 ID 或者不能获取了，或者就是获取的时候需要用户授权，造成一定的损失；再或者像 IDFA 和 OAID 面临频繁变更的情况，用户是可以主动重置的，包括重置系统，刷机，重装 APP 等都可能造成 ID 的变更。这是是我们保证设备 ID 唯一性最大的困难。

② ID Mapping 的变更。各个业务希望基于各自对 ID 的依赖去做 ID Mapping。以广告业务为例，广告业务目前去做广告投放或者广告回传效果监测的时候，对 IMEI 和 IDFA 的使用现在还是很重的。他们希望不管你内部使用哪种 ID，但是你需要能够基于 IMEI 或者 IDFA 和本部门完成广告投放方面的协作或者信息的打通回传。如果我们对设备 ID 的获取的覆盖率以及它的变更无法精准识别，那当进行外部协作，比如与广告业务的外部协作就会产生很大的折损，对效率造成影响。

作为中台部门，我们在构建画像平台的时候，首先需要解决这个问题，如果不解决，刚才提到的难点在业务侧会产生很大的影响，我们的解决方案主要是两个方向：

① 第一，快看能够维护每个设备各个 ID 的映射和变更关系，我们把这些 ID 尽可能都收集上来并且去维护它的映射和变更关系，并且基于收集信息去自建快看的 KKDID。生成快看自己的 ID 之后，我们对设备的唯一性就有了自己的识别体系，对它的质量也有了自己的保证。

② 第二，在建设的过程中，可以借助行业内的第三方反作弊平台，利用它的唯一 ID 的识别能力，提升自建设备 ID 体系的准确性。

我们在 Android/IOS 两个平台分别采取了很多判断逻辑去构建自建的 KKDID 体系，在构建自己的 ID 体系的过程中，需要做非常复杂的唯一性识别和判断。需要平台根据自己产品的特点以及收集的用户数据，制定适合自己业务的定制化判断逻辑。

下面列出一些快看自建 KKDID 后在公司内部的效果，这里只列出重点，我们其实有完整的评估报告：

① 第一，为安卓提升了约 2.2% 的 IMEI 填充率。比如我们有 3 亿设备，里面有一部分安卓，乘以安卓的比例，然后再乘以 2.2%，这部分设备原来是没有 IMEI 或者 IMEI 的识别是有问题无法精准匹配的，但是通过唯一 ID 识别，可以把这部分 IMEI 的填充率提升上来。如果有很多重复设备被识别成不同的设备会导致安卓的 IMEI 填充率降低，但是我们通过设备的唯一识别，可以提升其填充率。

② 第二，对比第三方反作弊平台，我们的唯一设备识别率提升了 1.5%。我们行业内的第三方反作弊平台，他们在设备唯一识别上也是存在很多 bad case 的，我们在构建的过程中发现了这些问题，即使是行业内 Top1/Top2 的反作弊平台。

③ 第三，我们在搭建了 KKDID 之后，还做了 KDDID 和 IMEI、IDFA、OAID 之间的两两映射，提升了各个业务在不同场景下使用对接上的准确性。

这是我们解决的第一个问题，也是我们构建画像平台的一个基础。首先要能够精准的识别唯一的设备，然后才能去对这个设备进行画像。

这里重点提了设备 ID，但不同的业务对设备 ID 的重要性依赖度是不一样。像很多商业化，用户只有登录后才能进行商业化的操作，如果对它做精准营销，只依赖用户登录后的登录 ID 就可以了，反而不那么关注设备层面的画像，所以需要根据不同的业务去思考这个问题。当然，KKDID 是一个通用能力，供大家参考。

（2）实践 2：数仓建模经验

接下来介绍第二个经验，中台型的画像平台对接的业务方非常多，会面临如何管理非常混乱的数据源的问题。为了解决这个问题，我们用了分层建模以及数据域和主题去分层管理的思路，特点是数仓有两个明确的业务数据域层和画像主题层两个明确的分层。

底层的业务数据域，DWD/DWS 层负责清洗和管理各个业务数据域内的明细层数据。以付费域来说，用户或者会员的付费，我们会在付费数据域把付费相关用户的行为全部在付费域里面进行建模，然后建不同的宽表进行存储和管理。对用户域、流量域甚至其他域都是用同样思路去建设的，不承担直接的画像计算或者挖掘任务。

在这之上我们建设了专门的画像主题，在数仓里面对应的是 DM/APP 层，承担着整个画像平台的画像标签体系的管理，以及标签数据的存储管理，以及宽表的建模。

画像主题的数据源头是各个底层的业务数据域，需要哪一个，可以从管理好的业务数据域里面对相应的数据进行提取和应用。这样做的优点是业务域的数据条理比较清晰，画像主题的数据能够统一管理，实现标签体系和标签底层数据的统一管理。

这是数据的存储和生产应用规范，能够在数据生产流程中形成这样一个标准，能够提升标签生产的效率。在数仓建设，比如一些数据产品建设的时候，如果面临这类问题，解决方案可以通用。

第二个经验实现了对我们画像平台标签生产效率的支撑。

（3）实践 3：多业务标签增量融合

作为中台型画像平台，我们会自己生产标签，同时各个业务线也有基于中台或者基于自建的数据平台定制化标签生产的诉求。各个业务线生产的标签能否在画像平台中使用呢？

我们的第三个经验就是能够支持多业务标签在画像平台里面做增量融合。如上图的左面部分所示，数仓里面有各个业务自己的数据域里面的数据，都做了数层分层管理和宽表建模的建设，业务开发同学或者产品同学基于建设好的数据，在业务内可以做一些开发和标签的生产。比如增长业务、基础业务或者广告商业化业务，用自己业务数据域的数据，生产一些复杂的定制化的标签。

在这个过程中，中台侧可以定义标签生产和融合的规范：比如标签生产的命名、准确性、覆盖率以及标签取值（码值）需要符合哪些规范；然后标签内容的存储位置、存储形式、存储格式也有一定的规范。

业务线标签生产完成后，中台会有对应的标签融合的任务，把业务生产的定制化标签，自动融合到画像主题。融合之后，还会触发标签的自动化管理，在标签的体系中，把业务侧生产的标签也融合进去，做统一的管理。

这样做的优点是作为中台，我们把画像平台的标签生产能力开放给业务，能够提升标签的生产效率，也能够给业务方的开发侧或业务侧进行赋能。

（4）实践 4：支持复合标签

第四个是偏产品功能上的一个创新。在画像平台的迭代中发现，用户除了对一些简单标签的使用之外，在业务的精细化运营、精准营销的过程中，对非常复杂的标签的使用是很频繁的，希望我们能够对很复杂的筛选条件做支持，分更多的维度对筛选的用户做不同维度的计算。

经过这部分功能的提炼之后，我们发现可以通过面向特定业务的某一个用户的行为去做一些符合标签类型的支持。

上图左面是我们画像平台后台截的一个比较有代表性的例子，这里的标签是近 90 天用户消费和充值明细，它是对用户近 90 天的行为做了维度的聚合，并且支持把筛选条件也糅合到标签里面。我们在画像后台使用这个标签的时候，就可以使用该标签下面特定的条件做筛选，甚至做一些复杂的筛选条件。比如近 90 天的用户，他的订单日期相对于当前时间是大于 30 天的，然后订单类型是充值类型，货币类型是人民币，对这个人群的标签，我们希望对它的金额维度做一个求和计算，得出求和后的结果，这是一个具体的例子。

它的优点是提升了标签计算的灵活性，能够固化高复用的复杂标签，降低开发成本。

对数据产品来说，需要对业务高频的标签使用场景有比较好的分析和洞察，才能够提炼出他对复合标签的真正诉求，从而把复合标签提炼出来。所以复合标签的生产需要，对产品侧的业务理解和分析洞察能力要求比较高，但它确实可以大大降低开发成本，提高标签的复用性，在业务侧看来这个能力是很方便的，可以对筛选条件和维度做很灵活的筛选和统计分析。

快看画像平台应用案例

下面分享一下快看画像平台的应用案例，这里分享两个例子。

1. 案例一：助力精准营销闭环

第一个案例是助力用户充值付费业务线的精准营销。精准营销应用画像平台之后，流程形成了一个营销的闭环。

（1）首先用户可以基于画像后台去做人群包的筛选，对于不同的营销活动，基于复合标签或者特定标签筛选出人群包。

（2）在运营后台，对人群包以及投放的特定活动做相应的操作配置，运营后台通过画像平台的功能 API 把相应的人群包或需要依赖的数据拉取到后台，基于我们营销后台的能力，对特定的人群包做特定的分发和营销活动的操作展示。

（3）对营销活动的数据进行采集，生成 BI 报表。

（4）运营人员可以根据 BI 报表中的指标数据观察每一个营销活动效果，根据效果的反馈，对自己的营销活动方案或者对人群包去做出相应的调整或优化。

这个闭环，在付费会员侧营销活动中的使用目前已经例行化了，也是使用画像平台的一个非常重的业务。上图右侧是在画像平台截取的一个筛选条件的截图。

2. 案例二：支持内容精准宣发

第二个案例是快看作为内容型的平台产品使用画像平台进行内容精准宣发的例子。

精准宣发业务是指什么呢？比如有一个新的漫画作品，平台想给其作者一定的扶持，让它的受众用户能够快速触达，从而能够对这个作品产生兴趣开始阅读，给作者和作品积累一定的人气。

这个操作过去经常出现的情况会对所有的用户做千人一面的分发，所有的用户看到的是同一个宣发的作品，这样的做法，造成很多非受众用户也会看到，分发效率有很大的可提升空间。

使用这个画像平台，就一定程度上可以解决这个问题。宣发运营侧对内容精准宣发的流程是什么？

（1）基于画像平台去圈选出特定内容偏好人群包。用户阅读打分类下的用户标签里面会有他的偏好，根据要宣发的漫画作品的品类和特点去匹配相应偏好特征的人群包，运营后台基于画像平台的功能 API 去获取人群包。

（2）在运营后台的配置中，配上相应的人群包和资源位，对该人群包的人群做定向的宣发。

（3）采集宣发的数据，将相应的指标可视化。

（4）根据 BI 报表的反馈和分析，驱动内容运营策做出相应的调整和优化。

我们画像平台的功能是比较通用的，在广告业务场景中以及渠道业务场景中，因为业务逻辑和流程的链路是非常长的，对画像平台的依赖会有很多偏定制化的需求。对于这样的场景，建议在他们的广告业务和渠道业务的数据平台中去建立画像模块，这个画像模块可以和自己业务的数据产品做很重的耦合，因为它就是服务于该业务的。画像模块可以把中台画像产品的基础能力甚至基础数据进行打通应用，这样可以极大提升画像建设速度，同时不需要关注画像是怎么生产，画像标签是如何管理的，画像的功能 API 是怎么样的，只需使用可依赖的接口，把更多的精力去投入到自己业务侧数据产品的流程和逻辑中。

总结和展望

最后介绍一下我们总结的一些经验，以及我们未来的发力方向。

经验总结有如下几点：

（1）中台型画像，要重点关注业务侧的通用诉求，做一些通用能力的提炼。

（2）大数据平台、数仓建模和数据挖掘的基础能力是画像平台的基本保障。这些能力是必备的，毕竟一旦涉及到画像的话，数据量会比较大，用户体量也比较大，对计算能力、数据采集、ETL 和建模能力的要求是很高的。使用的越重，这一侧整个全链路的要求也会越高。

（3）画像平台的核心能力是人群圈选、计算、洞察、复杂标签支持、标签融合体系等。

未来展望有以下三点：

（1）加强标签的系统性管理，自动创建的效率更高一些，目前有一些人工操作和干预。

（2）更完善的服务化能力建设。服务化是刚才提到的画像平台的功能 API 和查询 API，服务的稳定性保障以及响应及时性都有一些优化空间。

（3）实时画像与离线画像融合。目前实时画像的应用场景比离线画像要少很多，但未来实时画像的应用会越来越多，因为现在大家已经不太满足于 T+1 小时这样的数据产出效率了，更希望在分钟以内的延迟生产实时画像。后面我们会加强实时能力，并与离线画像进行一些融合。

问答环节

Q1：底层用户 ID 生成的规则能不能分享一下？

A1：由于信息比较敏感，可以大概的说一下。

ID 的生成规则，最基础依赖是先要把所有的 ID 收集上来。需要首先和法务、用户产品侧去讨论可以收集哪些 ID，因为不同产品的定位不同，能收集的 ID 也不一样。

确定了能收集的 ID之后，需要思考的第二个问题是不同的 ID 的变更频次也即它的可靠性是怎么样的？首先安卓和 IOS 是有区别的，然后安卓和 IOS 内部每一个 ID 的变更频次或可靠性也是不一样的，这里建议优先使用内部采集的 ID，对内部采集的 ID 优先使用可靠性更高、变更频次更低的。

如果可靠性更高的 ID 是空的或者有问题，再去找次优的可靠性低一些的 ID，经过这样的一个优先级的次序去逐步判断每一个 ID 在我们的 ID 库里面是否存在过，和我们已有的唯一设备是否有某一个 ID 的重合，这个是做设备唯一识别的一个很重要的点。

使用内部采集的 ID 做完优先级的判断之后，如果我们还采用了第三方的反作弊平台，最后可以使用第三方反作弊平台向我们开放他们内部的唯一 ID。我们使用他们的内部唯一 ID，在我们存下来的外部 ID 里面做去重判断，对我们自建 ID 的逻辑进行补充。基本上是以这样流程逐渐的积累。

ID 体系的建立，除了刚才提到的采集和规则的判断，很重要的一点就是如何把历史设备的信息回溯重建，因为历史设备信息也是需要基于同样的体系构建出来的，这是一个难点。

另外就是如何能够持续积累，并且唯一 ID 如何能够在设备上逐渐提升覆盖率，只有有了足够的覆盖率之后，在公司内部才能产生足够多的应用场景，覆盖度不高的话，很多业务没有办法直接使用这个唯一 ID。

Q2：快看漫画平台是如何防止过度打扰用户的？

A2：这个很依赖运营策略，体现了运营策略对于精细化的运营是如何理解的。重要的一点就是如何判断运营策略是有效的，同时也不过度影响用户。

我自己的一个经验是这样的，对运营部门的精细化运营策略或者阶段性的目标做评估的话，从这个部门的角度，可以建立一个完整的运营策略评估指标体系，而不是只看运营策略的直接效果指标。

比如通过 PUSH 希望能够提升用户的点击率，提升用户的每天打开人数。如果只看这个的话，通过 PUSH 频次的提升，或者对 PUSH 的文案做一些技巧性的优化，是很有可能带来效果的。但是如何减少对用户的打扰，对 PUSH 的场景来说，需要加一些围栏指标，就是限制指标，PUSH 不能够导致围栏指标的下降。比如用户对 PUSH 打开的长留（长期留存），比如接收到这样 PUSH 消息之后，对用户 PUSH 的触达率是否有影响。如果 PUSH 经常推垃圾消息或者说很有欺骗性、诱导性的文案，但用户又感受不到实际的信息和价值，那么他后面可能就把 PUSH 消息接收关掉了或者说根本不看了，这样肯定会影响未来的触达以及 PUSH 点击的一个长期留存。

所以我建议如果要减少用户的打扰，我们没有办法从全局去求每一个策略都考虑得非常深，而且也不可能盯得太细，但是我们可以用一些围栏指标去限制运营侧的人员去深度思考后再做出精细化运营策略的制定和执行，可能效果会好一些。

Q3：公司从 0 到 1 搭建画像平台，标签体系初期构建的时候有什么需要提前注意的点吗？

A3：我可以大概的积累一下可能会有哪些方面我们踩过的坑。

首先从 0 到 1 去建设，一定会伴随着你对业务的逐步的理解，以及业务诉求方面的积累。

如果我们是一个中台侧，对于单个业务提的需求，我们需要能够有一定的宏观视角去看，它是属于画像平台的哪些能力，或者说标签体系的哪一部分有这样的诉求，他的诉求是长期的需求，还是短期的需求。对于我们是要构建一个长期的能力支持，还是临时性的一个支持，这个分析是蛮重要的。这对于我们画像平台的一些需求能力的提炼是一个逐渐的积累的过程。前期在对接单个业务的时候，从整个数据中台侧我们产品同学在遇到这类需求的时候，可以适当的考虑用一些临时性的方案去支持临时性的需求，然后业务的临时性需求，有了一定的固定频次去对接的时候，再去思考如何将它固化下来，以及是否适合固化到画像平台里面。

有一个经验就是多个业务线里面和用户相关的需求，在前期都可以往画像平台构建的能力上多去思考能不能去做一些支持的。如果单个业务有很频繁的对用户这方面的一些画像并且比较固化，画像平台的建设就可以逐步启动去支持了。

从产品侧我们还需要考虑的一点，大数据平台、数仓建模和数据挖掘基础能力，是画像平台的基本保障。在有了一个通用或者需要固化的需求之后，我们对产品也有了初步的思考和设计，我们还要从底层思考我们当前有没有这样的数据能力去支撑我们去做画像平台的建设，需要和开发侧去做方向或者目标的讨论，看他们能不能提供相应的能力和人员的支持。

这可能是从 0 到 1 搭建的时候，对外以及对内的数据侧需要讨论的。

如果我们属于业务部门，想从 0 到 1 搭建画像平台，标签体系的话有什么要注意的点？我个人觉得如果这个业务是有一定规模的，包括人的规模以及业务体量都比较大的话，才是业务线内搭建画像平台的一个起点或者基础。在搭建画像平台的时候，思路就不是做一个大而全的画像平台，可能要先跑一些画像平台的功能性的 MVP。画像平台哪个能力目前需求是最强烈的，用户的使用会是最频繁的，我们先把这个功能性的 MVP 跑通，这是我们业务内去搭建的一个原则。

在业务内搭建的时候可以多和运营系统或者数据后台多做一些联动，去看看有没有产品已经有了类似的能力或者规划，如果有能力有规划的话，我们和他们一起去分析，这样的产品能力在哪做更合适，和哪些平台打通交互，各自该如何定位。这些讨论清楚也是我们从 0 到 1 计划去搭建画像平台的一个基础。

另外业务内也非常需要关注业务内现有的数据能力，我们平台能力是否足够完善，否则可能我们做完了产品方面的思考规划之后，发现项目没法启动，因为开发人力或者数据基础是不足的。

这是我觉得起步阶段可能需要注意的一些点，包括我们过去也踩过一些坑。

Q4：H5 的 Cookie ID 是否可以作为用户标识，基于 Cookie ID 的标签计算是不是有意义？

A4：我们的很多活动都是基于 H5 做的，因为 H5 的开发短平快，一个活动下线之后也就不再用了，做到 APP 里面成本会高，H5 的开发效率会更高，迭代速度也会更快。但它的一个问题就是 Cookie ID 的变更会很频繁，而且 H5 页面现在会面临一个难题，现在很多 APP 内嵌了浏览器，很多 H5 页面在自己内嵌的浏览器打开之后，在自己的浏览器里面很可能是有特定的 Cookie ID 的，那么对于同一个页面同一个设备，我用 UC、用百度、用微信、用钉钉打开，它的 Cookie ID 很可能是有很大差异的，或者根本就不一样，我们用 Cookie ID 去唯一标识这个设备的话，几乎是不可能的。

快看 APP 内嵌的 H5，我们有一套机制，H5 和我们安卓 IOS 做信息接口的打通，把我们设备层面的 ID 一定要传到 APP 内嵌的 H5 上。这样，我们内嵌的 H5 的活动也好，或者说各种页面，上报的很多信息，其实都是携带了我们的设备 ID 的，设备 ID 会比 Cookie ID 的稳定性要高很多。甚至我们自建的 KKDID 都可以传上来，当然这个依赖你们有没有自建的 ID，它的稳定性会更高。

对于很多快看 APP 外的 H5 页面，没有我们的设备 ID 可以获取。像小程序会好一些，对直接使用它的 Open ID，每个小程序都有自己的 Open ID 体系，都是可以获取的，作为匿名用户的一个标识是可以的。

但是对非小程序类的采集就会很难，个人经验，PC Web 或者 H5 页面，它的用户的访问习惯是用完即走的，包括你的活动应该基本上也都是短期的。所以我觉得这类活动，我们的目标前期不要设置成期望用户多么频繁，有多么高留存，有次日、7 日、14 日都能够使用我的 H5 页面。我们更多的可以在用户首次访问的时候，就抓住用户，激活他的兴趣，从而把他引导到我们的 APP，这是可以重点考虑的方向。因为不管是 PC Web 还是 H5，目前所有的数据平台都是一个难题，你包括友盟也好、百度统计也好，他们对于这种 Web 类页面的用户识别以及用户的一个累积，历史用户的识别都不重视，也没有这样的能力，所以我建议自建数据产品的时候，也可以吸取比较好的经验，不用过度的去想 H5 页面在站外的唯一用户标识，以及后续如何长期去做用户的识别，做精准分发。我觉得这个可能是一个行业难题。

Q5：人群效果是针对单个业务场景的回收，还是已经做了通用功能，所有的场景都能用呢？

A5：对于快看中台的画像产品，我们没有做人群包应用效果的 track，因为每个人群包在业务内的使用场景以及使用逻辑，包括数据统计的指标以及报表展示的逻辑都会有挺大差异的，通用能力很难提炼。当然会有一些很基础的效果的展示，但是我觉得意义并不大，对业务来说你给我了我也用不到，我更想看的是这个人群包在业务场景中，精细化的每一个关键链路的转化漏斗也好，各种人群行为分析也好，做一个更精细深层次的洞察，这不是中台型画像产品能提供的，所以我们是没做这个能力的。

如果想对你们的精细化运营效果做精准 track 的话，根据快看数据中台产品侧的经验，其实可以从分析师和数据产品侧协作，去把你们特定的营销活动的整个的数据产品侧的逻辑梳理一下，然后用 BI 报表或者说自建报表的形式，把它的整个分析模型以及它的核心指标固化下来，这个可能是一个更有效的一种手段。

Q6：人群精细化运营中人群的覆盖度和准确率是如何进行平衡的？

A6：这个应该是基于精细化运营在业务侧应用的角度去问我们如何去做人群圈选，能够对我们精细化运营的这些活动或者场景产生更高的准确性，同时就是整体的运营效果会更好。

所谓的精细化运营，他一定会越做越细，我们能够在我们运营的过程中逐渐发现人群里面存在的规律，就是哪一类人有什么样的规律，这些规律会以什么样的规则去确定下来这一人群，它是一个应该越做越细的过程。

为什么会需要这样？因为精细化运营如果始终处于某一个用户运营的力度上，就会眉毛胡子一把，始终在这个力度上，我们对人群的区分始终不会做得更细。我们很多活动的策略，针对的人群不一定是它非常精准的受众人群，所以效果可能会存在一定的瓶颈。

我个人的经验就是我们在运营的过程中，对每次精细化运营效果，人群投放效果多做一些分析，为什么有的投放没有效果，这部分没有效果的人群和有效果的人群，有一些什么样的差异。我们找到的差异就是我们下次精细化运营投放的时候，筛选人群包可以多加的规则，下次投放的时候加上这些筛选规则，人群的投放会更加的精准，效果也会好一些，转化率也会高一些，业务的指标可能也会更高。

这里面又引出一个问题，我们做的越来越细的话，这些人群的一个覆盖率就变低了，我们活动效果的总 UV 或者说我们的总的 GMV 或者总收入下降了，这也不是我们想要的效果。

能不能平衡？其实我觉得做的越细和覆盖率指标它不是矛盾的，首先做细的过程中，会逐渐细化出越来越多的人群包，不仅是对原来的人群包加条件让这个人群包越来越小，而且是创建越来越多精细化的人群包。一个好的方向，用户存在的特征，我们认识的越来越细，通过这些特征我们筛选的人群包越来越精准，数量越来越多，当然最好他们之间的重合度会低一些。不同的人群包之间是明显的特征差异，可以针对他们做更加有效的策略的制定和投放。这样我们就能够兼顾用户人群的覆盖性以及策略的有效性。

今天的分享就到这里，谢谢大家。