NexaAI 网红推广归因与结算

🎯 方案定位

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

在自有 BTOC（面向消费者的商城）上搭一套「网红有店铺、商品可追踪、订单可归因、佣金可结算」的推广底座。网红只推广 BTOC 可售池商品；借壳 BTOC 试点商品可进入推广，加价 BTOB 商品不进入网红推广。

🌟 本模块在 7·1 平台新蓝图中的定位 网红推广 = 平台的 C 端增长飞轮（BTOC 消费者层），推广已发布到 BTOC 的商品销售，按推广码 / 末次点击归因、按商品 / 订单维度计佣。它与「推荐人招商」（B 端飞轮，拉企业入驻、按企业维度归因）和「BTOB 大 B 商品海报」（分拨销售工具，连接下游小 B）复用部分分账与链接底座，但业务归因独立、互不干扰——产品上不要把三者混成一个「推广系统」。
✅ 好消息：后端底座已落地（9 张数据表 + 归因引擎 + 状态机 + 分佣公式 + 结算 + 打款），作为 BTOC 带货飞轮，补全前端（网红工作台 / BTOC 商家选品 opt-in / admin）即可。

📌 2026-07-01 推广边界 H2B 商城是封闭采购商商城，H2B 采购商审核通过后才可查看；H2B 商品上架需要管理员审核，BTOC 非 H2B 源头商品上架也需要管理员审核。商家主体统一，但 BTOB / BTOC 渠道资格分开审核；自助 BTOC 商家必须先通过 BTOC 渠道资格审核，才能发布 BTOC 商品并进入网红选品池；同一企业如果也申请 BTOB 资格，仍按独立渠道资格审核，不代表 BTOB 商品可以进入 BTOC。网红必须拥有店铺；网红只能推广 BTOC 可售池商品。H2B 借壳模式只开放 BTOC，且先由 2 家自控企业试点，试点商品可进入网红推广；H2B 加价模式只开放 BTOB，商品只能上架 BTOB，不进入 BTOC 选品库和网红推广。一个商品销售版本只能绑定一个目标销售渠道；同一实物产品如果同时做 BTOB 与 BTOC，必须复制/派生成两个独立销售版本。网红店铺支持商品二维码、店铺二维码、短链和优惠码；这些销售二维码不等于推荐人招商二维码，也不替代 BTOB 大 B 的商品/店铺二维码。

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

🖥️ 界面范围

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

⚙️ 后台（运营用）

网红管理：列表、审核、启用/关闭、短链点击数据
产品-网红关联：哪个产品被哪些网红推（产品视角）
优惠码：查看、停用（创建由网红端做）
短链：查看、停用（生成由网红端做）
来源报表：点击/订单/GMV（成交总额）/退款/ROI（只读查看）

💰 理念：钱全由 Stripe 自动管，后台不做人工审核 分佣、打款、退款冲正都程序化自动跑（复用 Stripe + 联合开店）。后台只做「管网红 + 看报表 + 停用码链」，不需要结算对账、异常队列、审计日志这些人工维护操作。

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

订单详情：🌐 推广标识 + 推广网红 + 佣金扣除（平台抽成 + 网红佣金）+ 商家可得金额
产品推广数据：被哪些网红推 + 点击/转化/订单/GMV
佣金支出：每个产品已付网红佣金总额
佣金率设置：按品设佣金（方案 A opt-in 时）
实时算账：改价/设佣金时实时显示净收益 + 平台扣 + 网红扣，护栏防赔

为什么必须做实际 BTOC 卖方是出佣金的一方，必须看到「钱花在哪、效果如何、实得多少」——这是 Amazon Seller Central 等的标配，否则商家无法对账。普通直营商品看供应商，联合开店商品看 distributor。

🛒 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 → 网红
分账	基于折后价，平台/网红/供应商（或 distributor）按规则分
自动打款	复用 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 商品销售版本，不取 BTOB 商品，也不取未通过 BTOC 渠道资格审核的商家商品。

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

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

🔗 商品源头对齐 7·1 新蓝图：H2B 联合开店后发布到 BTOC 新蓝图下，智能商品先在 H2B 完成供货方 / 日方采购方撮合，并通过国际化门禁（海外联网 / AI 模型可用 / 界面多语言 / 出口合规 / 本地化资料）。双方达成联合开店后，商品可按发布时绑定的 sales_channel_ids 展示到 BTOB 或 BTOC。网红选品库只取已经发布到 BTOC 的商品，不直接从 H2B 原始供货池拉货；下方「全量自动 / 商家 opt-in」两种方案都建立在「商品已进入 BTOC 可售池」之上。

