让甲方应用数据无功而返的十个大坑

我整理了甲方在数字营销上应用数据的十大坑。并且准备同时在抖音上,用短视频的方式介绍我看到的这些问题,及其背后的原因。

在跟甲方企业的朋友们交流的时候,被问到最多的问题是:“宋老师,告诉我们营销上数据应用的成功案例吧!”

这个问题很难回答,尤其是期望我提供一个holistic(全方位)成功的案例时。毕竟,软文是软文,落地为真相的时候,往往不忍直视。

“那讲讲不成功的案例吧!”

不成功的,或许不能称之为案例,我们不是看笑话的看客,我们的目的是不踩坑,不犯前人犯过的错。

那何不把这些共性的问题梳理出来?毕竟这不是一家两家的失误,这其实是这个行业比较共性的现状。你应该首先注意到这些问题,然后再正视这些问题,再之后就有很大机会解决这些问题。

我整理了甲方在数字营销上应用数据的十大坑。并且准备同时在抖音上,用短视频的方式介绍我看到的这些问题背后的现象。

第一坑:缺乏数据

没有数据不可怕,可怕的是没有数据但以为自己有。

谁说我没有数据,我每年花几百万买数据呢!

随着围墙花园墙壁的不断推高,以及个人隐私保护的不断加强,外部数据可用,但不可被拥有。

另一些外部数据的提供方式,是在你自有数据的基础上,进行数据增强,如果你自己没有基础性的数据,数据增强也无从谈起。

换句话说,今天企业自己积累第一方数据的意义很重大,否则基本上只能用用别人的数据,被外部数据的提供方(尤其是媒体)锁定,并且应用场景也被锁死在广告投放为主的场景上。

如何获取数据是一个很需要策略与执行的事情,并且不是只靠外部供应商和工具就能搞定的。具体而言,它不仅与企业的市场营销策略和消费者触点直接相关,也与“请求(诱使)”用户留下数据的设计、方法与诚意(或借口)直接相关。在这二者的前提之下,工具和技术才能发挥作用。

还没有搞清楚数据从哪里来,要用到什么样的技术,有什么样的限制,就急急忙忙跟风上系统,纯属胡闹!

避坑方法:避免踩这个坑的方法,一是要精心设计捕获数据的场景和方法,二是要用好工具。前者更重要。

还有朋友说,企业的其他系统很多,其实还是有大量数据可用的。但是,数据多,不代表有数据可用,一个原因在于后面要讲到的第二个坑(数据清洗)。

第二坑:有一大堆没用的数据

刚刚讲到,有数据不等于有数据用。

很多企业保管自己消费者和用户数据的方法,还是Excel。有些企业有CRM,但是其中的客户数据的字段相当混乱,或者空白和错误甚多。

但应用数据有一个很重要的前提,是“数据流转”,就是从一个系统输出给另一个数据的应用系统。但字段不匹配、ID不匹配、原始数据存在错误、拥有同样命名的数据含义却不相同等等问题,都导致数据流转成为空谈。

这些杂乱无章的数据,每天成吨地被生产出来,创造了一种数据异常丰富,数据资源取之不竭用之不尽的假象。

实际上不过是一大堆没用的数据。Garbage In Garbage Out!

为了让数据有效地组织起来,必须做数据清洗。今天,所谓的数据中台,要实现的一个重要的目的,也是让所有的业务能够享有同源数据,避免不同系统为同一个对象产出的数据出处不同、命名不同或是规则不同。

能够走到数据清洗这个环节的甲方,真的已经是挺高段位了。

避坑方法:避免这个坑的方法说简单也简单,说难,其实相当难——数据清洗和数据治理。基本上都得从业务端发起,甭想靠技术一劳永逸搞定。换句话说,数据不是多多益善,可用数据才是真数据。而要让数据可用,必须得甲方自己亲自参与进来投入精力。单靠技术不可能让数据拥有更好的质量,结合业务的技术才能让数据更靠谱。

第三坑:车有了,没会开车的人

