为什么成人分类广告应用永远通不过应用商店审核,该做什么来代替它

早晚有一天,经营分类广告目录的人都会问自己一个问题,和每个移动服务创始人在头几个月都会问的一样:这需要一个应用吗。听起来是显而易见的下一步。主屏幕上的图标,新消息或已审核广告的推送通知,一种比网站更正式的感觉。团队里有人把网站打包成应用,提交上去,几天后收到的拒绝理由跟漏洞或缺失的隐私声明毫无关系。它被拒绝,是因为这门生意本身是什么,而不是什么可以修好再重新提交的问题。

这是在投入任何开发时间之前就该弄清楚的部分。苹果和谷歌不会逐个应用地判断你这个特定目录是不是管理得好、审核得当,或者是否完全符合你所在国家的法律。它们多年前就已经白纸黑字地决定了,这类生意在它们的平台上没有立足之地,没有商量余地。接下来要说的是规则实际写的是什么,为什么不存在任何一种干净、合法、有年龄验证的市场配置能绕开它们,以及一个不依赖这两家公司改变主意的移动端形态是什么样子。

规则实际是怎么写的

苹果的《App Store 审核指南》在"令人反感的内容"部分第 1.1.4 条直接谈到了这一点。措辞并不含糊:应用不得包含"露骨的性或色情材料",该条款接着说,这"包括'约会'类应用,以及其他可能含有色情内容,或被用来协助卖淫、人口贩运和剥削的应用"。注意这句话在做什么。它禁止的不是露骨图片,反正分类广告目录本来也不需要展示这些。它禁止的是把协助卖淫作为功能的应用,不管广告文案怎么写、图片怎么裁剪。一个用得体、穿着整齐的资料照片和预约表单组成的目录,仍然是一个协助该条款所指之事的应用。

谷歌 Play 的政策在点名这一类别上甚至更加直白。它关于性内容的规则规定,谷歌不允许应用或应用内容"宣传或招揽以获取报酬为条件的性行为",政策还举出了一个具体例子:"宣传与性相关的娱乐、伴游服务,或其他可能被解读为提供或招揽以获取报酬为条件的性行为的服务"的应用。伴游服务被直接点名,而不是含糊带过。谷歌更进一步,单独禁止了"付费约会或性安排,即一方被期待或暗示要向另一方提供金钱、礼物或经济支持",也就是通常所说的"糖爸糖妈"关系。之所以多出这一条,是因为有运营者曾试图用更委婉的措辞描述同一种生意,谷歌于是专门堵上了这个口子,而不是留给解释空间。

值得弄清楚为什么普通的约会应用完全不受这些影响。Tinder、Bumble 和类似应用能留在两个应用商店,是因为它们宣传的功能里没有任何一项涉及为性安排提供报酬。这是两个平台都在划的那条线,是一条功能上的界线,而不是语气上的界线。一款约会应用在营销上可以尽情性感,一个分类广告目录也可以按创始人的意愿做得像做生意一样冷静专业,结果都不会改变,因为要问的问题从来不是"这看起来体面吗",而是"这是否协助了付费的性安排"。一个目录从设计上就对这个问题给出了肯定的答案,而这就是整个产品。

为什么没有取巧的绕开办法

新运营者在接受这一点之前,通常会尝试两件事之一。第一种是在商店的应用介绍里用含糊、跟类别无关的措辞描述应用,把它叫做"社交发现"或"高端陪伴"应用,而一旦审核员打开它,实际功能仍然符合被禁止的模式。这行不通,因为两家商店的审核团队都会打开应用,走一遍流程,遇到含糊的类别通常还会创建一个测试账号,像真实用户一样浏览广告。再打磨的介绍文案,也改变不了审核员三十秒后在屏幕上看到的东西。

第二种尝试是拆分:一个只能浏览资料的"干净"应用,配合一个网页支付或外部链接来完成真正的预约或付款,想法是把报酬环节留在应用之外就能绕开规则。这误解了两家政策实际在审查什么。苹果关于用户生成内容应用的条款写得足够宽泛,足以覆盖那些主要功能是把用户引导向受限活动的应用,即便交易本身在别处完成;审核过程中会跟踪外链,恰恰是因为这种模式在许多受限类别里都很常见,不只是这一类。一个存在的目的就是浏览一份付费陪伴广告清单的应用,才是被审核的那个应用,而不是最后那一步付款。

