🎯 方案定位

先做可追踪的推广底座，不先做自营联盟

在自有 BTOC（面向消费者的商城） 上搭一套「网红有店铺、商品可追踪、订单可归因、佣金可结算」的推广底座。网红只推广 BTOC 联合开店壳店报价栏的产品（即网红选品库）；其它日企 B2C 网店产品、BTOB 商品不进入网红推广。

🌟 本模块在 7·6 平台新蓝图中的定位 网红推广 = 平台的 C 端增长飞轮（BTOC 消费者层），推广已发布到 BTOC 的商品销售，按推广码 / 末次点击归因、按商品 / 订单维度计佣。它与「推荐人招商」（B 端飞轮，拉企业入驻、按企业维度归因）和「BTOB 大 B 商品海报」（分拨销售工具，连接下游小 B）复用部分分账与链接底座，但业务归因独立、互不干扰——产品上不要把三者混成一个「推广系统」。
✅ 好消息：后端底座已落地（9 张数据表 + 归因引擎 + 状态机 + 分佣公式 + 结算 + 打款），作为 BTOC 带货飞轮，补全前端（网红工作台 / BTOC 商家选品 opt-in / admin）即可。
📌 2026-07-06 推广边界 H2B 商城是封闭采购商商城，H2B 采购商审核通过后才可查看；H2B 商品上架需要管理员审核。商家主体统一，但 BTOB / BTOC 渠道资格分开审核。网红必须拥有店铺；网红只能推广 BTOC 联合开店壳店报价栏的产品（即网红选品库）。BTOC 联合开店目前仅开放给平台指定的一家壳店（壳作用），其它日企 BTOC 联合开店申请暂不开放；该壳店日企自主发布产品到报价栏。其它日企在 BTOC 平台上开的网店上架的产品、BTOB 商品，均不进入网红选品库。网红店铺支持商品二维码、店铺二维码、短链和优惠码；这些销售二维码不等于推荐人招商二维码，也不替代 BTOB 大 B 的商品/店铺二维码。2026-07-06 后，选品库商品按联合开店以销定采状态展示，允许预售/起订量/交付周期信息，不承诺前置仓现货库存。
P0：优惠码 + 短链 + 归因 P0：来源报表 + 自动结算打款 P0：网红端 + 运营管理 P1：ASP / 税务配置 P2：自营联盟
🙋运营直签 / PR主动找网红
›
🏷️优惠码 + 短链带参追踪
›
🛒BTOC 注册 / 下单消费者成交
›
🔗订单归因算到谁头上
›
📊来源报表看效果 ROI
›
💰自动打款复用 Stripe
📋 业务策略（运营主导，技术配合） 谁带来流量 / 消费者注册 / 订单、网红从哪来、带货还是粉丝拉新——这些业务策略由运营主导（见决策台 #2/#3/#5）。技术负责把追踪、归因、分账、打款的底座跑通，配合运营落地，即本报告下半部分。
🗺️ 路线图

分三期推进，本期只做 P0

把能力拆成三档，本期聚焦最左边的 P0，把追踪闭环跑通。

P0 · 本期必做

可追踪底座

  • 入驻/审核 + 选品库 + KYC(Stripe)
  • 优惠码、单品短链、点击采集
  • 订单归因 + 来源报表 + 数据看板
  • 自动分佣（复用 Stripe + 联合开店）
  • 网红端工作台 + 运营管理
P1 · 二期

放量与合规

  • 接入 ASP postback（数据回传）
  • 税务配置（源泉徴収/インボイス）
  • AI 辅助触达文案、素材
  • MMP 装机归因（如有 App）
P2 · 三期

自营联盟

  • 完全自助入驻生态（网红自己来申请）
  • 第三方市场连接器（TikTokShop/Amazon/乐天）
  • 高级风控（刷单/多账号检测）
  • 完整联盟平台产品化

ASP（联盟营销平台，帮广告主对接推广者的中间平台，如 A8.net、ValueCommerce）　·　联盟（让推广者自助入驻、推广赚佣金的网络）　·　postback（平台之间回传转化数据）　·　MMP（移动归因工具，追踪 App 下载来源）　·　KYC（身份认证）　·　onboarding（开户/入驻流程）