方案 A · 商家 opt-in

BTOC 商家勾选商品 + 按品设佣金

实际 BTOC 卖方在对应商家后台勾选哪些商品可推广、每个商品设佣金率。普通直营商品由供应商配置；联合开店商品由日方零售方 / distributor 配置。

✅ 实际卖方自主、佣金按品灵活
⚠️ 要开发 BTOC 商家端界面（推广管理页）
⚠️ 冷启动商家未必主动勾选

方案 B · 全量自动（更轻）

BTOC 商品全进库 + 平台统一佣金

所有上架 BTOC 的商品自动进选品库，平台统一定佣金率（如 5%/3%）。

✅ 简单、不需要商家端界面
✅ 网红选品多、冷启动快
⚠️ 实际卖方没自主权、佣金不灵活
⚠️ 佣金承担方需明确（入驻 B2C 默认同意？）

关键权衡：要不要开发 BTOC 商家端界面？ 方案 A 要（商家后台加「网红推广管理」页：勾选商品 + 设佣金），方案 B 不要。推荐方案 A（尊重实际 BTOC 卖方、跟 fund 决策「佣金由实际卖方承担」一致），但方案 B 更轻——由老板拍板，见决策台 #15。

商品扩展字段（两方案通用）：allow_affiliate（是否允许推广）+ affiliate_commission_rate（佣金率）+ has_promotion（是否配置优惠规则，决定能否生优惠码）+ promotion_rule_id（关联实际卖方优惠规则模板）+ affiliate_owner_id（佣金承担方：供应商 / distributor）。

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

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

优惠码的关联关系 网红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→注册登录→跳回 A	cookie 不受登录影响，仍归因 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·1 口径示例） 网红美月在 BTOC 带货「Lumina Pro 美容仪」，买家付 ¥58000：

网红美月 佣金 10%  = ¥5800   （由卖方樱花堂出）
平台佣金 5%    = ¥2900   （含支付通道费）
樱花堂(卖方)实得 = ¥49300   （¥58000 − ¥5800 − ¥2900）
核验：5800 + 2900 + 49300 = 58000 ✓

护栏：平台只抽 5%、永不倒贴；佣金由「实际卖方」承担；联合开店场景下卖方 = distributor（经销商），再与源头供应商二次分（见 ⑤⑥）。全程复用底座，0 新支付链路开发。

⚠️ 借壳 BTOC 试点推广责任 7·1 新版明确：借壳模式只开放 BTOC，先由 2 家自控企业试点；加价模式只开放 BTOB，不进入 BTOC 选品库和网红推广。
① 借壳 BTOC 试点——中国供方借日方资质开零售店、自己定价经营，实际营销受益方是中国供方；网红佣金和优惠成本建议由中国供方承担，但需通过日方店铺订单链路代扣/结算，资金通路要在结算规则里单列。
② 加价 BTOB——日方大 B 面向下游小 B 分拨销售，商品只上架 BTOB；商品海报、采购汇总、代下单和后续接口集成都属于 BTOB 分拨链路，不进入网红佣金链路。
边界：本模块只处理 BTOC 可售商品和借壳 BTOC 试点商品的零售推广；BTOB 大 B 对下游小 B 的商品海报、采购汇总、代下单不进入网红佣金链路。

⑤ ⭐ 联合开店镜像商品：四方分账（多一层 distributor（经销商））

联合开店比普通场景多一个 distributor（经销商）：它把供应商商品「镜像」到自己店铺加价卖。所以分账多一层，订单还要「分单」。

🏭源头供应商供货·源头价

›

🤝distributor（经销商）镜像加价卖

›

🎙️网红推广单品短链

›

🛒消费者下单付镜像售价

›

🔀分单 + 四方分账见下例

「分单」是什么：一个消费者订单，后台拆成两个关联单 —— distributor（经销商）的零售单 + 源头供应商的供货单（distributor（经销商）向供应商采购）。资金也按四方拆。这里仅指 BTOC 联合开店零售场景；BTOB 大 B 发给下游小 B 的商品海报、采购意向收集、代下单属于分拨采购链路，不进入网红推广归因。

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

📌 场景设定

源头供应商 A（H2B）：生产垫片，源头价 ¥100（给 distributor（经销商）的出货价）
distributor B（联合开店经销商）：镜像 A 的垫片，加价 ¥50 → 镜像售价 ¥150
网红 C：推广该垫片（佣金率 10%）
消费者：通过网红单品短链下单，付 ¥150（折后实付，不含运费）

