iOS 15 引入 Custom Product Pages（CPP）后，开发者已可为单个 App 创建最多 70 个页面变体。能力变强了，但页面同步、关键词分配、归因分析和审核维护成本也明显上升。 真正的难点在于，每个 CPP 都可能维护独立的截图、预览视频、推广文本和关键词；一旦主产品页更新，多个变体很容易出现信息滞后。若同时改动素材、文案与投放受众，后续也很难判断到底是哪一个变量驱动了转化变化。

用“场景 × 受众 × 渠道”矩阵决定是否创建 CPP，而不是为了把名额用满。把 CPP 当成精细化承接页和搜索补充页来管理，优先确保可维护、可归因、可复用。

具体执行时，首先，构建 CPP 矩阵：横向为受众（新用户/流失用户/特定渠道），纵向为场景（特定功能/地区节日/合作活动），仅对矩阵中有数据需求的方向创建页面；其次，不要把 CPP 理解成只能改截图。根据当前 App Store Connect 规则，CPP 可以配置独立的 screenshots、app previews、promotional text 和 keywords，并可通过关键词让页面在搜索结果中显示；但它不是重新命名应用标题 / 副标题的工具；同时，每次主产品页更新截图时，建立 checklist 同步更新所有 CPP 的对应元素（如版本号、UI 变化）。

在持续优化和复盘阶段，此外，通过唯一 URL 分发不同 CPP，并在 App Analytics 的 Custom Product Pages 维度中观察 impressions、downloads、conversion rate 以及后链路价值，而不是混用 PPO 数据口径；最后，定期清理低价值页面：优先下线长期无流量、定位重复、素材过时的 CPP，把维护精力留给真正承担获客任务的少数页面。