Web2App的投放应用 - 金融/小贷

前几天写了一个web2app的文章，大概介绍了下原理+实现方式，还大概介绍了一下可能web2app的应用场景。

具体文章：Web2App投放现状，解决方案还是鸡肋？快速无开发实现Web2App

介绍一下近期Web2app在小贷投放上的数据和场景。

Web2app可以实现的程度：

facebook，Google，Tiktok，Kwai这些渠道均可以实现投放到网页，再从网页下载App（GP或者APK），再通过三方统计回传数据到服务端，服务端通过网页端conversion API/ pixel 把安装和事件回传给广告平台，实现类似AEO的投放方式。

应用场景： 

1，解决下架包投放到APK，应用从GP被下架后，可以直接先到网页再下载apk，不过有广告平台的监管，一般不让投放apk的页面，合规和规避还有点技巧。

2，解决渠道不让投放金融的问题，包含TT在墨西哥，或者Google在印度等都存在不让投放金融App的情况，目前看有一定概率能躲过审核。

3，多App模仿贷超一次投放多个产品的方式。在一定程度上能让用户下载多个App，降低买量成本，这个适合做贷超，或者包多的客户。

4，解决IOS投放实时数据（概率归因）+campaign数量限制。

数据：

感谢5个壮士的支持，在MX市场我们做了大概几千美金的测试，目前已经有一些基本的数据，坦白说，其实数据不理想。

1，直接投单个产品的时候，成本在多次迭代下来，基本很难达到投放GP的水平，虽然我目标是在1.2倍范围内实现APK买量，但是成本限定下基本很难跑大，（同比下架之前在GP的包）。分析下来估计用户在下载时候都还好，但是在下载后安装比例降低，或者下载过程中会中断，我们实际上可以在投放上把页面做的尽可能像GP的页面，但是用户点了下载后就不是在手机上默默安装而是会从浏览器下载，这个过程中用户you比较大概率直接停掉下载，也存在下载后用户不去找安装包点安装，大概率还存在手机会拦截等问题，这个过程中损耗都比较大，而且很难找到优化办法。

2，投放多产品方式成本还是有希望下来，这个考虑其实是一个用户在下载小贷的时候心态一般是一次多下几个，能有哪个借到钱都成功。所以多产品在一个页面的时候明显安装总数还是能提高的，但是后续转化就可能被多家稀释，可能用户并不会每个产品都去走一遍申贷流程。（这里和api贷超不同，人家只需要填写一份资料申请多家，在这边下载的是不同的包，每个包都要走一遍申请流程）这个成本导致用户后续的行为转化比例并不理想。

3，投放大部分人最后都变成了再营销，由于web2app不好直接排除各家的已安装（我们按照大家都不愿意把各自的App权限授权给我，我并不能创建受众来排除），所以最终跑下来的结果就是老包基本绝大部分转化都是跑的卸载重新安装，并且跑下来后发现注册都比较少，还有包的后端行为都是跟着注册信息走，再安装的用户不统计后续行为，导致直接后续无转化。对新包和已经下架的包还好，新包的安装比例明显好一些，下架包估计是大家不介意，回流的客户也比删了强。

4，后端行为转化率，由于用户在营销占比比较大，看数据影响比较多，但是从纯的新安装用户看来其实不是很理想，主要还是投放的行为比较靠前，来的用户不够心诚，还存在一个可能是一个用户真不能同时申请几个，用户觉得太累了，或者要等更长周期才能看出来数据。

后续投放思路：

1， 已经下架的包需要补量的，这个估计不会有什么问题，但这个跑APK其实在各个广告平台都有点红线的意思，我们现在其实是技术手段隐藏了，但是迟早会被抓，不过也保不准只要用户不举报之类估计也抓不到。

2，就做再营销，网页在Google是可以投再营销的，只是这个应用不太必要。

3，按照贷超思路或者单个客户走多产品页面方式一次投多产品，一定情况下能稀释下成本。

4，规避审查，存在失败的可能，还可能被扫到，但是好在更换域名的成本不大，打游击的时候一大堆域名+页面轮流切，比重新做包简单多了。

撇开灰色的，其实跑IOS走概率归因能实时看到一些数据转化也是个不错的思路。

技术实现细节上：前面的文章已经大概介绍了逻辑，考虑这个实现还有不少成本和技术坑，如果各位老板需要尝试web2app跑小贷，可以直接联系我们，通用的单产品页面（模拟GP）和多产品页面（应用商店产品列表思路），已经都比较成熟，核心数据回传环节也都不需要各位开发，直接在三方上授权我们渠道即可开始投放。目前MX地区已经配置好随时可以开始，印度和其他有需求的地区随时可以开始对接。

进阶方案：

考虑到前面数据和遇到的问题，其实最早还没有实现web2app的时候我实现过其他方式。

用户直接在网页上实现网页的注册，之后提交个人信息申请贷款，再直接在网页授信，或者判断资料不够，以及需要补充人脸等生物验证的时候，提示用户下载App去补资料。即便用户在网页可以授信，最后提款也还是要求用户下载App查看额度、提款等。

在这个页面上，都是各种暗示完成下一步获得更高额度等，用来激励用户完成信息采集。

数据追踪上，比我们前面的web2app走三方来说相对要多一些工作量，需要自己来开发，把广告平台的参数和用户注册的用户关联，再等用户在App或者网页完成验证可以放宽的时候根据用户的信息，找到对应广告平台参数回传，走的全是服务端的验证，当然这里也并不是不可以走web2app的技术方方法，但是有一些用户在网页完成步骤了就不好追踪到。

坏处是这个方案的开发量很大，要实现网页的注册，申请等环节，再可能还要再走一遍所有web2app的流程。

好处是这个方案其实相比直接web2app在页面的处理比直接让下载App更友好，页面做的好有希望把成本直接降低下来，并且开拓到新的流量池子。

不过这套方案，不合适乙方来做，毕竟注册以及后端行为数据都靠甲方自己做。

欢迎各位老板直接走前面纯web2app方案和我们合作。 微信：narkuh

出海流量玄学研究中心，不定期分享信息流广告优化师投放技巧，主要内容为海外facebook，google，TikTok ads广告投放技巧分享，欢迎大家关注，分享内容，也欢迎大家分享更多关于游戏出海，跨境电商广告投放技巧。

请加知识星球一起讨论投放技巧，如有疑问可在星球向我提问

长按图片加知识星球