写点什么

浅谈电商的营销体系挑战

  • 2020-04-09
  • 本文字数:6157 字

    阅读完需:约 20 分钟

浅谈电商的营销体系挑战

本文内容来源于中生代技术群的主题分享,感谢中生代技术群的邀请,冒昧跟大家分享一些这几年在电商行业对营销的理解。


营销体系这个概念很大,泛化一点,面向用户的所有售前、售中环节都可以算是。


所以也不大可能面面俱到,想到什么就说什么,可能会比较散。


本次分享尝试从业务、产品和技术三个维度解读营销体系。


纯属个人感受,难免偏颇,请各位见谅,求指点。


12 年刚到当当的时候,觉得电商业务很有意思,从业务结构上看起来最复杂的有几点:


1.仓储的管理和优化,到仓库里的都是成本啊


2.供应链,良好的预测和库存控制


3.客户行为分析,读懂客户,维持客户粘性,拓展新客户


4.各种促销,把客户绕晕,但又不能晕到不买了


这第四点,就是指促销系统了,可以认为是狭义上的营销体系。


电商的运营核心目标就是销售,不是改变世界,也不是高品质生活,所以营销这方面也是表面竞争最激烈的战场。


于是就跟线下商场一样,要搞活动,要造节,最后发现一切正式非正式官方民间的节日都成了购物节。


顺便吐槽一下,如今 618、双十一搞得乱花渐欲迷人眼,我已经不怎么跟风非要占个便宜薅羊毛了,太费劲。


一般电商公司,一条产品线上关联几个主要角色,业务部门、产品部门、研发部门,今天也就从这三个方面来入手。


首先是业务。


在商业管理理论中有几种营销理论,分别是 4P、4C 和 4R。


4P:即产品(product)、价格(price)、渠道(place)和促进(promotion)


4C:消费者的需求与欲望(Consumer needs wants)、消费者愿意付出的成本(Cost)、购买商品的便利(Convenience)、沟通(Communication);


4R:关联(Relevance)、反应(Responsive)、关系(Relationship)、回报(Recognit)


这些搞成了理论的概念都比较多,不太好理解。


具体含义各位感兴趣可以百度,可以看做是一层层的进化。


4P:手里有货,琢磨怎么能卖出去。


4C:关注客户,满足消费需求。


4R:关系营销,维系客户,持续消费,发掘需求。


用一个比较糙的比喻,就是最早的时候是手里有货不知道卖给谁,可劲儿吆喝,用低价来吸引人,后来玩好了,知道该找什么样的人才有钱买东西,需要啥就卖啥,最后大家都熟了,有了感情,不是就图个新鲜感或者便宜了,而是越处越有感情,你自己还不知道自己想要什么,这边就做好了给你送上门去,开开心心掏钱。


什么叫发掘需求,就像乔布斯的 iphone,按照传统手机思维是发明不出来的,但确实是人们需要的。


所以最初做买卖其实是没什么营销的手段的,最多也就是改改价格,C2C 的话,可以砍砍价给个包邮送个赠品什么的,淘宝也还支持这么玩,自由度大一些,人和人的互动多。


但做电商网站做大了就是 B2C,需要人机互动,才越玩花样越多,越复杂越智能,这是行业的大趋势,越是综合电商越需要更多的营销手段。


像垂直品类或者唯品会闪购那种一招鲜吃遍天的电商,相对可能会简单一些。


而 O2O 这类非标品电商则要求更为复杂,本身实际情况就很复杂。


从赚钱的角度来讲,主管销售运营的业务部门是最重要的,业务部门的分工和运作模式决定了电商公司的业务模型。


在 PC 时代,首页是电商最重要的流量入口,有人说过,打开一个电商网站的首页,就能知道业务部门怎么划分的。


现在的淘宝上,天猫、聚划算、天猫超市,也是排在前面,单独标出红色的。


技术是业务服务,业务决定技术架构,营销体系的功能源自业务部门的运营能力。


有时候想技术驱动业务,做一个功能出来,但运营根本不用,做了也是白做。


比如常说的数据化运营,不是说搞一套大数据系统就 OK,而是运营人员切实的关注数据,使用数据,依赖数据。


