独立增长咨询 · 出海休闲游戏 / 出海应用 / DTC
增长决策可信度诊断
业务后台、归因平台、BI 三套 ROAS 对不上；实验做了，结论没人敢用。先花 5 分钟自检，拿到可信度判决，再决定要不要请外部顾问。
前滴滴 / 快手 / 迦游 · 实验与发行营销平台 · 只读诊断按小时
为什么内部觉得「还能扛」，却仍需要外部顾问#
业务还在增长时，每个团队都在本位把任务做完——投放有人盯、报表有人出、实验有人开。但管理层一边要加预算，一边在问"这个数到底能不能信"，卡住的往往是另一层：站在本位里，很难看见「能力–责任–结果」上的缝隙——哪些最佳实践其实可以外包给有真战绩的人；哪一段阶段责任没人认领；项目结束后方法会不会留在组织里。
缺的不是再多一张表，而是有人能对外包能力、阶段责任和可留下的结果说清楚。外部独立顾问的价值，就钉在这三边上：
| 顾问带来什么 |
|---|
| 能力 | 行业最佳实践、数据理解、平台建设方法——可外包给有可核对战绩的人，不是泛泛讲课 |
| 责任 | 阶段范围内可约定谁认领：诊断范围、里程碑验收、对齐会结论——不是「只出主意、不扛责」 |
| 结果 | 交付物无条件归属客户方：问题地图 / 口径 / 标准 / 共建方法沉淀在组织内——不是顾问带走就断 |
和「找一家服务商」怎么分。 服务商更适合规模化执行（代投、整包、人月扩编）；独立顾问更适合 1→10 / 10→100 时的判断、口径与阶段责任外包，协调成本通常更低。服务方式与适用边界见 服务页。展博落在独立顾问侧：不做代投，也不做人月外包。
下面先对号入座常见痛点；对上了，用自检漏斗往下走即可。
你是否正在面对这些问题#
| 你正在经历的现象 | 深层问题 | 先做哪个自检 / 诊断会回答什么 |
|---|
| 业务后台、归因、BI 的 ROAS / ROI 长期对不上 | 指标口径与数据合同缺失，决策建立在争议数字上 | 广告数据快检先判数据可信度；诊断再定位哪几条预算决策链路的断点在哪、先对齐哪几个口径 |
| 新渠道 / 新市场扩张，历史经验无法判断哪些可复用 | 数据底座不支撑跨渠道归因和复用 | 哪些信号可信、哪些必须重新基线化、哪些投入应暂缓 |
| 有实验工具但实验量少、结果不被采用 | 流量分层、统计可信度、实验治理未进入业务流程 | 实验能力自检先定位需求 × 能力现状；诊断再给治理 SOP 缺口、从"有分流"到"可规模化实验"的路径 |
| 团队在试 AI Agent，却停留在聊天、报表、Demo | 数据权限、审计、回滚、目标函数不具备 | 哪些场景适合先做、哪些只是"看起来很美"、Agent PoC 的前置条件清单 |
| 融资 / 预算会 / 董事会前要把增长讲清楚 | 缺少一套能在管理层对齐的共同语言 | 一份可直接进立项会的问题地图、优先级和分阶段建设建议 |
30 秒内如果发现"这就是我团队的问题"，直接回顶部做对应自检；想先看完整诊断范围，见 → 增长决策可信度诊断。
确认值得做之后：按小时诊断，交付什么#
自检和免费适配沟通确认问题真实后，按 ¥1,000／小时 做只读诊断：
| 深度（示例小时区间） | 你带走什么 | 双方大致投入 |
|---|
| 澄清（约 2–4h） | 一页断点清单 + 是否值得继续 | 1 次短会 + 少量只读截图 |
| 标准（约 8–16h） | 评分卡 · 问题地图 · 优先级矩阵 | 2–3 人访谈 + 看板只读 |
| 完整（约 20–40h） | 上列 + 90 天建议 · 管理层对齐纪要 · 完成证明 | 关键人访谈 + 一次对齐会 |
不是一份"PPT 报告"，而是可以进立项会、关键角色已对齐过的判断材料。适配沟通时书面确认覆盖主题与投入区间后开工。详见 服务与合作 / 诊断专页。
真实锚点：从"有分流"到千级并发实验#
某出海数字业务团队，已有自研的实验分流能力，但缺少实验平台架构专家。通过共同引荐邀请我参与诊断与规划：
- 我负责：实验体系现状诊断、流量域 / 层 / 正交架构演进规划、关键设计评审、阶段性共建节奏与组织培训；
- 客户工程团队负责：平台代码实现、工程落地、上线与运维；
- 共同产出：实验并发从十位数走到千量级，排期从月级缩短到天级，产品 / 算法 / 商业化团队的实验不再互相污染。
项目结束后客户邀请全职加入，是对该阶段顾问价值最直接的确认。
→ 查看完整匿名案例（已脱敏，不出现公司名、行业细节与具体业务数字）
为什么是我#
我不是泛 AI 顾问，也不是单一实验或 BI 工具专家。差异化来自四条能力线在同一个人身上的交叉：
- 实验科学：流量分层、因果验证、指标治理、统计引擎——在快手期间参与过从互斥桶到重叠框架的真实升级；
- 营销数据平台：多源归因、指标语义层、ROI360、行为与内容数据模型；
- 增长方法论：渠道生命周期、批量运营、策略引擎（观察者视角）；
- 企业级 Agent 治理：Schema 居中、分级授权、可审计执行、独立验证与效果闭环。
经历过 IBM / TalkingData 的企业数据咨询、滴滴 / 快手的实验与数据产品、Shopee / SEA 的电商算法平台，以及出海休闲游戏方向的迦游（实验平台与发行/营销平台建设与应用）。完整背景见 关于展博。
第一步：5 分钟免费自检#
按你遇到的问题选一个入口，约 5 分钟、答完即时出结果；提交结果即可预约免费适配沟通。
| 你遇到的问题 | 自检工具 | 回答什么 |
|---|
| 营销买量：ROAS / ROI 对不上，不知道这个数能不能用来加预算 | 广告数据可信度快检 | 选方向、品类、渠道看 ROAS / CPI / CVR / 留存 / LTV 行业基线与趋势，输入后台 ROAS 立即拿到可信度判决 |
| 实验平台：实验做了但没人敢用、想建平台但不知从何入手 | 实验能力自检 | 15 道单选，定位你的「需求就绪度 × 能力等级 L1–L4」，给切入建议，附棋牌游戏大厂脱敏案例 |
营销买量 · 数据快检 →
实验平台 · 能力自检 →
查看全部工具 →
下一步：提交自检结果，预约适配沟通 / 工作坊#
先在上方完成对应自检，也可以直接在下面留言。我会在 1 个工作日内回复，判断适合免费适配沟通、按小时诊断，还是先开工作坊对齐。
增长不是一次灵感，也不是某个爆款素材、某个新渠道、某个产品改版带来的偶然结果。
真正可持续的增长，来自一套能够不断提出假设、验证假设、沉淀结论、再继续迭代的实验体系（贝叶斯方法）。
我想用一句话概括这个观点：实验即增长。 这也是展博增长实验室推出的产品（实验&增长咨询服务，面向内容、电商、应用等非游戏行业提供实验&增长的诊断、咨询、平台建设、业务陪跑等服务）。
尤其在面向全球市场的数字业务里，这句话更接近现实。因为数字业务面对的是高度不确定的市场：不同国家、不同文化、不同平台、不同获客环境、不同用户付费习惯，都可能让同一个产品表现出完全不同的增长曲线。
在这种环境下，企业不能只依赖经验判断，而要依赖实验。
一、为什么说“实验”是增长的基础？ 科学的基础不是“我觉得”，而是“可论证”。
从证据可信度来看，我们可以看到一个从低到高的金字塔：案例研究、观察研究、类实验、随机控制实验，以及更高层级的统合分析。
这些方法形式不同，但本质上都在回答同一个问题：
某个变化，是否真的带来了结果？
在商业增长里，这个问题尤其关键。
比如：
留存提升，是因为新手引导改得更好，还是因为这批用户质量本来更高？ ROI 提升，是因为素材策略有效，还是因为渠道算法短期波动？ 付费率提升，是因为礼包设计更合理，还是因为活动期间用户天然更愿意付费？ 如果没有实验体系，团队很容易把相关性误判为因果关系，把短期波动误判为方法论，把偶然成功误判为可复制能力。
所以，增长团队真正需要的不是更多“拍脑袋的优化建议”，而是一套持续验证因果关系的机制。
二、为什么增长离不开实验？ 增长是所有商业组织前进的动力。
但增长本身不是一个单点问题，而是一组连续问题：
如何让更多用户看到产品？ 如何让用户愿意下载或进入游戏？ 如何让用户留下来？ 如何让用户持续活跃？ 如何让用户付费？ 如何让 LTV 高于获客成本？ 这些问题之间相互关联，任何一个环节的改动，都可能影响整体增长效率。
在数字业务里，增长链路尤其长：从素材、广告、商店页、下载、首日体验、新手引导、核心循环、活动运营、付费设计，到广告变现和再营销，每一步都有优化空间。
这也是为什么我认为：
增长不是找到一个答案，而是建立一套不断找到答案的系统。
这个系统的核心，就是实验。
三、数字业务公司的四类典型实验场景 如果把数字业务公司的增长拆开看，实验至少会发生在四个关键场景里：用户体验、产品特性、买量与营销效率、商业化收益。
1. 用户体验实验：优化用户进入产品后的第一感受 用户体验实验关注的是：用户是否愿意继续玩下去。
常见实验包括：
新手引导流程调整 首局难度设计 UI 布局优化 任务系统节奏 奖励反馈强度 核心玩法教学方式 衡量指标通常包括：
使用时长 次日留存、七日留存 对局数 关卡完成率 GMV 或早期付费转化 用户流失节点 例如，一个产品可能会测试两种新手引导：一种是强引导，明确告诉用户每一步怎么操作；另一种是弱引导，让用户更快进入核心玩法。
表面上看，强引导更“清楚”；但实验结果可能显示，弱引导让用户更快获得乐趣，反而提升了留存。
这就是实验的价值：它能帮助团队摆脱主观偏好，回到用户真实行为。
2. 产品特性实验：探索产品该往哪里发展 产品特性实验关注的是：产品是否真正解决了用户需求。
常见实验包括：
新玩法模块 社交系统 排行榜 活动机制 关卡类型 道具系统 个性化内容推荐 这类实验不只是验证“功能有没有用”，更重要的是帮助团队判断产品方向。
...
声明：本文为独立行业观察，基于公开资料与个人实践整理，不代表任何雇主或客户观点。文中引述的平台行为以文中标注的公开文章为准，落地前请以平台当期官方文档核验。
tl;dr（3 条）
在 Advantage+ / Performance Max 这类全自动 campaign 里，你批准的计划和平台实际执行的计划不是同一套：它可以自行扩版位、在视频与展示间重新分配预算、用已批准素材自动拼接新变体。 周报回答的是"结果如何"，回答不了"这是谁的决定"。自动化程度越高，后者越是责任划分和续费谈判的关键。 解法不是要求平台解释每一次拍卖，而是开跑前约定一本变更日志的最小集：人工指令、平台权限边界、重大投放变更、评估证据，再配上审批阈值与回滚权限。这件事必须在花钱之前做，事后追溯基本无解。 一、问题：批准的和交付的，是两套计划 ContentGrip 上周一篇文章（The media plan now needs a change log，Kai Indra，2026-11-01）把一个很多投手隐约感觉到、但很少摆上台面的问题讲清楚了：
在自动化投放中，客户批准一套预算与素材，平台实际交付的是另一个 campaign。
文章列的三类典型偏差，我在诊断里都见过对应版本：
版位自动扩张：批准时投搜索 / Feed，实际被扩到展示网络、对话式搜索版位； 预算跨格式再分配：视频、展示、发现版位之间的钱被平台按自己的目标函数挪走； 素材自动变体：你批准了 5 条素材，系统用它们拼接出你从没审过的 30 个组合。 这不是平台"出错"。这是 Advantage+、PMax 这类产品的设计本身——你买的就是它的自动化。问题在于，大多数团队的管理流程还停留在"人工逐条设置 campaign"的时代：审批流审的是一张静态计划表，上线后平台每天都在改写它，而组织里没有任何一份记录，说明改写得到了谁的授权。
文章里有一句话我认为可以直接贴在投放团队墙上：
周报记录了结果，但往往对产生这些结果的决策说得很少。
二、为什么这件事在 2026 年突然变严重 不是投手变粗心了，是平台这一侧的默认行为在半年内连续变化，且多数变更不需要广告主同意：
Google 把既有 campaign 扩展到对话式搜索版位；据公开报道，AI Mode 版位在部分国家无法 opt-out； Meta 推进 Andromeda 检索系统（我在 10 月初的平台数据主权一文里展开过），其检索与排序的复杂度已超出人工逐展示审查的能力； Amazon 把媒介计划对话化；TikTok 调整品牌安全与版位的默认打包方式。 每一个单独看都是"平台常规升级"，合在一起的效果是：没有任何一个后台能给你一份完整的账，说明「客户到底授权了什么」。权限边界在被平台单方面、连续地移动。
我在 从聚合投放到智能投放 Agent 里讲过结论：平台的智能只对齐平台自己的收入，广告主真实战场是跨平台的，必须长出自己的一层。变更日志就是这一层里最基础、也最被忽视的一块地基——它不是技术功能，是治理结构。
三、最小可行记录集：四件事 注意，要的不是每次拍卖的决策转录——那个既不现实、也没人看得懂。业务侧真正需要留存的只有四类信息（这个划分我同意 ContentGrip 文章的框架，也和我做诊断时实际检查的字段一致）：
...
声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点。
tl;dr（4 条）
经典固定窗 t / Z 检验只允许到点看一次。实验期间每天刷看板、一看到 p<0.05 就停，属于 optional stopping——名义 5% 的假阳性会被抬到 20% 量级（精确数字取决于偷看次数和停止规则，不是普适常数）。 序贯检验（sequential / anytime-valid）在设计阶段就把「允许反复查看」写进 Type I 控制：α-spending、SPRT、mSPRT、always-valid p-value / 置信序列是三族主流实现。 合法早停有代价：对弱效应更慢、置信区间更宽；早停的点估计偏乐观（winner’s curse），不能直接拿去做财务 forecast；它也不能让 30 天留存提前成熟。 小团队默认策略：序贯检验 + 至少跑满 7 个完整自然日 + guardrail 达标 + 无 SRM 才允许早停。选实验平台时直接问一句：是否 peek-safe / always-valid，而不是问会不会算 p-value。 一、一个每天都在发生的错误 我做实验诊断时最常见的场景不是"团队不会算 t 检验"，而是：
实验周一上线，看板每天刷新； 周三运营发现转化率 p<0.05，业务群里一句"显著了，全量吧"； 周五全量，下周核心指标没动，甚至回落，但没人再把它和那次"显著"联系起来。 这个流程里，分流可能是对的、指标口径可能是对的、Welch t 也算得没错——错在决策时序。固定窗检验的统计保证有一个前提：分析次数和停止时间不依赖数据。你答应它"跑到第 14 天看一次"，结果第 3 天看了一次、第 5 天看了一次、第 7 天显著就停，前提被破坏了。
固定窗检验不是"不能看监控"，而是不能用未校正的中期显著性作为停实验的充分条件。看健康度（有没有崩、SRM 是否正常）随时可以；把"显著"当全量按钮，不行。
二、为什么多看几次，5% 就守不住了 直觉是这样的：在两组其实没有任何真实差异（A/A）的情况下，累计检验统计量是一条随机游走的线，5% 的显著性阈值是线两边的围栏。你答应只在终点看一次，误入围栏的概率就是 5%。但如果你每天都看一眼，这条线在 14 天里任何一天蹭进围栏你就宣布"赢了"——蹭到的机会自然随查看次数累积。
...
作者：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 专家判断 / 单个案例 / 直觉 ← 最快、最便宜、最易偏 对业务团队，真正有用的不是记住五层名字，而是一条决策纪律：
小决策用快证据，大预算、不可逆决策用强证据。
一个必须同时盯住的盲点：金字塔只保证"结论是不是真因果"，不保证"换个场景还成立"（外部有效性）。在一个国家跑出来的显著 AB，放到另一个国家可能完全不成立。比给方法排座次更实用的产品动作，是给每条结论打上可信度标签（随机实验 > 准实验 > 观察 > 案例）。
...
作者：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 前先把口径说清楚。
场景 2：让业务"会做实验、读懂分析、相信结论" 这是"技术正确性 × 组织信任"问题，要同时回答四件事：
...
作者：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 整体豁免。规则平权不等于数据平权。
把镜头转到 in-app，情况还要再黑一层。open-web 的拍卖发生在页面里，发布商自己留得下每家的出价记录，所以法院有办法强制 Google 接进 Prebid 这个中立点。in-app 的统一拍卖发生在 mediation SDK 的二进制内部：流量主拿到的是 SDK 选择吐出的收入摘要，不是原始拍卖日志；经 exchange 接入的 DSP 只看得到自己的赢输。没有任何第三方站在拍卖现场，「所有 bidder 拿到相同信号」是一句无法从外部验证的声明。
...
控制面正在移到客户手里，数据重力没有。
作者：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 引擎，可以换。
...