当 CEO、业务、增长和数据团队看到的不是同一套数时，先把"这套数能不能信"讲清楚。#
业务后台、归因平台、BI 三套 ROAS 对不上；实验做了但结论没人敢用；管理层一边要加预算，一边又在问"这个数到底能不能信"。
这类营销买量和实验平台的数据可信问题，按三步推进：
- 先做 5 分钟自检——营销买量用广告数据可信度快检，实验平台用实验能力自检。
- 提交结果，进入 1v1 诊断或团队工作坊——带着自检结果过一遍真实场景，判断痛点真伪、数据基础和切入顺序。
- 确认值得做，再谈诊断冲刺与平台共建——只读方式完成诊断，输出问题地图、优先级矩阵与分阶段建设建议。
适合正在扩张、投放加码、准备做实验 / Agent，或数据已经"谁都说服不了谁"的内容、电商、SaaS 与消费应用团队。
先做 5 分钟自检 ↓
查看服务与合作方式 →
不接管投放 · 不改生产环境 · 不替你的研发团队做工程交付 · 固定范围固定输出，不按人天堆量
你是否正在面对这些问题#
| 你正在经历的现象 | 深层问题 | 先做哪个自检 / 诊断会回答什么 |
|---|
| 业务后台、归因、BI 的 ROAS / ROI 长期对不上 | 指标口径与数据合同缺失，决策建立在争议数字上 | 广告数据快检先判数据可信度；诊断再定位哪几条预算决策链路的断点在哪、先对齐哪几个口径 |
| 新渠道 / 新市场扩张，历史经验无法判断哪些可复用 | 数据底座不支撑跨渠道归因和复用 | 哪些信号可信、哪些必须重新基线化、哪些投入应暂缓 |
| 有实验工具但实验量少、结果不被采用 | 流量分层、统计可信度、实验治理未进入业务流程 | 实验能力自检先定位需求 × 能力段位；诊断再给治理 SOP 缺口、从"有分流"到"可规模化实验"的路径 |
| 团队在试 AI Agent，却停留在聊天、报表、Demo | 数据权限、审计、回滚、目标函数不具备 | 哪些场景适合先做、哪些只是"看起来很美"、Agent PoC 的前置条件清单 |
| 融资 / 预算会 / 董事会前要把增长讲清楚 | 缺少一套能在管理层对齐的共同语言 | 一份可直接进立项会的问题地图、优先级和分阶段建设建议 |
30 秒内如果发现"这就是我团队的问题"，直接在下方做对应自检；想先看完整诊断范围，见 → 增长决策可信度诊断。
确认值得做之后：两周诊断冲刺交付什么#
自检和 1v1 确认问题真实、值得进场后，用两周、只读、固定范围完成一次增长决策可信度诊断：
| 时间 | 动作 | 产出 |
|---|
| 第 1–3 天 | 开工对齐、3–5 位关键角色访谈、只读数据 / 看板 / 文档收集 | 问题清单初稿、范围确认 |
| 第 4–7 天 | 数据与归因链路走查、实验与决策流程拆解、AI 前置条件评估 | 事实确认稿（客户确认后进入下一周） |
| 第 8–10 天 | 问题地图、影响假设与优先级矩阵、分阶段建设建议 | 诊断报告初稿 |
| 第 11–14 天 | 管理层对齐会、修订定稿、明确下一步责任人与节奏 | 终稿 + 一次 90 分钟对齐会 |
五样东西带走：决策可信度评分 · 问题地图 · 优先级矩阵 · 分阶段建设建议 · 一次管理层对齐会。
不是一份"PPT 报告"，而是一份可以在立项会上直接使用、关键角色已经对齐过的判断材料。时间线和里程碑在对齐会上按你的资源与节奏共同确定，不预设承诺。
真实锚点：从"有分流"到千级并发实验#
某出海数字业务团队，已有自研的实验分流能力，但缺少实验平台架构专家。通过共同引荐邀请我参与诊断与规划：
- 我负责：实验体系现状诊断、流量域 / 层 / 正交架构演进规划、关键设计评审、阶段性共建节奏与组织培训；
- 客户工程团队负责：平台代码实现、工程落地、上线与运维；
- 共同产出：实验并发从十位数走到千量级，排期从月级缩短到天级，产品 / 算法 / 商业化团队的实验不再互相污染。
项目结束后客户邀请全职加入，是对该阶段顾问价值最直接的确认。
→ 查看完整匿名案例（已脱敏，不出现公司名、行业细节与具体业务数字）
为什么是我#
我不是泛 AI 顾问，也不是单一实验或 BI 工具专家。差异化来自四条能力线在同一个人身上的交叉：
- 实验科学：流量分层、因果验证、指标治理、统计引擎——在快手期间参与过从互斥桶到重叠框架的真实升级；
- 营销数据平台：多源归因、指标语义层、ROI360、行为与内容数据模型；
- 增长方法论：渠道生命周期、批量运营、策略引擎（观察者视角）；
- 企业级 Agent 治理：Schema 居中、分级授权、可审计执行、独立验证与效果闭环。
经历过 IBM / TalkingData 的企业数据咨询、滴滴 / 快手的实验与数据产品、Shopee / SEA 的电商算法平台。完整背景见 关于展博。
第一步：5 分钟免费自检#
按你遇到的问题选一个入口，约 5 分钟、答完即时出结果；提交结果即可预约 1v1 诊断或团队工作坊。
| 你遇到的问题 | 自检工具 | 回答什么 |
|---|
| 营销买量：ROAS / ROI 对不上，不知道这个数能不能用来加预算 | 广告数据可信度快检 | 选方向、品类、渠道看 ROAS / CPI / CVR / 留存 / LTV 行业基线与趋势，输入后台 ROAS 立即拿到可信度判决 |
| 实验平台：实验做了但没人敢用、想建平台但不知从何入手 | 实验能力自检 | 15 道单选，定位你的「需求就绪度 × 能力段位 L1–L4」，给切入建议，附棋牌游戏大厂脱敏案例 |
营销买量 · 数据快检 →
实验平台 · 能力自检 →
查看全部工具 →
下一步：提交自检结果，预约 1v1 诊断 / 团队工作坊#
先在上方完成对应自检，也可以直接在下面留言。我会在 1 个工作日内回复，判断适合 1v1 诊断、团队工作坊，还是两周诊断冲刺。
增长不是一次灵感，也不是某个爆款素材、某个新渠道、某个产品改版带来的偶然结果。
真正可持续的增长，来自一套能够不断提出假设、验证假设、沉淀结论、再继续迭代的实验体系（贝叶斯方法）。
我想用一句话概括这个观点：实验即增长。 这也是展博增长实验室推出的产品（实验&增长咨询服务，面向内容、电商、应用等非游戏行业提供实验&增长的诊断、咨询、平台建设、业务陪跑等服务）。
尤其在面向全球市场的数字业务里，这句话更接近现实。因为数字业务面对的是高度不确定的市场：不同国家、不同文化、不同平台、不同获客环境、不同用户付费习惯，都可能让同一个产品表现出完全不同的增长曲线。
在这种环境下，企业不能只依赖经验判断，而要依赖实验。
一、为什么说“实验”是增长的基础？ 科学的基础不是“我觉得”，而是“可论证”。
从证据可信度来看，我们可以看到一个从低到高的金字塔：案例研究、观察研究、类实验、随机控制实验，以及更高层级的统合分析。
这些方法形式不同，但本质上都在回答同一个问题：
某个变化，是否真的带来了结果？
在商业增长里，这个问题尤其关键。
比如：
留存提升，是因为新手引导改得更好，还是因为这批用户质量本来更高？ ROI 提升，是因为素材策略有效，还是因为渠道算法短期波动？ 付费率提升，是因为礼包设计更合理，还是因为活动期间用户天然更愿意付费？ 如果没有实验体系，团队很容易把相关性误判为因果关系，把短期波动误判为方法论，把偶然成功误判为可复制能力。
所以，增长团队真正需要的不是更多“拍脑袋的优化建议”，而是一套持续验证因果关系的机制。
二、为什么增长离不开实验？ 增长是所有商业组织前进的动力。
但增长本身不是一个单点问题，而是一组连续问题：
如何让更多用户看到产品？ 如何让用户愿意下载或进入游戏？ 如何让用户留下来？ 如何让用户持续活跃？ 如何让用户付费？ 如何让 LTV 高于获客成本？ 这些问题之间相互关联，任何一个环节的改动，都可能影响整体增长效率。
在数字业务里，增长链路尤其长：从素材、广告、商店页、下载、首日体验、新手引导、核心循环、活动运营、付费设计，到广告变现和再营销，每一步都有优化空间。
这也是为什么我认为：
增长不是找到一个答案，而是建立一套不断找到答案的系统。
这个系统的核心，就是实验。
三、数字业务公司的四类典型实验场景 如果把数字业务公司的增长拆开看，实验至少会发生在四个关键场景里：用户体验、产品特性、买量与营销效率、商业化收益。
1. 用户体验实验：优化用户进入产品后的第一感受 用户体验实验关注的是：用户是否愿意继续玩下去。
常见实验包括：
新手引导流程调整 首局难度设计 UI 布局优化 任务系统节奏 奖励反馈强度 核心玩法教学方式 衡量指标通常包括：
使用时长 次日留存、七日留存 对局数 关卡完成率 GMV 或早期付费转化 用户流失节点 例如，一个产品可能会测试两种新手引导：一种是强引导，明确告诉用户每一步怎么操作；另一种是弱引导，让用户更快进入核心玩法。
表面上看，强引导更“清楚”；但实验结果可能显示，弱引导让用户更快获得乐趣，反而提升了留存。
这就是实验的价值：它能帮助团队摆脱主观偏好，回到用户真实行为。
2. 产品特性实验：探索产品该往哪里发展 产品特性实验关注的是：产品是否真正解决了用户需求。
常见实验包括：
新玩法模块 社交系统 排行榜 活动机制 关卡类型 道具系统 个性化内容推荐 这类实验不只是验证“功能有没有用”，更重要的是帮助团队判断产品方向。
...
作者：zhanbo · 2026-10-10
声明：本文为独立行业观察，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。文中举例以移动应用生态为主（手游是程序化广告最早成熟的战场，很多机制从那里发源）。
tl;dr AdTech 只解决一件事：把"合适的广告，在合适的时刻，卖给合适的用户"自动化，并让每一方知道这次展示值多少钱。 记住五个角色：广告主 → DSP → Exchange → SSP → 开发者；大媒体（Meta / Google / TikTok）自成体系绕开中间层；MMP 负责独立归因。 一次展示在 100 毫秒内完成实时竞价，平均要经过十几次出价请求、至少三个交易所。 归因正在经历隐私重构：设备 ID 失效 → 精准归因缺失 → 依赖聚合数据和机器学习 → 第一方数据价值上升、增量测量成为前沿。 自动化成熟度分 L1–L5，绝大多数团队卡在 L2–L3，瓶颈是数据口径而不是算法。 一、先看全局：钱和广告怎么流动 广告技术的全部复杂度，都来自一个简单事实：广告主想买的是"结果"（安装、注册、下单），开发者卖的是"展示"，两者之间需要一整套市场来撮合和计价。
广告主 / 代理商 │ 我要这类用户，愿为一次安装付 X 元 ▼ DSP（需求方平台）──── 帮广告主在全网流量里自动出价、找用户 │ ▼ Ad Exchange ──────── 实时拍卖市场，100ms 内撮合买卖 │ ▼ SSP（供给方平台）──── 帮开发者管理广告位、把展示卖出最高价 │ ▼ 开发者 / Publisher（App、网站） 五个角色，一次认清 角色 站在哪边 做什么 DSP 广告主侧 代表广告主在海量广告位上自动竞价、定向、控成本 SSP 开发者侧 接入多家买家，帮开发者把每次展示卖出最高价 Ad Exchange 中间市场 执行实时竞价（RTB）的交易所；很多公司同时扮演 SSP 和 Exchange Ad Network / Mediation 聚合层 聚合多家流量或多家买家，给中小广告主 / 开发者一个统一入口 MMP（移动测量伙伴） 独立第三方 做安装归因、事件追踪、反欺诈——广告链路里的"裁判" 必须单独理解的是大媒体（Walled Garden，围墙花园）：Meta、Google、TikTok 同时拥有流量、广告系统和一方用户数据，广告主直接在其后台投放，归因也由平台自行回传（这类平台叫 SAN，Self-Attributing Network），基本绕开了 DSP–Exchange–SSP 这条公开市场。所以行业里实际存在两套并行体系：大媒体的封闭体系 和 开放互联网的程序化体系。
...
作者：zhanbo · 2026-10-10
声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 证据有等级：案例 → 观察 → 准实验 → 随机实验（AB）→ 系统综述，可信度逐层升高，成本也逐层升高。按决策的赌注大小选证据等级，而不是事事都开 AB。 大模型没有推翻金字塔，而是横切出两条线：Offline（Eval + 模拟，不占真实流量）产假设、筛候选；Online（AB，占真实流量）做因果裁决。 Eval 的本质只有两个动作：题库 + 专家标注。LLM-as-judge、模拟器都只是这两个动作的规模化替身，必须经人工校准。 标准发布链：离线 Eval 筛选 → 护栏评测 → 小流量 → 在线 AB 裁决 → 放量，trace 持续回流。 新地基是语义层 + Trace 仓库：一处定义口径，BI、Agent、Eval 三处消费。 一、证据金字塔：先分清"这个结论有多不可能是假的" 证据金字塔来自循证医学，衡量的是内部有效性——这个"有效"的结论有多可信。
L4 系统综述 / 知识收敛 ← 跨研究合并，等级最高 L3 随机对照实验（AB / RCT） ← 随机化消除混杂，因果识别最强 L2 准实验（DID/合成控制/Geo holdout…） L1 观察性研究（报表/相关/监控） L0 专家判断 / 单个案例 / 直觉 ← 最快、最便宜、最易偏 对业务团队，真正有用的不是记住五层名字，而是一条决策纪律：
...
作者：zhanbo · 2026-10-10
声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 数据产品本质上只解决五类课题：描述（发生了什么）、分析（差异是什么）、诊断（为什么）、预测（会怎样）、探索（还有什么机会）。核心命题永远是支撑业务结果，而不是交付数据本身——数据是中间品。
下面五个场景，是数据团队在不同公司反复遇到的真实战场：
场景 一句话症状 1. 被免费取数耗干 个个是 SQL 高手，却在无穷临时取数中疲于奔命 2. 业务不信实验 平台建了不用、用了读不懂、信了只信想要的结果 3. 投放三源对不齐 媒体 / 归因 / 数仓三份账，同一个 ROI 差 5–15% 4. 变现分析落不了地 做了很多分析，业务却说"这是你们自己想做的课题" 5. Data Agent 僵尸化 demo 惊艳、上线没人用 场景 1：被"免费取数"耗干的数据团队 结构性根因（为什么最佳实践落不了地） 要数是免费的：提需求的人不付成本，成本全落在数据团队，免费的东西不会被省着用。 成本收益不同体：用出成绩归业务，数据出问题找数据——这是数据团队天然弱势的根源。 改善工作没有催办人：临时需求有提出人、有 deadline，治理和自动化没有，于是永远被推后。 各方都在做"理性选择"（业务多提、管理层不投入、负责人硬扛），系统却走到最坏结果。 破解序列 先挤出一块时间：记录两周工作负载（部门 / 类型 / 耗时 / 是否重复 / 是否有人看），把"忙"翻译成组织的"损失"——“62% 工时在临时取数，三分之一是重复提取，预警模型已延期六周”。向领导要一个"改善特区"（如每周五下午不接新需求）。 建秩序但别引发地震：统一需求入口（话术是"为了更准更快"），公开队列；插队时把"做不做"换成"先做哪个"，取舍交还提需求部门或有统筹权的人。 推自助用拉力不用推力：选数据意识强的部门，先替代一个边界清楚的高频取数，手把手教，培养"数据大使"。 让成本被看见：不搞内部收费，改发"信息账单"（需求数、工时、重复需求、无人查看需求），后跟选择题——合并哪些、停掉哪些、省出时间做什么。让超载以延期形式出现，而不是以加班形式消失。 AI 判断：Data Agent 把写 SQL 的成本打到接近零，但取数真正耗时的是对口径、澄清需求、核数据——AI 替不了，反而让需求更"免费"。上 AI 前先把口径说清楚。
...
作者：zhanbo · 2026-10-10
声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 做什么：让业务人员用自然语言完成问数、异常诊断、监控与决策建议。首期只落地一个专业域（如 ROI 异常诊断），不做"全公司什么都能问"的超级 Agent。 为什么是现在：临时取数淹没数据团队、问题到决策链路长、口径各执一词；而主流厂商路线已全部收敛到"语义层 + Agent + 行动"，开源组合已足以支撑 PoC。 成功标准不是"能回答很多问题"，而是在目标场景里业务人员少找一轮分析师：一次解决率、诊断耗时、建议采纳率与可量化的业务结果。 首期严格只读：不自动改预算、不调生产写 API，建议必须人工确认。 权限、行列级安全、审计第一天内置，不能上线后补。 一、为什么大多数 Data Agent 会失败 三个常被数据验证的事实：
对 4,602 条错误 SQL 的分析显示，81.2% 的错误发生在 schema / 语义层，语法错误只占 18.8%（arXiv 2501.09310）。 企业真实查询在没有语义层时准确率仅 10–31%，补齐 context stack 后可达 94–99%。 MIT NANDA 研究：95% 的 GenAI pilot 拿不到可衡量的损益影响，根因是没有嵌入业务流程，而不是模型差；LinkedIn SQL Bot 嵌入现有工具后，采用率比独立聊天框高 5–10 倍。 结论很直接：瓶颈在数据与语义、在运营，不在模型。 只采购一个模型、做一个聊天 UI，几乎注定得到"demo 惊艳、上线僵尸"。
二、六件事，而不是一个聊天框 Data Agent 的产品边界覆盖六件事，聊天 UI 只是最表层：
[1] 入口层 Chat / BI / IM / 内嵌面板 —— 入口必须在现有工作流里 [2] Agent 运行时 意图 → 计划 → 工具调用 → 检查 → 解释 → 建议 [3] 语义/上下文层 指标 / 实体 / 维度 / join / 同义词 / 规则案例 [4] 工具层 metric_query / 新鲜度 / 异常检测 / 贡献拆解 … [5] 治理层 RBAC / 行列级安全 / 审批 / 审计 / 限流 [6] 评测与证据层 trace / 引用 / 黄金问题 / 用户反馈 / 业务结果 └──→ 失败聚类 → 修复语义 → 离线评测 → 发布门禁 → 再发布 三条关键架构原则：
...
平台们宁愿共同供养一个中立的裁判，也不投一个又当裁判又下场的玩家。
作者：zhanbo · 2026-09-18
声明：本文为独立行业观察 / 独立技术实践，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 2026-06，AppsFlyer 官宣拿到 Google / Meta / Unity / Moloco 四家超 $1B 联合投资（少数、非控制、非排他），投后估值约 $2.7B（以色列媒体称实际 $1.3B、近半是老股转让），ARR 约 $500M、盈利。四家都是它日常测量的广告平台——被测量对象集体出资，保它"中立"。 名单里没有 AppLovin。不是漏了：AppLovin 2021 年收购了 Adjust（行业第二大归因平台），自己又跑 AXON 买量引擎——既当裁判又下场踢球。平台不会投一个会跟自己抢媒体生意的玩家。这条分界线，是这笔交易最该被读出来的信号。 它的产品线已从归因工具长成 “Modern Marketing Cloud”：成本收入聚合 → 增量测量（Incrementality for UA）→ 跨端 LTV → Signal Hub clean room → Agentic AI Suite（官方自称 “a marketing execution layer”，带 MCP，可接 Claude / ChatGPT / Cursor）。它正沿"归因 → 决策 / 编排层"往上爬。 那它会不会吃掉 The Trade Desk？ 我的判断：不会变成 trade desk，移动 app 预算大头在自归因平台手里、不在 TTD；它会吃掉的是预算往哪分这层决策，以及代投 / 手动优化的工位。前提是守住"不下场买媒体"——这正是它和 AppLovin（Adjust）的根本分叉。 一、被测量对象集体出资，保一个中立裁判 表面看这是一笔大额融资，读起来要倒过来看：出资的四家，全都是 AppsFlyer 每天在测量的广告平台。
...
AdX 案划的是拍卖规则，不是你的数据产权。
作者：zhanbo · 2026-09-17
声明：本文为独立行业观察 / 独立技术实践，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 9 月 16 日 Google AdX 案的 106 页意见全文解封：法院拒绝拆分，只划拍卖规则——first look、last look 禁止，出价要对竞品服务器同条款开放，外加 6 年技术监督。但 Google 的数据、模型、买侧需求，一条都没要求拿出来平分。 in-app 市场更黑：拍卖发生在 mediation SDK 的二进制内部，没有 Prebid 这样的中立观测点；AppLovin 官方文档直接写明 IAA / Blended ROAS campaign 必须接 MAX 才能跑，变现侧的用户价值信号官方自认回流给 Axon。 法院能做的到此为止。广告主和流量主真正能做的不是换平台，是平台离不开，但产权属于自己的数据和预算裁量权要拿回自己手里——能力可以租，裁判不能租。 一、法院管得了拍卖规则，管不了你的数据 9 月 2 日弗吉尼亚联邦法院对 Google 广告技术案作出救济裁决，9 月 16 日密封意见全文解封。结论很多人误读成「Google 被平权了」。没有。被禁止的是三个具体动作：first look（对手出价前先看库存）、last look（看了对手最高价再反超一美分）、统一底价。被要求的是互操作：AdX 给竞品广告服务器的出价要 same terms、functionally equivalent，还要接入 Prebid。
注意没被碰的部分：Google 的买侧数据、出价模型、独家需求，一个字都没要求开放。防火墙只管住 Google Ads，DV360 整体豁免。规则平权不等于数据平权。
...
控制面正在移到客户手里，数据重力没有。
作者：zhanbo · 2026-09-16
声明：本文为独立行业观察 / 独立技术实践，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 2026 年春夏，Statsig、Optimizely、PostHog 在三个月里做了同一件事：把实验审批、flag 变更、SDK 接入全部搬出后台界面，交给 API、MCP 和开放标准。SaaS 的「头」——那个你每天登录点按钮的界面——正在变成可选项。 按钮到了你手里，数据还锁在它库里。界面可以搬走，数据重力搬不走，无头化没解决数据主权，反而把接入口子开得更多。 大客户能把控制面收进自己的 CI 和 agent；中小企业的「自建界面」大概率是换了个房东。文末三问，测你属于哪一边。 一、三家在三个月里做了同一件事 先看三组公开的产品动作，都发生在 2026 年。
4 月 28 日，Optimizely 上线 Change approvals：flag 的规则变更、人群调整、流量分配，可以强制走指定审批人，没审过的变更进不了生产。第二天，它发布 Experimentation MCP server，agent 可以直接查实验、建 flag、生成 SDK 代码，支持 Claude、Cursor、Copilot 一批客户端。
7 月 7 日，Statsig 把完整的实验评审生命周期搬进 Console API 和自家 MCP：八个新 API 端点、九个新 MCP 工具，覆盖发起评审、批准、驳回、提交全流程；同一条更新列表里还有 Audit Overrides，一个 API 调用就能审计全项目的 override。
PostHog 走的是另一条路：官方发布 OpenFeature 的 web provider 和 Python provider，应用代码只认 OpenFeature 标准接口，底下接 PostHog 还是别的 flag 引擎，可以换。
...
平台用 AI 优化匹配，用 Agent 提升你在它后台里的操作效率——但这些智能都长在平台的墙里面。跨出墙头，你得有自己的一层。
作者：zhanbo · 2026-09-09
声明：本文为独立行业观察 / 独立技术实践，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr 广告平台的 AI 投入方向一直很清楚：对内，用 AI 优化广告匹配——决定谁看到这条广告；对外，用 Agent 提升广告主在自家后台内的操作效率。这两件事平台都会越做越好，但它们有一个共同边界：只在自家平台的墙内生效，且优化目标天然对齐平台自己的收入。 广告主的真实战场却是跨平台、多渠道的。一个账户同时开着几家媒体，每一家都有自己的"智能投放"，每一家的智能都只对自己平台的钱包负责。于是广告主侧必然要长出自己的一层：聚合投放（一个入口管所有平台的动作和数据）→ 独立归因（跨平台的账算得清）→ 投放策略管理（预算怎么分、何时止损放量，规则在自己手里）→ 智能投放 Agent（这一层自己会感知、提议、执行、学习）。 这不是"要不要做"的选择题，是分工演化的结果：平台越智能，广告主越需要一个跨平台、对齐自己生意目标、且自己可控的智能层。 这套系统从第一天起就按真实广告账户设计、在真实投放中迭代。构建过程中最核心的结论是：它的护城河不在模型，也不在连接器，在"信任结构"——跨平台数据归一、写动作分级审批、动作结果延迟回采、策略只学真实样本。少一样，广告主就不敢把账户交出来，Agent 也学不到真东西。 本文按业务需求 → 痛点 → 概念模型 → 技术架构 → 实现的顺序完整展开，包含十几个具体的工程取舍和理由。适合正在设计或评估"AI + 投放"系统的人收藏慢看。 一、业务需求：平台的智能，和广告主的智能，不是同一种智能 先把一个常见的误会拆掉。
很多人觉得，广告平台已经这么智能了——全托管 campaign、自动出价、自动扩量、自动生成素材——广告主再建一套"智能投放"是不是重复造轮子？
不是。因为平台的 AI 从来只服务两件事：
对内，优化广告匹配：决定哪条广告展示给哪个人。这是平台收入引擎的核心，eCPM 竞价、点击率/转化率预估、探索与利用机制，全部围绕"平台生态的长期变现效率"设计。 对外，提升广告主在自家后台内的操作效率：自动托管、智能建议、对话式助手、官方 MCP 接口——让你在它的体系里花钱花得更顺、更快、更少摩擦。 注意边界：这两件事都只在单个平台的墙内生效，而且优化目标函数天然对齐平台自己的收入，不是广告主的利润。广告主面对的真实战场是另一个形状：
一个账户同时开着几家媒体，每家都有自己的一套"智能投放"，黑盒程度不一，建议互相矛盾； 预算总量是有限的，真正的决策不是"在 A 平台里怎么投"，而是"这一万元分给 A、B、C 各多少、什么节奏、按什么信号再平衡"； 平台报表里的转化是平台口径，跨平台去重、真实增量、回收周期，平台不会替你算——它们既没有动力，也没有彼此的数据； 投放经验（什么品类什么阶段用什么打法、什么信号可信、什么时候该逆着平台建议操作）散落在投手的脑子里和历史账户里，人一走就带走。 所以广告主侧必然要长出自己的一层。这不是"要不要做"的选择题，是分工演化推出来的，按依赖关系是四级台阶：
聚合投放：一个入口统一管理跨平台的计划、预算、出价、素材和报表，动作和数据先归一，结束"十个后台十套数"的状态； 独立归因与度量：跨平台账算得清——哪个渠道带来的是增量而不是平台自报的转化，LTV 回收按什么口径，这是后面一切策略的事实基础； 投放策略管理：预算分配规则、止损/放量阈值、素材轮换规则、平台建议的采信边界——把投手经验固化成可审计、可迭代、可复用的资产，而不是聊天记录里的手感； 智能投放 Agent：在以上三层之上，系统自己 7×24 感知异动、提出方案、在授权边界内执行、用真实结果复盘并改进策略。 顺序不能反。没有聚合，Agent 只能一个平台一个平台地当外挂；没有独立度量，Agent 学到的全是平台喂给它的自我评价；没有策略管理层，Agent 的每次决策都是一次性的，组织没有积累。Agent 是这层的最终形态，不是起点。
...
副标题：从 RCT 到 s-RCT：把实验从「省着跑」变成「跑得值」
作者：zhanbo · 2026-08-21
声明：本文为独立行业观察，基于公开资料整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr（3 条） 每个实验都有流量和时间成本，但是实验成功率却越来越低——s-RCT 用 AI agent 先模拟、先筛，把流量省给值得的实验。 Amazon 论文的实证：agent 模拟的原始方向信号偏弱（符号重合 0.70 没明显超过无信息基线），校准后才把误差降 77×——能筛，不能定。 实验效率的第一步不是换工具，是检查你的漏斗：历史实验库有没有、AI 会不会泛化假设、拟合指标建没建（回复「实验效率」拿诊断）。 一、开题：AI 能替我跑实验吗 「AI 能替我跑实验吗？」
增长团队最近被问得最多的，就是这个问题。
问的人手里通常攒着一叠实验报告：有的没跑完就被砍，有的跑完了结论是「无显著差异」。真正变成决策的，一个季度下来数得过来。
不是团队不努力。是实验这件事本身在变贵——每个实验都要真实流量、要排期、要工程师陪跑，而这些成本，一半花在了注定没结论的实验上。
另一面，想法的供给在爆炸。以前一周想三个实验，现在 AI 一天能给你三十个。流量和工期没变，候选池却大了十倍，实验成功率自然被稀释。这不是哪家公司的管理问题，是整个行业的漏斗问题。
二、从 RCT 到 s-RCT：效率的漏斗 实验效率的瓶颈，已经从「能不能跑」变成了「值不值得跑」。
过去十年，我们把 RCT 当作金标准：随机分组、真实流量、统计显著，一切都对。但金标准的前提是流量够、工期够、候选少。当候选变多、流量变贵，金标准就变成了奢侈品——不是不该用，是没那么多预算给每个想法都用一遍。
s-RCT（Simulated RCT，模拟随机对照试验）就是冲这个错配来的。Amazon 的两位研究者（Stefan Hut、Lorenzo Masoero，8/13 更新论文）提出：让 AI agent 拿着用户的「行为画像」和「干预描述」，在投入真实流量之前，先模拟一遍 A/B 结果，把明显没戏的候选筛掉。
把流程拆成四段：
历史实验库沉淀 → AI 泛化出假设 → AI 收敛掉弱候选 → 高价值的进真实 A/B 前两段是「库」和「生成」：历史实验库沉淀每次实验的结论，AI 从里面学模式、批量泛化出新假设。第三段是 s-RCT 的主场：agent 模拟结果，做候选的收敛和排序。第四段，只有排在前面的高价值候选，才拿到真实流量跑 RCT。
...