数据产品经理实战 -DMP 搭建



一、前言

DMP系统由于具体需求的不同以及公司重视程度的不同在项目实施上可深可浅，算是比较标志性的落地数据产品之一；同时一个优秀的DMP系统项目是涵盖了《数据产品经理实战-开篇》中的提到的多块内容，包括行为数据埋点框架搭建，数据仓库主题域设计，标签体系搭建，用户价值模型评分构建，实时计算平台，数据产品商业化等。希望能通过一个项目将整个数据产品的基本技能点全部串起来，建立起DMP系统更加立体的认知。



二、DMP-解释

百度百科的解释，DMP(Data Management Platform)数据管理平台，是把分散的多方数据进行整合纳入统一的技术平台，并对这些数据进行标准化和细分，让用户可以把这些细分结果推向现有的互动营销环境里的平台。当然这是标准的释义，不同公司对dmp系统有着不同功能的承载，以及不同的预期，笔者觉得可能会有以下几种：



标签分类管理系统：将目前数据库的所有标签进行可视化展示，标注每个业务线，每个业务主题下的全部标签，展示标签的属性，名称，依赖，逻辑，最主要是展现每个标签具体值的分布。该系统目的和意义在于进行更加精细化分析用户情况，以及标签的线上维护和管理。

（神策产品的标签管理功能）



用户画像看板：这种就比较常见，主要以可视化报告展示较多，通过标签组合实现一定的可视化视图，比如页面上用不同的维度词云图堆满一个人的画像，通过地图分析进行不同销售额的展示，观察用户的地域、性别、年龄、操作系统等分布，诸如此类。但笔者个人觉得这本是观赏性质大于分析性质的项目，本质是还是以描述既定的事实为主，属于描述性分析；同时为了兼顾展示效果，维度又设置的比较粗犷，对一线的业务运营同事提升的帮助很有限，可偏偏这种项目实践的很多，而且网上普遍的声量都还比较推崇此项目。





客群生成系统：这种项目就比较贴近于真实的dmp系统形态，一共分为以下几个模块：

用一句话来总结该系统的核心，提供一个web入口，在该入口里搜索数据库现有标签，进行自由组合并生成一个客群，以便外部服务进行接口的数据请求。



营销运营系统：这种系统会比“客群生成系统”多几个模块，算是业内比较认可和通用的dmp形态，它将提供更多场景和服务进行真正的用户运营，业内标杆产品可参见阿里的达摩盘。

从基础数据源的标签配置，客群配置，到具体执行层的营销任务，运营策略ABtest，调度任务管理，再到营销闭环的数据回流与分析。用一个系统完成N个精细化客群的生产，使用，回收，监控的全链路过程，“客群”，“营销任务”，“效果闭环”，是此系统的三个核心.



营销运营+活动配置系统：该系统是在“营销运营系统”中新增一个模块，活动配置模块

活动配置主要是指不同营销触达方式具体内容配置，比如电商，贷款行业的红包奖券具体配置，push文案，短链内容配置；保险，房地产，理财行业的电销话术建议；工具流量类产品的头图，气泡，弹窗广告素材配置等等。实际上此种dmp方向的产品就稍有超纲，但业内也存在一定量的此类产品，很多公司会根据自身的情况进行产品迭代。



三、DMP-现状梳理

下面进入实战环节，此处以运营营销系统为例，重点介绍该系统的实施过程。

既然是以营销为主，公司用户运营肯定在产品建设初期就以临时方案的形式存在。这种情况下，若没有专职负责dmp的数据pm进场，常规的公司运营架构为以下这种情况：



数据部门被动接入运营的标签需求，开发标签并提供标签查询接口，业务系统后台每天定时用接口将标签数据读取过来落库，再通过定时任务调起短信接口进行营销触达。



笔者看起来这样的情况有如下的一些问题：

1. 烟筒式开发流程，被动式需求接入。标签属于持续性且较为零散的数据需求，且易受运营同事“拍脑袋”的决策影响，数据团队作为承接运营需求实现的工程端，如若没有专职的产品介入，不进行必要的需求把控，版本管理和测试，一方面没法保证线上运营的标签数据需求质量，数据质量，二是长久以来会导致数据开发疲于需求的实现，逐渐将标签开发演变成一种“体力活”，不利于数据团队的技术栈建设。

