十年的标签库建设经历,从中我得到了什么启示?

8 评论 15543 浏览 109 收藏 17 分钟

根据多年工作经历,笔者分享了关于如何建设和运营好标签库的经验,分别流程、运营、创新、人员四个方面出发。

记得很多年前刚开始建设标签库的时候,目的还是很单纯的,想着数据仓库既然是数据的汇聚地,那么对于标签也需要有一个汇聚地,这就是标签库,在一个系统上承载所有的客户标签,实现360度的客户洞察,然后提供计算、搜索,收藏等一系列功能,想想也是很酷的事情。

第一期标签库承载了几百个标签,但好不容易建设完成了,却发现使用者寥寥。为了推动标签库的使用,当时还想着模仿维基百科。

业务人员可以依托标签库在企业内建立一种标签生成,发布,修改,下线的扁平化运营机制,这样大家的经验通过标签库就可以沉淀下来,比如业务人员提交业务规则,然后管理人员审核后进行开发并发布,还可以提供各种评论功能,这将是一个多么美好的标签生态啊。

但你会发现这只是一厢情愿,维基百科的理念在一个企业内是基本玩不转的,这牵涉到规模、机制、流程等一系列问题。

我们吸取了教训,继续为标签库找出口。

第一个手段就是希望基于原子标签的组装来实现自助取数,从而替代传统的人工取数。

但企业内取数的特点是灵活性非常高,既有营销清单又有分析报表,基于标签来实现复杂的分析显然不大可行,而对于简单的清单取数还不如设计几张宽表来得有效。

第二个手段是希望基于标签库直接为营销平台提供精准客户群,我们打通了标签库和营销平台,带来了标签库使用量的提升。

但当标签库的客户群无法满足营销要求时,我们还是要走人工定制模式,而这涉及到需要走不同的流程。

在标签库的运营上,似乎总是差了一口气,即使进入了大数据时代。

直到最近一年,当新的数据产品经理出现,当团队对于数据、产品、营销、流程有了更多的认识后,标签库才算进入了新的阶段。

以下是最近标签库产品经理给的需求图,这就是我们所需要的,标签库需要自我革命,不停的拓展使用场景,而使用体验也至关重要。

十年的标签库建设经历,我得到了什么启示?

很多大企业的BI其实不缺资源,缺的是对于一线的真正理解,缺的是一个真正的数据产品经理,能够对于企业的数据、平台、业务、机制、流程有个全局的理解,然后综合利弊给你一个解决方案。

那些等着业务人员提出需求,然后被动接受需求,实现需求的建设模式,很难打造出好的标签平台。

什么意思呢?就是你的数据产品经理,最好做过建模,搞过平台、干过营销、还懂流程,如果懂点运营更好,这样他才具备较好的决策判断能力,做事比较大气,知道哪些是一线真正需要的,哪些是性价比相对高的,哪些是聊胜于无的,哪些是不可能实现的。

关于如何建设和运营好标签库,笔者近来有四个体会,特此分享于你。

关注流程

标签库不能独立于企业的生产流程之外,标签库串接了多少流程,往往决定了它流量的基本面,没有流程的支持,你的标签库始终是个奢侈品,再好的体验,也不如接入一个企业的流程成为其中的必需一环来的重要。

标签库起码可以串接以下两个核心生产流程:

(1)标签库与营销平台的衔接流程:如果你的营销平台使用的客户群全部来自标签库,那恭喜你,你的标签库是有些生命力的,但在衔接的过程中,要关注用户体验,比如不要粗暴的将标签库页面内嵌到营销平台。

平台的衔接一定要无缝,就好像标签库不存在一样,用户在营销平台发起的投放流程应该最为便捷的选择到自己在标签库创建的客户群,反之,在标签库也应该最为方便的将客户群推送到营销等外部平台,这考验产品经理的功力。

很多系统衔接变成了简单的用户群导入导出,大量的线下操作,不仅造成了流程事实上的断裂,而且让标签库变得可有可,营销平台如果大多数时候用外部手工导入客户群,标签库价值何在呢?