营销体系的对象应该是客户,做好的话,就是千人千面,能够根据每个客户提供差异化服务。


这其中有很多玩法,往大了说,618、双十一,往小了说,限时抢、满减、多买多折、加价购、赠品、手机专享价,往花样了说,积分、抽奖、会员级别、礼券、拍卖、众筹、一元购、秒杀、团购、预售、预订、企业客户销售、分销、定时购、心愿单、红包、满额包邮等等等等。


花样多了有什么好处?细分市场,精细化运营,个性化服务,扩展用户接触面。


比如京东团购,当年有阵子我每天都去看有啥便宜好玩的东西,等于开辟了一个新的流量入口,夺宝岛也类似,把本来公司内部的功能变成了面向客户的。


总而言之,营销是面向人的,与同行竞争的,与人斗其乐无穷,电商都依赖于系统,营销活动的执行需要系统支持,需要把营销的手段都实现在系统里,而且要推陈出新,比同行玩得更吸引消费者。


当然,如果琢磨不出来新花样,跟风照搬也是难免的,总不能别人有了自己没有吧?至于别人的模式自己能不能玩好就是另外一回事了。


当当在 13 年效仿唯品会,推出了闪购频道尾品汇,就收到了比较好的效果。


一个公司经营多年,逐渐就会树立起自身的品牌形象,这个形象是消费者心目中的,不见得是公司的宣传口号。


而品牌是无形资产,是一个复合的符号,有了品牌影响力,意味着有了忠诚的客户群,就能活得很好。


比如当当近几年很少做广告,但活跃用户上千万,在图书销售领域有着极强的品牌。


比如有一些似乎名不见经传的电商网站,存在了很多年,一直不温不火,都是有稳定的客户群和收入。


从营销角度看,广告、代言、赞助、冠名、公益、行业大会等等都是,但相对传统,也不大可能通过系统来监控和评估。


而如今移动互联网时代,APP 端订单占了多数,还有每天都必须打开的微信,依托于公众号的营销也是很有效果的。


所以从业务层面看,跨渠道跨品类跨商家的协同、多种营销手段的聚合、面向客户的完整闭环、更深度结合技术手段是未来的趋势,也是对业务部门的挑战。


其次是产品。


所谓产品,落地之后就是系统,或者说产品线。


前面提到了业务运营上需要很多玩法,对于一个综合电商来说,很难用一套系统来实现,即便是规模很小,花样多了,也需要合理的建模和解耦,搞成一大坨就丧失了灵活性和扩展性。


基本上,不同的营销方式,需要不同的独立系统支持,于是前台系统越来越多,后台如果同样划分,就会特别零碎,各自独立,缺乏复用和协同。


于是乎我们看到了阿里调整了组织结构,提出了“小前端+大中台”的模式,组织结构对应着系统架构,有一个通用的平台,才好在上面展开各种手段。


电商的业务运营部门可以按照品类垂直切分,但产品线没有必要,除非是美团、去哪儿那样的包含多种差异很大的业务线的公司,如今多数的所谓电商,还是指在线零售。


那么业务体系中也需要有整体的运营部门,定义业务模型或者说业务模式,否则把握各部门不同品类商品不同的营销功能的责任就会落在产品部门,产品已经打散,再对应到各业务线,沟通成本高,对人员能力要求也比较高,就很难有好的配合。


如今电商行业越来越成熟,系统也在不断进化,促销的业务模型越来越复杂。往往会产生之前完全没有想到过的关联,比如手机专享价,比如赠送运费险。


这张图是当当促销系统重构时设计的模型,支持多种规则和维度,但真的还是有 hold 不住的。



随着移动互联时代的到来,引导客户使用 APP 成了经营目标,于是催生了分渠道的差异化营销,礼券有移动端专用的,促销价也有专门针对移动端的。


促销方法越来越多,同一个商品可能同时有几种促销,甚至出现了给客户选择使用哪种促销这种功能,促销的条件限制、互斥和叠加规则越发复杂。


