商业平台（上）：Web 实验与优化套件
Web 优化套件正在被整合进更大的 DXP、支付与私募组合；它们能卖编辑器，但卖不走分桶权、指标定义权与结论解释权。
2.1 赛道地图与产品谱系#
这批产品常被塞进同一张「A/B 测试工具」对比表，但血缘并不相同。至少有三条基因：页面活动（Optimizely Web、VWO、AB Tasty、Convert、Monetate Maestro）以「新建 campaign、改页面、定受众」为入口；企业个性化（Adobe Target、Dynamic Yield、Sitecore Personalize）以「这个人该看什么」为入口；交付基础设施（SiteSpect 的反向代理、Optimizely Performance Edge、Kameleoon 的边缘套件）以「请求在哪里被改写或求值」为入口。基因决定产品形态、买单人和计价锚点，也决定了它们很难互相替代。
| 活法 | 代表 | 核心资产 | 典型买单人 | 2026 状态 |
|---|---|---|---|---|
| 营销活动套件 | VWO、AB Tasty、Convert | 编辑器、模板、活动日历 | 增长/市场/电商 | 合并、涨价、独立者收缩 |
| DXP 模块 | Optimizely、Adobe Target、Sitecore Personalize | 与 CMS/CDP/分析捆绑 | CMO/CDO、IT | 被并入更大平台 |
| 统计垂直平台 | Kameleoon | 统计透明度、边缘交付 | 数据成熟的中大型企业 | 独立，靠 AI 建实验 |
| 网络层基础设施 | SiteSpect/Forte | 反向代理、合规部署 | 金融/医疗/大型集团 | 被 Monetate 吸收 |
2024–2026 年不是扩张期，而是整合期。2023-09-30 Google Optimize 硬停服 来源；2024-05-31 Oracle Maxymiser 停服 来源；2024-05-29 Harness 宣布收购 Split，2024-06-11 完成交割 来源；2025-06-30 Monetate 收购 SiteSpect 来源；2026-01-20 VWO 与 AB Tasty 宣布合并 来源，2026-09-16 统一为 Wingify 来源；2026-07-30 Monetate 再收购 Simon AI 来源；2026-10 Sitecore 把 CDP、Personalize、Search 合并进 SitecoreAI 来源。五年之内，几乎每一家「独立 Web 套件」都换了归属，或被并入更大的 DXP、支付、私募组合。
| 产品 | 技术血统与归属 | 2026 年的真实身份 | 对采购的含义 |
|---|---|---|---|
| Optimizely | 2020-10-21 Episerver 完成收购，Insight Partners 持有 来源 | DXP + Opal AI，实验是模块 | 买的是营销操作系统，不是单点实验 |
| VWO | 独立起家，2025 年 Everstone 多数股权，2026 并入 Wingify | 合并中的易用型套件 | 合同主体、续费与路线图要重签 |
| AB Tasty | 2014 年巴黎起家，Flagship 并入 | Wingify 旗下欧洲品牌套件 | 与 VWO 产品高度重叠 |
| Kameleoon | 独立 | 统计严谨的垂直实验平台 | 少数仍可长期独立的选项 |
| Convert | 独立 | 公开定价的中小客户工具 | 价格透明，但治理与统计有缺口 |
| SiteSpect | 反向代理起家，2025 年被 Monetate 收购 | Monetate Forte 的网络层底座 | 品牌弱化，买的是 Forte 而非 SiteSpect |
| Adobe Target | Adobe Experience Cloud | 企业实验 + 个性化引擎 | 最接近平台，但绑定 Adobe 栈 |
| Dynamic Yield | McDonald's 2019，Mastercard 2022 | Mastercard 的客户经营产品线 | 产品在售，路线服从支付生态 |
| Monetate | Kibo 2019，2022 剥离 来源，连续并购 | 实验 + 个性化 + CDP 拼图 | 整合期，能力变全但路线不稳 |
| Sitecore Personalize | 2021 收购 Boxever 而来 来源 | 并入 SitecoreAI Conversion Optimization | 双轨期，迁移规则待核实 |
| Oracle Maxymiser | 2015 年被 Oracle 收购 来源 | 2024-05-31 已停服 | 2026 年不应出现在任何 RFP |
这张谱系图对采购有三个含义。合同主体比功能清单重要：VWO/AB Tasty 已归 Wingify，SiteSpect 已归 Monetate，签约前要确认续费、涨价、停服、迁移由哪个法人负责。计费锚点决定你能买到什么：营销套件按 MTU 卖给市场部，DXP 按模块卖给 CIO/CMO，网络层按部署卖给基础设施团队。实验模块没有独立生存权：Maxymiser 不是输给 A/B 工具，而是输给 Oracle 的营销云战略；套件收缩时，实验能力会被优先牺牲。
2.2 Optimizely 深度拆解#
Optimizely 是这批产品里唯一同时拥有「营销入口」和「工程入口」的，但这不是一个产品，而是两条产品线：Web Experimentation 与 Feature Experimentation。2020-10-21 Episerver 完成收购，2021 年合并品牌，此后把 CMS、Commerce、ODP、Experimentation 打包为 Optimizely One；2024-09-30 收购仓库原生分析公司 NetSpring 来源，2025-05-07 推出基于 Gemini 的 Opal 来源，2026-06-22 发布新品牌。控制权没有变化——Episerver 是 Insight Partners 2018 年以 11.6 亿美元买下的私有组合公司，2024–2026 年未发现所有权变更的一手证据，所以「Optimizely 又被卖了」的说法不成立。
产品与交付。 Web 端提供可视化/代码编辑、A/B/n、MVT、Split URL；Feature 端提供服务端 SDK（Java、.NET、Node、Python、Ruby、Go、PHP、Swift、Kotlin、React 等）、Flag、远程配置、渐进发布；另有 Personalization/Recommendations 与 ODP。互斥组可跨 Web 与 Feature 划分流量，保证一个访客最多进组内一个实验 来源；提供 native global/local holdouts；Stats Accelerator 用多臂老虎机（UCB 家族）动态调流量，报表用绝对提升 pp，服务端需 sticky bucketing。交付有三套形态：标准 snippet、Performance Edge、服务端 SDK。标准 snippet 的完整配置可达 50–200KB，存在闪烁窗口；Performance Edge 把决策搬到 CDN 边缘，用同一套 MurmurHash3 分桶，向 HTML 注入小于 5KB 的 micro-snippet，只含命中变体代码，在 HTML 到达浏览器前「烘焙」好，实现 zero-flicker 来源。代价是 Performance Edge 并非默认、要改 CDN、能力有边界；三种交付形态并存，但不是同一套轻量 SDK。
统计。 官方名 Stats Engine，默认是频率派序贯检验，不是贝叶斯引擎。它计算 100 个连续置信区间，结果页显著性取其中最保守值，置信区间取交集，因此比 t 检验更保守、更不容易「先显著后反转」来源；提供 always-valid p 值、FDR 控制、多变异 Bonferroni、贝叶斯解释层。CUPED 用回归做协方差调整，默认读实验前两周同指标历史，只支持数值指标，不适用转化率，支持 Snowflake/BigQuery/Databricks 仓库原生 来源。SRM 用 SSRM 持续检查，但只覆盖手动分流、未开 Stats Accelerator、运行不超过 45 天、至少 1,000 访客的 A/B 来源；Guardrail alerts 可对收入、结账、注册、留存设阈值。
这里要标注一个「存在不同说法」：二手资料常把 Optimizely 说成「贝叶斯统计平台」。准确说法是——Stats Engine 默认序贯频率派；Feature Experimentation 可以在 Stats Configuration 里选 Bayesian，替代默认的 Sequential，也可以选固定 horizon 频率派 来源。把「可选贝叶斯」写成「默认贝叶斯」，会让选型时的统计假设完全错位。
商业与判断。 Optimizely 不公开套餐价，按模块/流量/部署年度报价 来源；第三方 Vendr 样本显示年合同额中位数约 8.1 万美元，实验类在 500 万 MTU 以下常见 5–8 万美元/年（第三方样本，非官方报价）来源。优势是统计完整、双端完整、PE 零闪烁；限制是贵、面宽、Stats Engine 保守、PE 非默认、snippet 大、指标仍以 Optimizely 为中心。适合已有 Optimizely 生态、要市场与产品实验统一入口的企业，不适合预算敏感、纯服务端、要求指标定义在数仓的组织。
Optimizely 真正值得学的不是「功能多」，而是两件事：同一套分桶、三种交付，以及把统计不确定性产品化（100 个区间、always-valid p、FDR、护栏告警都是可解释的产品表达）。但 DXP 的买单人决定了它的优先级：实验要为 CMS/Commerce 导流，而不是反过来。这个结构性约束，后面 2.7 会展开。
2.3 VWO 深度拆解#
VWO 的历史标签是「便宜、好用、上手快」，这个标签在 2025–2026 年已经失效。2025 年 Everstone 收购多数股权（第三方报道约 2 亿美元，官方未披露金额）；2026-01-20 与 AB Tasty 宣布合并；2026-09-16 统一为 Wingify，官方口径年收入超过 1.05 亿美元、4,000+ 客户、700+ 员工、11 个办公室，客户含 L'Oréal、LVMH、Decathlon、Puma、Forbes、Motorola、AXA、De Beers 来源。合并前 VWO 称 3,000+ 品牌、AB Tasty 称 1,000+ 品牌，与「4,000+」存在不同说法（有重复计算与口径差异），采购时应以合同主体和续费责任为准。
产品与套餐。 模块包括 Web Experimentation & Rollout（A/B/n、Split URL、MVT、Rollout、SPA、QA Assistant）、Feature Management/Feature Experimentation（Flag、渐进发布、服务端 SDK、Holdout Groups 来源）、Personalization/Predictive Data、Commerce（搜索、推荐、Merchandising）、Analytics/Engagement。套餐分层很硬：Growth 才含 MAB 与 Rollout，Enterprise 才有 Mutually Exclusive Groups、Approval Workflow、SSO、Self Hosting 来源。架构以异步 SmartCode 为主，支持 SPA 与元素隐藏/延迟渲染，但 anti-flicker 细节不如 Kameleoon 透明；服务端由 FME SDK 承担，覆盖 Java、PHP、Python、.NET、Ruby、Go、Android、Flutter、React Native；数据层是 Wingify Data360/Data Platform，事件、属性、受众、指标都在平台内定义 来源，没有 Optimizely Performance Edge 式独立边缘产品。
统计。 SmartStats 在 2024-12-03 升级为「Bayesian powered sequential testing engine」来源：贝叶斯默认，启动前可切频率派、启动后不能改；序贯解决 peeking，多变异用 Bonferroni；提供 Fixed Horizon（预计算样本、只判一次）与 Dynamic（无固定样本、持续检查）两种模式；引入 ROPE 做实践等价，用于提前停掉差变体；Pro 含 SRM Detection 与 Guardrail Metrics；官方称用精确分布而非正态近似，小样本更准 来源。官方文档未见 CUPED 支持（待核实），这是相对 Optimizely/Kameleoon 的短板。
这里还有第二个「存在不同说法」：说「VWO 是贝叶斯」必须带版本/账户前提。2026 年新版 Data Platform 另有「upgraded statistical engine」，SmartStats 只覆盖非 Data Platform 账户与迁移前 campaign。也就是说，同一个客户在不同账户、不同迁移阶段，可能跑在两套统计引擎上；采购 POC 时应要求厂商明确「这个账户默认用哪套、能否切换、历史结果是否可比」来源。
商业与判断。 2026-10 官网 Growth/Pro/Enterprise 三档全部只给「Schedule a Demo」，不再公开美元起价 来源；功能按套餐锁定，Pro 才有 Guardrail/SRM/MVT/Cross Domain，Enterprise 才有互斥组/SSO/自托管。历史「VWO 便宜」的标签正在失效，合并后价格体系如何并轨待核实。
VWO 值得抄的是把 ROPE、Fixed vs Dynamic、CTW 做成业务能选的开关，比只给 p 值更接近决策；但「启动后锁方法」和「CUPED 缺失」会让成熟团队不够用。合并后的产品重叠意味着 12–18 个月内会有一次路线取舍，采购要写清退出与迁移条款。
2.4 AB Tasty / Kameleoon / Convert / SiteSpect#
这四家代表四种「活法」：AB Tasty 是合并中的欧洲品牌套件，Kameleoon 是统计最透明的独立垂直平台，Convert 是公开定价的中小客户工具，SiteSpect 是网络层基础设施。它们正好覆盖「决策发生在哪里」的四个位置：同步 tag、异步脚本 + CSS 隐藏、tracking script + body hiding、反向代理。
AB Tasty：用首屏性能换无闪烁。 2014 年成立于巴黎，强项是电商、零售、旅游、金融的品牌客户；合并前称 1,000+ 品牌（L'Oréal、Samsonite、USA Today、Ganni），官方称监控 15,000+ 活跃 campaign 来源。模块覆盖 Web 实验（A/B、Multipage、MVT、Split/Redirect、A/A）、个性化（Emotions AI、AdaptiveCX）、Commerce（推荐/搜索）、Feature（原 Flagship）与治理（1V1T、审批、SSO）。未见独立 global holdout，以 control + 1V1T 控制污染（待核实）。
架构核心是同步 tag：官方建议放 <head> 同步加载，确保变体在渲染前应用；异步虽不阻塞，但可能先看到原版 来源。这是「用首屏性能换无闪烁」，同步 tag 拉长关键路径，高流量站点必须评估 Core Web Vitals。SPA 用 MutationObserver 在两次渲染间应用修改，SSR 在 hydration 后再应用；服务端 SDK 覆盖主流语言与移动端，支持 Decision API、panic mode、渐进发布、1V1T 来源；无独立边缘网络。统计以贝叶斯为主、频率派可选；贝叶斯报表展示 Chance to Win 与置信区间，频率派把 CTW 换成 p 值 来源；序贯用于 Sequential Testing Alerts，但只在检测到「输家」时建议停止，不提前宣布赢家，灵敏度 High/Balanced/Low 对应约 5%/3%/1% 误报 来源；SRM 用 S-SRM（频率派 p 值、阈值 0.01、Early Adopters，需联系 CSM）来源。未见 CUPED、系统化 FDR/Bonferroni、独立护栏指标（待核实）。设计取向是「业务友好优先」：CTW 好解释，序贯只止损；代价是想用序贯加速赢家上线做不到，想做方差缩减也没有。
AB Tasty 适合品牌营销团队、欧洲本地服务、需要「实验 + 个性化 + 推荐」一体化的客户；不适合性能敏感高流量站点、需要序贯赢家决策、CUPED/仓库原生或只想买纯实验的公司。合并后与 VWO 的产品重叠是最大不确定性。
Kameleoon：把统计取舍讲清楚。 定位 AI-powered experimentation & personalization，客户以中大型企业为主，强项在电商、媒体、旅游、医疗、金融；官方称 1,000+ 品牌，Samsung 是 PBX 案例客户。模块覆盖 Web 实验（可视化/代码编辑、A/B/n、MVT、SPA、PBX）、Feature（Flag、渐进发布、Holdout、跨设备）、个性化（AI Predictive Targeting）、推荐/搜索与治理（跨端互斥组、Holdout、Health Checks、生产审批）。未见经典 MAB；AI Predictive Targeting 是「按转化 likelihood 定向」，不是流量动态分配（待核实）。
架构是六者中最透明的：异步 snippet 从 Cloudflare CDN 加载，单文件 Brotli 压缩约 29KB；初始注入 blocking CSS rule 隐藏内容，脚本加载后移除，默认超时 750ms，超时可选「禁用本页/禁用本次访问/带闪烁继续」，官方称正常网络超时约 2–3%，SLA 超过 99.99% 来源。服务端 SDK 覆盖 Java、C#、PHP、Node、Ruby、Python、Go 与 Android、iOS、Flutter、React/React Native；官方称 zero-latency SDK，分桶本地完成，性能影响小于 1ms。边缘 starter kit 覆盖 Cloudflare Workers（2024-10）、Akamai EdgeWorkers（2024-12）、AWS Lambda@Edge（2024-07）、Fastly、Vercel，另有 Nginx 模块与 OpenFeature provider。这是六者中最完整的「客户端 + 服务端 + 边缘 + 自托管」矩阵。
统计支持三种方法并给出取舍：固定样本频率派（功效最大、但 rigid）、贝叶斯（可融先验、先验错会带偏）、序贯（可随时看/提前停、置信区间任意时点有效，但功效较低、效应估计精度较差）；官方建议序贯做早期止损、固定样本做最终验证 来源。支持多重比较校正、CUPED（用实验前数据做协方差调整，建议与固定样本结合）、Winsorization（极端值缩尾）。Health Checks 含 SRM、Overlapping Exposure、Conversion Tracking、Visitor Tracking；启动后 24 小时每小时跑，之后每天跑 来源。Web/Feature 都支持 Holdout；互斥组支持 Web 内、Feature 内及跨客户端/服务端。未见独立 guardrail 产品（待核实），Health Checks 偏数据质量而非业务护栏。
Kameleoon 的优势是统计最完整、交付矩阵最全、对工程最友好；限制是品牌/生态比 Optimizely/VWO 小、无仓库原生指标层、价格不透明、自托管/边缘需工程投入、PBX 生成质量需人工审核、护栏产品化弱。PBX 2025-06 beta、2025-09-25 GA，官方称建实验时间最多减少 97%、前 1,000 个实验平均回收期小于 3 个月（官方宣称，未经独立验证）来源。
Convert：把价格做成产品。 定位高性价比、隐私友好、无套件捆绑的 CRO/实验平台，客户以中小企业、代理、Shopify/DTC 商家为主；策略是「免费迁移 VWO」+ 公开定价 + 不限实验数，承接 VWO 涨价/合并后的价格敏感客户。模块包括 A/B、Split URL、Multipage、MVT（Pro）、Full Stack & Flags（Pro）、Personalization、MAB（Pro）、Sequential（Pro）、Holdout、Mutual Exclusion、Visual Editor、Heatmaps、SRM Check、MCP Server。
架构以客户端 tracking script 为主，Body Hiding 隐藏页面直到变体应用以降低闪烁；SPA 通过 URL/选择器监听支持。服务端两条路径：① Cookie hand-off——后端/边缘先决定变体，写 _conv_sptest 短生命周期 cookie，客户端 script 读取并上报；② Full Stack SDK——完全服务端分桶/上报，支持 PHP、Node、Python、Ruby、Java、Android、iOS 等 来源。没有自建边缘网络；CDN 边缘逻辑可通过 cookie hand-off 实现，但需客户自己写。
统计三种方法齐全：频率派（固定样本、p 值、置信区间、t/卡方、可配置阈值、多重比较校正控制 FDR）、贝叶斯（后验、Credible Interval、Probability to be Best，默认无信息先验、可连续监控）、序贯（AGILE 框架，可中期有效停止）来源。未见 CUPED、独立 guardrail 产品（待核实）。定价（2026-10-18）：Growth 100K tested users/月，年付 299 美元/月（3,588 美元/年），月付 399 美元，含 A/B、Split URL、MCP Server、Deploys、SRM Check、Heatmaps、Signals；Pro 100K/月，年付 420 美元/月（5,040 美元/年），月付 599 美元，含 MVT、Multipage、Full Stack、MAB、Sequential、SSO；Enterprise 12M/年，Price on Request；全部 15 天免费试用，价格不含税 来源。
Convert 的价格透明是最大差异化，299 美元/月的锚点比企业套件低 1–2 个数量级；但治理、仓库原生、CUPED、服务端/边缘能力都弱，适合中小团队/代理/落地页实验，不适合大型企业统一平台。
SiteSpect：把实验做成网络项目。 定位企业级、无标签、网络层实验/个性化平台，面向大型企业，尤其是医疗、金融、保险等受监管行业，以及有私有云/本地部署要求的集团。核心卖点是 reverse proxy：流量经过 SiteSpect 集群，HTML/CSS/JS/API 响应在到达浏览器前被改写，不需要客户端 snippet，天然无闪烁、对页面性能影响小 来源。2025-06-30 被 Monetate 收购后，官方强调其私有云/本地部署、HIPAA/PCI 合规经验；2026 年 sitespect.com 已指向 Monetate 的 Maestro 与 Forte，品牌弱化 来源。这里存在不同说法：有资料称 2025-06-30 完成交割，公开稿用「Acquires」但未单独披露交割日，采购应以合同主体为准。
模块包括 A/B（客户端/服务端 campaign、Visual Editor、Factors/MVT、Triggers、Audiences）、个性化、推荐、server-side Flag、Omnichannel/Mobile（待核实）；单租户/私有云/本地、SSO、审计、PCI/HIPAA；无现代互斥组/分层（待核实），以 control 为主，未见 global holdout。未见经典 MAB。
部署不是「加一行 JS」，而是「改网络」：客户交前端 URL、后端 origin、SSL 证书、端口；SiteSpect 建集群、配站点、部署健康检查；客户把 DNS 或 CDN 指向 SiteSpect；SiteSpect 终止 SSL、转发请求、改写响应，页面源码与 JSON 是主要改写对象。官方称配置通常 3–5 小时、最快 3 天上线；DNS 切换建议提前 24 小时把 TTL 降到 300 秒。代价是必须动 DNS/CDN/证书，涉及网络、安全、运维多团队；代理是全局故障点；WebSocket、HTTP/2/3、流式响应兼容性需逐项验证。SPA 支持比想象中好：首个 HTML 响应注入 ssdomvar.js、core.js 等库，用 MutationObserver 监听 DOM，框架无关，客户端与服务端变体可在同一 campaign 混用 来源。
统计是六者中最传统：频率派假设检验，用 two-tailed t-test 比较变体与对照，计算 z-score、p 值、置信区间；报表展示 90%/95%/99% 置信条，置信图用 80% 区间辅助；没有 always-valid p 值/alpha spending/序贯校正，没有贝叶斯、没有 CUPED、没有自动 SRM 检测 来源。定价不公开，按企业 license + 流量/部署 + 服务报价；典型合同六位数美元/年（推断，官方未披露），TCO 还要加证书、CDN 规则、运维人力、灾备。
SiteSpect 是「基础设施」，不是「营销工具」；买它等于买一个网络项目。它适合受监管、私有化、需要改写 API 响应的场景，不适合想要轻量接入、快速迭代、现代统计的团队。
| 交付位置 | 代表 | 防闪烁 | 首屏代价 | 部署门槛 | 适用 |
|---|---|---|---|---|---|
| 同步 tag（head） | AB Tasty | 强 | 高（阻塞关键路径） | 低 | 品牌站点、欧洲合规 |
| 异步脚本 + CSS 隐藏 | Kameleoon、VWO、Convert | 中—强 | 中（隐藏超时/闪烁兜底） | 低 | 大多数 Web |
| CDN 边缘注入 | Optimizely Performance Edge | 强 | 低 | 中（改 CDN） | 高流量、已有 CDN |
| 反向代理 | SiteSpect/Forte | 最强（架构级） | 低 | 极高（DNS/证书/网关） | 受监管、私有化 |
「防闪烁」不是功能开关，而是部署位置的结果；任何厂商说「零闪烁」都要问「在哪一层实现、代价是什么、失败时怎么办」。
2.5 Adobe Target / Dynamic Yield / Monetate / Sitecore#
这四家常被归为「企业个性化套件」。严格说，只有 Adobe Target 以实验为核心能力；另外三家的第一性问题都是「这一屏该给谁看什么」，实验只是投放模式之一。它们共享同一套架构：受众/画像 → 决策/分配 → 内容下发 → 曝光回收 → 模型训练。差别在「决策在哪、模型多复杂、统计承诺是什么」。
Adobe Target：用能力分层换延迟。 它是 Adobe Experience Cloud 里的实验与个性化引擎，覆盖 Web、App、邮件、IoT 与服务端体验 来源。分 Standard 与 Premium：Premium 只增加 Automated Personalization、Auto-Target、Recommendations、Recommendations as an Offer、Enterprise User Permissions；Auto-Allocate 属于 Standard，不是 Premium，这是生态里最贵的误解 来源。
手动 A/B 用 Welch's t-test、固定 horizon，不自动做 B vs C 比较。Auto-Allocate 是 bandit：80% 智能分配、20% 随机探索；冷启动每个经验至少 1,000 访客、50 转化；每小时更新，选「当前最优」和「Bernstein 95% 区间上界最高的挑战者」；区间不重叠时打 winner badge，官方称误报率约 5%、赢家真实响应不比最优差超过 1%（相对）来源。代价是只有新访客重分配、回访者保持原体验、启动后不能切回手动。Auto-Target/AP 用 Random Forest + ε-greedy：每个 experience/offer 一个模型，先在随机流量上训练并用 AUC 验证，24 小时重训，无法区分个体时回退 Thompson；控制组 ≥10%，单个 experience 每日至少 1,000 访客 + 50 转化、整体 7,000 + 350，会话内预测不变 来源来源。XT 是规则不是实验，MVT 是全因子，推荐是 Premium 模块。
架构三层：SDK 回源（at.js/AEP Web SDK → Delivery API，能力最全）；On-device decisioning 把 A/B 与 XT 编译成 rule artifact，缓存到 Akamai CDN 来源；2026 年 CDN-based delivery 可跑 Akamai EdgeWorkers、Lambda@Edge 来源。但边缘只支持 Form-based Composer 的 A/B 与 XT、手动分流，不支持 Visitor Profile/Network/Mobile/Traffic Source/Experience Cloud Audiences，artifact 传播最长 20 分钟，也不支持 Auto-Allocate、Auto-Target、AP、MVT、推荐。结论：Adobe 的「零延迟」与「ML 个性化」不可兼得，边缘只能承载规则可序列化的实验，用模型必须回源，这是要写进 SLA 的硬约束。
价格不公开，按产品选项、数字资产量、全渠道方式定制 来源；第三方估算议价后 7.2–24 万美元/年，首年 7.9–30 万美元+（第三方，非官方）来源。限制：非仓库原生；手动 A/B 无序贯/CUPED/多重比较校正；Auto-* 只优化单一目标；每活动最多 50 个「受众×位置」、每体验 350 个 offer、300 个选择器、单 offer 75KB；北京 RDC 只覆盖 Analytics AppMeasurement，不覆盖 Target，决策与事件只能走海外，且无私有化版本 来源。启示是「按决策延迟做能力分级」，Standard/Premium 的切分说明实验卖「测量」、个性化卖「模型」。
Dynamic Yield：承认自己不做因果推断。 McDonald's 2019-03 收购 来源，Mastercard 2022-04 完成收购 来源；2026-10 dynamicyield.com 已 301 到 mastercard.com，品牌写作「Mastercard Dynamic Yield」，产品结构变成 Experience OS、Experience OS Agents、Shopping Muse、Experience APIs、Experience Search 来源。这不是停服，而是被收编为支付公司的客户经营产品线；产品仍在售、仍在迭代，但路线图服从 Mastercard 的金融与商户生态。
能力以 campaign/experience 为核心：横幅、弹窗、推荐位、搜索、邮件/短信/推送；实验只有 A/B allocation、Dynamic Allocation（MAB）、推荐与 Experience API。没有 Adobe 式「每访客一个模型」的公开叙事，MVT 未见文档（待核实）；强项是内容/商品/促销的实时个性化，不是产品策略实验。
Dynamic Allocation：初始均分；用主指标计算每个变体的 Probability to be Best，表现好的逐步加流；至少每小时重算并重新分配；探索/利用比例 10/90，10% 随机（hidden control），90% 给当前最优；编辑变体不会重置算法，新增变体先按 1/n 给流量，被编辑的变体最初几小时按 1/n 重新评估 来源。官方明确说它「less focus on statistical significance and more focus on optimization and speed」。P(best) 不是 p 值，不能回答「带来多少增量」，只能回答「现在该多给谁流量」。
架构是 JS tag + Choose API + 移动 SDK，服务端可用 Experience API 来源。含推荐的 Choose 调用 95% 情况 10–140ms，不含推荐 10–30ms；默认限流每个 section 每分钟 22,000 次。它是为「页面同步渲染」设计的。Vendr 合同中位数约 10.1 万美元/年，区间 6.26 万–10.94 万美元/年（2025 页面数据，第三方）来源。限制是 SaaS 为主、无公开私有化、实验治理无公开文档、被 Mastercard 收编后路线确定性下降、中国大陆无常驻区域。它适合促销/推荐位，不适合产品实验；拿它做因果结论，是用错了工具。
Monetate：并购拼图与「自动上线」。 2019 年 Kibo 收购；2022-10-28 Kibo 把个性化业务剥离为独立公司，沿用 Monetate 品牌，由 Centre Lane Partners 与 GarMark Partners 支持 来源；2025-06-30 收购 SiteSpect；2026-04（页面只标 Apr 16，年份推断）推出 Forte 来源；2026-07-30 收购 Simon AI 来源。2026 年的 Monetate 是「Maestro 实验套件 + Forte 网络层实验 + Simon AI CDP + 推荐/搜索」的组合体。整合期既是机会（能力变全），也是风险（路线图与团队稳定性）。
Maestro 是实验套件：客户端/API 驱动的 A/B、A/B/n、MVT、feature experimentation、dynamic testing；Forte 是面向受监管、登录态、结账链路的「安全实验」，把客户端、服务端与 flag 统一，底层沿用 SiteSpect 的混合架构 来源，可部署在云、私有网络或本地。Monetate 是这几家里唯一公开承诺 on-prem/私有网络部署的，但 Forte 是反向代理方案，不是轻量 SDK。
架构有两种接入：JavaScript API + Monetate tag（同步 tag 阻塞加载，保证无闪烁但可能增加加载时间；异步 tag 不阻塞，但可能闪烁）；Engine API（一次调用同时完成三件事——传上下文、取当前上下文应触发的 actions、回传事件/指标）来源。这个「三合一」是为了降延迟，但也意味着曝光、决策、指标回收耦合在同一个请求里，排查问题和离线归因会更依赖厂商日志。
统计上，Auto-Promotion 容易被误认为 bandit，实际是显著性达标后的自动上线：控制组阈值 >0、体验里不能有 split；活动跑够天数、目标指标正向 lift 显著、且没有任何指标负向 lift 超过置信度；然后复制为「无控制组的全量实验」、暂停原活动、激活新活动 来源。它优化「赢家上线速度」，不是「在线学习中的流量分配」；真正的在线学习在 Automated Personalization 里，但算法细节没有公开 来源。定价不公开，需询价；从产品组合与企业级服务看，客单价不会低于 Adobe Target 的量级。限制是客户端 tag 的闪烁/性能取舍、统计文档弱于 Adobe/Sitecore、连续并购带来产品重叠、中国大陆无常驻区域。它的价值在「受监管行业的私有化/网络层实验」，不是「更好的 A/B 工具」。
Sitecore Personalize：决策层很强，统计层够用。 2026-10 Sitecore 把 CDP、Personalize、Search 合并进 SitecoreAI，统一为「Conversion Optimization」，强调「single license and shared context」来源；官方定义是「SitecoreAI 的实验层」来源。但 Personalize 没有立刻消失：文档仍在更新，独立 Personalize 仍在售，FAQ 仍讨论 standalone 与 XM + Personalize 的买法 来源。本文判断 2026 下半年是「双轨期」——新客户被引导到 SitecoreAI，老客户继续用 Personalize，迁移与折算规则待核实。
实验分三类：Web experiment（模板/表单做页面变体）、Interactive experiment（开发者全栈实验，后端返回 JSON，前端渲染，适合 App/SPA/服务端）、Triggered experiment（FreeMarker 生成内容，推给 ESP 或短信/推送，做站外触发）来源。
决策层是差异化：基于 DMN 标准，业务人员可用规则建模，同一个 decision model 可复用到不同渠道；支持 decision model、decision table、programmable decision、analytical model、knowledge source、data system，跑在 Lambda 架构（批 + 流）上 来源。这比 Adobe 的「受众 + 体验」表达力更强，适合「下一步最佳动作」这类复杂决策。
统计有 Classic 与 Optimized 双引擎：Classic 固定假设、跑到统计显著；Optimized 是多臂老虎机，官方建议用于周末闪购这类时间窗有限的场景。Optimized 用 Thompson sampling；每个变体保留至少 1% 流量做持续探索；后验按 Beta(p, q+1) 计算（p 为转化数，q 为曝光数）；用 Monte Carlo 抽样 N 次，统计每个变体「成为最高」的次数，除以 N 得到新权重 来源。这里有一个细节：文档写的是 Beta(p, q+1)，而工程上常见的 Beta-Bernoulli 后验是 Beta(1+conv, 1+fail)；两者在 q 很大时接近，小样本阶段不同。本文按官方文档原样引用，具体实现待核实——读厂商统计文档不能只看结论，要看他把哪个量当参数。Sitecore 还主动提示：4 个变体 + 1 个控制组时，实际误报率约 18%，建议 Bonferroni 校正。这是少见的「自曝其短」。
Personalize 自带轻量 CDP：能识别用户、建画像、跨有限会话保存状态，但不能访问客户画像、不能分群、不能导出数据，要用完整 CDP 才能解锁 来源。企业已有 CDP/数仓时，这部分是重复建设；只做站内实时个性化 + 实验，轻量版够用。部署是 SaaS，客户端 Boxever.js，服务端 full-stack API，没有 Adobe 式设备端 artifact，也没有 Forte 的私有化叙事。
成本与生命周期是更大的风险。Sitecore 不公开 Personalize 单价；第三方数据显示 Sitecore 整体首年总成本：中小型 7.5 万–25 万美元，中大型 25 万–75 万美元+，大型超过 100 万美元/年，实施费可能等于或超过年授权费 来源。XP 10.0/10.1 的 Extended Support 在 2026-12-31 结束，之后进入 Sustaining，安全补丁「任何价格都买不到」；XM Cloud 不包含 xDB 的分析与个性化，迁移必须单独购买 CDP + Personalize 来源。中国方面，Sitecore 没有大陆 region，XM Cloud 没有可备案的托管资源；Personalize 的数据落在境外，构成 PIPL 下的跨境传输 来源。
Sitecore 的 DMN 决策层最有表达力，但实验统计是「够用」而非「领先」，且被 DXP 生命周期绑架。它适合已有 Sitecore 栈、需要决策编排的客户；不适合无 Sitecore 栈、需要完整 CDP 但不加购、或要求仓库原生的团队。
Oracle Maxymiser：一个已经消失的参照系。 2015-09 Oracle 收购 Maxymiser，并入 Oracle Marketing Cloud；当时称每月优化超过 200 亿次客户体验。据 Monetate 的迁移说明，Oracle 在 2023 年宣布停服、生效日 2024-05-31；Oracle 官方公告本次未能直接核验（官网 403），该日期按第三方资料引用 来源。2026-10-18 复核：原产品页 404/301，Gartner 产品名改为「Oracle Maxymiser (Legacy)」来源，PeerSpot 标注「EOL」来源。三条教训：实验模块会随套件战略被砍；停服时没有「等效替代」，Oracle 其他工具可以替代部分功能，但不包括 A/B 测试；迁移成本被低估，配置、受众规则、历史报表都要重建，而公告到生效日只有约一年。合同里必须写「停服/剥离时的数据导出、配置迁移、过渡期支持」。
2.6 六平台能力对比矩阵#
先看六家 Web 套件。符号：● 原生支持；◐ 部分支持/需加购/待核实；○ 弱或无；— 不适用。
| 维度 | Optimizely | VWO | AB Tasty | Kameleoon | Convert | SiteSpect |
|---|---|---|---|---|---|---|
| 定位 | DXP 中的实验模块 | 易用型套件，合并后上探企业 | 欧洲品牌型实验+个性化+推荐 | 统计严谨的 AI 实验平台 | 公开定价的中小客户 CRO | 网络层企业级实验 |
| 典型客户 | 中大型企业、DXP 买家 | SMB→中大型 | 中大型品牌/零售/旅游 | 中大型企业、数据成熟 | SMB、代理、DTC | 大型企业、受监管 |
| 可视化编辑 | ● | ● | ● | ● | ● | ◐ |
| 服务端/Flag | ●/● | ●/● | ●/●（原 Flagship） | ●/● | ◐/◐（Pro） | ●/◐ |
| 个性化/推荐 | ●/◐ | ●/● | ●/● | ●/● | ◐/○ | ●/◐ |
| 互斥/分层 | 互斥组，无正交分层 | Enterprise 互斥组 | 1V1T/优先级，无分层 | 互斥组（跨端），无分层 | 互斥实验，无分层 | 未见 |
| Holdout | ●（global/local） | ●（FME） | ◐ 未见独立产品 | ●（Web/Feature） | ◐ 有条目，待核实 | ○ 以 control 为主 |
| 防闪烁 | Snippet/PE 边缘，PE 零闪烁 | 异步 SmartCode，待核实 | 同步 tag/SSR 锁定 | 异步+CSS 隐藏+750ms | Tracking script+Body Hiding | 反向代理，架构级 |
| 公开定价 | 询价；第三方中位约 8.1 万美元/年 | 询价（原低价） | 询价 | 询价 | 299 美元/月起 | 询价（企业级） |
| 2026 状态 | 在售，DXP+AI | 在售，合并为 Wingify | 在售，并入 Wingify | 在售，独立 | 在售，独立 | 被 Monetate 收购，品牌弱化 |
再看统计与治理。这张表最重要的不是「谁有勾」，而是「默认是什么、可选是什么、限制在哪」。
| 维度 | Optimizely | VWO | AB Tasty | Kameleoon | Convert | SiteSpect |
|---|---|---|---|---|---|---|
| 默认统计 | 频率派序贯 | 贝叶斯 | 贝叶斯 | 三选一 | 三选一 | 频率派 t 检验 |
| 可选方法 | 贝叶斯（Feature Exp.）、固定 horizon | 频率派（启动前） | 频率派 | 固定/贝叶斯/序贯 | 固定/贝叶斯/序贯 | — |
| 序贯 | ● always-valid | ● Dynamic | ◐ 仅止损告警 | ● | ● AGILE | ○ |
| CUPED | ● 仅数值指标 | ○ 未见 | ○ 未见 | ● | ○ 未见 | ○ |
| 多重比较 | FDR+Bonferroni | Bonferroni | ◐ 待核实 | ● | FDR | ◐ 待核实 |
| SRM | ● SSRM（有条件） | ● Pro | ◐ S-SRM（需 CSM） | ● Health Checks | ● SRM Check | ○ |
| 护栏 | ● Guardrail alerts | ● Pro | ◐ 弱 | ◐ 弱 | ◐ 弱 | ○ |
| 指标层 | ODP、GA4、Adobe、仓库可读 | Data360、GA4、Adobe、CDP | GA4、Adobe、Segment、推荐数据 | GA4、Adobe、数仓、OpenFeature | GA4、Adobe、Segment、GTM | GA4、Adobe、WATTS/API |
企业个性化四家的对照已在 2.5 展开，这里不再重复一张表；关键差异可以压成一句：Adobe Target 的实验最完整但绑定 Adobe 栈，Dynamic Yield 的 P(best) 只服务促销，Monetate 的 Forte 是唯一公开的私有化路径，Sitecore 的 DMN 决策层最强但统计只算「够用」。
读这张矩阵，可以提炼两个结论。
第一，基础能力已经商品化，差异在统计、治理与交付架构。可视化编辑、A/B/n、基础报表六家都能做；真正拉开差距的是 CUPED、序贯、SRM、护栏、互斥组、holdout、边缘/网络层交付。把「编辑器好不好用」放在第一权重，是把商品化能力当成了差异化能力。
第二，统计标签必须写四列：默认方法、可选方法、仅某模块、不支持指标。VWO 贝叶斯默认可切频率派，但新 Data Platform 另有引擎；Optimizely 默认序贯、Feature Experimentation 可选贝叶斯；AB Tasty 的序贯只用来止损；SiteSpect 只有 t 检验。CUPED 在 Optimizely 只支持数值指标、不适用转化率。不问清这些边界，POC 会得出错误结论。
治理则是套餐函数：互斥组、holdout、SSO、审批、自托管几乎都被锁在 Enterprise。这不是技术限制，而是价格歧视；自建时不要复制这套逻辑，否则团队会用影子工具绕开。
2.7 Web 优化套件的共性局限#
把六家放在一起看，会发现短板高度相似。这不是巧合，而是「卖给营销团队、按流量计费、靠套件 upsell」这套商业模式的必然结果。
一，指标层是套件自己的，不是企业的。 套件把指标定义、事件收集、报表都放在平台内，形成数据孤岛。Optimizely 在 2026 年补齐了仓库原生——CUPED 可以跑在 Snowflake/BigQuery/Databricks 上——但这仍是「仓库可读」，不是「指标定义在仓库」：指标口径、归因逻辑、报表语义依然由 Optimizely 定义。真正的仓库原生是把 metric definition 放在 dbt/MetricFlow，平台只负责分配、曝光、统计查询。差别在规模化时会变成「同一指标在 GA4、平台、数仓三个口径」的治理灾难，也让自定义方差缩减、异质效应、长期 holdout 分析变得困难。对 PE 持有的厂商，这不是技术难题，而是组织难题：把指标定义权交给客户数仓，会削弱平台内报表的价值与粘性。
二，统计是差异点，但不是可审计的科学。 六家的默认方法各不相同，CTW、P(best)、置信区间的话术也不统一。AB Tasty 的序贯只用于「检测输家」，不能提前宣布赢家；VWO、AB Tasty、Convert、SiteSpect 都没有公开的 CUPED；多重比较和 FDR 有的做、有的不做；SRM 常常是付费功能或人工检查；护栏指标只有 Optimizely 和 VWO 做得比较产品化。后果是：实验数量上来后，误判率不可控；「显著」被当成「有效」；业务方记住的是「CTW 95%」，而不是「效应量、置信区间、护栏是否被击穿」。CTW 本身没有错，错在把它当成上线后赚钱的概率——它是给定模型与先验下的后验概率，还依赖指标口径、样本代表性、无 SRM、无 novelty effect。
三，治理被切成套餐，规模化时最贵。 互斥组、holdout、SSO、审批、自托管几乎都在最贵套餐；中端工具没有完整的 RBAC、审计、实验台账。试点时十个人、五个实验，感觉不到问题；一旦扩到十个团队、每年数百实验，就会出现「谁都能改线上」「实验互相污染」「历史结果查不到」的混乱。更糟的是，团队会绕开平台，用 Feature Flag、前端脚本、甚至手工灰度做「影子实验」，平台的指标与治理彻底失效。
四，交付架构有物理约束，没有免费午餐。 浏览器 snippet 会闪烁；同步 tag 不闪烁但损害 Core Web Vitals；异步 + CSS 隐藏有超时和闪烁兜底；反向代理能架构级消除闪烁，但要把 DNS、证书、CDN、网关全部交出去；边缘决策只能承载规则可序列化的实验，ML 个性化必须回源。Adobe 自己就承认 On-device/CDN 不支持 Auto-Target、AP、MVT、推荐；SiteSpect 的「零闪烁」是用「改网络」换来的。任何「零闪烁」的宣传，都要追问实现层、首屏代价、失败模式。
五，实验设计原语缺失。 六家都没有正交分层、factorial design、switchback、cluster randomization、interleaving 的公开原语；互斥组只是「不重叠」，不是「正交」；MVT 是全因子组合，不是带交互效应建模的 factorial design。这意味着它们只能覆盖营销页面、内容、文案、推荐位等场景，做不了推荐/搜索/定价/社交网络/双边市场等复杂实验。对 DAU 千万级的公司，主战场恰恰在后一类。
六，供应商生命周期风险。 Maxymiser 停服、SiteSpect 被吸收、VWO/AB Tasty 合并、Dynamic Yield 被收编、Sitecore 改名，都说明「实验模块没有独立生存权」。退出成本不是「能不能导出 CSV」，而是「历史实验还能不能复现」：有没有 assignment 级曝光日志、当时的 metric 定义、config version、salt、统计方法参数。只给聚合报表、不给 assignment 级数据的厂商，停服时你拿到的只是一张结果表，无法复核。合同要写通知期、数据导出格式、迁移协助、价格保护、数据删除证明；优先选给过无停机迁移方案的厂商，避开「硬停服 + 无继任」的产品。
这六条局限的根因，是商业模式而不是技术能力。套件卖给营销团队，按 MTU/流量计费，靠 CMS/个性化/推荐 upsell；因此优先做编辑器、模板、活动运营，而不是分桶、指标治理、统计审计。理解这一点，就不会指望「买一个套件」解决平台问题。
2.8 对我们的启示#
对 DAU 千万级、研发数百人的公司，结论不是「买哪家」，而是「哪一层买、哪一层必须自己掌握」。可以把实验平台拆成六层，分别决定买、建、还是不买。
| 层 | 建议 | 理由 |
|---|---|---|
| 可视化编辑/活动运营 | 买或轻自建 | 长尾需求，自建 ROI 低；但要能导出活动配置 |
| 分桶/曝光/Flag | 自建 | 核心资产；统一哈希、salt、config version；不能被供应商锁定 |
| 指标/统计 | 自建 + 仓库原生 | 口径与可审计性；CUPED/序贯/SRM/护栏必须自己掌握 |
| 治理/审批/审计 | 自建 | 组织流程，不能外包；多租户/权限/实验台账 |
| 个性化/推荐 | 买 | 内容/商品生态，非实验核心；与实验平台解耦 |
| 网络层/私有化 | 仅受监管场景买 Forte | 部署重；不如自建反向代理/网关层 |
第一，把 Web 套件定位为「营销实验卫星」，不是核心平台。 核心平台服务推荐、搜索、增长、商业化等服务端场景；套件服务落地页、内容、活动。两者共用分桶与指标，但不共用工作流：营销要模板、审批、素材；产品要 SDK、Flag、分层、holdout。用 campaign 工具承载全公司实验，最后一定是「营销嫌统计复杂、产品嫌编辑器没用」。
第二，一套分桶、多种交付。 Optimizely 的 MurmurHash3 + Performance Edge、Kameleoon 的边缘 kit、SiteSpect 的反向代理，说明「同一套 assignment API，多种交付形态」可行。自建应把分桶、配置、曝光做成独立服务，snippet、SDK、边缘 worker 都调同一套 API；不要在三个地方各写一套哈希。曝光日志至少带 experiment_id、variant、unit_id、assignment_time、config_version、salt、surface。
第三，统计引擎要可解释、可审计。 默认序贯/always-valid，提供固定样本模式；CUPED 支持数值指标 + 仓库前两周数据；SRM 自动检测；FDR/Bonferroni；护栏指标；比率指标用 delta method；双视图——默认业务语言，一键下钻到频率派/序贯原始输出，并强制显示 SRM/护栏状态。Optimizely 的 100 个区间、VWO 的 ROPE、Kameleoon 的三方法取舍都可借鉴，但不要只给一个 CTW。
第四，指标层必须仓库原生。 指标定义放 dbt/MetricFlow，平台只做分配、曝光、统计查询；否则会变成「第三个口径」。Optimizely 的 CUPED on warehouse 是「仓库可读」，不是「指标定义在仓库」；真正的仓库原生要能版本化、血缘化、复用。
第五，治理要产品化，内部不要按套餐 gate。 互斥组、正交分层、holdout、Health Checks、审批、审计、实验台账是规模化刚需。把「谁负责口径、谁审批、谁解释统计」写进 RACI。Kameleoon 的 Health Checks、Optimizely 的 SSRM/Guardrail alerts 值得借鉴，但不要做成「只有管理员能用」。
第六，采购按「退出成本」而不是「功能清单」决策。 合同主体、路线图、assignment 级数据导出、OpenFeature/私有化、价格保护、12 个月通知期、迁移协助、数据删除，缺一不可。POC 用 3G、低端安卓、SPA 首屏实测「原版可见时长」与 CWV；要求厂商给出序贯/贝叶斯的假设、alpha 分配、多重比较校正、CUPED 窗口。Split→Harness FME 的无停机迁移是正面例子 来源；Optimize 硬停服、Maxymiser 无等效替代是反面教材。
第七，AI 用来降本，不用来替代判断。 用 AI 生成变体、配定向、写报告，把「建实验」成本降下来；但显著性判断、护栏取舍、上线决策必须由人负责。PBX 称减少 97% 建实验时间，即使成立，也只是把瓶颈从「建实验」转移到「评审与决策」。
可以买编辑器，不能买走分桶权、指标定义权和结论解释权。 实验平台不是买一个 UI，而是建一套「分桶—曝光—指标—统计—治理」的公共基础设施；Web 套件是补充，不是主干。放对位置能服务好营销团队，放错位置就是第三个口径、第二个影子平台和下一个停服风险。