惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
云风的 BLOG
云风的 BLOG
Last Week in AI
Last Week in AI
H
Hackread – Cybersecurity News, Data Breaches, AI and More
B
Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
H
Help Net Security
B
Blog RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
Netflix TechBlog - Medium
S
SegmentFault 最新的问题
The Cloudflare Blog
I
InfoQ
美团技术团队
博客园 - 三生石上(FineUI控件)
MyScale Blog
MyScale Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 司徒正美
L
LangChain Blog
A
About on SuperTechFans
T
The Blog of Author Tim Ferriss
Y
Y Combinator Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
MarTech​-CDP实战手册:CDP交付阶段-标签规划(十)
光波 · 2023-10-07 · via 人人都是产品经理

MarTech​-CDP实战手册是作者在平台分享的一个系列文章,之前作者和我们分享了交付阶段的相关内容,这篇文章,一起来解析一下标签部分怎么做。

标签规划

标签规划需要先了解标签的分类,根据标签的分类进行梳理,分类包含事实标签、规则标签、预测标签。

1)事实标签

属性标签是相对比较稳定的标签,主要以客户的性别、年龄、地区等,在梳理属性标签时需要考虑相同属性多源流入,如果有数据中台则需要数据中台进行融合,输出唯一属性,若无数据中台则需在CDP中进行属性的来源的优先级调配,保证属性标签数据质量。

2)规则标签

没有直接对应数据,需要通过规则进行定义,规则包含属性、行为、标签的交并排进行配置产出,规则标签初期往往不会特别多,因为属于灵活可配置的标签,事实标签足够全面,基本上可以覆盖所有规则标签。规则标签构建类型有商业价值标签、用户偏好标签、生命周期标签、营销时机标签。

3)预测标签

参考已有事实数据,来预测用户的行为或偏好。比如用户a的历史购物行为与群体A相似,使用协同过滤算法,预测用户a也会喜欢某件物品。

4)标签规划流程

业务场景梳理-标签规划-行为建模-口径确认-数据加工-标签验证-规范运营。

5)业务场景梳理

业务场景确认:一般根据业务部门或生命周期进行梳理,规划业务场景,并通过业务场景进行流程梳理,根据每个节点进行标签规划。

① 生命周期确定业务场景:

② 增长阶段确定业务场景:

③ 业务需求确认业务场景:

1. 标签规范

因格式问题无法直接展示表格,需要表格模板可留言沟通。

标签规划表:

标签命名规范:

标签举例

2. 行为模型

行为模型需要进行行为数据源梳理,如果有第三方接入的话则直接对接第三方即可,业务内部部分行为也需要进行梳理,构建统一的行为模型,帮助CDP进行实时、离线的行为接入。

构建并梳理建立用户行为模型,先基于业务场景,构建业务模型,通过统一的建模,统一业务口,根据数据实际情况,建立数据模型,并基于对齐的数据口径上开发。

行为数据模型在车企行业通常包括“用户行为主题”,“订单主题”,“用户权益主题”,通过多个业务主题可以比较容易的描述常见的用户行为。

字段介绍:模型名称:模型宽表名称/ 行为名称;单一行为名称/ 模型;模型字段:可包括维度度量型字段;数据口径:关联哪些维度,事实表的哪些字段,进行建模。

3. 口径确认

口径确认其实分为两步,在原有系统中肯定涉及到部分标签,需要将之前标签与新标签进行映射,名称未改则不需要确认,如果有偏差或者修改或者通过标签调研发现多个业务标签命名或规则不一致,则需要进行各个业务线口净统一。

4. 数据加工

数据加工要考虑两点,其一为数据加工清晰化流程,其二则为数据加工过程中的安全性。

数据加工流程图:数据源-数据中台(数仓)-CDP应用数据构建,从ODS进行数据清洗后,进入到DWD层,再流入DWS层,其中DIM层可与DWD和DWS联动应用,在进入DM层进行整合,最终流入CDP进行ADS构建从而提供给上层进行应用。