一线很难有先知先觉,反正习惯了也就这样,但计算一下就知道有多少人工无谓的浪费,一线提不出需求,不是它不需要,而是往往它不知道还可以这样,这种事情太多了。

(2)标签库与开发平台的衔接流程:现在大家都在提大数据的PaaS,各种高效的数据建模和开发工具让你的数据处理效率获得了极大提升,但很多时候你却没有解决数据的最后一公里问题。

比如你作为开发人员刚开发完了一个模型,然后需要业务人员去进行营销投放,你可以计算一下需要经历多少流程,多少系统,多少人员,多少时间才能完成这个数据的最终推送,如果我告诉你只要在系统上点击两次就完成了,是不是效率更高?

事实上,每多一个流程,每多一个审批,每多一个中间人,每多一个系统,企业的营销效率就会打个折扣。

标签库作为企业的客户管理中心,要最大可能的直接对接所有的数据管理平台,将数据推送到标签库的功能按钮就要像FB的like按钮一样,无处不在,只要你的数据要推送到渠道营销,你的平台就得设计这个like按钮。

关注运营

前面的流程可以解决流量的基本面问题,但如果你要真正的发挥出标签库价值,就需要关注标签的质量,其始终是标签库的核心竞争力。

很多企业建了很多标签,要么无人问津,要么昙花一现,为什么?

有两个主要原因:一个是人家没有读懂你的标签,不敢用,另一个原因是人家用了效果不好,不想用。

这就需要靠运营,但大多企业建设标签库的时候人员一堆,但建完了就呈鸟兽散,实际上每建完一个标签,标签团队就多了一个负担,得有人为这个标签的效果提升负责。

我们现在都在提中台,标签也是中台,而数据中台最核心的工作,不是建什么功能,而是持续的提升模型和标签质量,让这些数据持续的产生价值。

因此,需要建立标签效果的反馈机制,比如依据营销的成功率进行标签的评估,你起码得知道哪个标签跟哪个营销活动有关,你才能从营销的成功情况评判标签的价值,而流程贯通往往又是自动化评估的前提。

但光知道了标签的效果还不够,还需要有专人去优化提升,这就需要责任到人,一个好的标签生命期往往只有半年,假如没有强大的建模团队保障,标签容易昙花一现。

很多模型和标签之所以建了再建,最终问题就是运营的问题,企业的标签库有建设团队,但往往没有运营团队。

在IT系统上我们会特别关注运维,因为系统无法稳定、高效运行会直接影响生产,其实标签也一样,标签的价值无法维持最终也影响生产,但标签运营往往做不好。

也许企业对于数据的理解还比较浅,数据驱动运营有很长的路要走,也许是组织机制的问题,比如营销归属市场,标签归属IT部门管理,中间会存在边界不清的问题,也许是责任界定的问题,比如营销真的做坏了也很难追责到标签身上,更大可能是政策、产品、渠道出了问题。

KPI虽然不是万能的,但没有KPI让标签运营失去了方向,在起步的时候,我们需要有一些目标感的东西。

做了大数据之后,我们才非常艰难的形成了对于部分重点标签的前端反馈机制,但还远远不够,比如以下是宽带模型的反馈示例,你只有不停的获得一线的数据,才能知道努力的方向:

十年的标签库建设经历,我得到了什么启示?

下面的这位同事专门负责流量模型的建设,就是要不停的迭代。

十年的标签库建设经历,我得到了什么启示?

关注创新

标签库建设的主要目的就是服务好精准营销,我们希望把很多数据的能力以标签这种标准化形式进行高效输出,侧重在检索、实时、簇群、性能等方面进行提升,当然每个企业的实际情况不同,但一定要敢于打破常规,为业务人员更好的赋能。

(1)检索:标签多意味着检索效率低,大多业务人员习惯于就访问自己关注的那几个标签,因此需要设立业务专区,根据自身企业的业务分类将标签分门别类,但无论哪种分类都解决不了一线灵活管理的要求,因此还需要提供自定义目录能力,共性的标签确保权威性,个性的标签确保灵活性。

(2)实时:用户的兴趣有短和长之分,很多用户的购买决策往往是瞬时的产物,其实跟长期的偏好关系不大。

