抖音开放平台Logo
开发者文档
“/”唤起搜索
控制台
  • OpenAPI 简介
  • 通用参数
  • 小程序 OpenAPI SDK 总览
  • 签名算法
  • 基础能力
  • 触达与营销
  • 支付
  • 运营
  • 生活服务
  • 通用能力
  • 生活服务交易系统(全融合版)
  • 生活服务交易系统(账号融合版)
  • 错误码和返回码
  • 通用参数
  • 预约
  • 查询接口
  • 预下单
  • 营销算价
  • 营销算价扩展点介绍
  • 查询营销信息扩展点
  • 算价扩展点
  • 营销查询算价二合一
  • 支付
  • 核销
  • 分账
  • 退货退款
  • CPS佣金设置与查询
  • 即送(原随心团)解决方案
  • 核销工具解决方案
  • 历史版本(不推荐使用)
  • 垂直行业
  • 其它
  • 功能简介

    营销算价扩展点是交易系统为开发者提供的用于接入开发者自有营销能力的扩展点,方便开发者将自身已有的营销能力无缝的接入到抖音开平交易系统。
    例如:如果开发者 A 通过某种途径给其抖音小程序用户 C 发放了一张开发者自有的优惠券,后续用户 C 在该开发者小程序中进行下单交易时,可以使用这张优惠券进行下单以获得开发者 A 提供的优惠。
    目前营销扩展点支持优惠券、会员、活动、积分这 4 种营销能力,优惠券支持立减、满减、折扣等,具体支持的券类型请参见接口字段定义。
    平台不限制营销能力的隶属方,只要开发者自己有能力进行营销逻辑处理即可。例如:开发者可以使用自己发的小程序优惠券,也可以使用"某第三方平台"的优惠券,只要开发者的系统自己能处理"某第三方平台"的优惠券即可。

    注意事项

      1.抖音开平交易系统只记录营销的信息用作交易快照(会作为客诉判责依据)
      2.平台不校验「开发者自营销」信息的有效性,也不负责「开发者自营销」券的发放/领取/核销/回退、会员身份赋予/校验、积分增减等逻辑,这些合法性判断、自营销生命周期关联操作由开发者自行在预下单、退款等流程中进行处理
      3.营销抵扣的算价逻辑由开发者自行实现,平台只要求使用营销后整单实付金额 > 0,开发者需要在算价扩展点返回结果中将优惠分摊到各层订单上,平台支持算价结果分摊到最细粒度的 item和分摊到goods两种分摊模式:
      如果开发者返回的算价结果分摊到最细粒度的item,平台将以开发者算价结果为准
      如果开发者返回的算价结果只分摊到 goods层,则平台会根据goods层的分摊结果按item金额等比例拆分,将goods层的算价结果自行分摊到 item单上,从而获得每个 item 订单用户的实付金额,无法整除分摊时 item 单的实付金额最大差值为 1 分。
      4.使用营销下单的订单,后续如果用户发起退款,平台会根据 item 单的实付金额发起退款。
      5.同时使用多种营销优惠能力进行提单时平台不支持优惠互斥等逻辑,默认为叠加逻辑,即订单上所有的营销优惠项同时被用户享用

    相关接口

    接口
    类别
    使用场景
    备注
    前端JS-API
    开发者未使用提单页模板
    前端组件
    开发者使用提单页模板
    扩展点

    营销扩展点交互流程简介

    整个交互中,开发者在交互中的任一步骤返回失败则后续流程都会被终止。

    JsApi 组件交互流程

      此模式下开发者需要实现算价扩展点供流程中二次算价请求调用,并返回订单的最终算价明细

    前端模板提单组件交互流程

    查询&算价扩展点分离模式(旧流程,不推荐,新接入的开发者建议使用下面的二合一模式)

      此模式下不支持用户手动选择可选优惠
      开发者需实现【查询营销扩展点】+【算价扩展点】

    查询算价扩展点二合一模式(推荐)

      此种模式下用户可以自行实现营销的叠斥逻辑,也支持用户自行选择切换使用的优惠。
      开发者需实现【营销查询算价二合一扩展点】

    营销分摊逻辑 showcase

    优惠分摊的逻辑按照订单结构分为三层:order 层,sku 层,item 层。(这里的 sku 层与前文的 goods 层是同一个含义)