🙋 网红供给 · 运营策略

网红从哪来（运营主导，技术提供工具）

这是运营主导的业务策略，技术提供工具支撑、配合落地。

三种来源（运营决策，见决策 #3） ① AI 辅助直签（P0 主力，运营主动找人）· ② ASP 联盟（P1 并行放量）· ③ 自建联盟（P2 自助入驻）。
技术要做的：网红账号管理（不是候选人库） 运营后台管理已注册网红：列表、审核、启用/关闭、看短链点击数据。候选人库（潜在网红 pipeline）P0 不做，由运营线下谈合作。
⚖️ 模式选择 · 影响技术范围

模式 A（直签）vs 模式 B（自建联盟）

此选择影响技术范围（模式 B 要建完整联盟系统），技术需关心。推荐 A，详见决策台 #1。

模式 A · 推荐

运营直签 + 轻量工作台

运营直签驱动，P0 全套：入驻/审核、选品库、KYC(Stripe)、单品短链、自动分佣（复用）、数据看板。最小闭环，开发量轻。

开发量轻
模式 B · 放 P2

自建联盟（自助入驻）

B 独有：完全自助入驻生态（网红自己来）、第三方市场连接器、高级风控、联盟规则。入驻/选品/KYC/分佣 P0 已有，B 是做成成熟联盟 SaaS。

开发量重
🔄 核心流程

三条主链路怎么跑

cookie（浏览器缓存的小标记）　·　click_log（点击记录）　·　consumer_referral（消费者拉新关系，P1）　·　last-click（末次点击归因）

① 带货归因（推商品 → 下单）

🏷️生成优惠码绑来源/活动
›
📺网红口播/发帖IG/TikTok
›
🛒用户下单输码或经短链进站
›
🔗写归因优惠码优先
›
📊进入来源报表

② 短链归因（带链接渠道）

🔗生成短链/r/:code
›
👆用户点击写 click_log + 种 cookie
›
🛒下单（无码）
›
🔗按末次点击归因短链有效期内
›
📊进入来源报表

③ 消费者拉新归因（P1 · P0 不做，仅展示未来形态）

🎫生成粉丝邀请码/落地页
›
📣网红向粉丝推广平台
›
📝消费者注册记录 consumer_referral 来源
›
🛒首单回流
›
📊注册/首单报表
归因优先级（一笔订单怎么算到谁头上） ① 优惠码 > ② 短链有效期内的末次有效点击 > ③ 无码无有效点击 = 自然流量，不归因。一笔订单最多一条有效归因。
边界：这里的拉新只指 C 端消费者 / 粉丝注册，不包含中国供方、日方采购方、BTOB 大 B 等企业商户招商；企业商户归推荐人系统处理。
🧩 功能清单

P0 要做哪些功能

FR（功能需求，Functional Requirement）

编号优先级功能为什么
FR-1P0优惠码管理不依赖外链，是 IG（Instagram）/TikTok/口播场景的必备归因手段
FR-2P0短链与点击采集追踪可放链接渠道的点击和转化
FR-3P0订单归因后续报表和结算的根数据
FR-4P0来源效果报表判断哪个网红/活动有效，算 ROI（投入产出比）
FR-5P0自动结算与对账复用供应商分佣机制，算网红佣金后 Stripe 自动打款
FR-9P0网红账号管理已注册网红审核/启停/短链数据（不含候选人库）
—P1/线下候选人库 CRM潜在网红 pipeline，P0 运营线下谈合作
FR-6P1ASP postback 接入放量阶段，需先确认与站内归因去重
FR-7P1税务配置源泉徴収/インボイス（日本税务合规）
FR-8P2完整联盟平台完全自助入驻生态、第三方市场连接器、高级风控（入驻/选品/KYC/分佣 P0 已有）
🖥️ 界面范围

后台、BTOC 商家端与 BTOC 各改哪里

⚙️ 后台（运营用）

  • 网红管理：列表、审核、启用/关闭、短链点击数据
  • 产品-网红关联：哪个产品被哪些网红推（产品视角）
  • 优惠码：查看、停用（创建由网红端做）
  • 短链：查看、停用（生成由网红端做）
  • 来源报表：点击/订单/GMV（成交总额）/退款/ROI（只读查看）
