关于后端:百度交易中台之商品推广流程构建以及实现

47次阅读

共计 5960 个字符,预计需要花费 15 分钟才能阅读完成。

导读:从 2020 年开始,百度开始构建本人的商品推广零碎,目前零碎利用在百家号和直播场景中,为 B 端商家以及 C 端作者、主播提供了便捷带货流程,为宽广用户提供了间接简略的购物体验。本文依照业务概念、用户界面、零碎架构、外围实现的程序介绍商品推广零碎,旨在抛砖引玉,心愿能给读者带来思考和帮忙。

全文 5874 字,预计浏览工夫 12 分钟。

一、推广流程概述

上次谈到的《百度交易中台之订单零碎架构浅析》,讲述了订单零碎的实现形式以及迭代流程,本期基于订单零碎,持续介绍推广零碎的设计与实现。

商品推广零碎,是目前电商平台带货场景业务下较为常见的零碎。* 宝联盟、* 东联盟、多 * 进宝等都是相似的商品推广零碎。在当今社会中,随着常识付费、短视频、直播业务的凋敝,公众表白自我的门槛开始升高,越来越多的内容创造者(短视频时代,大部分的内容创作者是作者或者主播)具备了弱小的影响力。于是面向商家、作者(主播)的商品推广零碎就显得非常重要,这个商品推广零碎连贯了 BC 两端,极大的解放了生产力。

商品推广零碎围绕着作者(主播)、商家、用户为外围,提供一个能够同时服务三者的平台。在推广流程中,不同的角色有非凡的称说,作者(主播)称为流量主,商家称为广告主。

(1)流量主

商品推广流程的指标是最大限度的促成交易。推广商品的个别伎俩是进步商品曝光量、减少商品点击量,越多的人看到商品,促成交易的可能性就越高。商品推广零碎则是通过联结有影响力的主播或者作者,一起进行推广,借此来扩充影响面,就是通常人们口中说的“带货”。这个计划,宗旨是通过影响有影响力的人,通过品牌效应、名人效应去达到宣传商品的指标。参加推广流程的作者或者主播,因为能够帮忙订单零碎吸引流量,因而称为【流量主】,下文统称参加商品推广流程的主播和作者为流量主。

(2)广告主

在常见的商品推广流程中,为了吸引更多的流量主加盟参加推广,会依据商品的类别,酌情为每一笔订单设计一个佣金比例,如果消费者通过流量主提供的入口进行商品购买,则流量主会取得肯定比例的分佣返现。分佣返现的金额,由商家或者平台提供,依据不同的场景会有不同的策略。

对于须要推广商品的商家来说,一个推广流程,相当于进行了一次对商品的广而告之,只不过这个广告不肯定来自某个广告公司,也可能来自某个名不见经传的普通人。这些商家角色,在推广流程中,被形象的称为【广告主】。

(3)CPS

随着科技的倒退,3G 和 4G 网络让挪动领取成为了互联网反动的“蒸汽机”,5G 和大数据则让信息立体化。商品推广流程在二者的根底上,提供了让更多人参加到交易当中的机会。常见的电商平台根本都反对分佣推广,在电商场景中,个别通过 CPS 形式实现分佣动作。

CPS 是 Cost Per Sales 的简称,是在商品推广中常见的计费伎俩,通过理论的销售量进行免费的,更适宜购物类 APP 进行推广,然而须要准确的流量进行数据统计转换。

二、百度商品推广流程业务特点

CPS 推广带货,一共须要面向 3 个不同维度的用户提供服务,别离对应上文中的流量主(主播 + 作者)、广告主(商家)、用户(消费者),同时,整个 CPS 推广零碎的建设,也是从这三个点动手进行性能拆解。能够将其拆分为 3 个用户界面服务以及 5 个外部外围服务。

(图 1:百度整体带货体系构建)


(1)三个用户界面

从图 1 中能够看到,商品推广零碎,次要有三个用户界面,别离是针对广告主的小程序 B 端,针对流量主的商品选品界面,针对用户的订单购买界面。上面别离对三个界面进行阐明。