能给用户多个选择似乎还是好的,比如我遇到过因为 VIP 折扣导致低于包邮门槛加上邮费反而更贵的情况,那时候我认为我应该有权决定是否享受 VIP 折扣。


但如果选择太多就会形成困扰,我更倾向于电商系统应该默认提供最优解,保留用户选择的权利。


最优解怎么来?就要在最终下单结算的交易环节进行整合计算,上面说的所有营销规则,多数都要作用在交易系统,于是交易系统成了最复杂的计算系统,还要求够快,不能让客户等。


现在很多 B2C 都是平台电商,搞起促销来,要整合入驻商家,同样需要系统化支持,于是便有了活动管理平台。


活动管理平台的核心模型是活动,由平台或者商家发起,设定一定的条件和要求,这样既便于宣传,也便于在数据上进行统计,支持运营。


下面的图是我们的系统架构规划图,其中能够看到营销工具和活动管理部分。



数据化运营,最怕的就是没数据,或者有了数据分析不出来,为什么某个商品销售的好,为什么某个地区客户多。


这一切的一切还是先要有数据,尽可能收集所有有价值的数据,价格的历史,库存的变化,用户的操作行为。


只有有意识有目的的积累足够多的数据,才有可能应用大数据技术,挖掘分析出规律,提供好的推荐、预测。


用好数据,需要专门的人才,不是只需要会开发和算法,更重要的是理解业务,会数据分析。


复杂的营销给系统带来的更大挑战是计算收益,评估效果,设错价格的情况属于乌龙,但叠加了几种不同促销,如何分摊成本,计算毛利率又是一件麻烦事儿。


如果做到位,每个客户都会有用户画像,有计算出的信用度和消费倾向,喜好,成长潜力。


我曾经开玩笑说电商的最终的目标就是精细化计算,每个人看到的价格和优惠都是不同的,连比价都没法比。


而且现在面向用户端的聚合太强,用原来简单功能划分的方法切分产品归属已经不合时宜,需要更多的交叉重叠,对于管理成本和沟通效率都带来了挑战。


最后是研发。


综合电商,业务量可以不大,但商品一定要多,充分发挥“长尾效应”,当然这也体现的是运营策略。


商品数据量大了,促销系统既要支持大数据量,还要提供快速响应的服务以及保证数据一致性,自然会有很多挑战。


比如一般的促销规则是基于商品的,也有基于店铺的、品类的,再交叉叠加客户级别、渠道、区域等等,当然也都有时效性。


这其中需要分别建立不同的数据模型,要支持数据量的快速增长,促销已经是常态,多数热销品随时都在促销,促销数据既变化率较高,数据量也大,怎么扩展?


要支持例外品,要同步给搜索系统,要快速更新,同步商品的状态,分色分码关系的变更,尽量避免数据不一致的情况。


这就需要搭建基于数据库分库分表、高效大批量的 MQ、缓存集群的技术架构。


还要支持各种互斥和叠加的规则设置、计算,客户被绕晕了,系统不能晕,这需要规则引擎。


赶上促销,流量暴涨,还要能快速的一键部署,弹性扩容。


说到搜索,关于促销我一直比较关注,促销活动那么多,动不动就几十万品,其实意义是不大的,客户根本看不过来。


那么最基础的,就是提供搜索功能,这方面亚马逊做了,京东和当当都没怎么做。


京东比较精一点的是很多促销活动商品非常有限,在活动页面上都展示出来了,不需要搜索。


当当目前正在改进促销列表页面,原来支持品类、价格销量排序,接下来将会提供搜索功能。


做得再好一些,可以提供基于收藏夹、购物车甚至是浏览历史、推荐列表的凑单推荐。


至于秒杀、拍卖、预订、定时购之类的多半都是独立的系统,根据各自不同特点实现即可,多数都有成熟的解决方案。


最基本的商品推荐,目前能做到个性化非常好的也不多,这里有很多现实问题,比如国内电商较多,难以数据共享导致数据不完整,也有时间不够长数据积累不足方面因素,可能还有一些算法效果的问题,现在多数的推荐主要基于商品相关性提供,类似买了又买看了又看,从客户本身特征挖掘有限。


