指南：百度保障为百度内部产品线的产品和服务提供保障能力。网友在购买保底商品或使用保底服务时，因商家欺诈或未履行承诺，可通过保底平台发起赔偿申诉，获得相应赔偿。同时，百度担保为商家提供增值担保服务。加入百度保障计划后，商家可以申请相应的高级保障标签，提高订单转化率。百度保函主要服务于两个核心场景：开环场景和闭环场景。百度保障的业务目标是围绕百度商家提供的内容和服务，构建良币驱逐劣币的百度信誉生态系统，让用户可以放心地从百度获取信息和服务。全文6610字，预计阅读时间17分钟。一、背景百度保障是百度为处理商家与网民之间的投诉和纠纷而制定的综合方案。百度信誉生态让用户可以安全地从百度获取信息和服务。目前，百度保障覆盖了百度所有主要核心业务场景。搜索场景，无论是PC还是Wise，内部还是外部，几乎涵盖了所有的交易场景；电商场景，toB还是toC，爱购、度小店精选、招财猫等；Feed场景、Feed广告、小程序防护；重点垂直品类，柠檬美妆、生活服务、医疗、教育等。网民在百度交易或使用百度服务时，只要寻找“保”字样，如有商家欺诈或商家承诺不履行的，可以通过担保平台发起赔偿申诉，获得相应的赔偿。图（1）展示了百度在搜索场景和电商场景两大核心场景的主入口和保障服务标签的公开。图（1）保障核心场景入口百度保障产品介绍百度业务线商户可以使用百度保障作为统一入口服务，通过支付保证金等形式加入百度保障计划。同时，百度保障提供高水准的保障标签服务，为所有B端商户赋能。商家加入保障计划后，百度保障标签和高级别保障标签将展示在C端商家对应的产品和服务上，从而增强网民对百度产品和服务的信任度，提高订单转化率。当网友购买带有“保”的商品或服务时，商家存在欺诈或违约行为时，网友可以来百度保提供相应的证据，经过运营判断过程，获得相应的赔偿。根据百度的特点，目前的保护补偿体系主要支持两种补偿形式，即：基于互联网用户行为记录（如点击记录、小程序调用记录）的开环场景补偿应用和基于订单（e-商务订单、支付订单）闭环场景补偿应用。图（2）百度保障产品介绍二．业务架构全景图（3）是安全业务的全景图。最底层是保护核心业务数据，主要分为三类，即商户数据、网民数据和赔付数据。商户数据包括：商户基本信息（商户ID、商户名称、营业执照等）、押金信息、高保信息等网友数据包括网友基本信息（网民ID、姓名、姓名）、实名信息等。补偿数据主要包括补偿申请记录、证据信息、百度支付记录等。数据层之上是基础服务层，主要包括基础能力、计算融合服务、第三方服务.中间层是保障服务的核心制度，主要包括统一准入制度、公开制度、准入制度和补偿制度。核心系统直连业务的B端和C端，为各业务方提供服务。图（3）担保业务全景（1）入职系统主要服务于各业务方的B端系统，为客户提供有保障的入职服务，客户可以在其中管理保证金和高位担保。业务方接入保函时，需要与保函确认不同行业的保证金门槛，并相应配置保函测试。那么，业务方B只需要将保障页面以iframe的形式嵌入即可。(2)公开系统主要为各业务方的C端或其他展示端提供高性能的担保数据查询服务，包括担保标记和担保浮层。主要数据维度包括：账号userid、网站url、小程序appkey、店铺ID维度。(3)有保障的接入系统，主要服务于开环场景下互联网用户行为数据的接入。由于开环场景，互联网用户在申请赔付时，能够在线获取的在线凭证只有互联网用户在系统中的点击行为等数据，所以对于开环场景，需要接入不同业务方的点击行为数据，作为网民申请赔偿的依据。(4)保障补偿制度主要包括两种场景的补偿，开环场景的点击记录补偿，闭环场景的订单补偿。两种补偿方案的主要区别在于补偿的依据不同，判断补偿的操作标准不同。在申请赔偿的过程中，需要验证网友的真实性，主要是利用人脸活体技术。在投保过程中，为网友提供联系商家、联系平台等服务，提升网友的报案体验。最终运营统一确定补偿。三保服务核心能力介绍3.1统一结算统一结算主要针对各商家B端系统设计，方便商家快速加入保。商户加入担保的门槛条件是支付足够的保证金。担保保证金将保证金充值、退款、扣款、罚款、财务对账等复杂繁琐的金融交互逻辑纳入底层能力，业务方只需嵌入担保统一入口页面即可。由于历史原因，百度存在多个账号体系，业务方的账号体系和权限控制体系也不一致，导致业务方存在各种账号权限控制。那么遇到这种情况，百度安全该怎么办呢？首先，百度保函作为通用服务，不需要感知业务方的个体权限逻辑。因此采用token认证进行统一的访问控制，具体的权限控制交给业务方。业务方通过安全接口api将页面参数传递给安全令牌服务，获取令牌信息，然后将令牌信息作为参数组装到安全入口管理页面中，将安全入口页面以框架。保证测试控制token的有效期，保证同一个token只能在一个浏览器中正常访问。这有效地将有保障的统一入口服务与业务方账户体系和权限控制服务解耦。客户介绍服务主要解决不同业务方保障维度不一致的问题。比如小点友家在店铺层面加入百度保障计划，生活服务商户通过账号ID加入保障计划。客户导入服务将业务方的不同维度转换为担保商户（deposituserid）的维度，所有担保的数据都与deposituserid挂钩。从风险的角度来看，收取的保证金数额与商户的行业类别绑定，由商家、担保、法务共同制定不同行业类别的保证金限额。同时保证提供通用和个性化的保证金计算服务。不同的业务方根据不同的业务特点选择保证金计算策略。例如，一家小店更喜欢将保证金要求最高的品类的保证金作为最低保证金金额。Aibuy可使用所有品类商户的最低保证金金额和最低保证金金额。商家必须缴纳大于或等于最低保证金的最低保证金，方可加入百度保障计划。商户加入基础保障后，才能申请高级别保障。图（4）保障统一结算接下来我们看一下业务方与保障统一结算的核心交互。1、业务以页面iframe的形式嵌入到保单统一管理页面中。商户可在本页面进行押金管理（包括押金充值、退款等）和高保管理。商户加入高保项目（如7天无理由、48小时发货、假一赔三等）后，相应的高保项目标签可以显示在对应的商品详情页，从而增强网友对产品的信任度，提高转化率。2、当业务方商户的行业类别发生变化时，将以api的形式通知保函，并完成相应保证金和高位保函项的重新计算逻辑。3、最终担保情况和担保事项结果将以api的形式发送给业务方，同时进入信誉公示系统，并在各页面展示用户的C端。业务侧接入步骤，确保统一结算。1.初始化类目与安全资金、类目与高级安全物品的关系。2.是否需要自定义保证金计算策略，需要就升级，不需要就直接介入。3、配置上线，主要配置业务方需要的功能和对应的下发接口地址。这样一个新的业务方的进入，一天之内就可以完成。3.2信誉披露随着百度担保业务场景的不断拓展，越来越多的担保标签和信息被披露到各个场景和业务方。同时，保函希望建立统一的百度保函品牌，这就需要统一保函标签和信息在不同场景下的数据和披露方式信息。需要为C端用户提供统一的保障数据服务和前端统一风格。目前的保障信息显示每天20亿条数据，峰值qps达到15Wqps，那么信誉披露如何在保证高性能的情况下支持这么高的qps呢？下图（5）是声誉披露的核心实现。图（5）声誉披露的核心实现首先，无论保障信息披露的场景多么复杂，披露的数据维度都比较稳定，主要包括通用维度userid、url、小程序appkey（主要根据百度的业务特点，百度核心内容主要来源：百度商家userid、百度自然结果url、第三方小程序appkey）和业务方个性化维度sappid+objectid。规范各个维度的数据结构。为了提高检索的性能，减少检索的逻辑，信誉公开采用读写分离和离线计算的形式，即信誉信息入库时，根据检索要求，将数据先检索结果检索需要的结构，检索只需要取出相应的Data，做简单的fine-tuning即可。声誉披露采用多区域部署。根据征信数据源存储的特点，采用主多从模型。数据在华北写入，同步到华北、华东、华东从库，减少因地域差异产生的不同区域数据量。地区的影响。同时使用mysql作为数据备份，数据通过binlog以异步消息队列BP和文件udw的形式输出，满足不同业务方的个性化需求。在语言选择方面，信誉披露服务在golang中实现，并行处理各种检索请求，最大限度地提高服务性能。目前信誉公开实时检索服务平均响应时间稳定在2ms以内，支持20w+qps。3.3点击记录进入前文提到，当网民在百度购买、使用带有保证标志的商品或服务被骗时，可以来百度保证提供证据申请赔偿，从而获得相应的赔偿。百度的薪酬体系主要支持薪酬开环场景和闭环场景两种场景。开环场景是指用户从百度获取相关业务信息，然后在线下完成交易。整个交易过程百度基本不知情。一个典型的开环场景是：互联网用户在百度上搜索广告，点击丰巢广告跳转到商家。着陆页了解商户的相关信息，最终在线下完成整个交易过程。对于开环场景，一个非常重要的信息就是网友在百度的行为记录。这是网友申请赔偿的证明，否则不能证明是自己从百度上了解到的信息。不宜为百度保证的不同业务方存储一套上网用户信息记录。为了降低业务方的接入成本，同时最大程度的解耦业务方的逻辑，从而保证点击接入接入服务的收敛性，维护所有业务方的点击记录在保证测试。当网民浏览产品或服务时，业务方只需将相应的点击记录接入保函，后续网民根据当时的点击发起补偿申请，补偿流程和财务的运作支付对商家来说都是透明的。图（6）有保证的点击记录访问架构点击记录访问系统主要处理点击的分发、字面量还原、合并、入库和存储。首先，需要规范点击记录结构（主要包括搜索相关查询、素材标题、点击时间、点击ip、跳转链接、网友passportid、商家userid等）。单击以访问支持文件、异步消息队列、API和其他样式。点击记录系统由两个主要服务组成，bzWorker和bzMerge。bzWorker的主要用户对不同业务方的点击记录进行自适应处理，包括点击日志素材的还原、无效日志的过滤等，当有新的日志源接入时，只需要自适应地封装这些服务即可作为物质修复。bzMerge是点击日志的通用入库逻辑。其中bzWorker和bzMerge采用master-worker模式。master负责消息的分发，worker负责消息的处理，可以最大化点击日志的干预率和资源利用率。图（7）bzWorker实现在bzWorker和bzMerge之间增加一个redisbuffer，可以启动良好的削峰效果，提高系统的整体稳定性。当下游bzMerge挂掉时，点击记录会暂存在缓冲区。不会有消息丢失。点击记录数据存储分为两部分。点击映射数据存储在gaia-x中。gaia-x是一个newsql分布式数据库（SQLonDistributeKV）。它是一个列式存储数据库。与ddbs相比，主要优点是节省了良好的存储资源和扩展性。同时使用sndb存储重复率高的基础素材信息，最大程度节省存储空间。保障点击记录接入系统，满足业务方点击记录秒级延时干预，支持20000+写入吞吐量。3.4补偿申请百度担保的补偿有两个核心场景，即开环场景和闭环场景。对于开环场景下的补偿，主要由网友提交相应的证据信息，主要由运营控制。整个投保流程比较简单，所以这部分主要介绍闭环场景下的订单赔付。闭环场景下的订单支付要比点击记录支付复杂的多。首先，开环场景下支付凭证的点击记录已经汇聚保障，而闭环场景下的订单分散在各个业务方。订单是交易场景的基础服务。每个业务方都构建了自己的或使用了通用订单服务。如何在保证订单接入薪酬体系的同时，减少业务方的侵入？同时保证在整个交易过程中同一个订单有可能产生一个在处理订单？如果用户在商城中选择了商品下单，首先在商城的订单中心会有一条订单记录。同时，为了方便用户更方便的查找订单，业务方的订单数据将接入手机订单中心。当用户完成支付时，也会生成一条支付记录。如果用户在其他APP（如百度地图）进行交易，订单也会进入百度地图订单中心，那么如何保证无论用户在哪里申请赔偿，数据都会同步更新，避免刷单等情况？从以上流程，我们可以发现担保支付的三个主要角色：担保业务方、担保平台、首白订单中心（订单聚合平台、担保伙伴）。保障平台和手百订单中心是两个独立的服务商，不同业务方的接入维度存在差异。加入手百订单中心的商家不一定加入担保平台，同样加入担保平台的商家也不一定加入手百订单中心。在整个订单赔付过程中，如何让移动100订单中心尽可能不感知保赔业务，从而当新的业务通过移动100订单中心添加到保赔中时，移动100订单中心可以透明而不自知？网友在商家下单的瞬间，只有商家才能感知到当前对应的商品或商户是否加入了保障计划，所以只要商家下单，保障快照信息是否对应给订单的是baoinfo（主要包括：保函为业务方分配的原始sappid、业务方添加保函的维度objectid、业务方原始订单idorderid、当前保函状态等。)，从而保证整个订单流转过程中原始信息baoinfo的透明传输。保赔信息只需要与原保赔信息关联，因此无论网友在何处发起赔付，只要订单快照中的原保赔信息保持不变，对应的赔付都是一样的。而只要百度保函与首白订单中心建立合作关系，后续加入保函的业务方只要按照约定向首百订单中心提供原始保函信息baoinfo，即可完成订单支付接入保函。整个过程中，首百订单中心都是透明的。图（9）在订单补偿实现的同时，在订单补偿闭环场景下，网友对补偿体验的要求也不同。因此，订单赔付相对于开环场景，引入了系统的自动判断逻辑，比如48小时发货，只要网友申请，系统判断商家确实迟到，直接赔付给网友，无需人工审查。对于薪酬建立、财务支付、开环场景，采用统一财务支付。网民需要提供相应的银行卡信息，经过财务审核，财务审批后方可进行支付。付款周期长。在订单补偿场景中，百度保障推出了快捷支付能力，直接通过提现小程序实时给用户打款。四、电商场景实践电商场景的典型代表是小点网。小店优选商户通过缴纳保证金加入百度保本基础保障计划。商家根据自己的行业类别选择相应的高级别保障项目，并在商品详情页公开保障项目，以增强买家对商品的信任度，从而促进订单转化。当商品出现质量问题，或商家不遵守承诺（如承诺后48小时内未发货），您可以直接在手百订单中心或小店订单发起赔偿中心。从实验数据可以看出，商品加入保障计划后，商品详情页提单转化率可大幅提升。图（10）小店优化保障实践五、发展与对未来的思考。在业务方面，我们将继续深化对电商、服务、医疗等垂直行业的保护，让用户在百度上获得的内容和服务更加可信。在技??术上，信誉保障研发团队将引入更多自动化的系统判断方式，提高保障处理效率，进一步降低运营成本，提升网民投保体验；数据方面，着力打造B端数据保障能力，让百度保障成为B端赋能的利器。推荐阅读：深入理解VisualTransformerWKWebView中的输入可视化方法（渲染篇）-深入理解DOM树构建WKWebView（入门篇）-WebKit源码调试分析GDPStreamingRPC设计百度APP解码优化中视频回放
