自定义产品页（Custom Product Pages）和产品页优化（Product Page Optimization，PPO），是 App Store 上两个真正能改变产品页效果的功能，而不是「改一改文案然后祈祷」。前者是复制——同一款应用最多可以有 70 个额外的产品页，每个页面都有独立链接，各对准一类人群；后者是实验——用最多 3 组对照去和你的默认页比，最长跑 90 天，让数据告诉你能不能换。把两者搞混是最常见的错误：有的团队建了十几个自定义页去「测试」一张截图，有的团队用一个 90 天的实验去回答一个本该按人群切分就能回答的问题。
下面按真实动手顺序展开：先决定哪个工具能回答你的问题，再在 App Store Connect 里建页面或建实验、过审核、用独立链接或 Apple Ads 投放，最后在 App Analytics 里读结果并决定是否保留。文中所有数字都来自 Apple 官方文档——这两个功能和你的商品页一样，受同一套元数据审核规则约束，写错一样会被拒。
一、两个工具，两种用途
把区别说清楚，其实只有一句话。
- 自定义产品页是「很多页面服务很多人群」。你发布默认页的其他版本，每一版突出一个功能、一支球队、一个角色、一个季节或一种语言版本，用独立链接分发出去，长期在线。它是分群工具。
- 产品页优化是「一个问题，认真测量」。你做出若干「对照版本（treatment）」，随机展示给一部分 App Store 访客，让 Apple 的统计告出哪一版以至少 90% 的置信度优于原版。它是实验工具，而且会结束。
实操判断很简单：如果你已经知道对面是谁，用自定义产品页；如果你不知道两个创意哪个转化更好，跑实验。反过来行不通——实验只能告诉你「这版在一堆混合流量里赢了」，没法告诉你「RPG 玩家喜欢 RPG 截图」。
二、两个工具各自能改什么（比你想的窄）
能动的范围比大多数团队以为的要小，而这个边界决定了你能测什么。
- 自定义产品页可以替换截图、宣传文本、App 预览视频。每个页面还可以指定关键词，让这个页面在那些关键词的搜索结果里出现，替代默认页；也可以指定深度链接，用户从该页打开 App 时直接落到某个具体页面——自定义产品页的深度链接需要 iOS 18 / iPadOS 18 及以上。
- 产品页优化可以替换App 图标、截图、预览视频。图标是 PPO 独占的能力：一组对照可以换掉商店里显示的图标，连测试期间安装该 App 的设备上的图标也会一起换。自定义产品页碰不到图标。
两者都不能改应用名称和副标题。如果你真正的问题是标题，那这不是实验能解决的——那是一次随版本提交的元数据修改。
三、第一步：在 App Store Connect 建自定义产品页
入口在 App Store Connect，起点有两个：空白页，或者复制默认产品页。实操上建议复制——空白页往往意味着把已经有的素材在每种语言里再传一遍，还会丢掉你花了一个季度调出来的版式。
- 在 App Store Connect 打开应用，进入自定义产品页。
- 选择复制默认页或空白页，然后给页面起一个半年后还能看懂意图的名字。
- 按语言逐个替换截图、宣传文本、预览视频，只替换这个页面所服务的人群真正在乎的那几屏。你可以覆盖 App 支持的全部语言，也可以只做需要的几种。
- 如果希望它能在搜索里被发现，就指定关键词。Apple 的规则很具体也很容易踩：关键词必须与页面意图相符，而且同一组关键词只能属于一个页面——不能把一套词同时给三个页面。
- 可选：加深度链接（iOS 18 / iPadOS 18 及以上），让用户打开 App 后直接进到页面所宣传的那一屏。
另外，处于预订（pre-order）状态的应用同样可以使用自定义产品页。这一点对「上线前先攒人群」的团队很重要，不必等到正式上架才开始分群投放。
四、第二步：提交审核（可以和版本更新完全解耦）
自定义产品页不是一个随手就上线的编辑面板。页面里用到的任何元数据都必须提交审核，而真正有用的一点是：这件事可以独立于 App 版本更新——不用发版、不用新构建、不用动二进制。对发版排期已经排到一个月后的团队来说，这个独立性就是全部价值。
审核不是走流程。Apple 给出的「顺利通过」条件朴素得近乎无趣：截图和预览必须符合尺寸与格式规范，所有元数据必须符合 App Review Guidelines。换句话说，页面必须描述 App 真正做的事——自定义产品页仍然是你的产品页，默认页上会被拒的说法，在这里一样会被拒。
如果你要维护二十个页面、七八种语言，靠手工复制粘贴就是页面失真的开始。App Store Connect API 支持自动化上传和提交自定义产品页的元数据，这也是把「二十个页面」变成「一套一致的页面」的唯一现实做法。
五、第三步：用独立链接把它投出去
没人访问的自定义页只是一次设计练习。每个页面都有独立链接——默认产品页 URL 加上产品页 ID 参数——这条链接就是所有入口：
- 自有渠道。邮件、社媒、官网落地页、线下物料上的二维码。把 campaign 指向与它承诺一致的那个页面，而不是默认页。
- Apple Ads。自定义产品页可以用于做 Search 标签页广告、Today 标签页与搜索结果广告，也可以做广告变体，让每个广告组落到为它量身做的页面；页面上的深度链接再把人直接带到 App 内的那个位置。
- 其他 App 与网页内。广告网络可以通过
SKOverlay或SKStoreProductViewController传入自定义产品页标识，渲染 StoreKit 广告并直接打开指定页面，而不是落到默认页。 - 编辑推荐位。自定义产品页有机会出现在 Today、游戏、App 标签页的编辑精选故事与合集里。
两个运营细节：一是把独立链接当成资产来管——版本化、和它所属的 campaign 存在一起、付费投放前先确认链接还能打开；二是让承诺对得上，如果页面截图展示的是某个模式，而用户装上后默认看到的不是它，第一天就产生落差，你买来的转化在第七天就蒸发掉了。
六、第四步：在 App Analytics 里读真实的数
页面上了线，唯一会为它记账的地方是 App Store Connect 的 App Analytics。在 Acquisition（获取）标签页里，你能看到每个页面的产品页展示次数、下载量、重新下载量和转化率，于是比较的对象是「这个页面 vs 你的默认页」，而不是「这个页面 vs 你的感觉」。
Apple 公布的一个总体数字值得当作起点参照：把用户引到自定义产品页的开发者，转化率平均提升 2.5 个百分点——而默认产品页的平均转化率约为 1.6%。请把它理解为「被引导的流量」上的结论，而不是「建十个页面就能抬高基线」的承诺：提升来自素材与人群的匹配，那是工作，不是配置。
更深一层是质量。App Analytics 也能回答：从自定义页安装的人是否留存更久、内购花得更多；每个页面的留存数据、每位付费用户的平均收益都能单独看。一个页面完全可能同时做到「转化率上升、单用户收益下降」——分群页面常常吸引更窄、意图更低的人群。两个都要看，用「每次展示带来的收益」而不是「安装量」来判定成败。
七、第五步：配置产品页优化实验（一次只能一个）
PPO 同样在 App Store Connect 里配置，约束很硬，配错一次就浪费一个季度。它运行在 iOS / iPadOS 15 及以上，并且同一时间只能有一个实验。
- 起一个未来的你看得懂的名字。参考名称最多 64 个字符。「春季图标配色测试，3 个图标，英/德」远远好过「测试4」。
- 最多三组对照。每组对照是一个替代页面，可以有自己的图标、截图、预览；没有替换的部分继续沿用原版。对照组越少越快出结论——加得越多，越难把信号从噪声里分出来。
- 分配流量比例。你选择随机抽多少比例的访客看到对照版本。Apple 自己的例子：分配 40% 流量、做两组对照，则每组各得总流量的 20%，原版保留 60%。同一位访客在整个实验期间始终看到同一组对照，比较才干净。
- 有意识地选择语言。每组对照可以覆盖 App 支持的全部语言，也可以只选其中几种；但语言越多，流量被切得越碎，出结果越慢。
- 先估时长，再决定要不要开始。可选的估算器会依据你期望的转化提升幅度、以及 App 现有的展示量与下载量，算出预计时长，以及要达到至少 90% 置信度需要多少展示量。如果估算超过 90 天，就去改条件——减少对照、提高流量占比——而不是开一个注定跑不完的实验。
实验会跑满 90 天或直到你手动停止，而且一旦开始就不能再改。请把配置页当成只能填一次的表单：中途调整流量比例、替换一张截图都不允许，所以按下开始之前就要想清楚。
八、第六步：先过审核这道门
PPO 有自己的审核机制，这一点最容易被「实验是内部的事」这个误解绊倒。
- 新元数据要过 App Review。对照版本里新加的截图、预览、图标，必须在实验发布前获得审核通过。
- 备用图标必须打进二进制。如果某组对照包含备用 App 图标，这个图标的所有变体都必须包含在你已发布 App 的二进制包里。只存在于 App Store Connect 的图标，装不到任何设备上。
- 不含图标的实验可以单独送审。只改截图或预览的实验，可以独立于新版本提交审核——和自定义产品页拿到的自由度是一样的。
涉及图标的实验要倒着排期：带着这些变体的二进制必须先成为线上版本，实验才能开跑。所以图标测试通常要和一次版本提交绑在一起，而不是找个清闲的周顺手开。
九、第七步：读结果、应用胜出版本、闭环
实验进行中，App Analytics 会显示一个仪表盘，告诉你还需要更多数据，还是某一组对照已经明显优于或劣于基线。每组对照能看到展示次数、转化率、提升百分比和置信度，你还可以随时切换基线，让对照之间互相比。
Apple 的建议很明确：等到至少有一组对照以 90% 置信度被判为优于或劣于基线，再做动作。把某组对照应用到原版页，就等于对所有访客展示它——如果实验还在跑，这个动作会直接结束实验。所以顺序是：先到置信度，再应用，然后确认应用上去的素材确实是你想上线的那一套。
还有一个经常被漏掉的收尾动作：如果应用的这组对照包含备用 App 图标，你在下一次提交新版本时，必须把这个图标一并包含在 App Store Connect 的版本信息里。商店侧和二进制必须一致，否则下一次提交又会把旧图标带回用户设备。
十、合规那一层：不到被拒不会有人读
这两个功能本质都是元数据，而元数据按 App Review Guidelines 审——最常出事的是第 2.3 条（Accurate Metadata，准确元数据）。真实的失败案例长这样：
- 截图展示的是用户拿不到的版本。概念图、把付费墙后的功能演示成免费功能、暗示支持你并不支持的硬件。
- 宣传文本或预览承诺了 App 做不到的事——保证、不是真实价格的「价格」、把三天试用说成免费。
- 关键词与实际页面不符。Apple 要求指定关键词与页面意图相符、且同一组关键词只属于一个页面；把竞品品牌词塞进一个毫不相关的页面，就是把一次营销实验变成一次账号问题的典型做法。
- 多语言版本各自漂移。英文页改对了，德文页还留着旧说法——在德国市场，那依然是一个有误导性的页面。
这些都不高深，就是把「商店元数据必须真实」这条日常纪律，应用到一个比单一商品页增殖快得多的表面上。也正因如此，真正在跑几十个页面的团队会把上传自动化，并且按语言维护同一份审核清单。
十一、KappS 在这件事里的位置
KappS 做的是账号与发布这一侧：让开发者账号、付款与税务资料、商店元数据保持在经得起 App Review 的状态——协助准备与合规提交材料，而不是绕开任何检查。对于要规模化运营自定义产品页的团队，通常落在三件事上：
- 账号健康。Apple Developer Program 账号、协议、税务与收款信息保持良好状态，避免页面提交被一个毫不相干的行政冻结卡住。
- 多语言元数据一致。对声明、价格、截图建立唯一事实来源，英文改一次能同步到所有语言，而不是在另一个市场继续留着一个过期的承诺。
- 送审准备。在页面进入审核前，按第 2.3 条再核一遍截图、预览与宣传文本；并用 App Store Connect API 的路径把页面批量上传、批量提交，减少手工出错。
我们不提供「转化率翻倍」的包装、不卖安装量，也不做承诺 App 做不到的事的元数据技巧——那些是通向「页面被拒」「账号被拒」甚至两者同时发生的最快路径，也不是我们提供的服务。这件事真正稳定的做法很朴素：让页面对准人群、在上面说真话、然后用数据看它到底带来了什么。
资料来源（Apple 官方文档）：App Store — Custom Product Pages（developer.apple.com/app-store/custom-product-pages）；App Store — Product Page Optimization（developer.apple.com/app-store/product-page-optimization）；App Review Guidelines 第 2.3 条 Accurate Metadata；App Analytics — Acquisition。