数据安全:数据安全属于在数据中台的范围内要考虑的,但在标签规划时涉及到比较多的敏感数据,因此需要在这个阶段考虑到数据安全性的问题,给相应的数据中台提出安全性需求,确保数据传输的的安全稳定。每个公司的安全范围可颗粒度不同,而且数据安全是个大项这里不做额外拓展。

需要遵循以下原则:

5. 标签验证

数据源质量验证,对ODS、DM层进行数据质量评估,真实性 > 60% 被认为较为可信。

八维评估数据源各数据项的质量:

  1. 完整性:空值检查;
  2. 规范性:引证数据;
  3. 及时性:延时时长;
  4. 唯一性:重复性检查;
  5. 一致性:数据比对;
  6. 关联性:业务检查;
  7. 有效性:字段是否符合格式;
  8. 真实性:与实际值比较。

标签表计算准确度:继承DM层的各数据项完整性、真实性,且要求基于此数据项的标签计算准确度达到99.9%.

  • 与DM层进行比较,确保数据一致。
  • 逻辑错误验证:如年龄是否超出正常驾龄范围等。
  • 取值单一性验证:确保一个主体在一个标签上只有一个值,如同一个客户在性别标签上,同一时间点不能既有“男”取值、又有“女”取值。
  • MECE原则验证:确保通过规则切片后,各标签值对应的用户量累加是全部用户,不能少也不能多。
  • 模型算法合理性验证:模型算法的设计逻辑符合业务逻辑,测试集与训练集样本分配合理。

业务准确度:在业务过程中验证,通过设计业务策略或AB测试,从业务角度评估标签值的准确度。

  • 业务反馈验证:销售顾问或其他业务人员可在标签使用过程中给予反馈,并提交开发进行数据源数据项的修正。
  • 通过设计问卷调研等相关活动收集数据,增加数据源可信度。
  • 模型算法准确率验证:用AUC指标来衡量模型的准确率,一般AUC>0.8是比较好的表现。
  • 通过使用相关标签圈定客群做POC验证,设置AB测试,根据触达客群后的转化效果对比对照组的表现来评估;若显著低于对照组,则需要排查标签准确度。

6. 规范运营

除了在标签设计需要规范化设计外,在标签实施过程也需要有标准化的流程进行把控,保证标签有序的开发实施。

与此同时需要进行标签的权限和审核流程的规划,标签权限体系需要细化和内置到系统中,总得来说,有两类权限可以会直接影响到业务流程和数据安全。

业务权限:通过将权限授权给固定角色,进而对于功能权限进行精细化管控;以下为举例的角色打来,根据实际企业和业务会有更细分的范围。

数据权限:通过将标签可拥有,可查看的权限,授权给标签的创建和使用者。

7. 经验总结

标签规划:

切记大而全:标签随着业务走,大而全的标签会使标签开发成本、运营成本、运维成本增加,标签设计时应该场景化,开发采取少儿精、小步快跑的规划思路,优先实时数据质量高、业务需求强的标签。

标签质量:

ID打不通,会导致多端多平台无法实现标签一体化,往往会出现业务系统上标签A,SCRM中也出现类似标签A的标签,导致标签定义一致但为打通,因此应该从数据治理曾进行oneid体系的构建,打通全域数据,并将标签统一化管理。

标签无法验证,如果前期未考虑标签的验证流程,会导致标签构建完成后无法对标签进行验证草草上线可能对运营造成偏差,因此在抱歉构建时就需要考虑标签数据验证及业务验证的双重验证,对不同类型的标签进行标准化逐层验证。

数据质量太差,数据质量差会导致标签不完善甚至无法落地使用,对于这点在规划阶段是要进行数据勘察,确定哪些高优标签的数据出现缺失,优先对于该数据员进行数据治理和数据补全,确保标签可实施可落地。

本文由 @光波 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。