前两年是DMP火了,这两年是CDP火了,还有让人可远观不可亵玩的中台也半火了。但是赶着潮流上系统的,可能会惊慌发现,车都造好了,但似乎没有几个人会开车。

开车这个问题可以算是数据应用上最大的坑之一。

一个解决方法是,让提供系统的供应商也顺便提供司机。但问题来了,造车,可以是流水线,可以复用代码,或者直接用SaaS,但开车,确得实打实的靠人。

供应商也没有那么多人。并且,供应商派来的司机,虽然懂车,却不懂你的路,也不懂你的交通规则系统,所以,这车也不容易开好。

避坑方法:培养自己的人学会开,最靠谱。甲方内部,一定得要有聪明好学的小伙伴。

第四坑:破车

花了大钱买的车一定是豪车?好车?这可真不好说。

行业中的破车挺多的。

一个原因是,甲方不一定有辨识好坏的眼力。很多时候,真到了落地使用的时候,第一次点火启动,才发现这车只有两档,顶多跑二十迈!

因为造一辆好车和破车的成本差别实在是太大了。这篇文章“为什么toB市场总是一个劣币驱逐良币的市场”,对“好系统”和“差系统”的成本,有具体的案例解释。

很多甲方把能否实现某某功能作为好车和破车的主要衡量标准,这绝对是大谬。

没有任何系统或者工具能够实现所有你需要的功能,一个好车,有两个特点,第一,基础功能做得特别扎实。比如,细分(分群)功能每家数据工具都有,但是水平差异却特别大的功能。好的细分功能,支持的属性字段多,可用的规则丰富,背后的算法也精当,这样计算速度就快,细分能力也强,实用。不过,功能一旦强大了,看起来就复杂,用起来也不简单,成本还贵,反而不讨喜。

好系统的第二个特点,是能够灵活配置,除非确实不能解决业务问题,否则只需要依靠配置,而不用二次开发,就能实现针对甲方业务系统的定制化。不好的系统,可能刚好反过来,什么都要二次开发,否则用不了。但是,有的甲方认为,二次开发就是针对我们的“诚意”,就是好。殊不知,基本功没有做好,才得不断地“东拼西凑”、“狗尾续貂”。

避坑方法:这坑怎么破?买车之前得试驾,亲自开一开,至少能感受到一些基础的性能。此外,品牌优劣也很重要,偷偷问问其他甲方先行者们的体验,或是问问对这块有研究的中立的专业人士,也很有价值。

第五坑:忽略功能发挥所需要的前提条件

这个坑,不少甲方也都踩过。

比如,过去忽悠甲方说,我们能搞定阿里的数据。但他没告诉你条件,前提是,数据的应用都必须且只能在阿里的生态内。这个条件,其实是很“严苛”的。

现在大家都明白了围墙花园这种“自然现象”,上面的忽悠肯定没市场了,但新的忽悠仍然不断萌生。

最典型的,数据打通。几乎所有的数据系统都有这个功能。

但数据的打通,需要条件,而不只是靠技术。条件具备了,技术完全不是事儿。

条件不具备,而让技术直接去搞定,今天没有这样的可能了。

说支持“全链路”数据打通是今天的各种工具的“时髦”。但前提是,全链路都得同意安装这个工具的代码(就是用这个工具做埋点),并且每个链路上用户都得留下电话号码,并且链路的终点不能是天猫淘宝这类封闭平台。否则,要么根本就谈不上“全”链路的打通,要么跟你自己捣腾导出订单Excel之后,自己打通这些数据没什么差别。所谓全链路,都是在严格适用范围限制下的“全链路”。

又比如,说自己的推荐算法(推荐引擎)如何如何智能,如何如何天下无敌。其实,这个功能今天也很成熟,但是也需要创造条件才能工作。毕竟其背后是监督学习,要“喂给”机器靠谱的数据,并且要认真告诉机器哪些work,哪些不work。这些条件,都得靠甲方自己去创造,不关数据系统和算法的事情。

