PMax、Shopping、Search 迁移手册：保留基线，不做全量跳切

三类 campaign 的迁移应当是一连串可回退实验，而不是“关旧开新”。全量跳切会同时改变学习、查询、商品、预算和归因，结果再好也难以复用。

先做判断

先写迁移目的：提高查询控制、恢复商品可读性、扩大赢家商品，还是减少品牌污染。没有目的，只因为“PMax 应该更先进”或“Shopping 更透明”而迁移，通常会制造新的结构噪音。

执行前必须通过四个闸门：追踪可信、Feed/商品健康、页面可承接、利润护栏明确。否则迁移只会换一个容器继续承载坏输入。

七步迁移流程

一，保存基线。 记录至少一个完整业务周期的花费、查询、商品、品牌/非品牌、订单、新客和贡献利润，并保存重大变更时间线。

二，定义角色。 Search 管已知高价值查询；Shopping 提供商品与查询可读基线；PMax 负责限定范围的发现或放大。每种容器只设一个主任务。

三，选最小子集。 按库存、毛利、历史需求和页面准备选择商品或查询，不全目录迁移。对照组保持原目标、预算和促销条件。

四，设置边界。 核验品牌、否定、搜索主题、URL、商品与地域边界，避免新旧容器无意抢同一任务。具体平台优先级执行前回查官方。

五，运行完整观察窗。 覆盖学习与转化延迟，除硬故障外不连续改动。比较总业务增量，不只比较 campaign ROAS。

六，晋升与淘汰。 稳定高价值查询迁入 Search；赢家商品进入放大单元；错配商品回 Feed/页面修复；低质查询在适当层级排除。

七，分批转预算。 只有子集通过利润、新客和稳定性闸门，才逐步转移下一批，并保留上一稳定档位。

角色设计见PMax、Shopping、Search 组合指南；完整复合过程见Shopping/Search 迁移案例。

迁移判定表

若目标是解释 PMax 下滑，先回到小范围 Shopping；若 Shopping 已找到稳定查询，迁入 Search 控制消息；若 Search/Shopping 已验证商品和利润，PMax 可承担扩量。若迁移后只是平台归属变化而总订单不变，不算成功；若平台 ROAS下降但非品牌、新客和利润改善，可能反而更健康。

每阶段提前定义失败：达到花费护栏仍无有效下游信号；品牌/老客占比超出角色；主要商品无曝光；页面或 Feed 出现硬故障。失败时回到上一稳定结构，记录证据，不复制同样设置重启。

常见误判

• 全量切换后用前后周比较，忽略学习、季节和商品变化。
• 只迁 campaign，不迁品牌、否定、URL 和商品所有权。
• 看到一个查询成交就晋升 Search，没有验证可重复性与利润。
• 新结构表现差时继续加预算，未使用预设回退条件。

验证清单

• 迁移目的、角色、主指标与利润护栏书面明确。
• 追踪、Feed、页面与结账在执行前通过。
• 基线覆盖查询、商品、品牌、新客、订单和利润。
• 从可回退商品/查询子集开始，对照条件保持一致。
• 观察窗覆盖转化延迟，期间只处理硬故障。
• 晋升、淘汰、预算转移和回退都有预定义规则。

适用边界

本手册适合有足够数据做子集对照的电商账户。极低量账户可顺序测试而非并行，避免信号更碎。平台查询路由、Shopping 与 PMax 竞价、品牌/否定能力会更新，迁移前必须核验当前官方规则；本文不给固定观察天数或转预算比例。