💰 理念：钱全由 Stripe 自动管，后台不做人工审核 分佣、打款、退款冲正都程序化自动跑（复用 Stripe + 联合开店）。后台只做「管网红 + 看报表 + 停用码链」，不需要结算对账、异常队列、审计日志这些人工维护操作。

🏪 BTOC 商家端（出钱方必看 · P0 新增）

  • 订单详情：🌐 推广标识 + 推广网红 + 佣金扣除（平台抽成 + 网红佣金）+ 商家可得金额
  • 产品推广数据：被哪些网红推 + 点击/转化/订单/GMV
  • 佣金支出：每个产品已付网红佣金总额
  • 佣金率设置：按品设佣金（方案 A opt-in 时）
  • 实时算账：改价/设佣金时实时显示净收益 + 平台扣 + 网红扣，护栏防赔
为什么必须做虽然网红费用由商家/商品毛利承担、平台代结算，但日企仍需看到「自己的产品被推广得怎样、分佣比例、实得多少」——这是 Amazon Seller Central 等的标配，否则日企无法对账。联合开店壳店日企在 BTOC 商家端查看自己报价栏产品的推广数据。

🛒 BTOC（消费者侧，只小改）

  • 商品页：支持 ref/click 来源参数与 cookie
  • 结账页：优惠码输入、校验、错误提示、折扣展示
  • 注册页来源记录（P1 · 拉新用，P0 不做）
网红端嵌在 BTOC（路径 /admin）网红有独立工作台（选品/短链/数据/佣金/账户），用 BTOC 账号登录，不复用消费者页面布局。详见第 8 章。

📋 各平台菜单 + 字段明细（开发清单）

基于前面业务逻辑，各平台要开发的菜单和核心字段如下（优惠码功能全新开发）。

🎙️ 网红端 /admin

菜单核心字段
🏠 工作台待办（审核/绑定状态）、今日数据概览
🛍️ 选品库商品图/名/售价/佣金率/可否生码、筛选、「加入推广」
🔗 推广链接商品/短链/二维码/点击数/生成时间、「生成」
🎫 优惠码商品/码/优惠率/使用数/生成时间、「生成」（仅 has_promotion 商品）
📊 数据看板点击率/转化率/订单/GMV/佣金、按时间/链接筛选
💰 我的佣金明细（订单/商品/率/金额/状态）、提现记录
⚙️ 账户资料、Stripe 绑定状态、邀请码

🏪 供应商端 vendor-panel

菜单核心字段
📦 商品管理商品列表、编辑 allow_affiliate（是否允许推广）
🎫 优惠码规则配置选商品、优惠率、佣金率、有效期、总次数上限、每人限用次数、实时算账预览（净收益/平台扣/网红扣）
📊 推广数据每商品的推广网红列表、点击/转化/GMV、已付佣金总额
💰 分账明细订单详情：🌐 推广标识、佣金扣除、供应商可得金额

⚙️ 运营管理端 admin

菜单核心字段
👤 网红管理列表（账号/状态/绑定/数据）、审核、启用/关闭、创建、邀请链接
🛍️ 产品-网红关联哪个产品被哪些网红推、各网红数据
🎫 优惠码管理查看所有码、停用
🔗 短链管理查看所有短链、停用
📊 来源报表点击/订单/GMV/退款/ROI、按网红/商品/时间筛选

🔧 平台核心逻辑（后端开发）

模块核心逻辑
优惠码生成网红生码实例（绑网红 + 继承供应商规则模板 + 独立 code）
优惠码校验结账校验：码存在 / 商品匹配 / 有效期内 / 未超次数
归因码 → 网红；短链 → cookie → 网红
分账基于折后价，平台收平台佣金；网红费从商家/商品毛利中扣除并由平台代结算；日企得扣除平台佣金、优惠和网红费后的余额
自动打款复用 daily-payouts，退款窗口后 Transfer 到 Stripe
护栏佣金率 3%~30%、联合开店优惠+佣金 ≤ 毛利
🎙️ 网红端

网红自助工作台（嵌在 BTOC 里）

网红需要一个自助页：管理网红店铺、选品上架、拿商品/店铺二维码和单品短链、看点击/转化/佣金、绑定 Stripe 提现。不新建项目，嵌进 BTOC，使用 BTOC 独立账号体系。