尝试这两种绕开办法中的任何一种,都有第二重代价,比单纯的拒绝更严重。一次直截了当的拒绝,即应用被诚实归类,只是恰好落入某条内容规则,两家平台都会照单全收地当作一次拒绝处理。而在元数据里用一种方式描述应用,安装后实际功能却是另一回事,这在审核团队看来读起来就不一样了,更接近试图误导他们,而不是善意的分类错误。苹果的开发者协议给了它充分的依据,可以因为不诚实或误导性的提交对账号采取行动,这与普通的内容拒绝是分开的,也更严重;反复重新提交同一个被拒应用的伪装版本,正是那种会升级处理的模式。现实的风险不是一个被拒的应用消失了。而是一个绑定着公司名称、银行账户以及注册在其下的每一个其他应用的开发者账号,会被一次性整体拉下,只因为一个不管怎么描述都永远不会被批准的应用。

这些都不是对这门生意本身的评判。它在自己的司法管辖区内完全可以是合法的、审核得当的、年龄验证正确的,却仍然通不过这项测试,因为这项测试与合法性或审核质量毫无关系。这是一家私营公司的产品政策,写出来就是为了把整个类别彻底排除在外,而不是去评判其中每一个具体的运营者。

该做什么来代替它

替代方案不是因为预算不够而退而求其次的选择。它是这类目录能够真正长期保有的唯一移动端形态,因为它不是从一家已经白纸黑字表明不会接纳你的公司那里租来的。用网页清单和 Service Worker 构建的移动网页应用,可以带着自己的图标被添加到手机主屏幕,以全屏方式打开、没有浏览器界面,在用户看来的表现就跟安装过的应用一样。这一切都不会经过苹果或谷歌应用商店的审核,因为它根本不是通过这两家分发的。适用于它们市场里应用的内容规则,根本不适用于一个网站,网站在两个平台上受到的都是宽松得多、也更通用的浏览规则约束。

推送通知能补上跟原生应用之间剩下的大部分差距。安卓上的网页推送已经很成熟,运作方式和原生通知一样。在 iOS 上,主屏幕网页应用从 16.4 版本起就能接收推送通知,这如今已经覆盖了几乎全部在用的 iPhone。把目录添加到主屏幕的用户,可以像使用下载的应用一样,收到新消息、广告审核通过或验证完成的通知,而这两家公司都不需要审核它、批准它,也没有能力把它撤下来。

这也消除了一种在结构上与运营者已经在基础设施提供商那里遇到过的问题完全相同的依赖关系:一个条款公开、答案早已可以预知的平台,它可以按自己的时间表终止合作,不管这门生意本身表现如何。这一类别在应用商店里的一个页面,不是那种可能在某次政策审查后才显现出来的慢性风险。它是一个有据可查、可引用的规则背后的确定拒绝,这也让它成为最容易直接避开、而不需要去管理的基础设施风险之一。

运营者真正需要决定的事

第一个决定不是技术问题。而是一个应用到底能不能解决它本该解决的问题。创始人通常想要两件事之一:一种让自己像主流应用那样容易被发现的方式,或者一种不需要向浏览器请求权限就能发送推送通知的方式。不管能不能获批,应用商店搜索都不是这一类别的现实获客渠道,因为这么具体的一个页面在还没能为任何词排上名次之前就会被下架,所以即便在最理想的情况下,曝光这个理由也站不住脚。对分类广告目录已经行之有效的自然流量和直接流量策略不受有没有原生应用的影响,因为它们没有一个是走应用商店搜索这条路的。

有一个更窄的类别值得了解,因为它跟面向公众的市场类应用真的不一样,有时也可行:一个供已验证广告主管理自己广告、消息和账号的操作工具,不面向公开搜索,本身也不会向应用商店用户展示一份可浏览的付费陪伴目录。这更接近普通的商业管理软件,虽然提交前仍然需要仔细阅读当时有效的指南,因为界线恰恰取决于这个应用向谁展示了什么内容,但它不会自动落入禁止面向公众的目录类应用的那条规则。

对其他所有人来说,答案是不要再把缺失的应用图标当成需要道歉或者迟早要补上的东西。取而代之的是把移动网页体验做扎实:一个带真正清单文件、能快速加载、可安装的网站,一个在恰当时机(而不是页面一加载就跳出来)显示的"添加到主屏幕"提示,以及用户真正主动订阅的推送通知。这在这里不是备选方案。这是唯一一种不会以拒绝信收场的移动端策略,如果一意孤行还想蒙混过关,等着的就是一份账号封禁通知,而这门生意本来就从未有机会被放行。