广告主界面局部,小程序 B 端服务作为商家端,为广告主提供商品注册服务,即,广告主能够在小程序后盾的界面,开明商品分佣带货,从而让本人的商品失去推广。

(图 2:小程序 B 端带货开明界面)

(图 3:小程序 B 端用户收益界面)

在理论带货流程中,开发者能够本人作为广告主开明带货,这样的形式带有肯定的开发成本(比方当当、亚马逊等);百度也提供了一套残缺的开店服务,能够通过非常低的老本参加到商品推广流程之中(比方度小店)。

流量主界面局部,百家号、直播生态作为选品服务作为入口,为主播以及作者提供方便快捷的商品引入,并且在这部分中,还能够引入百度自有的体系商品。

(图 4:百家号编辑选品界面)

上图是百家号的编辑界面,流量主通过编辑按键的增加商品,能够从商品库中抉择商品,并且将商品橱窗嵌入文章之中。嵌入文章之中的商品链接,如果被普通用户点击并且胜利下单,则会依照肯定规定,将该笔订单算作流量主的一次推广。在百家号直播的界面,也能够进行选品以及增加商品链接,这里就不再赘述。

(图 5:选品平台抉择界面)

图二,这是百家号的选品界面,能够看到,在选品中,不仅包含淘宝、京东、拼多多的分佣商品,还包含一些具备百度特色的选品库,包含度小店、当当网、亚马逊、电影票友等。

用户界面局部,则和广告主相似,商品、订单的界面依赖于百度小程序进行展现,这样的设计不便于在百度 APP 产品矩阵内进行共享,在技术实现上,广告主的商品界面,只须要开发一次,即可在所有的百度生态内 APP 上进行展现以及推广。

(图 6:用户界面)

用户界面次要就是面向宽广消费者,消费者在观看直播,或者观看作者的文章时候,如果这个直播或者文章中蕴含商品推广的话,就能够依照图 6 中展现的流程进行商品购买。此时购买的商品就是来自于商品推广零碎。

(2)五个外围服务

通过梳理用户界面,能够将商品推广零碎依照性能点进行拆分,在本期的实现中,拆分为 5 个外围服务。服务见下表:

在 5 个外围服务中,挂载服务、推广服务是针对商品推广场景从新设计以及开发的,交易系统、结算零碎、资产零碎是交易中台曾经有的能力。

(3)建设具备百度特色的推广流程

2020 年开始,百度着手建设团体外部的商品推广零碎,零碎的构建过程中,面临很多技术挑战,次要有以下几个方面:

  • 百度的业务多个 APP 造成的产品矩阵,如何提供对立的技术实现计划,让流量主和广告主单方能享受最优质的产品服务
  • 如何在缤纷多变的页面中,无效的采集用户的推广行为
  • 如何整合现有的订单和结算零碎、输入一套领取和结算的规范模型

下面只是列举的一些大的问题点,放到细节之上,还有许多前台看不到的,然而很影响体验的问题,比方流量主命中无效推广之后,是须要调配佣金的,这部分佣金的计算如何实现,调配后的佣金又如何能实实在在的变成流量主的支出?又比方作为广告主来说,如何定型定量的看到本人的推广记录?总是波及到资金变动,任何人都想看的仔仔细细。

然而,抛开挑战不说,从交易中台开始构建 CPS 推广体系,起步就是站在伟人的肩膀上的。依靠于底层的交易能力,能够疾速建设一套 CPS 推广实现,业务上充沛复用已有的能力,包含下单、资金池、资产记账、提现等都能够疾速实现;技术上则能够依靠于交易的底层框架,疾速的实现性能。

三、商品推广服务实现

(图 7:挂载服务 && 推广服务架构图)

挂载服务以及推广服务尽管在简单的商品推广的体系中占据了十分重要的作用,然而从设计角度,进行独自拆分之后,其实各自的性能是比拟繁多的,这也合乎零碎之间高内聚低耦合的规范。

上图将服务依照分层设计的形式,拆分成为 4 个层面,从上到下,别离如下:

业务层:这一层指代形象的业务,是能够扩大的多个服务方,不同的服务方站在不同的角度进行接入,包含广告主、流量主、用户多个角度的不同服务。

接入层 :这一层次要指对业务层提供服务的服务网关层,次要的性能是流量转发、服务鉴权、负载平衡等。除了惯例网关的性能之外,接入层还针对 BC 两侧(B 代表商家、C 代表用户) 的不同流量进行了拆散。其中交易对立网关次要承当来自消费者的流量,该网关的特点是用户申请量大,然而绝对简略,因而对于网关的设计,非性能需要方面,性能、平安是次要的考量点。其中电商开放平台 (trade.baidu.com) 则作为商家端的网关入口,这部分网关访问量没有那么高,因而次要侧重于业务的解决以及关联。

服务层:这一层是外围的服务提供者,包含前台后盾多个服务。

动静库:商品推广的外围前端组件,次要负责推广数据的上报,并且须要保障安全性以及数据合法性;

注册服务:这是一个后盾服务,提供广告主流量主的注册开明,并且联携上层的商品零碎、结算零碎提供商品导入、分佣比例设置的性能,是承前启后,数据的注册核心;

挂载服务:挂载服务提供在商品注册之后,进行商品橱窗链接生成、数据真实性校验

推广服务:商品推广的外围后端组件,对外承接来自动静库的推广记录上报,对内承接来自交易系统的订单命推广断定。

组件层:这一层依赖于度长外部的各种中间件疾速实现性能。

对于推广记录以及挂载服务来说,设计难点在于和整体零碎的分割,自身业务较为繁多,在此值得介绍的包含两局部,一部分是基于动静库的推广记录上报,另一部分是则是基于数据库批写的写入优化。

(1)基于动静库的推广记录上报