还有最基本的就是变价了,抓取行业商品价格、促销、库存情况,根据变价策略进行调整,这方面的关注点一个是怎样抓取和防抓,抓取的时间点,变价的速度,与比价平台数据同步的实时性。这方面可以关注到的包括当年淘宝屏蔽百度,最近据说有所放开,以及京东当年某段时间价格干脆用图片显示。


这是很有趣的,藏在水面下的暗战。


这些很基本,虽然低价竞争是最有效的,但也是比较低端的运营方式,前些年电商价格战,亏得都比较狠,所以近几年已经不太多了。


还有对于流量的利用,在一些主要的流量入口,活动列表页,可以根据商品展示的效果反馈调整顺序,汰换商品。


基本的功能要做好,现在有更高级的也不能落下,所以行业竞争的门槛和成本都是在不断提高的。


随着流量越来越珍贵,营销模式进化到了更为聚合密集的场景,在每一个能够与用户交互的场景尽一切可能带来转化,加深关系。


比如如今商品详情页、购物车、交易页面上会聚合更多的信息,自动匹配能够使用的礼券,或者推送新的礼券,也许将来每一个界面都聚合所有核心功能。


这样自然需要更多的系统交互,服务调用更为复杂,更难以管理,要有服务治理机制和框架,需要有应用层的流量控制。


另外,要做数据化运营,先要收集数据、汇总数据、处理数据,与业务系统之间解耦的常见做法是通过消息中间件,也就是说,业务系统将业务事件、数据通过消息发出来,监听消息的可以是其他业务系统,也可以是数据系统。


对于运营类的数据系统,并不需要特别精确的数据,但实时性越高越好。因此传统的离线方式的处理已经不能满足实时营销的需求。


把数据收集下来才能形成反馈,针对用户形成下一步的营销动作,在用户还没离开之前就进行交互,如果离开,则要通过其他的渠道,邮件、短信、微信等等进行处理。


实时分析,实时决策,对系统资源和技术能力的要求都很高。


这样一系列的自动化协同营销,只有基于完整的系统体系才可能一触而发绵绵不绝。


那么在研发技术层面,需要有足够的系统资源,高效全面的数据收集体系,高度匹配的业务分析工具,完善的自动化运维部署系统,保障稳定的高可用架构和基础平台。


没有好的技术基础,要想构建如此复杂的营销体系,是不大可能实现的。


所以,业务决定技术,技术支撑业务,最终替代人,并实现人力无法完成的业务处理,最终,人可能换,可能变,但成型的系统才是真正的营销体系,将业务能力固化在系统里,公司才可能真正的实现技术业务一体化。


好了,三方面都说了不少,个人拙见,求指正。


Q:有两个小问题,第一个,就是上面提到的基础平台都有哪些;第二个就是如果业务朝令夕改技术这边该如何应对。


A:


1.技术层面的基础平台跟营销关系不大,业务层面的话,可参考阿里的中台,搜索、数据、共享事业群(交易啊、商品啊,客户啊等等)


我:


2.电商基于系统,业务变更正常,但必须考虑时间成本和代价,包括 ROI。一般互联网鼓励试错,但不代表可以一错再错不负责任。就像做产品、项目要有复盘,业务方面也应该衡量效果和成本。


Q:全渠道营销工具,里面有很多的营销玩法:1、这些玩法的生命周期有多长,新玩法和老玩法对销量的 buff 加成怎样?2、如何把这些营销工具有机结合起来一起用?有什么策略管理吗?


A:


1.产品生命周期看业务部门需要了,技术提供可行性和数据支持,比如分配流量,A/B TEST,以便判断营销效果,做好了,有一定积累和模型,可以做一些预测,但最终决策还是运营部门。


2.有机结合一方面是被业务部门天马行空逼出来的,另一方面产品部门要分析通用性,进行系统层面的整合,并将整合后的能力反馈给业务部门。基本属于业务驱动型,要说策略,就尽量不要重复造轮子吧。还有,可能的话,留出一定扩展性。


Q:请问团购网站在你所说的电商范围内吗?做这类网站有什么需要注意的地方?


