营销中心形态各异,大致可分为:电商、门店和第三方营销平台。
淘宝、京东等电商平台的商家端都会配备营销中心,主要用于发券、建立活动和数据统计分析;饿了么、美团、盒马等外卖或新零售平台主要扎根于实体门店,帮助门店完成线上店铺的营销活动发放和线下门店的到店活动;第三方营销平台可以不提供线上店铺服务,仅作为渠道运营商存在,提供券、促销等运营活动的发放。
笔者给大家分享的营销中心具有普适性,可以兼容线上线下各场景。
一、营销中心的实质
营销中心这个字眼实在太庞大,仅靠一篇文章很难讲透彻,笔者接下来讲的也都是一些实战经验,如果有讲的不明白的欢迎踊跃发言讨论。
1. 主体
营销中心的发放/创建主体是一个主题(theme),例如:创建一个主题活动——“三八妇女节,逛吃逛喝我买单”,这个活动里可能会包含线上商城的优惠券、店铺券,也可能包含满减活动;其次,主题也可以通过H5页面传播,同样也可以通过线下易拉宝宣传。
这种组合方式最大化地分离了主题和内容,让营销平台使用起来更明确、数据统计更精确、用户画像更准确;同时在接下来的创建、审核和发放环节,同样益处多多。
2. 规则
上图是某平台规则设置页面的截图,基本上在规则方面都大同小异,下面这张图是笔者针对主题和活动概念设置的一些规则。
这里要强调几点:
规则是需要预设的:
我见过有的营销平台,规则都是现加的,更甚者直接在活动创建的代码里补充上,这是非常不可取的。一方面太过于麻烦,另一方面不便于数据统计和分析,在活动期间发生BUG等突发情况,纠错难度大
规则不可能全覆盖:
笔者一开始天真的以为:只要将所有的规则都纳入系统逻辑即可,规划中发现这是不太可能的。因为活动形式有千千万,新的活动形式也在日益更新,有的新活动就有新的规则,所以在规则预设上不需要太过于追求全面,尽可能覆盖当前活动形式即可。
不建议使用统一规则设置:
有的营销系统会将限制规则放在发放阶段去做,作为统一收口处。
但笔者不建议如此,其一,不同活动限制规则可能不同(虽然像有效期等规则是相同的,但仍然有不少规则是存在差异的);其二,统一收口在多人员、多部门协同办公上可能存在问题,公司里创建活动和最后审核发放的可能是不同的人,关注的点不同,创建的人更关注活动细节,审核的人更关注活动全局,让审核的人去设定统一规则不太适合。
3. 审核
审核作为可选步骤,在这里主要强调两点:
如果不需要审核,也请写进系统逻辑:
审核在许多小企业中是可以跳过的,但是希望大家也督促后端开发将其写入底层逻辑中,至于审核与否,根据实际业务需求出发。往后如果需要加上审核逻辑,不需要再担心重大的逻辑变更问题。
多级审核逻辑:
多级审核的概念是指:多名不同级别的人通过多阶段的审核流程,批准通过或不通过。
在这里,我着重强调将主题、券、活动分开设置审核逻辑,且需要考虑逆流程。上文已经交代了,不同的人员关注点不同,领导审核主题的宏观信息,如利润、成本、时间等,运营人员审核的是活动和券的内容细节。
4. 发放
发放是笔者认为最为复杂和重要的模块,发放承接了主题(含活动内容),设置发放的信息,最终数据汇总也会受发放时设置的信息影响。
发放阶段主要设置以下信息:
发放渠道:渠道一般分为线上(app、小程序、公众号、双微等)和线下(门店、卖场、户外等);线上线下又可以细分出很多场景,例如:线下自助POS支付后,线下POS支付前,门店活动区域扫码,线上分享,广告车/花车巡游,宣传海报,传单等。
消费方式限制:又称为核销限制,主要作为消费渠道的限制,可以分隔线上线下不同的运营方式、有效地引流和便于数据收集。
发放人群:不在设置活动和券的时候做,是因为发放人群是针对主题而言的,作为统一收口限制的规则。
发放位置:这块主要考虑到线上线下不同场景;同时便于运营人员在没有开发的配合下,就能完成运营活动的投放。
5. 数据
营销中心内的数据模块,主要展示活动相关,如:活动GMV,利润,拉新,促活,成交笔数,领取数量,使用数量,分享数量,用户画像等。
数据是作为运营分析和决策制定的关键因素,但数据模块过于庞大,笔者就不在这里展开谈论,想要详细了解大家可以自行搜索相关文章。
二、券和活动的区别设计
刚才在讲主题的时候,有提到过券和活动的概念。那么,现在就来讲一下:为什么故意要将活动形式分为券和活动(也可以理解为促销)两种呢?
笼统地将两者混为一谈,在系统设计开发上会造成逻辑混乱——规则设置、数据统计、运营目的都不同。券的概念类似红包,有立减和满减两种性质,都是在金额上满足消费者的需求;而活动更多样化,规则限定更灵活。
在结算时,也通常可以看到,活动是进入结算页面后自动计算的,而券(红包、奖励金等)是需要手动勾选使用的。同时,分开设计也可以将两者的可延展性最大化。
三、规则限制和互斥性
上文已经提到了规则,但是互斥性没有详细说明。互斥性的主要目的在于:
1. 明确系统和业务逻辑
互斥性可以梳理活动与活动、活动与券、券与券之间的使用关系,对运营人员把控活动进度,开发人员编写代码都有很大的帮助;同时,消费者在使用或向消费者说明时,可以更明确,避免纠纷和争论。
2. 方便支付收银系统作出校验判断
营销中心的职责不仅仅是创建活动和券,发放使用就完事了。对后续的收银支付同样有深刻的影响。如果不明确互斥性,结算时系统无法或直接跳过校验,会直接导致经营亏损或系统报错。
3. 控制成本支出
互斥性对运营人员来说,控制成本是非常大的职责。
大家使用饿了么或美团外卖都会发现:商家的活动有很多,但是同享的并不多,满X元减X元是无法与商品特价同时生效。
这就是商家在做促销活动时,计算成本利润后作出的决定。
4. 尽可能避免系统BUG导致的大规模亏损
互斥性在一定程度上可以减轻由系统BUG造成的严重后果,例如:设定券和活动的互斥性,就可以避免当券可以无限领取时,导致的可能性的亏损。
那么,笔者是如何设置互斥性的呢?
完全自由组合:
这是笔者在面对着N多个活动和规则,抓耳挠腮后的想法。
完全自由组合的意思就是:当需要设置互斥性时,通过当前活动或券的适用范围(商品、店铺、品类、品牌等),来判定该适用范围有无进行中或审核中的活动或券,自由勾选后互斥。
举个例子:当设置NIKE所有商品的满减活动时,可以看到当前NIKE正在进行中和审核中的所有活动和券信息。勾选某个活动后,被勾选的活动和当前设置的满减活动就形成互斥关系。
这样做的好处只有一个:方便。
笔者不是偷懒的人,在设想完全自由组合的逻辑上,并不是觉得这样方便设计,而是考虑到之后线上线下共同运营时的潜在问题。
我之前做过大型超市的部门负责人,对线下活动了解的比较清楚,深知其中的自由度其实非常高。如果在营销中心设计上,做过多的限制,那么对线下而言无疑断送的不少财路。
所以,笔者通过规则去约束、通过自由的互斥性设置去放开活动组合的可能性。
五、结言
最后,笔者想补充一句:本文是笔者和开发、运营人员共同参与讨论、商议、梳理出来的底层逻辑,并不涉及原型设计,也没有教大家应该怎么去设计。
笔者强调的是底层逻辑,只有明确了大体框架和脉络流程,才能设计出正确的交互原型图,才能写出完整的产品PRD文档。
对本文如有疑问或发现问题,欢迎指正,欢迎留言交流。
文/小鸡腿