PMax、Shopping、Search 不是三选一：用角色组合，而不是平台偏好

PMax、Standard Shopping 与 Search 的选择，不应由“哪个最近更流行”决定。三者解决的控制问题不同：Search 管已知查询，Shopping 提供更可读的商品流量，PMax 用更宽的库存和自动化寻找增量。成熟账户往往需要组合，而不是押注单一类型。

先做判断

先判断当前最缺的是控制、发现还是规模。查询边界混乱、品牌污染严重时，需要提高可读性；已有赢家商品却覆盖不足时，需要扩量；完全没有可靠转化和 Feed 时，任何自动化都会放大错误输入。

因此顺序不是“先建哪个”，而是“哪一种容器最适合承担当前任务”。没有明确任务的组合会形成内部竞争；有角色契约的组合可以让 Search 保护高价值意图，让 Shopping 检查商品匹配，让 PMax 发现长尾和跨库存机会。

三角色组合框架

控制层：Search。 放入必须精确承接的品牌、高价值非品牌与已验证查询。文案、关键词和落地页可以形成明确接口，适合保护核心意图与测试主张。

可读层：Standard Shopping。 适合需要看商品与查询关系、Feed 尚在迭代、预算较小或要建立基线的阶段。它不是“旧方案”，而是诊断工具：当 PMax 结果无法解释时，可读性本身就是价值。

探索与扩量层：PMax。 适合转化、Feed、页面和利润口径已稳定后，探索未覆盖查询、放大赢家商品或跨更多库存寻找转化。PMax 的受众和搜索主题更接近输入线索，不等于硬定向；品牌、URL、商品和否定边界才是核心控制。

组合时给每层写输入与退出条件。例如探索层发现稳定高价值查询后，迁入 Search 精确管理；赢家 SKU 可以从发现池迁到独立放大池；反复错配的商品先回 Feed 与页面修复，而不是提高预算。具体迁移步骤见三类 campaign 迁移手册，结构边界见从业务推账户结构。

迁移决策矩阵

• 数据少、Feed 未验证：先用可读结构建立基线，限制商品范围。
• 查询已验证、需要主张控制：用 Search 承接，并设置 PMax 的品牌与查询护栏。
• 商品已验证、希望找增量：小范围 PMax 扩量，保持对照组，不直接全量迁移。
• PMax 高回报但业务不增长：拆品牌、再营销、非点击归因与渠道贡献，先验证增量。
• Shopping 与 PMax 同时跑：按当前平台规则核验竞价与优先级，避免使用过期经验做结论。

常见误判

• 认为 PMax 自动化程度高，所以不需要 Feed、页面和利润边界。
• 认为 Standard Shopping 一定会被 PMax 压制，未用实际展示与查询数据验证。
• 把 Search 与 Shopping 同时出现当作必然蚕食；不同广告格式可能互补，关键看增量和成本。
• 全量切换后才比较结果，导致季节、预算和学习状态一起变化，无法归因。

验证清单

• 每种 campaign 只有一个主角色：控制、可读诊断或探索扩量。
• 品牌、非品牌、再营销和新客口径可以分别查看。
• 商品集合、URL、查询和否定边界在各容器间无意外重叠。
• 迁移保留对照与基线，观察窗覆盖转化延迟。
• 平台收入同时用后端订单、利润和新客结果校准。
• 当前竞价优先级、报告能力与排除设置已从官方资料回查。

适用边界

本框架面向有商品 Feed 的电商账户。服务型获客虽然也可使用 Search 与 PMax，但应把商品分组替换为线索质量、CRM 回传和销售阶段，不能照搬电商结构。平台会持续调整查询透明度、竞价规则和自动化设置，执行前必须验证当前能力；文章提供的是角色逻辑，不是固定界面教程。