2. 碎片化标签管理。烟筒式开发流程下，标签都是伴随着业务需求一个一个出，没有专门的标签体系文档和设计框架保证其标准与通用性，会导致开发的人力资源与计算资源的浪费。笔者曾经见到过描述同一个非常明细的业务行为竟然被开发成了6个标签，有3个因数据倾斜被超时kill掉停止跑数1个月却无人发现，有2个计算逻辑一模一样（就是sql不一样，一个用主题表一个贴源表），这就是没进行有效的标签管理所带来的影响，而且这块工作在很多公司都没被引起重视。

3. 单一的营销活动。因为在用户营销初期，作为距离触达用户最近的线上业务系统，自然就要承载起营销工具的发送任务。在业务系统本就处于长期的需求溢出状态下，部门的角色定位及本身的需求排期也无法将用户运营作为高优先级需求进行标准且通用性的技术方案落地，只能是作为临时方案先把需求先满足，等有时间再后续重构（但一提到重构，大家都清楚这是一个在祖传代码坑里蹦迪的行为），这就导致前期能接入的营销工具较为单一，技术架构不健全，且通用性不强。

4. 离线式触达时效，在目前流量费用越来越贵的情况下，转化率的提升的重要性已经不言而喻。在众多的用户运营活动中，笔者的亲身经历部分场景下的T0实时营销转化率要比T+1天的转化率高达一倍左右，而既有的从数仓通过接口给到业务后台，再用定时发送的数据交互流程，低内聚高耦合，如果要进行技术架构升级，有较大的重构成本。



基于以上的情况，所以我们在项目开始之前需进行基本盘的摸底，梳理公司现有的标签池现状，包括标签开发流程，标签体系框架，现有的用户运营流程，确认目前线上主要的营销工具是什么，其他营销工具（push，短信短链，弹窗，banner，微信公众号push）的对接方式是怎样的，以及触达效果数据的回收落地情况。以下笔者片面的罗列了一些摸底时需要了解清楚的点，仅作参考：



四、DMP-现状优化

上述DMP分类的时候我们有提到三个核心“客群”，“营销任务”，“效果闭环”，那优化方案也是以这三大块为核心。



客群&标签开发流程优化

1. 标签开发版本管理，由数据pm牵头进行标签项目管理。首先要和主要的标签需求方领导，自己的领导，数据开发的领导达成一致，标签需求统一走版本管理。建议一周一次迭代，统一汇集，整理，评审，开发，测试，发布。

2. 标签文档信息维护，开辟一份项目行动组知识库，包含独立的标签需求列表池，独立的标签元数据信息维护，元数据信息记录可参见下面的内容

3. 专职的标签测试人力，此项为可选项，一般公司不会提供专职数据测试人力在数据部门，若对数据质量有非常精准的要求可申请借调标签测试人力。

（元数据信息记录）

营销工具优化

梳理公司目前使用的营销工具，与部门所在领导达成一致，统一营销工具入口，形成技术中台的基础服务，方便后续的多租户，多客群管理。



效果闭环优化

1. 数据清洗落库，所有营销工具的效果回收数据均进行ETL，落库，回收进数仓，加入每日常规数仓批处理调度任务流。

2. 主题域建模，针对效果回收的数据表进行数仓建模，设计维表，明细事实表，汇总主体表以及展示结果表，提升数据易用性。

3. 确认口径，与业务同事共同制定营销效果回归报告的指标口径，确认业务增量的计算方式，建立用户运营监控的指标体系，例如响应率提升的计算，关联交易金额的计算，推荐引擎的效果评定计算等。



其他优化，强调几点笔者亲身经历过的坑

1. 标签任务需支持海量中单个任务的重启执行。很多公司的标签建设初期为了建设方便，通过一张hive的大宽表进行维护，一旦上游单个业务数据源异常污染个别标签后，修复时需重跑整个标签宽表，非常耗时，而标签又是直接运用于线上业务的关键性应用，无法承受如此大的时间成本（当然为了解决线上营销服务异常这问题，仅凭单个标签任务重启是远不够的，这里不做展开）。

2. 标签任务调度链路需和数仓主批调度链路严格区分。数仓主批调度一般执行顺序为数仓贴源层→聚合层→应用层，这种主批调度的串并联关系非常复杂，批处理时间会随着日积月累越来越长，若一开始不进行合理规划直接将标签与数仓常规任务全部放在一起，数仓离线的不确定因素将会直接影响至线上的标签任务，导致线上服务异常，但此时再进行任务拆分，血缘梳理等数据治理工作已是浩瀚工程。（这里便已涉及到专项的数据治理工作，笔者后续也会有专门的篇幅讲述企业级数据平台的治理的思考）