A:团购网站也算是电商,相对模式比较单一,好像分成商品类和服务类。团购多数是要对接供应商或者商家,整合模型比较复杂,系统对接也比较多,需要数据同步。这是我想到的。


Q:组织一次营销活动,在 20 个营销工具里面,选哪套配置会得到最佳效果,技术能支撑业务决策吗?(例如选择 3 个营销工具的“铁三角”组合什么的)


A:技术支撑业务决策,在有比较充足的数据沉淀情况下是可以的。


本文转载自 IT 民工闲话 公众号。


原文链接:https://www.protocol.com/scruff-rejects-selling-location-data


2020-04-09 15:581328

评论

发布
暂无评论
发现更多内容

9种跨域方式实现原理

华为云开发者联盟

开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

工业生产环境下,时序数据库 TDengine 如何打造全面有效的数字化监控?

TDengine

数据库 tdengine 时序数据库

使用Jira盗版会存在的6大风险

爱吃小舅的鱼

项目管理 软件开发 软件管理

APISIX Ingress 如何使用 Cert Manager 管理证书

API7.ai 技术团队

证书 api 网关 APISIX Ingress Controller

泰山众筹sun4.0矩阵合约系统开发搭建

开发微hkkf5566

带你读论文丨S&P21 Survivalism: Living-Off-The-Land 经典离地攻击

华为云开发者联盟

人工智能 华为云 论文 企业号 2 月 PK 榜 华为云开发者联盟

如何让OpenHarmony编译速度“狂飙”

离北况归

OpenHarmony

NFTScan 正式上线 Fantom 网络 NFTScan 浏览器和 NFT API 数据服务

NFT Research

NFT 数据基础设施

如何通过jstat命令进行查看堆内存使用情况

华为云开发者联盟

后端 开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

新年新气象,老兵开新坑

致知Fighting

Java Go 服务器

线上网络丢包引起的接口响应时间过慢,快速排查案例

KINDLING

Java 运维 网络 丢包 eBPF&Linux

开心档-软件开发入门之MongoDB 创建集合

雪奈椰子

mongodb 开心档

实战分享 | 金融数据采集报送平台实践

葡萄城技术团队

MySQL中的distinct和group by哪个效率更高?

Steven

理论+实践,教你如何使用Nginx实现限流

华为云开发者联盟

后端 开发 华为云 企业号 2 月 PK 榜 华为云开发者联盟

简单概述Serverless

天翼云开发者社区

OpenHarmony标准系统内核学习【2】CPU轻量级隔离特性

离北况归

OpenHarmony

基于GIS+WebGL智慧消防3D可视化云控系统

2D3D前端可视化开发

智慧消防 消防物联网云平台 消防三维可视化 智慧消防系统 消防云控平台

谈谈我工作中的23个设计模式

阿里巴巴中间件

阿里云 云原生

单线程 Redis 如此之快的 4 个原因

C++后台开发

redis 中间件 后端开发 单线程 C++开发

CompletableFuture实现异步转同步

FunTester

聊聊Docker镜像

天翼云开发者社区

Docker 镜像

SparK 用稀疏掩码为卷积设计 Bert 预训练

Zilliz

计算机视觉

RocketMQ Streams拓扑构建与数据处理过程

Apache RocketMQ

RocketMQ 消息列队

10大知识管理软件厂商有对比

爱吃小舅的鱼

项目管理 知识管理软件

行云洞见|为何行业权威都预测“云原生IDE 将成为常态”?

行云创新

ide 云原生 云端IDE Cloud IDE TitanIDE

LeaRun快速开发平台:自由搭建个性化门户

力软低代码开发平台

全景剖析阿里云容器网络数据链路(三):Terway ENIIP

阿里巴巴云原生

阿里云 云原生 云原生容器

开心档-软件开发入门之MongoDB 覆盖索引查询

雪奈椰子

mongodb Ppython 操作mongodb库 开心档

如何用Apipost校验响应结果

爱研究代码的极客人

APi设计 JSON Schema apipost

单线程架构的Redis如此之快的 4 个原因

JAVA旭阳

redis 缓存

浅谈电商的营销体系挑战_语言 & 开发_IT民工闲话_InfoQ精选文章