先理清：三个角色别混淆

seller · 供应商

卖货主体（H2B 供应商/联合开店），商品归他，已有 /sellers/[handle] 页。网红绝不碰这个。

网红 · affiliate

推广者，不卖货，推荐别人商品赚佣金。全新角色，不是 seller。

消费者

买家。点网红链接进商品页，cookie（浏览器缓存标记）记归因。

账号体系：复用 B2C 消费者账号 customer + 标签 is_influencer=true + 状态字段。网红同时也是消费者，一个账号两用。路径 /admin 进网红工作台（与消费者页布局隔离 + 鉴权）。

网红状态机 & 权限分层

📝注册自注册邀请/运营创建
›
🔵待审核运营审身份
›
🟡待绑定支付✅可选品 ❌禁生成码
›
🟢正常使用生成短链+看数据+提现
关键边界：绑定 Stripe 前只能选品浏览，禁止生成推广码/短链 没绑定收款账户就没法接收佣金，会产生算不清的账。先绑定、再推广。

Stripe 提现绑定流程

1️⃣创建 Connected Account系统/运营
›
2️⃣生成 onboarding 链接Account Links API
›
3️⃣网红点按钮自助认证在 Stripe 上传证件（平台不碰）
›
4️⃣webhook 回传状态account.updated
›
5️⃣标记「已绑定」可提现
⚠️ 日本站注意 JP 站 Stripe Express 账户不可用（静默降级 Standard），网红账户类型直接用 Standard。
🔐 KYC 方案：平台不存身份证，全交 Stripe 网红要过 KYC（身份认证），但平台不负责、不保存身份证/银行卡等 PII（个人身份信息）。KYC 完全由 Stripe 在 onboarding 托管页完成（证件、银行账户都填在 Stripe 侧，平台碰不到）。平台只存 Stripe Connected Account ID + 绑定状态，靠 webhook（account.updated）得知 KYC 是否通过。合规、零数据风险。

P0 核心闭环：单品推广链

本期必须有网红店铺。网红选品 → 商品进入自己的店铺货架 → 生成商品二维码 / 店铺二维码 / 单品短链 → 用户进入网红店铺或 BTOC 商品页 → cookie 归因 → 下单 → 算佣金。

🛍️网红选品从选品库挑商品
›
🔗生成单品短链/推广码绑归因
›
📺发帖推广挂精准链
›
🛒用户进商品页B2C 详情页+种 cookie
›
💳下单→归因→佣金
为什么 P0 不做合集页/店铺 B2C 已有 /sellers/[handle] 是供应商的页，网红不能复用（会撞货权/联合开店）。网红「合集页」是营销推荐列表，非必需——单品链已能完整闭环。合集页放 P1，且必须是独立新页（如 /influencers/[slug]），绝不碰 sellers。

网红工作台结构（路径 /admin）

🛍️ 选品库

浏览可推广商品 → 选商品 → 生成单品短链 + 推广码 + 二维码。

📊 数据看板

每个链接的：点击率、转化率、优惠券用量、关联订单、预估佣金。

💰 我的佣金

佣金明细 + 每日自动到账（复用供应商 Stripe 分佣，绑定后自动 Transfer）。

⚙️ 账户设置

绑定 Stripe（onboarding）、资料维护、状态查看。

💰 为什么 P0 能做自动打款？因为基建已有 平台已有给供应商的 Stripe 分佣自动化（daily-payouts 每日 Transfer + Commission 抽成）。网红打款直接复用这套，只需新增「网红佣金计算逻辑」（归因订单 × 佣金率 − 退款冲正）。网红绑定 Stripe = 成为 Connected Account（关联收款账户），佣金每日自动到账，无需运营手动打款。
自注册邀请（减轻运营负担） 运营筛选网红 → 生成「网红邀请链接」（带 invite_code）→ 发给网红 → 网红自填邮箱密码注册 → 自动标 is_influencer=pending → 运营只做审核。⚠️ 此「网红入驻邀请码」与「消费者拉新邀请码」是两套，必须区分。
💰 选品与佣金

选品库从哪来 & 佣金怎么分账

