导购是电商业务梳理的第三篇,前两篇为
- 电商业务梳理
- 电商业务梳理1-导流 梳理过程中,想通了很多事情。很长时间没回顾,很多内容都忘记了,正好借这个机会,重新加深一下印象。
这个系列主要聊功能,配上图片与数据结构。会聊为什么需要这个功能,这个功能的演进过程,未来要如何发展,同时更新架构图。梳理完这个系列后,再聊每一部分的具体实现。
这个系列大体分为:导流、导购、商品、购物车、交易、支付、订单、监控、用户体系、搜索。
昨天看毛选,看到一个词叫“狭隘的经验主义”,说的是一些人满足于甚至仅仅满足于他们的局部经验,把它们当做到处可以使用的教条。而“非狭隘的经验主义”指最广大的有实际工作经验的同志,他们的一切有益的经验,是极可宝贵的财产,科学地把这些经验总结起来,作为以后行动中的指导,这是马克思列宁主义。
所以梳理、总结的好处是有理论支撑的,对自己也是极为有利的。
导购是为了引导用户购买。好的导购能引起用户兴趣,能让用户方便找到想买的商品,所以需要给用户展示最重要的信息。一般涉及以下几点:活动页、首页、分类页。
活动页
活动是电商的重要组成部分,好的活动能够有效增加用户量、销量、网站知名度。
电商初期,我们以极高的频率做活动,一周一个小活动、一月一个大活动,慢慢带起热度和氛围。
那时的玩法相对单一,主要是直降、满减、满赠等。后续我们不断扩充玩法,增加了抢券、抽奖、抢购、秒杀、竞价、拼团、直播,红包、支付减免,大型活动会做配套游戏。市面上的玩法都尝试过,现在常用的都是数据证明效果不错的。
组件化
原因
活动需要占用很多人力,这些人力包括前端、服务端、测试、运营、产品等。
产品:设计活动页面、设计游戏,和研发同学沟通
运营:梳理销售目标,和产品确认活动页面是否能够满足需求
前端:开发活动页面,根据运营提供的数据进行填充
服务端:开发新的玩法、游戏,或者对已有的玩法进行配置,确保在新的活动上能正常使用
测试:测试每一个细节点,确保活动无误
这五个角色间有很多沟通,而且活动开始前运营根据具体情况,很多销售计划需要进行变更,导致前端、服务端同学跟进调整,极易引进线上问题。所以一个大型活动,至少需要提前两个月开始准备。
我们能否从这种困境中走出来呢?而不是每次活动都走重复的流程。
我们能够发现活动页面上的元素比较固定、活动玩法相对齐全,在这种情况下,特别适合组件化。
前端:只需要关注于组件开发,组件里的内容运营自己编排
服务端:沉淀玩法,将玩法配置化;运营自行配置玩法,和前端组件匹配好,玩法便上线了;服务端专注于新的功能开发
产品:将精力放在新增组件、玩法、游戏上
运营:销售目标不需要同步多方,自己能够随意编排活动内容,效率更高
测试:无需重复测试活动;精力放在自动化测试上,解放人力
可以看到,通过组件化,大家都能从重复操作中解放出来,将精力放到更高维度的事情上。对于研发人员而言,如果事情重复三次,就值得用系统化方案解决,这才是以技术推动发展的态度。
最终通过组件编排出的页面,用内容发布系统发布。
实例
活动页面之所以可以组件化,是因为静态内容相对固定,一般包含商品图片、名称、价格、描述、活动时间等。
动态内容的实现也比较简单,因为组件上配置的商品信息必有商品id。动态数据通过接口返回,根据返回的商品id做对应。不过这个接口请求量会比较大,需重点关注,可参考常用缓存技巧。
1 | [ |
数据
活动页面通过内容发布系统发布,自然需要做SEO。活动需要做好预热,正好与电商业务梳理1-导流关联起来。
活动过程中,需要收集各种数据情况,如热点图、GMV、点击率等信息,有了这些信息才能优化系统,也能帮助商家及时发现问题。所以活动也需要和数据中心做打通。
发展
组件化对当前业务是可用的,但不是终点。业界有更成熟的方案,如阿里的天马、京东通天塔、字节跳动的万象等。对于活动的玩法,可以参考尽在双11:阿里巴巴技术演进与超越第3章里的[会场,小二与商家共同打造的购物清单]。
为什么我们没有演进到更高的阶段?
我觉得一是大家闷头苦干,缺乏技术是生产力的意识,也缺少一些系统性思考,所以有时候停下脚本,从更高的维度来看待问题,是极有益的。
二是必要性。系统提供的能力和业务情况是匹配的,不是说别人有的系统我一定需要。这也是为什么我建议刚毕业的同学去大公司,因为大体量的业务,往往需要更高级的系统支撑,在演进过程中,自己能够学到很多东西,慢慢的成为这方面的专家。
除了组件化外,活动页面也没有做推荐,没有做到千人千面,这也是可以提升的地方。
首页
首页最为大家熟知,也最重要的页面。比起临时性的活动,首页是永久存在的,它给用户带来第一印象。所以首页能否引起用户的兴趣、能够给用户提供便捷的服务,对电商发展有重要影响。在启动APP到达首页过程中,还有启动页等小型导购功能,见缝插针是一门艺术。
组件化
原因
最开始电商只有PC和M,使用PHPCMS,通过配置固定模块,运营可以在模块内配置相应的商品。后来增加APP、IOS,首页发布时除了发布H5页面,同时将首页数据以json格式存储,APP通过接口获取首页数据进行渲染。
这种方案的最大缺点为模块不能编排,前端页面需要硬编码PHPCMS里的模块,所以位置都已确定,缺乏灵活性。解决方案还是组件化。
根据历史情况分析,整理出指定组件,通过组件化技术,运营可随意编排。APP内部有组件解析方案,只要按照规则进行解析即可。
实例
下图为首页截图,轮播图中的数据在json结构中。组件化的一个关键点在于确定好具体元素。
1 | { |
千人千面
最开始首页数据完全通过运营配置,这有很多问题。
- 每个用户看到的是相同数据,很难完全匹配每一个用户的喜好
- 运营维护能力有限,有些商品因售罄、下架等问题,无法及时发现更新,浪费坑位
所以需要数据中心的推荐能力,能够做到千人千面。
我们现在能够做到运营配置兜底,多种算法同时运行,运营可根据需求随时切换算法,这也意味着系统支持了AB功能。下面这张图就是根据算法动态推荐而来。
数据
数据对于首页的重要性不言而喻。像各种算法、各坑位带来的收益,要能实时显示。首页往往是漏斗图的开始位置,这些都能辅助运营优化销售策略。
首页的相关数据应该收集到数据中心,因为推荐来自数据中心,这些数据指标能够让数据中心优化自己的算法。另外,数据中心有用户画像,可以扩展用于AB测试。目前的AB方案是业务层自己做的,思路也比较简单,根据用户尾号区分,业务层无法做的更加深入。
发展
首页的发展与活动页有很多相似性。除此之外APP对组件的解析方案可以优化。需要达到的目标是无论今后组件如何增加,各个版本的APP都有能力解析。
分类页
分类页存在感不高,但其实很重要。分类的目的是为了方便用户查找,很多用户往往只知道自己需要买某个品类,但对于具体型号却不甚了解,此时分类页的作用便体现出来。
如用户想买手机,进入分类页后很容易看到有哪些新品、手机分几大类、每个大类里分哪些型号。
分类页的大小类别需要用心梳理,方便用户查找和比较。用户点击具体图标后,或者跳转到商品页,或者跳转到列表页,用户可在列表页做各种排序。
分类页是商品类目的延伸,实际使用中,分类页未必和类目完全一致。
最开始也是使用PHPCMS管理分类页,后来在运营后台搭建分类页配置系统,终端通过接口返回数据进行渲染。
分类页也需要关注数据,用户点击能够说明很多信息。分类页面不需要千人千面,但新品需要能够及时更新到分类页中,毕竟商品更新频繁的情况下,运营可能忘记更新分类页。
1 | { |
总结
其实搜索也能算导购,不过不知道是怎么做的,等找到相关资料再补一下。在梳理的过程中,大家能够发现,数据中心的作用越来越大。
本次的架构图为:https://www.processon.com/view/link/6235717b1e085306f8c26f5f