当团队选择用于流量仲裁的 Apple Developer 账号时，问题几乎总是相同的：选择哪种账号类型（Individual 还是 Company），选择哪个 GEO，账号在首次发布前需要“养”多久。在聊天群里，人们通常用个人经验来回答这些问题。但是， 在一个团队中行之有效的方法，在另一个团队中可能行不通。
本文基于 SmartShop 的观察。 该服务提供 Apple Developer 账号，并与流量仲裁团队、开发者和工作室合作。在此期间可以明显看出，团队分为三种类型。每种类型都有其典型的错误，提前了解这些错误会很有帮助。
为什么不存在“最容易过审的”账号
Apple 会审查整个应用，而不仅仅是账号。 影响决定的因素包括：
- 账号；
- 应用代码；
- 构建版本（包）；
- 名称、描述和截图（元数据）；
- 设计；
- 团队如何回复审核员的意见。
因此，“GEO + 账号类型 + 养号时间”的完美组合是不存在的。 如果某个方案在别人的项目中奏效了，这并不意味着它在你的项目中也会奏效。
问自己一些其他问题会更有用。你到底在测试什么？在每次尝试之间你改变了什么？你如何记录结果？ 在没有答案之前，在 Individual 和 Company 之间做选择解决不了任何问题。
类型 1. 新手：寻找现成的方案
这是什么样子的。 团队阅读了聊天群和论坛，收集了别人的案例，并计划发布一个 WebView 应用（这是一个 - 打开网页的“外壳”应用）。目前在开发、提交审核和维护应用方面的经验还很少，因此主要时间都花在寻找“正确”的参数组合上。
典型错误。
- 计划中没有为失败的尝试留出余地。
- 团队过早开始扩大规模。
该怎么做。 在购买账号之前，请回答五个问题：
- 有多少预算用于开发、账号和重新提交？
- 团队准备花多少时间进行测试？
- 谁来处理 Apple 的意见和技术问题？
- 如果最初的几次尝试没有通过，是否有足够的资金继续下去？
- 你将如何记录结果，以便从每次尝试中吸取教训？
有几个应用获批并不意味着流程已经稳定
常见的情况。首批应用通过了审核，团队认为一切正常，并购买了大量账号。然后开始被拒，而资金还在按照成功时制定的计划继续花费。
三到五个获批的应用 - 不足以得出这样的结论。 最好立即将第一笔利润的一部分预留出来，用于测试、改进和流程发展。 即使开局良好，工作也可能会放缓数周或数月，你需要在这方面做好资金和组织上的准备。购买的账号数量应该与团队实际能够准备、测试和维护的数量相匹配。
类型 2. 取得初步成功后的团队：混乱的变更
这是什么样子的。 团队已经发布过应用并获得了初步结果，但新的一批表现较差。于是开始盲目尝试：更换供应商、更换 GEO、更换账号类型、更换开发者或设计。周围充斥着来自聊天群的建议和卖家的承诺。
典型错误。团队一次更改多个参数。 结果不清楚到底是什么影响了结果。变化很多，但对原因的理解却越来越少。
该怎么做。
- 按顺序寻找原因：账号、代码、构建版本、包装设计、意见处理。
- 每次只更改一个参数。
- 记录提交日志。 以下几列就足够了：
| 记录什么 MD | 为什么记录 MD |
| 账号（类型、GEO、购买地点） | 比较不同的批次 |
| 构建版本 | 查看代码中发生了什么变化 |
| 与上次提交相比做了什么更改 | 了解是什么影响了结果 |
| 名称、描述、设计 | 不丢失以前的版本 |
| Apple 的回复（日期和正文） | 注意到重复出现的意见 |
| 每次尝试的成本 | 计算真实的经济效益 |
别人的案例和传闻可以作为测试的思路。但是 必须在你们自己的应用、团队和预算上进行测试。
类型 3. 经验丰富的团队：因缺乏新测试而停滞
这是什么样子的。 团队知道他们需要哪些账号以及需要多少数量，清醒地计算支出并做好了被拒的准备。但即使是这样的团队，在采购和发布方面也会出现暂停，有时是一到几个月。
典型错误。当一切顺利时，团队停止了流程的发展。 他们建立了 10–20 个跑通的转化链路 (flow)，并将所有精力投入其中。然后，部分转化链路失效了。有时如果它们有共同的要素，甚至会全部同时崩溃。没有备用方案，团队不得不在维护当前项目的同时寻找新的解决方案。
该怎么做。
- 不断分配时间和资金进行新测试，即使主要工作进展顺利。
- 改进代码，测试新方法，完善构建和发布流程。
- 检查不同转化链路之间有哪些共同要素，以免一个问题导致一切同时停滞。
iOS 应用的“基础设施”包括什么
基础设施 - 不仅仅是账号，而是应用从想法到维护的整个过程：
- 代码和使用的组件；
- 构建并上传应用到 App Store Connect；
- 开发者账号、访问权限和团队中的角色；
- 名称、描述、设计和功能说明；
- 审核后处理修改意见；
- 记录每次尝试之间的支出、结果和变更。
如果流量通过网页漏斗引入，还会增加落地页、分析和流量分配。这部分内容在 关于使用 Cloaking.House 进行 iOS 流量细分 的文章中单独进行了分析。
三大核心原则
1. 测试假设，而不是轻信承诺。 谨慎对待诸如“这个 GEO（或账号类型）保证过审”之类的说法。一个成功的案例只能提示你值得去测试。但是 关于扩张的决定最好基于一系列的结果来做出。
2. 为被拒预留预算。 提前计算好最坏的情况。例如，提交的 100 个应用中只有 5–10 个通过了审核。这不是预测，而是一种了解你是否有足够抗风险能力的方法。将所有支出（开发、账号、团队工作）与已盈利应用的收入进行比较。开始前最大的问题是：如果最初的几次尝试失败，或者发布停滞了几个月，你能否继续测试？
3. 不要依赖单一供应商，也不要停止发展。 从不同供应商处购买账号并比较条件：库存、期限、交付质量、支持服务、承诺兑现情况。这样你对单一渠道的依赖就会减少，也能更快地积累经验。要将供应商的质量与具体提交的结果分开评估： 通过审核的是应用，而供应商只对其负责的那部分工作负责。
选择账号供应商。 如果需要定期购买账号，必须提前了解可用的类型和 GEO、交付期限、访问权限的验证程序以及支持条件。根据 SmartShop 的观察，无论是新手团队，还是已经建立好发布流程的团队，都会面临这些任务。同时，供应商的经验之所以有用，并不是因为它是通用方案的来源，而是因为它提供了一个更好地组织采购的机会：确定所需账号的数量、协商条件并避免不必要的开支。代码、元数据和处理 Apple 的意见仍然是团队的责任。因此，区分账号质量和应用审核结果非常重要。 这种方法有助于更准确地找出被拒原因、控制成本并构建更稳定的流程。
总结
在 iOS 流量仲裁中带来稳定结果的不是“秘密方案”，而是一个清晰的流程：可测试的假设、提交日志、预算储备和持续的测试。 在采购之前，请确定团队能够准备、测试和维护多少个应用，并根据这个数量来选择账号和供应商。
成为第一个分享看法的人！
我们重视您的反馈——欢迎分享您的看法。