有时候,也不一定是供应商非要忽悠,而是甲方自己没有搞清楚,想当然,于是供应商也就将错就错了。也有时候,是甲方根本就没有意识到看似理所当然的功能也是要在一定前提下才能发挥作用的。

避坑方法:只能通过学习,学习数据的逻辑,学习目前的技术解决方案的适用范围和可用场景,学习各种解决方案背后的技术之外的条件。并且,不要尝试记住常识,而是应该理解常识背后的原理和原因。

第六坑:重解决方案,轻运营

有车,也有司机了,是不是这车就能开稳开好?

不,前面还有一个大坑,一个几乎所有甲方都没有做好应对准备的大坑。

即使是数据都清洗了,也有了工具、技术,以及使用工具和技术的人员,并不意味着能够应用好数据。

解决方案牛X,代表不了任何成功。

因为解决方案必须有用武之地,而用武之地,需要靠甲方设计出具体的应用场景。毕竟,这里有一个很普遍的误解,那就是,有了某个牛X的解决方案,就能为我创造过去实现了不了的场景。误解在于,解决方案是必要条件,但远不是充分条件。

比如,有了CDP,就能让我实现过去不可能有过的“千人千面”或“one on one”的消费者沟通与运营。

没错,没有CDP或者类似的东西,确实不能实现千人千面。但是,就算你有CDP,并且有可以熟练操作CDP的员工或服务商,千人千面也不可能就随之实现。

因为,千人千面的背后,究竟给什么人以什么“面”,或者对不同的人传达什么信息,以及在什么时机和场合下传达,都不是CDP和CDP使用者该负责的。得靠甲方自己,基于自己的目标和约束条件进行设计。CDP不可能预知这些设计,也不会自动产生这些设计。此外,在执行所谓千人千面的过程中,也可能需要不断调整优化,这些,也都不是CDP等解决方案能自动解决的,照样要依靠甲方自己的营销运营团队。

如何避坑?记住:业务先于数据,数据先于技术。其次,有了好的解决方案,要比过去更勤快。因为工具强大了,能力和责任心也必须更加强大,才能与之匹配。

第七坑:部门墙

应用数据的目的,本质上,是为了建立障碍更小的组织。但组织内部的障碍,却反过来会影响数据的应用能力。

毕竟,数据应用要基于数据打通,而数据打通,则将消弭很多组织内部部门之间的信息不对称。

对于部门而言,透明化未必是好事,而且很可能对于自己的部门没有好处,却为其他部门“做了嫁衣裳”。

而且数据化可能会改变原本已经很圆熟的工作流程和操作,员工又得重新学习适应,很可能怨声载道。甚至,不排除令人恐惧的“组织结构优化”。

不建数据系统等死,上数据系统早死。

部门墙的无声阻挠,最后,会让数据的应用限于局部、限于孤岛、限于不伦不类的半吊子应用。然后被质疑、被推翻,再之后,当下一个时髦风口来临,又重新开始一个新的系统。如此往复,却始终难以见到成效。

避坑方法?一个组织的成功和失败的原因归根结底是人。数据领域的CEO工程不一定能成功,但不被CEO重视和支持的,注定会失败。找到共同的利益诉求,做好人心的工作,设计好“不直接受益却要出力的部门”的激励。对于有些企业,解决方案也不能仅仅只服务于整个组织的美好未来,同样要给各个部门“画好饼”。

第八坑:跟风

数据应用与企业的战略直接相关。

比如,要盘活自己的存量流量和客户(私域流量),那么肯定要建立一个描述这些流量和客户的数据系统,至于它叫CDP,还是叫CRM,或是叫客户数据库,反而并不重要。

不过,建立这个系统的逻辑,是从企业的战略出发的,例如从上面盘活自己存量资源的策略引发,然后才需要有数据应用的系统。

但,绝对不是因为自己的友商竞争对手建立了CDP,所以我一定要建立一个。

