有什么字体设计的网站,企业类型,濮阳网络培训基地,天河做网站系统本文根据神策数据副总裁张涛在《用户个性化运营—标签体系搭建新机遇》主题沙龙中演讲整理所得。 标签系统#xff0c;在企业中已不是什么“高大上”的说辞。然而让用户标签价值真正落地企业不多#xff0c;就像“青少年谈性”#xff0c; 有一段话形容得再贴切不过#xf… 本文根据神策数据副总裁张涛在《用户个性化运营—标签体系搭建新机遇》主题沙龙中演讲整理所得。 标签系统在企业中已不是什么“高大上”的说辞。然而让用户标签价值真正落地企业不多就像“青少年谈性” 有一段话形容得再贴切不过 “everyone talks about it, nobody really knows how to do it, everyonethinks everyone else is doing it, so everyone claims they are doing it。”每个人都在说不知道谁做了每个人认为另外人在做所以每个人都声称自己在做…… 今天我的分享主要包括四方面 搭建标签系统企业中究竟谁在做 看似简单的“标签系统搭建”的三步走 “大功告成”后逐渐暴露的问题 破局的三种方式 一、搭建标签系统企业中究竟谁在做
在一家企业中各职能角色更多的关心“能不能使用标签”而很少关心“该由谁做标签的建设者”。事实上绝大多数企业标签的建设最终是由企业的一个支撑部门来完成比如是技术部门或者是数据部门。 二、看似简单的“标签系统搭建”的三步走
乍一想构建用户标签是很简单的事情。简单说正如“把大象装进冰箱”三步即可收集需求——构建标签框架——填充数据下面详细介绍。
2.1 第一步是“需求收集”
构建企业的标签系统支撑部门会把“全公司的所有的需求”都扛在了肩上因此第一步是收集全公司的需求。市场、运营、产品和技术等对标签诉求差异很大。
比如市场同学关注用户的整体画像更看中“结果”如他们希望了解“渠道属性”知道哪些渠道投放后用户转化效果会更好运营同学则希望了解更为精准的数据据此来构建用户分群实现用户的个性化推荐如给“消费超过 1000 元的用户”推荐某个活动产品同学则关注千人千面的个性化页面展示技术同学追求调取数据的便捷性希望各职能线将所有数据放在一个平台上形成统一的用户信息管理平台而不是每次开发一个新需求都要去不同的业务系统调取数据……
当然这只是企业内部需求多样性的缩影。事实上因为在企业中标签需求方众多即便同样是产品同学对标签的理解和需求也是千差万别的。
2.2 第二步是“抽象”
面对收集到的“琳琅满目”的需求“抽象”是让标签体系满足多业务线需求的必需步骤需要抽象成一个标签框架这是一个极大的挑战因此大部分企业的标签系统的初始框架是一个很庞大的系统。在初始框架中通常会包括人口统计学信息、用户个人档案、业务数据沉淀、业务方标记信息、策略类计算标记等。 这里我重点解释下“策略类计算标记”。我们给用户打标签很多时候不是依赖用户的填写的信息或者采集到的基础维度的信息而是会包含策略计算的标签比如我们给“启动 APP 但七天未注册”的用户打上“高流失风险”的标签这就是定义的一个策略标签。 2.3 第三步是在标签框架中“填充数据”
数据的来源通常包括用户填写、行为数据、业务端数据、策略规则、外部补充等。其中“行为数据”这一来源中用户分群是常用的数据分析模型比如筛出“半年内看过宫斗剧五部以上”的用户群体并给该群体打上“宫斗迷”的标签“外部补充”不单是购买数据库这种补充数据的方式对大企业、大集团来讲多业务线经常会涉及到数据的不断交流和互相补充。
三、“大功告成”后逐渐暴露的问题
整体看来从收集需求——构建标签框架——填充数据这是一套很通畅的逻辑链条。许多企业都能做到这一步但这一步就意味着大功告成了吗实际上在企业走访的过程中我发现大家会有各种各样的问题以下几种更为典型。
3.1 标签的定义解释
通常标签系统建设团队定义一个标签名为“高价值用户”各业务线基于自身对该群体的差异化需求对“高价值用户”存在理解偏差和应用差异标签系统建设团队需要花费较多时间来讲解标签的定义而经常给某业务线同学解释清楚后又发现不符合其实际需求……
3.2 更新维护
标签是不断更新的标签之间存在一定的相互交叉与依赖且系统背后有一定的逻辑关系而业务方对此并不理解经常诧异昨天的标签数据为什么没有跑出来跑出来的是空值……在应用的时候存在各种顾虑。
3.3 新增需求
“高中低价值用户分得太粗我要⼀个介于中高之间的标签……”类似这种需求会很多标签系统建设团队会因此排期过满。 举个例子。在一次银行客户的拜访过程中客户向我咨询“开发一个新的标签需要多久”对我们来说建一个新标签是很简单的事情修改规则并跑几分钟数据就出来了。而事实上该银行客户从提出用户分群的想法到与数据部门沟通并确认需求再经过排期开发全过程竟长达一个月。 为什么这么久客户解释数据部门作为后端支撑部门在话语体系上是无法和业务口同学直接沟通比如“高贷款潜力”用户可能对数据部门是较为陌生的概念。因此双方在沟通过程中需要沟通至每个字段、取值、运算规则等在明确后又可能因为研发资源不足而需要排期…… 3.4 需求冲突
抽象出来的标签框架是符合全企业业务线的需求的比如定位启动 APP 后七天没有注册的用户是“高流失风险”用户有的业务线却认为“当天没有下单就是高流失风险用户”因此建议标签系统建设团队修改标签但修改标签会影响其他业务线对标签的使用。
3.5 数据输出
比如运营团队会根据用户分群进行个性化推荐而推送系统也需要一些标签这会造成一定的复杂度。 基于以上问题标签系统建设团队一直会扛着来自各种业务线的压力虽然花费较大精力完成的标签系统在内部却被反馈用不起来。 四、破局的三种方式
过去十年中我几乎一直在做 C 端的产品设计和运营管理也有短暂的 B 端经验工作中会涉及标签系统针对以上情况我考虑三种比较可行的破局方法
4.1 放弃大而全的框架以业务场景倒推标
4.1.1 签需求
前面讲到产品、运营、市场等对标签的诉求有较大的差异同时不同的运营团队的诉求也存在很大差异⼤而全的标签框架实际是站在用户视角搭建的但是标签的真正应用者是业务方所以应该从业务视角来实现。
因此最佳的处理方式是我们应该放弃顶层的用户抽象视角针对各业务线或部门的诉求和实际的应用场景分别将标签聚类起来提供给相应部门。 以某直播平台的消费者运营为例其消费者运营分为两类大 R 用户和普通用户大 R 用户年消费从几万到上百万不等而普通用户年消费在几百至几千元之间。运营团队对两类人群的运营思路完全不同因此对标签的诉求也不同针对大 R 用户平台会为该群体提供一对一的服务因此运营者需要了解大 R 的详细数据比如他们的互动对象、关注主播类型等而普通用户则通常采用用户分群的方式运营即可。因此我们不可能用同一套标签覆盖整个运营团队这种以业务场景倒推标签需求的方法能够与业务场景贴合更紧密可用性上升。 4.2 标签生成自助化解决效率和沟通成本
主要表现在三个方面。
1标签生成的自助化能够让沟通成本降最低。前面讲到各业务线对标签的定义的理解不同需要标签系统建设团队花费大量的时间沟通。如果能够让业务方自己定义规则这必然是沟通成本最低的方式。
2标签生成的自助化可重复修改的规则降低无效标签的堆积。业务一直在发展如果规则一成不变则很难跟上业务节奏的变化。我曾拜访过一家电商他们发现半年前定义“母婴客户群”的转化率一直在降低因此根据实际情况重新修改和定义了“母婴客户群”规则并命名为“母婴客户群新”这时之前的规则是无效的且会一直占据计算资源……诸如此类如果支持规则重复修改的话这一类无效标签就会大量地消失。
3释放数据团队人力释放业务团队的想象力。数据团队应该花较多的精力在企业的整个数据中台或新业务模型方面而不是处理各业务线的标签诉求和标签维护上自动化的标签生成能够极大限度地节省人力和释放团队想象力。 举个例子。有一家线上健身 APP是神策标签系统应用较为深度的企业他们从标签的创建到推送动作完成的全程不超过半小时这意味中他们半小时内即可对一次推送活动的效果进行评估。他们曾给我讲过一个有趣的故事公司针对白领推出一款腰椎修复的课程基于用户分群筛出用户群体后发现效果并不好然后深入研究发现此项课程容易坚持的群体特征是BMI 指数较高的群体。于是团队重新创建了新的运营计划最终取得较好的效果。 我们通过这个案例可以看到一旦业务人员能够快捷地访问和创建标签后这会赋予他们很大业务上的想象空间让更多优质的运营场景落地。
4.3 有效的标签管理机制
有效的标签管理机制主要表现在以下几个方面。
1规则及元信息维护标签相关的规则和元信息要尽可能的暴露给使用者让使用者在使用的时候能清楚知道标签的规则是什么、创建者是谁、维护者是谁、标签的更新频率周期等而不是没有规则或者将规则存在标签建设团队内部的一个 word 文档中。
2调度机制及信息同步标签之间有一些关联标签之间的链条断裂是否有个调度机制或者信息同步机制让大家的工作不被影响。
3高效统一的输出接口将所有的业务信息和用户数据信息汇总在一起有统一的输出接口改变之前需要针对不同的业务系统开发不同接口的情况。 我们回顾三种破局方式本质上是解决了价值、手段、可持续性三方面的问题以业务场景倒推要求需求让业务方用起来作为最终目标让标签系统价值得以实现标签生成的自助化它解决的是我们用什么样的手段去实现价值有效的标签管理机制意味着一套标签体系能否可持续性地在一家企业里面运作下去。 总之对企业最重要的是一套标签系统能不能在业务上用起来能不能覆盖更广泛的需求而不是一个大而全的框架。
———————————————— 版权声明本文为CSDN博主「神策数据」的原创文章遵循 CC 4.0 BY-SA 版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/sensorsdata/article/details/92841022
