您现在的位置: > 百度推广百度推广
百度交易中台之订单系统架构浅析：商品推广系统
发布时间：2023-10-18作者：青鸾传媒来源：青鸾传媒点击：
来源丨百度极客说（ID：）
简介：从2020年开始，百度开始构建自己的产品推广体系。 该系统目前应用于百家号和直播场景，为B端商家和C端作者、主播提供便捷的产品交付流程，提供了广泛的用户。 直接而简单的购物体验。 本文按照业务理念、用户界面、系统架构、核心实现的顺序介绍了产品推广系统。 旨在介绍想法，希望给读者带来思考和帮助。
全文5874字，预计阅读时间12分钟。
1. 推广流程概述
上次讨论的《百度交易中心下单系统架构简析》描述了下单系统的实现方法和迭代过程。 本期以订单系统为基础，继续介绍促销系统的设计与实现。
产品促销系统是当前电商平台业务场景中比较常见的系统。 *宝联盟、*动联盟、多*金宝等都是类似的产品推广系统。 当今社会，随着知识付费、短视频、直播等业务的繁荣，大众表达自我的门槛开始降低，越来越多的内容创作者变得可用（短视频时代，大多数内容创作者（即作者或主播）具有较强的影响力。 因此，针对商家和作者（主播）的产品推广体系非常重要。 这个产品推广体系连接了BC的两端，极大地解放了生产力。
产品推广体系围绕作者（主播）、商家、用户，提供一个可以同时服务三者的平台。 在晋升过程中，不同的角色有专门的名称。 作者（主播）称为流量主，商家称为广告主。
(1)交通大师
产品促销过程的目标是最大化交易。 推广产品的一般方法是增加产品的曝光度和点击量。 看到产品的人越多删除百度推广记录，促进交易的可能性就越高。 产品推广制度就是与有影响力的主播或作者联合推广，扩大影响力，也就是人们通常所说的“带货”。 该计划的主要目的是通过影响有影响力的人，通过品牌效应和名人效应来达到推广产品的目标。 参与推广过程的作者或主播被称为“流量主”，因为他们可以帮助订单系统吸引流量。 以下将参与产品推广过程的主播、作者统称为流量主。
(2) 广告商
在常见的产品推广过程中，为了吸引更多的流量主加入并参与推广，会根据产品的类别为每笔订单设计佣金比例。 如果消费者通过流量主提供的入口购买产品，那么流量主将获得一定比例的佣金返现。 佣金和返现的金额由商家或平台提供，根据不同的场景会有不同的策略。
对于需要促销产品的商家来说，一次促销的过程就相当于给产品做了广泛的广告，但这个广告不一定来自于广告公司，也可能来自于一个不知名的普通人。 这些业务角色在推广过程中被形象地称为【广告商】。
(3) CPS
随着技术的发展，3G、4G网络让移动支付成为互联网革命的“蒸汽机”，5G和大数据让信息立体化。 基于两者，产品推广过程为更多人参与交易提供了机会。 常见的电商平台基本都支持分成佣金推广。 在电商场景中，佣金分成一般是通过CPS来实现的。
CPS 是每销售成本的缩写。 是产品促销中常用的计费方式。 按实际销量收费。 比较适合购物APP推广，但需要精准的流量进行数据统计换算。
2、百度产品推广流程的业务特点
CPS推广和销售需要为用户提供三个不同维度的服务，分别对应前面提到的流量主（主播+作者）、广告商（商家）、用户（消费者）。 同时，整个CPS推广体系的建设，也从这三点入手进行功能的拆解。 它可以分为3个用户界面服务和5个内部核心服务。
（图1：百度整体投放体系构建）
(1) 三个用户界面
从图1可以看出，产品推广系统主要有三个用户界面，分别是针对广告主的小程序B端、针对流量主的选品界面以及针对用户的订单购买界面。 下面分别介绍这三个接口。
在广告主接口部分，小程序B端服务作为商户侧，为广告主提供产品注册服务。 即广告主可以在小程序后台界面激活产品的佣金分成，从而实现其产品的推广。
（图2：小程序B端产品激活界面）
（图3：小程序B端用户收益界面）
在实际投放过程中，开发者可以自己充当广告主来进行投放。 这种方式带有一定的开发成本（如当当、亚马逊等）； 百度还提供整套的开店服务，可以以极低的价格推出。 成本涉及到产品推广过程（比如杜小点）。
在流量主界面中，百家号和直播生态作为选品服务作为入口，为主播和作者提供方便快捷的产品介绍。 这一部分还可以介绍一下百度自己的系统产品。
（图4：百家号编辑选品界面）
上图是百家号的编辑界面。 流量主可以通过编辑按钮添加产品??，从产品库中选择产品，并将产品展示窗口嵌入到文章中。 如果普通用户点击文章中嵌入的商品链接并成功下单，则该订单将被流量主按照一定的规则计为促销。 在百家号直播界面，还可以选择商品、添加商品链接，这里不再赘述。
（图5：产品选型平台选择界面）
图2，这是百家号的产品选择界面。 可以看到，选品不仅包括淘宝、京东、拼多多的佣金型产品，还包括度小店等一些具有百度特色的选品库。 、当当、亚马逊、影迷等
用户界面部分与广告商的类似。 产品和订单界面依靠百度小程序进行展示。 这样的设计方便了百度APP产品矩阵内的共享。 从技术实现上来说，广告主的产品界面只需开发出来，就可以在百度生态内的所有App上进行展示和推广。
（图 6：用户界面）
用户界面主要面向消费者。 消费者在观看直播或阅读作者文章时，如果直播或文章中包含产品宣传，则可以按照图6所示流程购买产品。 此时购买的产品来自产品促销系统。
（二）五项核心服务
通过对用户界面的梳理，可以将产品推广系统按照功能点进行拆分。 在此实现中，它分为 5 个核心服务。 服务内容见下表：
五项核心服务中，挂载服务和促销服务针对产品促销场景进行了重新设计和开发。 交易系统、结算系统、资产系统是交易中心已经具备的能力。
（3）构建具有百度特色的推广流程
2020年开始，百度开始在集团内部建立产品推广体系。 系统建设过程中，面临诸多技术挑战，主要表现在以下几个方面：
以上只是列出了一些主要问题。 看细节的时候，有很多问题是前台看不到的，但却极大影响了体验。 比如，流量主打到有效推广后，需要分配佣金。 这部分佣金是如何实现计算的，分配的佣金如何才能真正成为流量主的收入？ 再比如，作为广告主，如何才能定型、量化地看到自己的推广记录呢？ 总是涉及到金钱的变化，任何人都想仔细看看。
然而，抛开挑战不谈，从交易中心开始构建CPS推广体系，是站在巨人的肩膀上。 依托底层交易能力，可快速建立一套CPS推广实现，业务中可充分复用现有能力，包括下单、资金池、资产记账、提现等，可快速落地； 从技术上讲，它可以依靠交易的底层框架来实现功能的快速实现。
3、产品推广服务的实施
（图7：挂载服务&&推广服务架构图）
虽然挂载服务和促销服务在复杂的产品促销系统中发挥着非常重要的作用，但从设计的角度来看，分开后，它们各自的功能其实比较单一，这也符合系统之间内部含量较高的情况。 低耦合的标准。
上图按照分层设计方法将服务分为4个层次。 从上到下，它们分别是：
业务层：该层是指抽象业务，是多个可扩展的服务提供者。 不同的服务商从不同的角度提供接入，包括广告商、流量主、用户等不同的服务。
接入层：该层主要是指为业务层提供服务的服务网关层。 其主要功能是流量转发、服务认证、负载均衡等。接入层除了常规网关??的功能外，还隔离了BC两侧的不同流量（B代表商户，C代表用户）。 其中，交易统一网关主要负责来自消费者的流量。 这种网关的特点是用户请求量大，但比较简单。 因此，对于网关的设计，在非功能性需求方面，性能和安全性是主要考虑的因素。 其中，电商开放平台（）作为商户的门户入口。 这部分网关的访问量不是很高，所以主要以业务处理和关联为主。
服务层：该层是核心服务提供者，包括多个前端和后端服务。
动态库：产品推广的核心前端组件，主要负责上报推广数据，需要保证安全性和数据合法性；
注册服务：这是一项后端服务，提供广告商流量的注册和激活。 并与下级产品系统、结算系统配合，提供产品导入、佣金比例设置等功能。 它是过去与未来的纽带，是数据登记中心；
挂载服务：挂载服务在产品注册后提供产品窗口链接生成和数据真实性验证。
推广服务：产品推广的核心后端组件。 对外接受动态库的促销记录上报，对内接受交易系统的订单促销判断。
组件层：该层依赖都昌内部的各种中间件来快速实现功能。
对于促销记录和安装服务，设计的难点在于与整个系统的连接。 业务本身比较单一。 这里有两个部分值得介绍。 一部分是基于动态库的促销记录上报，另一部分是基于数据库的。 批量写入的写入优化。
(1)基于动态库的促销记录上报
【动态库】是百度小程序提供的一个框架组件，可以绕过小程序底层的基础能力，比如图表、富文本编辑器等。产品动态库就是采用这种绕过设计方式，嵌入到开发者的开发环境中。产品详情页面，并且可以完整获取产品页面的扩展参数。 （复制此处链接查看小程序动态库官方文档：）
（图8：小程序动态库示意图）
小程序的动态库如上图所示。 最上层是订单的购买页面，最底层是小程序的运行容器，中间层是动态库。 动态库是按需动态加载的基础库。 它是由一些特定的小程序业务平台（如大搜、丰巢等）发布的删除百度推广记录，可以提供业务平台的一些业务功能或约束。 动态库具有以下特点：
由于动态库本身是由交易中心开发和维护的，因此促销数据报表是通过动态库上传的。 基于动态库实现数据上报具有明显的优势：
1.遵循开闭原则：避免在订单页面硬编码数据上报。 与订单页面完全解耦，无论开发者升级还是报表逻辑更新，都不会互相影响。
2、修改一处，多处使用：小程序动态库可以无缝应用于各种矩阵APP，未来还可以开源应用于外部主机APP。 扩展性和兼容性都非常好。
3、优秀的可维护性：由于促销报表与订单页面完全分离，开发无需考虑业务实现和问题，具有良好的扩展性。
不过，由于动态库是一个比较底层的实现，俗话说，能力越大，责任越大。 在实际开发中，动态库对于性能和安全性都有非常高的要求。 动态库的加载不会减慢开发速度。 提单页。
关于数据协议，虽然动态库可以独立于订单页面运行，但是如何为动态库设计广泛使用的数据协议并使其具有良好的可扩展性是一个问题。 在实践中，我们对挂载链接函数进行了改造，实现了服务器端生成链接+动态库解析连接的闭环。
见下图；
（图9：带货链接的动态库闭环）
安装服务提供了为产品选择界面生成链接的能力。 对于不同的产品，会生成专属流量主的特定链接，并携带一些扩展参数。 这些参数将与产品页面一起加载。 虽然这些参数对产品页面没有影响，但它们是动态库加载的必要参数。 这些参数包括自我验证机制。 如果随意修改，报告验证会检测到。 针对不同的商家和产品，可以通过挂载链接中设置不同的参数，实现个性化的促销数据上报能力。 例如，对于不同类型的服务，如果点击促销链接，在产品详情页面的停留时长可能会有所不同。
数据协议的统一格式也有利于后续判断推广是否成功。 例如，可以统一采用时间窗口策略来判断用户晋升流量主是否成功。 对于一些商家来说，此时也可以跳出产品的品类，直接确定用户。 是否触及商家其他有效促销活动。
(2)基于数据库批量写入的写入优化
促销数据上报具有请求量大、业务相对简单的特点。 另外，促销数据实时查询的需求也不是那么强烈。 在实际开发中，我们对促销服务采用了数据库异步批量写入机制来提高性能。
（图10：批量写入优化）
现在我们用上图来说明一下优化过程。 改进前的单写实际上是简单的单写。 每次数据上报，流程都会走一次，经过控制层、服务层、数据持久层写入数据。 这样做的优点是逻辑简单，写入实时性好，适合一般的OLTP业务。 但对于数据上报服务（类似的服务还有打点服务、日志上报等），就不需要实时查询了。 因此，在服务资源有限的前提下，可以采用批量写入的方式，充分利用资源。 提高服务吞吐量。
图中右侧部分是优化后的批量写入。 批量写入本质上是生产者-消费者模型，目标是降低数据库的TPS。 图中每收到一条上报记录，就会加入到内存的阻塞队列中，同步写入改为异步写入。 队列每隔一定时间执行一次写入。 这样一来，写入数据库的QPS其实就大大降低了。
台中一般采用水平分表的db设计，促销记录的设计也是如此。 数据表按照子表字段的路由存储在不同的数据表中，不同的表也可以分离到不同的数据库实例中。 ，进一步横向扩展。 下图是《百度交易中心下单系统架构简析》中的数据表规则。 促销记录的分表方法类似。
（图11：表分表规则）
对于这种数据库结果，在数据库批量写入时，可以进行另一种优化，即将同一个实例和子表的记录聚合起来，然后统一执行。 这样可以进一步提高数据库的写入效率。
4. 总结
产品推广系统建设的难点在于业务复杂、建设路径长、需要跨团队、跨部门的合作。
业务明确之后，对于技术侧的实现来说，除了动态库之外，其他部分的实现复杂度并不算太高。 关键在于边界条件的控制和细节的彻底控制。 推广系统和交易平台有幸站在巨人的肩膀上乘风破浪，自然会事半功倍。
古往今来，软件开发工程按照工作领域大多分为系统工程师、算法工程师和业务工程师。 无论你是什么类型的工程师，如果你想不辜负你的使命，你需要积累广度和细节。
本站对作者上传的所有内容将尽可能审核来源及出处，但对内容不作任何保证或承诺。请读者仅作参考并自行核实其真实性及合法性。如您发现图文视频内容来源标注有误或侵犯了您的权益请告知，本站将及时予以修改或删除。