营销系统概述

目前情况,互联网平台可使用的营销方式已经比较成熟;C端在用户侧包装及展现形式上可能会存在变形和延伸,但对于B端而言,更需要关注的是营销系统底层逻辑,抽象出表象下的可复用规则,及各系统之间互相之间的关联作用;

营销工具类型归纳

1)类型归纳
互联网目前情况出现的活动形式大约有13种,按照使用场景可归纳为以下三大类:

单品类活动:折扣,立减,买赠,特价,秒杀;

凑单类活动:阶梯满减,阶梯满折,阶梯满赠,M元N件,买M件免N件,第M件N折,第M件N元;

传播类活动:拼团

单品类活动适用于提升转化率,凑单类活动适用于提升客单价及产生关联售卖,传播类活动则适用于拉新及进行站外活动。
2)优惠券、红包的特殊说明
这里需要说明的是优惠券、红包虽也属于营销系统内,但其不能称之为活动工具。
区别在于:活动的本质是商品,券、红包的本质是等同于用户个人资产,作为结算时的扣减逻辑存在;活动与活动之前可存在互斥关系,但是券、红包可以与活动进行叠加。
3)两种比较特殊的活动形式

特卖:不同平台对特卖的处理方式不同,有的实质为折扣/立减等,有的被定义为“栏目“,特卖其实可包括多种活动类型,是在活动上的一种包装形式;

平台补贴:我个人理解为平台按照单量或销售额,帮助商家承担一部分成本;因工作中暂不涉及这种类型,如果有了解的小伙伴可以帮忙补充一些。

资源位活动

一般来说,资源位活动与“栏目”比较相似,这些“栏目”出现在可以由平台给与流量的位置,如:首页、首页轮播、搜索结果页等,可包含一种及一种以上的活动类型。
常见的“栏目”有秒杀、拼团、品牌特卖等,不同平台对“栏目”的主题和包装形式不同,栏目与活动形式可形成一对一、一对多及多对多的关系;
以京东首页为例,“京东秒杀”、“每日特价”、“品牌闪购”等,都可以定义为“栏目”,其中“品牌闪购”只是“栏目”名称,在二级页面内又可包含买赠及折扣等多种活动类型。

营销系统全流程模块拆解

模块化的本质在于“求同存异”,将共用的部分抽象出来,最好可以拆解成最小颗粒度,便于进行插件化组装,快速的搭建一个新的活动类型。
上面说完了目前情况现有的平台活动形式,接下来我们来拆解一下一个营销工具都包含了哪些模块:

模块一:活动基本信息

在这里列举一些活动基本信息内可共用的字段,也有少部分根据不同工具所匹配的字段信息,如凑单类所需的凑单页,可以选择系统自动生成或自定义跳转,可根据具体情况添加字段,在此不再赘述。

模块二:活动规则模板

活动规则模板其实本质为“活动准入规则模板”,意在对可提报的商品及商家进行范围限制。规则模板需进行动态化的设计,以适应不同活动在不同阶段的需要。
举例:如单价高的商品,是不适合进行拼团;M元N件比较适合食品及配饰品类;产品经理除了注重产品侧思考的同时,也需要注重商品的特性,对于设计营销工具很有帮助。

模块三:活动下发方式

活动可手动下发,也可选择系统下发方式,区别在于规则是否具有高度一致性和活动是否具有固定的节奏;
举例:如节奏及时间概念比较强烈的秒杀活动,如果每个单独的时间点都有业务手动下发,不仅辛苦,而且效率很低,这种情况下可设置系统按照日,周等不同时间维度进行自动下发

模块四:活动选品及提报

1)选品模板
这里需要注意不同活动所需要提供的活动信息是不同的,所以提报时的选品模板需要按活动类型进行处理,除了常规的活动价,活动库存,限购数量外,如立减有立减金额字段(可针对单个sku进行修改)等
2)可提报商品及提报校验
选品、提报应与活动规则模板相关联,规则即是选品及提报时的部分校验逻辑;判断商品是否为可提报商品,以及是否满足活动模板要求;这一步可以帮助业务进行选品及提高入选几率。
通用校验还包含如商品状态等,诸如售罄状态是否可提报,活动开始前是否需要二次校验;