以前我们的实时营销是基于事件触发来进行推荐的,比如你需要对进入某个商场的人进行产品推荐,在系统层面往往是先离线圈定一波购物潜在人群,也即静态标签,然后再配置一个触发规则,在这批人进入某个商场的时刻触发营销(LBS)。

现在我们衍生了标签的内涵,业务人员可以将整个场景(LBS)封装成一个动态标签,动态标签的管理模式跟静态标签完全一致,这样标签库就可以把场景知识也沉淀下来,虽然在营销的时候技术实现不同,但对于用户来说是透明的,这有助于实时营销的普及及推广。

(3)簇群:每个用户都处于一个特定群体中,我们的世界实际是被各种社交网络包围着的,考虑到运营商有大量的社交通信产品,比如家庭网,亲情网,宽带,集团等等,因此需要结合业务实际突破了原有以用户为核心的标签管理方式,打造簇群这种新的标签体系,这样可以大幅提升客群管理效率和生成效率,比如营销家庭产品肯定更关注户主,因此就需要家庭标签,而不是个人标签。

(4)性能:标签库特别关注两种性能,一个是实时计算能力,一种是实时查询能力,前者解决标签组合计算生成客户群的效率问题,比如10个标签组合关联得到目标用户群,你得在极短的时间生成,后者解决的是实时统计的问题,因为业务人员需要基于实际数据量调整策略。

虽然当前能支撑的技术不少,但一定要结合企业实际选择适合的,比如前者可以采用GBASE(其实还不够快,但够用就好),后者可以采用ES等。

关注人员

可以看到,标签库跟企业的各种平台都有千丝万缕的关系,产品化难度其实挺高,不是安装一下就可以拍屁股走人了,当然很多时候标签库不成功,不是产品问题,而是管理问题,这里重点提二点:

第一,从自身人员的角度讲,企业需要有自己的数据产品经理和核心建模团队,光有项目经理是远远不够的,标签库这种系统要运营好,付出的代价非常大。

笔者并不认为合作伙伴可以替代企业自己的这类角色,最多是辅助角色,企业不可能把一个客户洞察中心让一个合作伙伴去管,因为只要跟数据紧捆绑,就意味着本地化属性非常高,意味着巨大的交易成本。

第二、从合作伙伴的角度讲,一定要在本地配备足够的人员,他们才是产品提升的眼睛,适当的定制化不可避免,研发团队除了听取一线的声音,更要关注开放性,为本地PSO赋能。

现在数据类的组件太多了,各有千秋,一个产品不可能打包天下,在一个地方做的足够好就非常不错了。

标签库可以跟互联网公司的DMP相类比,DMP在精准广告投放平台的作用可是居功至伟,相对还是比较成熟的。

但考虑到传统企业相对薄弱的数据基础,复杂的营销机制和流程,单薄的人力资源配备,其建设和运营标签库的难度实际非常大,而考虑到每个企业的实际情况不同,又决定了大家不一样的演进路线。

希望我的分享于你有启示。

 

作者:傅一平,从事电信行业工作,在数据仓库、数据架构、机器学习、数据产品、数据管理、精确营销、数据变现等领域有10多年从业经验,公众号:与数据同行(ID:ysjtx_fyp)

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写得真好,大佬能提供下标签库原型的截图吗?现在这边要做企业画像,也要搞标签库

    来自广东 回复
  2. 学习了,感谢分享。

    来自广东 回复
  3. 为作者打call,标签体系和金融的风控决策引擎系统比较相似

    来自北京 回复
  4. 写的太棒了

    来自北京 回复
  5. 电信行业吧

    来自四川 回复
  6. “一线很难有先知先觉,反正习惯了也就这样”一定也是郁闷过了的呢,哈哈哈哈哈哈哈哈

    来自广东 回复
  7. 建标签库需要小团队协同作战,大部门之间的鸿沟,是标签库好建不好用的重要原因。另外标签部门需要有明确的标签定义规则和展示平台,可能同一个标签,不同的业务条线有不同的业务规则来定义,需要明确区分避免混淆。同时建立好标签新增和淘汰的机制。

    来自湖北 回复
  8. 写得很好,标签库的原型能否给个原型例子。

    来自广东 回复