3. 控制有效的标签数量。标签并不是越多越好，大量的标签会严重占用计算资源和人力资源，需在事前事中事后进行质量把控，笔者提供几个思路，一是事前的需求把控，合并逻辑性标签，比如“是否购买产品1用户”，“是否购买产品2用户”这种多个逻辑标签就可直接合并成序列型标签“用户购买产品名称”；二是事后的标签上下架处理，对标签的使用次数做监控，定期下架一定范围内未使用过的标签，释放计算资源。



以上都是对现有流程的优化，或是对必要环节的补充，可根据具体场景及环境的不同进行更改。



四、DMP-系统设计

有了上面现状优化的准备工作，下面将进入系统真正搭建环节，此时便需要数据pm从0到1对系统原型，需求文档进行起草，下面是dmp核心功能的架构。

系统架构

（系统功能架构图）

还是上面提到的三大核心，“客群”，“营销任务”，“效果闭环”，具体的原型和UI样式大同小异，这里也就不直接放出；有功能架构后，便可使用交互和设计将功能串起来落实成具体的页面，进而便会自动组装成一个系统。



这里提出几点笔者在项目实施上的心得，

客群生成需支持客群复制与拆分。一是适配后续要上的多试验策略功能，二是可加快运营同学的配置效率



客群自定义格式导出。客群作为一组用户明细信息数据的集合，在实际用途中不仅运用于营销触达，还会直接提供至外部，比如对外的渠道结算核对等。可直接在DMP上预留客群自定义格式的导出功能（需加入oa的审批流程），减少碎片化的临时提数需求。



标签元数据的存储。对接至dmp的标签值以及元数据最好是独立数据存储进行直连，避免以接口请求的形式读数仓的标签宽表。



人员配置：

高级后端开发*1，负责数仓对接至dmp的数据服务架构设计及开发

中级后端开发*1，负责标签开发和部分接口开发

前端*1，负责前端页面开发

测试*1，负责整体系统的功能测试

中级数据产品*2，1人负责具体dmp的功能，主导具体产品的实施与交付，控制项目节奏；1人负责标签管理，主导标签开发与验收的持续性交付



版本迭代功能：

一期：标签搜索，展示，客群配置，客群交并集，复制，拆分；

一期主要目的是核心功能客群配置的上线，也是为运营同学提前熟悉系统打好提前量；同时需根据二期里程碑时间制定dmp用户运营与旧业务后台用户运营的切割计划。



二期：营销任务配置，营销效果回归报告，系统权限管理；

二期上线后可完全覆盖用户运营闭环整个流程，但仍建议保留旧流程作为Plan B，待dmp稳定后即可完成彻底的切换。



三期：实时客群更新，ABtest多实验组配置，标签，客群更加细粒度的权限管理

三期将会在二期核心功能的基础上进行优化，主要实现针对同一客群的多策略发布，实现更加精准的策略与客群的匹配。



以上每期开发时间因具体项目而异，笔者建议两周较为合适。产品经理是整个公司的资源杠杆，切忌功能架构设计一味的追求大而全，避免项目为了做而做，从而降低资源的使用效率，需在整个功能架构上遵循mvp原则，保证产品迭代小步快跑，在最短的时间内完成核心功能的全覆盖。（在这里也挖个坑，后续会推出专门讲数据类项目未达预期效果的反思与复盘内容的一篇内容）



五、结语及展望

以上就是最基本的dmp系统建设的过程，笔者尽量以详细的步骤讲透每一个需要注意的点。当然该dmp系统还是基于业务规则做基本的离线计划式营销，强依赖专家意见与业务规则，比较初级；高阶的层次应该是以算法模型+用户生命周期管理为方向，做成触发式即时营销，进行算法渗透，实现智能运营决策。这个也可以算是未来发展的方向，整体功能如下图：

后续也会专门开篇讲dmp平台的升级具体落地实战，探讨由dmp升级至智能运营系统的思考。



下篇将进入大数据平台门户系统搭建项目的实战，甚至也可以叫它数据中台项目，笔者会基于自己的理解及当时公司的理解谈谈企业级数据中台产品应如何建立。