模块五:活动审批流

审批流需考虑正向及逆向流程,审批流与时间节点密切相关,会影响审核状态:
1)正向流程中
需考虑参与角色及进度是否一致性;如在平台活动中,涉及多个部门,则需要考虑各部门之间的审批流是否独立;如果超时未审核,是否自动驳回等。
2)逆向流程中
需考虑打回结果及二次提报审批流;如在“打回修改”后,操作权限由谁来承接,二次提报的流程是否可根据不同的活动信息,进行不同的设计等。
举例:如审批流正向流程如下图所示,如二审对某商品进行了“打回修改”的操作,那么二次提报流程可进行怎样的产品设计呢?

方案一:再次进行的审批

方案二:直接回到打回处审批

如信息不重要,比如仅为活动短标题等,可直接选择方案二,节省审核时间及提高审核效率;如为库存,价格等,可酌情选择选择方案一;
那么如果“打回修改”可直接由“一审”进行修改而不是由“申请人”承接呢,可对数据流转指向再进行进一步思考。

模块六:营销数据报表

“业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。产品经理要和业务人员一起,关注完整的体系化指标建设,设计有使用价值的报表。观察、分析问题的视角和思路是报表设计的核心,绚丽的交互只是次要的存在”—— 杨堃《决胜B端:产品经理升级之路》

报表数据可以帮助业务规划、决策、分析活动,作用范围覆盖了活动创建、活动中、活动后,是运营人员不可或缺的工具。
1)提供客观、准确的活动数据
我们可以大致从流量数据和交易数量两个维度进行规划:

流量数据:如新客数,活动及商品UV等——流量型数据需注意前端的数据埋点;

交易数据:如销售额,销售件数,支付用户数,转化率,客单价等——交易型数据需注意订单金额的准确性。

在营销系统中,不同活动关注的数据不同,如拼团活动还需关注开团订单数,参团订单数,成团订单数等
2)发现数据指标变化
这里需要对数据结果进行处理,进一步对比数据值,观察数据曲线;总体数据可加入一些对比分析数值:如销售环比,与昨日,与上周等带有时间性质的数据字段,可以更直观的感受到数据变化。
如设定范围数值,当数据出现不正常的波动时进行预警,便于业务团队分析数据变化原因。
虽然数据报表一般呈现在BI系统内,但是我比较倾向于在活动系统内同时展示实时数据,方便运营人员就地进行观察和调整。

模块7:营销系统权限体系

因营销系统常常涉及到跨端(平台端,商家端),多角色参与,多状态多操作情况,所以在角色及权限设计上需要格外严谨,否则容易造成混乱。
不同平台中设计的方式有可能会不同,有的是按照角色去判断功能及可操作项,有的则按照权限点去判断,再把权限点加在不同的角色中,这是由平台的权限体系所决定。
这部分需要在产品设计阶段就规划好状态/角色/权限对应表,不仅用于技术开发,也应用于功能上线后的权限配置。
如下表所示:
首先系统会默认所有角色均有“详情”权限。
其次,结合状态及权限判定,如在CEO审核状态下,找到具有“CEO审核”权限的人,展示“去审核”的操作:

ToC与ToB 营销工具设计差异

本人曾经在一个项目中负责过ToB 电商app中营销模块的产品设计,发现两者在设计上还是有一些区别的,在这里也可以简单介绍一下。
我们先来看下ToC端与ToB端的差异性:

由表内部分可见,适用于C端的活动方式如拼团,并不适用于B端。
所以在进行ToB营销模块设计时,规划了“本地配”,“控区控价”等带有区域特性的栏目,控制物流时效,降低运输及包材成本。
并打造了B端专题系统及页面购物车,缩短成交路径。进行个性化的营销策略,根据店铺主营类目及线下门店销售数据推荐商品,精准触达用户,增加转化。最后也取得了不错的效果。

写在最后

营销系统是个很庞大的体系,与前端购买交易流程,后端供应链密切相关。
同时,与CRM系统,订单系统,财务系统均有交集;如果从0-1规划营销系统,应注重各个系统之间的协同作用,如果大家有兴趣,会在以后的文章内进行分享。

发表评论