这两件事必须说清：选品库 = BTOC 联合开店壳店的产品报价栏（平台指定的唯一壳店自主发布的产品）；其它日企在 BTOC 平台上开的网店上架的产品暂不进入网红选品库。BTOB 商品与未过审商品同样不进选品库。

① 选品库来源：两种方案（影响是否要 BTOC 商家端界面）

这决定了 P0 要不要开发 BTOC 商家端界面，是关键范围决策，见决策台 #15。

🔗 商品源头对齐 7·6 新蓝图：选品库 = BTOC 联合开店壳店的产品报价栏 新蓝图下，联合开店已退化为纯协议层（仅 joint_agreement 同意标记，不驱动产品复制、无镜像、无关联关系）。BTOC 联合开店目前仅开放给平台指定的一家壳店（壳作用），其它日企 BTOC 联合开店申请暂不开放。该壳店日企自主发布产品到 BTOC 报价栏，其产品报价栏即网红选品库；其它日企在 BTOC 平台上开的网店上架的产品暂不进入网红选品库。下方「商家 opt-in / 全量自动」两种方案都建立在「产品已在壳店报价栏发布」之上。
方案 A · 商家 opt-in

壳店日企勾选商品 + 按品设佣金率

壳店日企在商家后台勾选哪些产品可推广、每个产品设佣金率。网红费用由商家/商品毛利承担，平台代结算，壳店日企必须看到佣金、优惠、平台佣金和净收益预览。

  • ✅ 日企自主、佣金按品灵活
  • ⚠️ 要开发 BTOC 商家端界面（推广管理页）
  • ⚠️ 冷启动商家未必主动勾选
方案 B · 全量自动（更轻）

壳店报价栏产品全进库 + 平台统一佣金

壳店报价栏所有产品自动进选品库，平台统一给默认佣金率（如 5%/3%）。网红费用由商家/商品毛利承担，平台代结算，必须配商品毛利护栏。

  • ✅ 简单、不需要商家端界面
  • ✅ 网红选品多、冷启动快
  • ⚠️ 日企没自主权、佣金不灵活
关键权衡：要不要开发 BTOC 商家端界面？ 方案 A 要（商家后台加「网红推广管理」页：勾选商品 + 设佣金比例），方案 B 不要。推荐方案 A（尊重壳店日企、让其按品定分佣比例），方案 B 更轻——两种方案下网红费用都由商家/商品毛利承担，平台代结算，由老板拍板，见决策台 #15。
商品扩展字段（两方案通用）：allow_affiliate（是否允许推广）+ affiliate_commission_rate（分佣比例，日企自定）+ has_promotion（是否配置优惠规则，决定能否生优惠码）+ promotion_rule_id（关联优惠规则模板）。佣金实际出资方为实际 BTOC 卖方/商品毛利，可由 product owner / seller_id 推导，无需额外 affiliate_owner_id 字段。

② 优惠码校验与归因（码 = 网红 × 商品 的绑定凭证）

优惠码不是孤立的码，它绑定 { 网红, 商品, 佣金率, 折扣 }。网红选品生成推广资产时建立关联，结账输入码即按此关联校验和归因。