同样,为什么我一直很担心数据中台对企业是一剂猛药。因为,数据中台过于强调自身,强调要为企业建立数据能力,但往往很少强调这些数据能力的出口和应用究竟具体是什么。把它描述为一个万能钥匙、包治百病的灵丹妙药、能够对接各种需求场景的数据硬通货……但问题在于,对于大部分甲方,他们还在迫切地需要搞清楚自己要解决什么问题的阶段,一个大而全的数据中台并不比具体在某一个领域的数据系统更针对、更好用,却要耗费更多的资源,并有更大的失败的风险。

避坑方法:不要跟风,在决定建立数据系统或数据平台之前,必须做两件事情。第一,在建任何数据系统之前,搞清楚数据要应用在哪里——要做业务上的咨询,无论是内部“自省式”的咨询,还是聘请外部的商业咨询。第二,基于第一步的商业咨询,做“数据审计”,对现有数据情况,以及数据和数据能力的欠缺做一次评估。基于二者,才可能有正儿八经的规划,也才有建立成功的数据应用系统的可能。

第九坑:过高期望

数据不是万能的,对它的期望要合适,但绝对不能过高期望。

数据有很多短板,比如,数据绝对不可能是全面的。有一些消费者的属性你就是不可能获得,不会因为你上了所谓的数据平台就能凭白搞定这些数据。很多时候,真正能搞定数据的是依靠运营人员的智慧和努力,工具只是做好了它应该做好的记录而已。

数据也不见得总是准确的,本来捕获的就是关于人的数据,而人是如此善变。因此,现实来讲,数据系统最终提供的都是概率,而你应用这些系统的好的结果,也是某些业务结果概率的提升。

数据也不见得都是所谓的“资产”。确实有太多的数据,太过于离散、太过于随机。挖掘这些数据背后的价值,无功而返的情况多得是。

而且,很多很多时候,所谓的大数据,一点也不比小数据更管用,更好用。大数据鱼龙混杂模棱两可,小数据更加精准优质;大数据可能早已过了保质期,但小数据却更实时更鲜活。

对于应用系统的期望,也应该现实。前面已经说过,很多功能之所以能够实现的背后,都需要有很多前提条件的满足。所有功能所针对的应用场景也都非常具体。尤其是跟围墙花园体系打交道,更有很多的限制。

避坑方法:现实一点,不能给予更多承诺的供应商,也许对你反而是更靠谱的供应商。

第十坑:人才匮乏

这可能是当今唯一一个同时困扰甲方和乙方的麻烦吧。

数据应用,对人的要求太高了,而真正既懂这一块的知识,又有实践经验的人才,实在太稀缺了。

要做好数据应用,至少对人才提出了三点要求。

第一,要懂业务。第二,要懂数据。第三,要懂数据应用的系统和工具。

这样的人太少,一般都不便宜,关键是很难找到

于是,退而求其次的解决方法是,找一个懂业务的(尤其是懂运营的),再找一个懂数据的,再找一个熟悉系统和工具的。然后,新的问题来了,这三个角色之间的协同该怎么做?并且,懂数据的人和懂业务的人合在一起,未必就变成了懂得如何将数据应用在业务上的人。

在绝大多数其他领域,专业化的分工越来越细,但在数据领域,却越来越强调要能做到懂得更多的跨界领域。这也意味着,这个领域的人才总是很稀少的。

无论对于甲方还是乙方,只要有内行员工在,很多坑就能避免。

避坑方法:相比于想办法让懂数据的人懂业务,让懂业务的人懂得数据背后的逻辑和道理似乎要更可行。业务的理解不是书本和理论层面上的理解,而几乎都只能来自于实践。从实践出发,去研究数据如何带来创新的或者优化的业务实践,是一个可行的逻辑方向。但反过来,让懂数据、工具或者技术的人才反过来去深刻理解业务,是有难度的,一个主要的原因,是他们缺乏真正去实践业务的机会。

十个坑讲完了。看看你们中了几个?

-加入宋星的读者群-

欢迎加入我的读者群

 

未经允许不得转载:版权归宋星及chinawebanalytics.cn所有宋星的数字观 » 让甲方应用数据无功而返的十个大坑
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址