【动静库】是百度小程序提供的框架组件,能够旁路式的为小程序提供底层的根底能力,比方 ECharts 图表、editor 富文本编辑器等。商品动静库则利用这种旁路的设计形式,嵌入到开发者的商品详情页面,并且能够残缺的获取到商品页面的扩大参数。(复制此处链接查看小程序动静库官网文档:https://smartprogram.baidu.co…)

(图 8:小程序动静库示意图)

小程序动静库如上图,最上层的是订单的购买页面,底层是小程序的运行容器,中间层的就是动静库。动静库是按需动静加载的根底库,由一些特定的小程序业务平台方公布(如大搜、凤巢等),能够提供该业务平台的一些业务性能或束缚,动静库具备如下特色:

  • 动静库会静默更新,由动静库公布方决定更新,小程序开发者不能决定何时更新。
  • 动静库能提供自定义组件或者 JS 模块给小程序应用。
  • 动静库公布方当初只能是百度。
  • 动静库的应用,须要开发者明确的在页面标识能力援用。

因为动静库自身由交易中台进行开发和保护,推广数据上报则通过动静库进行上传。基于动静库的数据上报实现,具备显著的长处:

1、遵循开闭准则:防止下单页面中硬编码实现数据上报。齐全和订单页面解耦,不管开发者降级,或者上报逻辑更新,都不相互影响。

2、一处改多处用:小程序动静库能够无缝的利用在各个矩阵 APP 上,后续还能够开源利用到内部的宿主 APP 之上,扩展性和兼容性十分好。

3、可维护性优良:因为推广上报齐全脱离了订单页面,开发方面不必思考业务实现以及问题,具备良好的可扩展性。

然而因为动静库是比拟底层的实现,俗话说能力越大责任越大,动静库在理论的开发中,对于性能和安全性具备十分高的要求,不能因为动静库的加载,而拖慢开发的提单页面。

对于数据协定方面,动静库尽管能够独立于订单页面运行,然而如何为动静库设计一套宽泛通用的数据协定,并且让其具备良好的可扩展性,这是一个问题。在实践中,咱们通过对挂载链接性能进行革新,实现了服务端生成链接 + 动静库解析连贯的闭环。

参见下图中;

(图 9:带货链接动静库闭环)

挂载服务为选品界面提供链接生成的能力,对于不同的商品,会生成该专属流量主的特定链接,并且携带一些扩大参数。这些参数会随着商品页面一起加载。这些参数尽管对商品页面不形成影响,但却是动静库加载的必须参数。这些参数蕴含自验证机制,如果被轻易批改的话,上报验证就会发现。对于不同的商家和商品,通过在挂载链接中设置不同的参数实现个性化的推广数据上报能力,比方针对不同类型的服务,命中推广链接,在商品详情页面的停留时长能够有肯定区别。

对立格局的数据协定,对于后续判断推广是否命中也有益处,比方能够对立的应用工夫窗口策略断定用户针对流量主的推广是否命中,对于某些商家,还能够跳出商品的领域,间接断定此时用户是否命中商家的其余无效推广。

(2)基于数据库批写的写入优化

推广数据上报具备申请量大,业务比较简单的特点,再加上推广数据实时查问的需要没有那么强烈,在理论的开发中,咱们针对推广服务采纳了数据库异步批量写入的机制来进步性能。

(图 10:批量写写入优化)

当初配合上图阐明一下优化流程,改良前的单次写入,其实就是含糊其辞的单次写入,每次数据上报,走一次流程,数据通过管制层、服务层、数据长久层进行写入。这样的益处是逻辑简略,写入实时性好,适宜个别的 OLTP 服务。然而对于数据上报服务(相似的服务还有打点服务、日志上报等)来说,并没有实时查问的需要,所以在服务资源无限的前提之下,能够采纳批量写入的形式来充分利用资源,进步服务的吞吐量。

图中左边的局部就是优化后的批量写入,批量写入实质上是一个生产者消费者的模型,指标是升高数据库的 TPS。图中的每次收到上报记录,就会退出到内存的阻塞队列中,将同步写入变更为异步写入。队列每个肯定工夫执行一次写入,这样一来,数据库的写入 QPS 其实是大大降低了。

交易中台中,个别采纳横向分表的 db 设计,推广记录的设计也是一样,数据表依据分表字段路由存储到不同的数据表中,并且对于不同的表,还能够拆散到不同的数据库实例当中,进一步进行程度扩容。下图是《百度交易中台之订单零碎架构浅析》中的数据分表规定。推广记录的分表形式大同小异。

(图 11:分表规定)

对于这种数据库后果,在数据库批量写入中,还能够再进行一次优化,行将同一个实例、分表记录进行聚合,而后对立执行。这样能够进一步提高数据库的写入效率。

四、总结

商品推广零碎的构建,难点在于业务简单,构建门路长,须要跨团队以及跨部门单干。

业务梳理清晰之后,对于技术侧的实现,除了动静库之外,其余的局部实现复杂度都不是太高。关键在于对边界条件的管制,对细节的把控是否周全。推广零碎以及交易中台,有幸站在伟人的肩膀上,踏浪潮头,天然事倍功半。

古往今来,软件开发工程多半依照工作畛域,划分为零碎工程师、算法工程师和业务工程师。不论是哪一类工程师,要想不负使命,都须要在广度和细节之上进行积攒,厚积方能薄发。

招聘信息

百度挪动生态事业部 MEG,用户核心招聘研发岗位(PHP/GO/C++),咱们次要负责公司 Passport、用户资产、属性、百度 APP 会员等外围业务方向,致力于打造高效、便捷、平安的用户体系。如果你对 Passport、百万级 QPS 服务、分布式设计 & 治理感兴趣欢送退出咱们。

关注同名公众号百度 Geek 说,点击菜单栏“内推”即可退出搜寻架构部,咱们期待你的退出!

举荐浏览:

[](http://mp.weixin.qq.com/s?__b…|百度搜寻稳定性问题剖析的故事(下)

|百度搜寻稳定性问题剖析的故事(上)

|百度对于微前端架构 EMP 的摸索:落地生产可用的微前端架构

|社群编码辨认黑灰产攻打实际

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦!

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注

正文完
 0