优惠码的关联关系 网红X 选品(商品A) → 生成推广资产 → 可选「推广链接 /r/X-A」或「优惠码 NEXA10」。
每个码 = { 网红X, 商品A, 佣金率, 折扣 }。输入码 → 系统反查到网红X + 商品A → 这就是码能归因到网红的原理。
场景用户输入系统判断结果
A码不存在（瞎添/打错）查无此码❌「优惠码无效」，不折扣、不归因
B码存在，但订单商品 ≠ 码绑的商品商品不匹配❌「该码不适用于此商品」
C码存在 + 商品匹配，但停用/过期/超上限失效❌ 提示具体原因
D码存在 + 商品匹配 + 有效全通过✅ 应用折扣 + 归因到码绑的网红
回答两个常见疑问 ① 商品没进选品库，用户输码？ 没进选品库就没网红为它生码 → 码不存在(场景A)或绑别的商品(B) → 都失败。
② 商品在选品库但网红Y没选它？ 码绑的是「网红X + 商品A」。网红Y没选A 就没有「Y+A」的码；用户输的码绑的只能是选了A 的网红X → 归因X，跟Y无关。
🔗 规则模板 + 码实例（解决多网红同商品归因） 供应商配的是优惠规则（产品A→10%优惠，存规则ID 如 111），不是对外码。网红生成各自独立码实例（对外 333/444），后台关联规则 111。
→ 多网红推广同商品：优惠规则共享（111），码和归因各自独立（333→网红A，444→网红B）。
优惠来源：① 日企让利（默认，商家承担优惠金额）② 平台补贴（大促，平台掏钱）。
优惠码功能全新开发（独立模块，含规则模板 + 码实例 + 校验 + 归因 + 分账）。
⚠️ 能否生优惠码 = 商品是否配置优惠规则 商家 opt-in 选品时设 has_promotion。只有配置了优惠规则的商品，网红才能生成优惠码（码必带优惠，否则用户不填）；没配置 → 网红只能用推广链接（纯归因，不降价）。
💰 平台补贴（可选 · 大促才用 · 不一定要做） 平台做活动时额外掏钱给用户优惠（叠加在日企让利上）。例：日企让利 10% + 平台大促补贴 5% = 用户享 15% off。
分账：日企让利从商家扣，平台补贴从平台收入扣（需扩展平台补贴账户）。本阶段省着用，只在关键拉新节点放，不默认开启——见决策 #20。
归因优先级（决策 #25） 优惠码 > 末次点击。既点过链接又输了码？按码归因（码是更明确的推广意图）。无码才按 cookie 末次点击。

推广链接归因边界场景（cookie 绑网红 · site-wide）

推广链接（短链）和优惠码不同：优惠码绑「网红+商品」，推广链接种的是 cookie，cookie 绑「网红」（全站归因）。用户点链接进站后，30 天内买任何商品都归因该网红。

核心逻辑：归因看 cookie，佣金看商品 归因：cookie 绑网红 X，30 天内用户买任何商品，订单都算 X 带来的流量。
佣金：仅当所购商品在选品库（开推广）时才付佣金给 X；不在选品库则记录归因但不付佣金。
场景用户行为归因佣金
1 登录跳转点链接→商品 A→注册登录→跳回 Acookie 不受登录影响，仍归因 X买 A 正常付佣金
2a 买 B·B 在选品库点 X 链接(A)→没买 A→买 B(B 开推广)归因 X（cookie 全站）✅ B 有佣金设置，付给 X
2b 买 B·B 不在选品库点 X 链接(A)→买 B(B 未开推广)归因 X（流量是 X 带的）❌ B 无佣金设置，不付
2c 买 B·供应商未上传点 X 链接(A)→买 B(B 根本不在选品库)归因 X❌ 同 2b，不付
登录跳转技术要点 注册/登录后必须跳回原商品页（redirect_to=原 URL），cookie 跟域名走、不受登录态影响 → 归因不丢。
归因冲突（点了多个网红链接） last-click 末次点击：最后一次有效点击的网红赢（决策 #25）。
🔄 优惠券全链路流转图（从配置到打款）
🏪供应商配规则has_promotion=true
›
🎫网红生码实例绑自己+继承规则
›
📝用户填码结账
›
✅校验+优惠+归因折后价→网红
›
💰分账+打款Stripe Transfer

③ 佣金计算公式（现有逻辑：商品 & 运费分别抽）

【平台手续费】平台收，跟网红无关（现有逻辑）
  商品抽成 = Σ(商品售价 × 数量) × 5%
  运费抽成 = (运费 + 运费税) × 5%   [ENABLE_SHIPPING_COMMISSION=true，供应商承担]
  注：商品基数不含运费；运费独立抽 5%（运费抽佣是现有逻辑，不进决策台，见 ③公式；如需改不抽，改 ENABLE_SHIPPING_COMMISSION=false）

【网红佣金】给网红
  应付 = Σ(归因商品 折后实付 × 商品佣金率)
  基数 = 商品价，不含运费（行业惯例）
  退款冲正 = 已退款订单佣金（按比例）
  净应付 = 应付 − 冲正  →  每日 Stripe Transfer 给网红

【多商品】按商品行逐个算，同店铺汇总 / 跨店铺独立

④ 普通场景：三方分账（供应商直营）

