上一篇数据中台的实战文章讲了《数据中台实战(八):如何打造可以支撑N条产品线的标签平台》,这次讲如何搭建全渠道自动化的营销平台。
先讲一下全渠道营销平台是什么。运营的大部分工作就是搞营销活动,刺激用户下单和复购。在很久很久以前,一个公司几个月才搞一次活动,为什么要几个月,因为从一场活动的策划、准备、开发、上线、运营,要耗费大量的人力物力。
现在可以说已经进入全民营销这么一个阶段,有些公司甚至一天搞一场活动,有些大型公司甚至一天搞n场线上的活动,类似抽奖、优惠券、拼团、秒杀等活动,玩的乐此不疲。那么我们怎么支撑这种高频次、快反应的营销活动呢?
因此我们需要一个全渠道营销平台,可以支撑运营常见的一些玩法,比如发优惠券、发推送的消息、节假日可以玩H5的小游戏等,我们这个全渠道自动化的营销平台可以支撑n条产品线的常规营销活动,每个产品线只需一个运营的负责人在平台上配置,就可以发起活动,在活动进行中可以输出实时的效果分析数据,在活动后的效果复盘也能自动化的输出数据。
这样就形成了一个营销闭环,有了营销的闭环就可以实现用户及收入的增长。全渠道营销平台是一个面向运营的,综合业务中台的营销能力和数据中台的数据分析能力的智能平台,也是打通双中台的一个比较好的实际应用场景。
无论做什么样的活动,都可以简单的抽象出一个通用的流程:活动策划-圈人-做活动-看效果。
第一步是活动的定义,就是活动的目的是什么?为什么要做这场活动,是为了拉新,还是沉默用户的促活、还是老用户的复购还是其它的原因?接下来就是基于活动的目的来定义我们要玩一场什么样的活动,比较常规的有屡试不爽的抽奖、还有发优惠券等。
第二步是是要定义目标用户,也就是用户圈选,我们需要邀请哪些人参加我们创建的活动?通过这场活动我想让这批目标用户产生哪些行为?这一般来说就是基于活动的目的,来定制相应的圈选策略。
第三步是制作活动内容,比如抽奖我们得配置什么时候开始、什么时候结束,奖品是什么等?接下来推送渠道的选择,我是通过什么样的方式来告诉目标用户来参加活动呢?是用短信,推送,或者是在微信群里通知我们的用户?
第四步是要看数据,活动进行中数据情况怎么样,关注那些指标,这些指标是否有升高或者降低,活动后的数据怎么样,我怎么通过这次活动后的数据快速调整让下次活动做的更好。
这个抽象的流程基本是全渠道营销要做的内容了,上
上一篇数据中台的实战文章讲了《数据中台实战(七):流量分析》,这次讲如何打造可以支撑N条产品线的标签平台。
亚马逊的CEO Jeff Bezos曾说过他的梦想,「如果我有一百万的用户,我就会做一百万个不同的网站!」。
当然,现在大型的电商公司如亚马逊、淘宝等已经实现了他这个梦想,就是我们常说的千人千面-用户个性化推荐系统。
那么如何实现千人千面呢,这个基础是先对用户打标签。
为什么要给用户打标签呢?
最主要原因就是让我们更加了解我们的用户,他是谁?他在哪里?他用的什么设备?他用了我们的什么服务?他的使用习惯是什么?他的偏好是什么?
当我们更加了解我们的用户,我们才会有可能知道他的痛点,我们才会知道应该推荐给他什么样的产品,他购买的概率也才会更高一些。
那么什么公司适合建设标签平台?
一些小的创业公司是不适合的,现在的产品和运营张口闭口就是户画像、用户标签和PPT上面贴满标签的标签云人像。一个真正的标签平台是一个非常浩大的工程,它需要投入很多的开发资源,就只是一个标签体系的建立都需要,n个角色参与(数据开发工程师,数据挖掘工程师,前端工程师、后端工程师、产品经理、模型设计师),加上需求的调研时间,最少也得2-3个月的时间。后期比较深的一些功能如标签圈选、人群画像等又是很大的工程量。
所以,建立标签平台需要很大的工作量,投入很多的资源,前期也不能很快得到回报,是一个方向大致正确的事情。创业公司或者小型公司初期、用户量较少的公司还是不建议做标签平台,当公司有一定规模,用户量有一定基础、数据有一定的积累,再投入资源做标签平台还是不晚的。
那我们该怎么建设标签平台呢?
上面已经说了,当有了一定的用户基础、数据基础才适合搭建标签平台。这时会面临一个问题,当公司发展到搭建标签平台这么一个阶段,一定是多个产品线,多种角色、数据分散度很高的情况。
那么怎么统一这些产品线的标签呢?
例如笔者所在的公司有n条产品线,我们想打通服装批发产业的上下游,从生产端服装的打版服务,到线上的销售平台,到供应链服务平台和金融服务平台等产业的上下游我们都在运营。
我们在搭建标签平台时就遇到了以下个挑战:
上一篇文章讲了《数据中台实战(六):交易分析》,本文讲数据中台实战(七):流量分析。
流量分析的核心就是你的平台每天有多少个用户过来,都去了哪里,在那个位置产生了消费。
针对这几个问题,我们做了几个功能:
这些功能都是通用的,几乎每个互联网产品都会用到。
只要前端产品做相应的埋点,就可以自动化输出数据,支撑N条产品线的流量分析。
先讲一下网页分析,第一步要做的就是和产品线的产品经理沟通现在有那些网页,网页的地址是什么,网页名称是什么,网页有没有在数据库中管理起来。
比较不幸的是,我们的网页是没有管理起来的,我让产品线的产品经理输出了一份现有产品所有的网页名称和地址。
由于没有管理起来,我们只好将这份表格导入数据库,并给网页的英文名称定义中文名称,目的就是更方便运营能理解数据。电商产品的主要网页有这么几个:
其中有两个核心的页面需要讲一下,一个是推广页,一个是商品详情页。
推广页一般都是付费推广,推广页每天访问人数、点击次数、每一步的转化率直接影响到我们的投放ROI。
推广页的流量一般都很大,做投放的同事需要每天监测PV、UV这两个指标,如果发现暴增或者暴跌的情况,就要及时查明原因及时解决,所以我们给出趋势图。对
于访问时长来说一般是越少越好,我们希望用户能够尽快注册进入产品,而不是一直停留在推广页;如果一直停留在推广页说明吸引用户的是我们的推广页,而不是我们的产品,访问时长也是一个监控产品功能的比较好的指标。
我们第一次投广告时就发现一个问题,对比整个产品的平均访问时长来说,推广页的访问时长多了好几倍,经过查看明细数据,发现有一部分用户一直访问推广页,而且是同时发送多个访问请求。
我们当时就用一个未注册用户访问推广页,发现用户访问完推广页会填一些问
上一篇文章讲到《数据中台实战(五):自助分析平台》,本篇文章讲一下交易分析模块。
交易数据是一个公司最核心的数据,领导层会十分关注,一线的运营的kpi也是围绕交易额展开。领导层和一线的运营还是有些不同,公司领导层关注的是大盘,是不会看一些明细数据,而运营需要大量的明细数据来分析数据上升或者下降的原因。
所以给领导层看的功能都是计算好的看板,给运营看的数据的是可以各种维度拆解的数据,所以交易分析模块针对领导层和运营要分开设计。
我们先看下领导层关注的指标有哪些。需要对公司的领导层做一个调研,ceo的视角和每条业务线老大的视角还是有些不同。
针对领导层的交易指标还是要围绕着公司的全年计划来定义,作为高层他们是公司全局的视野,需要一眼能看到公司全年的交易额、收入、每日的交易额、每日的收入。其次就是公司总用户数,每日新增用户数。还有就是每条产品线都有交易额、收入的kpi,可以针对总的交易额做一个拆解,每条线的交易额、收入、完成率。这些指标的口径要向公司高层确定好,然后邮件同步确认,因为交易的数据是每条业务线很敏感的数据,口径必须一致。
我们也约了公司的几个领导层共同确定了一下,基本确定领导层关注的数据指标,主要分为三块:交易额、收入、用户数。
交易额没什么歧义,口径比较清晰,就是按下单金额(用户看到的包含优惠的原价)、下单时间来统计。为了防止刷单,我们又加了一个规则,所有未支付、已取消的单不算进交易额,这个也和领导层、各个产品线的负责人做的一个进一步的确认。
公司总用户数是以手机号为唯一ID,业务中台总体中心有多少手机号,公司就有多少用户数,这个十分明确。各个产品线的用户数就有一些小问题,因为我们的用户都在用户中心,用户只有一个平台标识,注册了产品线A的用户平台标识就是产品线A,不可能是产品线B。所以我们和产品线的运营同事定了一个规则,比如产品线A的用户的定义是,平台标识为产品线A或者注册了产品线A又登陆产品线B的用户。
关于收入这个指标,数据中台统一取订单中的佣金来计算,这就要求各个业务线都要接入中台的交易中心,提交订单时,已经把佣金算好记录到订单中。和业务中台的产品经理沟通后,除了某些产品线会有一些线下订单,这些是没有直接进入业务中台的,他们的运营会每隔一段时间补录进入系统,这样会会导致交易数据的显示没那么及时,其他产品线交易
上一次说到《数据中台实战(二):基于阿里OneData的数据指标管理体系》,这次我们谈下产品经理更加关注的模块产品设计。接下来的文章将从六个方面讲数据中台的产品设计包括用户分析、商品分析、活动分析、流量分析、还有自助分析平台、标签平台、推荐系统的搭建。全部基于实战,读完这个系列,你就可以搭建属于你们公司的数据中台。
还是要先讲一下背景:笔者所在公司为XX环球商品贸易港,是集团旗下汇聚原创设计师品牌及时尚买手/采购商两大社群,通过B2B电商、RFSHOWROOM、富贸通等子品牌为时尚行业提供一站式产业+渠道服务的平台。公司还在广州市、西安市有线下的综合实体商贸中心,涉及到的系统有CRM、ERP、Marketing等各种各样的系统,公司涉及的n条产品线。
如果每条产品线都有专门的运营、产品、研发团队,一方面需要耗费大量的人力资源,另外一方面公司的数据散落在每条产品线,再收集起来就会造成很大的挑战。数据中台的存在就是为了解决这些问题,公司内每个系统的数据都流入数据中台(数据中心),这样数据就会更加规范的存储与组织。
另外只需要一个团队就能支撑起整个公司的数据相关的需求,这是数据中台的优点。但是从这里你也能看出来,由于追求通用性,无论业务中台还是数据中台都是缺乏灵活性的,数据中台的模式是比较重的,这就要求前期公司数据的调研工作一定要做的足够细致,才能避免以后反复改造的问题。
在这里也给大家一个判断公司是否引入数据中台的依据:如果你的公司有多条业务线用到了多个系统,需要通过数据整合来驱动业务,那么你们就合适引入数据中台。如果公司公司只有一条业务线或者初创公司,这种你们还是重点关注你们的业务和价值探索,因为数据中台是需要大量的资源支撑的。接下来我们先讲最核心的用户分析。
刚才提到中台产品的设计讲究通用性,那用户模块我们也需要选择一个比较通用的模型来设计功能,尽量使设计出来的功能能适用大部分的产品线。
用户模块的功能设计我们参考黑客增长AAARR这个模型,从用户的获取、激活、留存、转化(收入)、传播(推荐)五个方面来设计功能。这个模型是比较抽象通用,适用于每个互联网产品,因为每个用户的生命周期都会经过几个过程。
先讲一个坑,拉新的工作每条产品线都会有对应的人员去做,如果每条产品线都有一套自己的标准,需要针对每条产品线的拉新统计单独做一套功能,那么会对统计造成
商品的生命周期分为售前、售中、售后,接下来结合数据中台实战,分别从三个时期的细节方面分析下,如何保证我们提供的都是真正的好货。
上一讲讲了用户模块《数据中台实战(三):用户分析(产品设计篇)》我们用的是海盗模型,从用户的获取、激活、留存、收入、推荐的角度来做分析。这些指标是没问题,但是作为电商产品,如果站在价值的角度来思考就有问题。
你可以分析下我们提到的用户相关的指标,比如:注册量、访问时长、留存率等这些指标都无法提高产品的价值,指标中最重要的是留存率,你发现站在价值的角度留存率也只能监控产品的价值,但是并不能提高产品的价值。
对于B2B电商产品来讲,产品的价值就是要给我们的采购商提供好货,所以商品才是最核心的地方。我们的用户直接接触的是我们的商品,商品能直接传递公司的价值。没有好的商品就不用提用户、产品、流量等其他方面的运营,这些都是手段,这些手段在我们提供好的商品基础上才会事半功倍。
我们先看下商品的整个生命周期,第一步是招商的工作人员负责吸引供应商入驻,如果有一套对供应商的严格筛选标准, 能直接决定商品的档次、品质和货源的稳定性等因素。
第二步是商品的选择,我们要从供应商的货中挑出最好的货给我们的用户,包括商品的款式、质量、性价比等指标。细节的地方我们会涉及到商品的图片及文案,每个细节对商品的转化率都有比较大的影响,因为用户是否下单是有很多因素的,我们把可控的因素做到最好,那就可以比较好的提高转化率。
接下来是商品的销售环节,我们怎么通过数据挑出好卖的货给到我们的用户的呢?
商品卖出去后我们的售后怎么样、我们的发货速度怎么样,也是直接影响用户的体验,可以说商品的每个环节都直接决定我们产品给用户的价值。
怎么保证我们的商品都是爆款、好货呢?
商品的生命周期分为售前、售中、售后,接下来结合数据中台实战,分别从三个时期的细节方面分析下,如何保证我们提供的都是真正的好货。
我们有一套严格的准入机制。为保证效率,我们要求供应商适应“快反应”的柔性供应链模式,并建立了供应商分级动态管理系统,包括供应商准入机制、供应商绩效评估和激励机制、供应商分级认证机制、供应商升降级调整机制。从供应商的选择、分级、合作模式、绩效测评、订单激励和退出等方面进行严格的动态管理。
在供应商准入方面,由招商小组、相关业务部门、品控管理小组到生产供应商进行实地访厂和现场打分,重点评估厂家
本文将通过具体案例来介绍OneData的实施流程,继而介绍阿里OneData数据体系中数据指标的管理和数据模型的设计,最后再为大家讲数据看板的设计。
上一篇文章讲了《数据中台实战(一):以B2B点电商为例谈谈产品经理下的数据埋点》,本文我们先以一个例子实战介绍OneData实施流程。接着再讲阿里OneData数据体系中数据指标的管理、数据模型的设计。最后讲一下数据产品中,数据看板的设计。全是实战干货,看完本文你就会知道数据中台最核心的内容。
比如当时我们运营提了一个比较有指导意义的数据指标叫爆款率,我们以爆款率为例先说一下OneData每个步骤实施的流程和涉及的角色。
业务口径应该由数据中台的产品经理主导,找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的,比如运营说爆款率的定义分子是是专场中商品销售件数超过20件的商品数,分母是专场内的总商品数(专场如上图所示,商品会放在运营人员组的一个一个专场里面)。
这里面有几个坑:
1. 这个20件可能是运营拍脑袋定义的数据,这时要协调我们的数据数据分析师看下历史专场销售件数的分布找出最合理的值,然后和运营基于数据再一起定义最终的阈值。如果历史数据专场销售件数大部分都远远超过20件那么这个指标就所有的专场都是爆款专场,就没什么意义了。
2. 商品的销售件数超过20件,其中有一个十分有争议的字眼那就是销售,怎么定义销售?是下单就算,还是支付才算?考虑不考虑退款?如果考虑退款是发起退款就算还是退款实际发生后再算?其实是有很多问题要考虑的。最终和运营确定为该专场支付后的商品件数除以专场商品的总件数。
3. 销售的商品件数是按商品销售的件数还是按照商品下SKU的销售件数,这个是要搞清楚的,可能运营不关心这个事,但是影响到模型的设计。
处理完这些坑后关于指标的定义还需要问这几个问题。我们统计的维度是什么?比如爆款率的计算维度是专场内商品的维度,一个是要专场内,一个是商品,原子指标就是销售款数。还有就是统计周期,一般统计周期分为按小时、按天(当天)、按业务周(运营自己定义的统计周期)、按自然周周、按自然月月、按年,还有就是截止到昨天也是比较常用。爆款率的统计周期是统计专场开始到结束时间内的销售件数。
接下来要问清楚这个指标有什么用,给谁用。
不是所有的指标都有开发的意义,因为后面你会发现我
本文以B2B电商产品“亿订”为实例,与大家一同谈谈数据中台的数据埋点。
笔者所在公司为富力环球商品贸易港,是富力集团旗下汇聚原创设计师品牌及时尚买手/采购商两大社群,通过亿订B2B电商、RFSHOWROOM、环贸快版、环贸映像、富运通、富贸通等子品牌为时尚行业提供一站式产业+渠道服务的平台。
笔者所在部门为数据中台,职责就是为公司搭建数据中台,支撑各产品线数据化运营,通过数据中台打通各条产品线的数据,更精准的为产业的上下游客户服务。本文以B2B电商产品亿订为实战,谈数据中台的数据埋点。
图片来源:富力环球商品贸易港公众号
刚入公司时,公司的数据埋点这块是和百度合作,用的百度移动统计。
运营反馈百度的流量分析做的很强大,但是最大的问题是不能结合电商的业务数据,比如:只有坑位的流量数据却拿不到坑位的交易额、转化率(交易额/PV)这些数据,另外电商的主路径 访问>商品详情>商品列表>加购>下单>支付整个流程的转化率是取不到的。
此时,就拉上我们的开发,叫上了亿订产品经理和运营负责人,一起沟通目前的问题。
图片来源:百度移动统计, 百度的移动分析看不到任何业务数据。
沟通后确定主要确定解决以下问题:
问题一:要知道亿订B2B电商产品每天的主路径 访问用户数>商品列表页>商品详情页>加购>下单>支付主路径每天的人数及每个步骤之间的转化率。目的是长期监测每步的转化率如果有明显异常,运营同事会进一步分析转化率低的原因。
图片来源:亿订电商, 从左到右以此为:首页、商品列表、商品详情、加购、结算页
问题二:因为问题一只能解决总体转化率,要想定位到底是那里的转化率低导致整体转化率低的原因,还得看用户每个入口路径各环节的转化率。
问题三:要解决坑位的转化率问题,因为评价坑位好坏的因素不止有PV/UV百度统计的两个指标,运营同事定义了坑位的转化率为(pv/坑位交易额)来综合判定坑位的性价比,如果坑位的放在很明显的位置,那他的转化率还是很低,那就要分析原因,改变运营策略。比如图片的调整、商品的调整、位置的调整等。
问题四:要打通用户的行为数据和用户的交易数据,用户运营的同事需要更加了解他们的用户比如什么时候访问,访问了那些商品、什么时候加购,加购了那些商品,什么时候买了那些商品。这些百度是做不到的。通过用户的 访问行为,运营同事会进行针对性的运营型。
问题五:要看到用户的留存情况,留存的定义分为两种,第一种是访问留存
首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。
要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。
我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。
在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速的。
数据中台的出现,就是为了弥补数据开发和应用开发之间,由于开发速度不匹配,出现的响应力跟不上的问题。
数据中台解决的问题可以总结为如下三点:
效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。
协作问题:当业务应用开发的时候,虽然和别的项目需求大致差不多,但因为是别的项目组维护的,所以数据还是要自己再开发一遍。
能力问题:数据的处理和维护是一个相对独立的技术,需要相当专业的人来完成,但是很多时候,我们有一大把的应用开发人员,而数据开发人员很少。
这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。
史凯总结说,“数据中台是聚合和治理跨域数据,将数据抽象封装成服务,