💰 ¥150 四方分账（平台费两边扣 + 网红由 distributor 出）

消费者付 ¥150（结算价¥100，售价¥150，毛利¥50，无运费，网红distributor自定10%）

   平台 fulfillment 5%（从A，基于结算价¥100）= ¥5
   平台 display 5%（从B，基于毛利¥50）       = ¥2.5
   ├─ 平台共收 ¥7.5（两边扣：A出¥5 + B出¥2.5）
   ├─ 网红 C 10%（distributor 自定，从B）    = ¥15
   ├─ 源头供应商 A 收 = ¥95   （结算价¥100 − fulfillment¥5）
   └─ distributor B 收 = ¥32.5 （售价¥150 − 结算价¥100 − display¥2.5 − 网红¥15）
                              └ 毛利¥50 − display¥2.5 − 网红¥15 = 净¥32.5 ✅不赔
   核验：7.5 + 15 + 95 + 32.5 = 150 ✓

🎫 联合开店 + 优惠码（优惠由 distributor 承担，从差价出）

镜像售价 ¥150（结算价¥100，毛利¥50），distributor 让利 10% off：
   优惠 = ¥15（从 distributor 毛利出）→ 折后售价 ¥135，用户付 ¥135

   平台 fulfillment 5%（从供应商，结算价¥100）= ¥5
   供应商得 = ¥95（结算价固定，不让利）
   distributor 毛利（折后）= ¥135 − ¥100 = ¥35（原¥50 − 优惠¥15）
   平台 display 5%（基于毛利¥35）= ¥1.75
   网红佣金（distributor 自定，折后售价¥135）= ¥13.5
   distributor 得 = ¥35 − ¥1.75 − ¥13.5 = ¥19.75
   平台总 = ¥6.75
   核验：95 + 19.75 + 6.75 + 13.5 = 135 ✓

   关键：优惠 ¥15 由 distributor 承担（差价让利），供应商照收结算价
   护栏：优惠 + 佣金 ≤ distributor 毛利（防赔，跟 #19 同机制）

⚠️ 联合开店佣金承担方（必须确认） 普通直营场景佣金由供应商承担；但联合开店里「实际 BTOC 零售卖方」是 distributor（经销商），源头供应商只按源头价 / 结算价供货。建议联合开店的网红佣金由 distributor（经销商）承担（distributor 是加价受益方）。见决策 #17。

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

💳下单支付预估佣金 pending

›

📦订单完成+ 过 15 天退款窗口

›

✅确认佣金 available可提现

›

💰daily-payouts只打 available

金额安全红线：必须有退款窗口（如 15 天），否则佣金打早了、随后退款，钱追不回。退款触发 clawback 冲正。

✅ 决策台 · 开会现场勾选

逐项确认方案。每项默认已勾选推荐项，不同意可直接改选。底部汇总栏实时显示当前方案组合，可一键复制给研发。

① 核心模式 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），归因各自正确
优惠从卖方扣（供应商/distributor），各方基于折后价分账
联合开店优惠 distributor 承担，护栏（优惠+佣金≤毛利）防赔

归因 / 报表

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

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

分三期推进，本期只做 P0

可追踪底座

放量与合规

自营联盟

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

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

运营直签 + 轻量工作台

自建联盟（自助入驻）

三条主链路怎么跑

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

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

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

P0 要做哪些功能

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

⚙️ 后台（运营用）

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

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

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

🎙️ 网红端 /admin

🏪 供应商端 vendor-panel

⚙️ 运营管理端 admin

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

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

先理清：三个角色别混淆

网红状态机 & 权限分层

Stripe 提现绑定流程

P0 核心闭环：单品推广链

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

🛍️ 选品库

📊 数据看板

💰 我的佣金

⚙️ 账户设置

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

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

BTOC 商家勾选商品 + 按品设佣金

BTOC 商品全进库 + 平台统一佣金

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

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

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

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

⑤ ⭐ 联合开店镜像商品：四方分账（多一层 distributor（经销商））

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

📌 场景设定

💰 ¥150 四方分账（平台费两边扣 + 网红由 distributor 出）

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

✅ 决策台 · 开会现场勾选

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

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

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

④ 常量配置 4 项 · 开发前必定的数值

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

P0 做完要达到什么效果

优惠码 / 短链

归因 / 报表

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