例：垫片 ¥100 + 运费 ¥10（现有逻辑：运费也抽 5%）
消费者付 ¥110（商品 ¥100 + 运费 ¥10）
   ├─ 平台抽成 5%  = ¥5.5   （商品 ¥5 + 运费 ¥0.5，运费也抽）
   ├─ 网红佣金 10% = ¥10    （仅商品价，不含运费）
   └─ 供应商得     = ¥94.5  （剩余）
   核验：5.5 + 10 + 94.5 = 110 ✓
🎫 用户填优惠码的钱链路（日企让利 10% off）
商品原价 ¥100，用户填码享 10% off → 折后 ¥90 + 运费 ¥10 = 用户付 ¥100

   商品部分 ¥90 分账：
   ├─ 平台抽 5%    = ¥4.5（基于折后价，非原价）
   ├─ 网红佣金 10% = ¥9（基于折后价）
   └─ 供应商商品   = ¥76.5
   运费部分 ¥10（运费不参与优惠码）：
   ├─ 平台运费抽 5% = ¥0.5
   └─ 供应商收运费   = ¥9.5
   ─────────────────────────────
   供应商总得 = ¥86（承担了 ¥10 让利）
   平台 = ¥5    网红 = ¥9
   核验：86 + 5 + 9 = 100 ✓

   关键：优惠 ¥10 由供应商承担（让利），各方分账基于【折后价 ¥90】而非原价
💰 实战版：¥58000 订单分账链路（7·6 口径示例） 网红美月在 BTOC 带货「Lumina Pro 美容仪」，买家付 ¥58000： 
网红美月 佣金 10%  = ¥5800   （由卖方樱花堂出）
平台佣金 5%    = ¥2900   （含支付通道费）
樱花堂(卖方)实得 = ¥49300   （¥58000 − ¥5800 − ¥2900）
核验：5800 + 2900 + 49300 = 58000 ✓
护栏：平台只抽 5%、永不倒贴；网红费用由商家/商品毛利承担，平台只做代结算；售后准备金从平台成交佣金中切份额。全程复用底座，0 新支付链路开发。
🎯 7·6 新版要点：网红费用由商家/商品毛利承担，平台代结算 本模块核心变更——网红推广费用由实际 BTOC 卖方/商品毛利承担，平台负责归因、出账和代结算，不从自己的平台佣金中承担。这样平台佣金不会被推广费吃穿，卖方可通过商品毛利护栏决定哪些商品允许推广。
边界：本模块只处理 BTOC 选品库商品（即 BTOC 联合开店壳店报价栏产品）的零售推广；BTOB 商品、其它日企 B2C 网店产品暂不进入网红佣金链路。

⑤ ⭐ 联合开店：纯协议层（日企自营，无内部分账）

7·6 新版明确：联合开店已退化为纯协议层——仅 joint_agreement 同意标记，不驱动产品复制、无镜像、无关联关系。日企按双方线下谈妥后的单一售价发布产品，联合开店订单 = 日企自营订单，货款归日企，平台收佣金。没有 distributor 内部分账、没有分单、没有四方分账。

🏭联合开店日企线下定价·后台维护
›
🎙️网红推广单品短链
›
🛒消费者下单付日企售价
›
💰日企自营分账见下例
联合开店 = 日企自营（已决策）：取消借壳费、坑位费、供应商↔经销商内部分账、linked listing、forked product。联合开店订单按普通日企自营订单处理：货款归日企，平台收 5% 佣金（+网红费从平台佣金扣 +推荐人费 +售后准备金切份额）。无二次分账、无分单。

⑥ ⭐ 具体例子：密封垫片（联合开店 + 网红）

📌 场景设定

  • 联合开店日企 B：按线下谈妥价格发布垫片，售价 ¥150（单一售价，非镜像加价）
  • 网红 C：推广该垫片（日企自定分佣比例 10%）
  • 消费者：通过网红单品短链下单，付 ¥150（折后实付，不含运费）

💰 ¥150 日企自营分账（平台收佣 + 网红费由平台出）

消费者付 ¥150（日企售价¥150，无运费，网红分佣比例10%）

   平台佣金 5%（向日企收，基于售价¥150）= ¥7·6
   ├─ 其中网红 C 10%（日企自定比例，由商家毛利承担，平台代结算）= ¥15
   ├   ⚠️ 网红 ¥15 > 平台佣金 ¥7·6，平台需另行垫付差额
   ├   （促销期默认比例可后台调低，避免平台倒贴）
   ├─ 售后准备金（从平台佣金切份额，比例后台可调）
   └─ 平台净收 = 佣金 ¥7·6 − 网红 ¥15 − 准备金（动态）
   日企 B 实得 = ¥150 − 平台佣金 ¥7·6 = ¥142.5
   核验：7·6 + 142.5 = 150 ✓（平台另垫网红 ¥7·6）
🎫 联合开店 + 优惠码（优惠由日企承担，从售价让利）
日企售价 ¥150，日企让利 10% off：
   优惠 = ¥15（从日企售价出）→ 折后售价 ¥135，用户付 ¥135

   平台佣金 5%（基于折后售价¥135）= ¥6.75
   网红佣金（日企自定，折后售价¥135，10%）= ¥13.5（由平台支付）
   日企得 = ¥135 − ¥6.75 = ¥128.25
   平台总 = ¥6.75 − ¥13.5 = −¥6.75（垫付）
   核验：128.25 + 6.75 + 13.5 = 148.5 + 优惠 15 → 与 ¥135 + 平台垫付对齐 ✓

   关键：优惠 ¥15 由日企承担（售价让利）；网红费由平台支付（从平台佣金扣，不足垫付）
   护栏：网红费率可后台调，避免长期倒贴（默认 5%，可调 3-30%）
💡 联合开店佣金基数（已简化） 联合开店 = 日企自营，无 distributor 内部分账，佣金基数按日企自营处理：平台佣金基于日企售价（折后）收取，网红费按日企自定分佣比例由平台支付。所有比例后台动态可配。

⑦ 佣金确认时机（防退款追不回）

💳下单支付预估佣金 pending
›
📦订单完成+ 过 15 天退款窗口
›
✅确认佣金 available可提现
›
💰daily-payouts只打 available
金额安全红线：必须有退款窗口（如 15 天），否则佣金打早了、随后退款，钱追不回。退款触发 clawback 冲正。

✅ 决策台 · 已按 7·6 方案决策

各项已按 2026-07-06 老板最终方案勾选推荐项，可改选查看影响。底部汇总栏实时显示当前方案组合，可一键复制给研发。

① 核心模式 6 项 · 必须先定，影响研发范围

② 网红端 8 项 · 含 KYC，本期新增

③ 选品与佣金 6 项 · 核心商业逻辑

④ 常量配置 4 项 · 动态可配，仅默认值（后台随时调）

⑤ 默认规则 3 项 · 按推荐默认即可

⏸️ 不进决策台：现有平台逻辑（运费抽佣、手续费率 5% 见 ③公式）+ P1 待定（CPA 口径、ASP 去重）。决策台只放网红端新功能的开发前关卡。

如果老板坚持模式 B（完整联盟平台） 相比 P0，B 额外要做：完全自助入驻审核流、第三方市场连接器（TikTokShop/Amazon/乐天）、高级风控、联盟规则与公开注册页。入驻/选品库/KYC/自动分佣/数据看板 P0 已全部包含，不是 B 独有。P0 会明显变重，且冷启动风险仍在。
✅ 验收标准

P0 做完要达到什么效果

优惠码 / 短链

  • 可创建、停用优惠码；重复码报错
  • 结账输码可应用折扣并写归因
  • 过期/超上限/范围不符返回明确原因
  • 短链写点击记录、种 cookie、正确跳转
  • 供应商配 has_promotion 后网红才能生码；没配只能生短链
  • 多网红同商品：码独立（333/444），归因各自正确
  • 优惠从日企售价扣（日企让利），各方基于折后价分账
  • 网红费由平台支付（从平台佣金扣），日企不额外出资

归因 / 报表

  • 归因优先级正确，过期不归因
  • 退款触发 clawback（佣金冲正）
  • 单品短链正确种 cookie、跳转商品页
  • 报表可按来源/活动/渠道/时间筛选并导出
  • 结算明细可导出，可标记付款状态
决策进度 0 / 13