Reliable source: Meta is about to launch its own web2app solution, currently in the whitelist application phase. From the Meta backend images, it appears the solution is already developed. When setting up a campaign, you…
可靠消息： Meta即将推出自己的web2app方案，目前应该是在白名单申请阶段。 从看到的后台图片观察，目前已经开发好，并且投放时候直接填写网页的下载地址，无需单独对接，可以再网页再单独接一些pixel代码，但是也可以不接，不需要通过三方中转数据，也可以不搞conversion api对接之类，直接实现Facebook自己归因的web2app。 猜测原理： Facebook自己实现了一套“概率归因”逻辑，从Facebook内点击广告的用户，有一大堆的基本用户信息（非敏感类），比如ip，设备基本情况等，用户点击广告后再安装APP（无所谓从什么形式，包含去商店了，或者直接推广了apk），只需要这个APP内配置了Facebook sdk，或者通过三方把基本信息回传给到Facebook，都可以再根据回来的数据实现归因匹配，基本等同于他用自己的一套算法实现了“概率归因”。 好处： 1，不用通过三方先实现概率归因，再将数据回传给到Facebook，直接Facebook自己归因，大概率要归因到更多数据，之前三方会有拦截，损耗等等，现在不需要了。 2，省了三方的钱，有多少人是因为要搞web2app接的三方（ 三方：MMP）。 3，省了开发精力，但是肯定还得自己做个落地页，估计审核的也会严格。 使用场景： 1，不能上架的产品推apk，不过这只是技术方案，大概率后面不会开放给小客户，必须直客白名单用，免得给灰产利用。或者开放了，使劲封。 2，主力小说，短剧之类，尤其是iOS，通过自己的web2app，加落地页带上DDL ! 等等…IOS+DDL+W2A 概率归因？这是要办大事啊….先不能说了，政策上不一定可行。 广告： 等FB官方的web2app可能不确定啥时候能有，用三方的web2app还要自己折腾对接和落地页。找我们…安排商务给你对接+落地页都做好（基于三方AF+ADJ回传数据实现），0基础实现，以前还说让你们看我后台，现在省心了，全包服务到位…(没有给钱解决不了的技术困难）
What is Web2App? Web2App is a method for promoting mobile applications (Apps) through web advertisements. Users can download the app by clicking on an ad link while browsing a webpage. Unlike direct promotion in app…
什么是Web2App？ Web2App 是一种通过网页广告推广移动应用（App）的方法。用户在浏览网页时点击广告链接，即可下载应用。与直接在应用商店推广不同，Web2App可以直接下载APK，提供了针对无法通过Google Play获取应用的追踪解决方案。 Web2App的关键点 在追踪方面，App广告通常使用第三方或Facebook SDK、Firebase等工具直接追踪，而Web2App需要通过网页广告重新对接追踪技术来实现。 注意： 对于大多数产品，Web2App增加了转化步骤，可能导致用户流失和更高的成本。适合在以下场景使用： Web2App的基本原理 Web2App通常依赖第三方统计工具，对接SDK，再连接Facebook的Conversion API，Google通过Pixel并走GA4回传参数。主要过程包括： 其他平台的原理类似，通过参数传递和第三方回传实现追踪。这一过程复杂，通常需要两周以上研究时间，且可能遇到各种问题，如安装追踪不到后续事件，或者安装信息无法和广告关联等。 Web2App的应用现状 常规产品一般不需要Web2App，因为增加步骤后成本难以控制。测试显示，Web2App主要适用于解决Google Play上架问题或产品审核难度高的场景。 潜力领域包括小说、资讯、漫画等，通过网页展示免费内容，再引导下载App查看更多。金融类产品可在网页上完成大部分流程，仅在App中进行生物验证和放贷环节，可能降低整体成本，增加流量空间。 对于灰色产品，Web2App可部分解决无法投放的问题，但并不完全规避审核风险。规模过大时仍可能被广告系统检测到。
Web2app 这个事情差不多搞了两个多月之后，现在差不多也越来越清晰。最近甚至已经把web2app的自动优化价格预算都做完。但是还是有必要把最近的一些投放做一下做节。 重点结论： 1，不到万不得已，不要去折腾自己开发（走免开发的成熟方案另说），收益率太低。 2，仅有用户有“刚需”的产品才有成功几率，或者就直接是扛得住高价的产品。也有一部分是有天然优势的项目可以尝试。 3，投放成本，无论多努力，都无法达到直接投商店包的成本。 4，搞灰色项目的，正常就封户严重，加上web2app思路封户这会更严重，可以想办法规避，但是探索的周期会很长，可能还不如研究如何上包。 1，开发问题 现有的web2app方案，都是基于三方+conversion api或者pixel之类来实现，在开发过程中考虑到优化师不懂技术，一定会遇到比较多问题，最典型的是event不能回传给到广告平台，中间大多数人探索+开发周期直接奔着一个月，关键是最终开发好之后还有一大堆巨坑：包含投放量级上不去，落地页转化率要优化，封户问题严重等，有90%以上的概率一定会半途而废。 直接打广告：如果你真想试试web2app，走apsflyer+adjust的同学可以直接联系我这边走我们的通用方案，免开发做下尝试（但是目前也基本只接一些大客户，小贷客户的web2app需求）。 盈量Web2App投放合作说明（客户免开发） 2，目前测试下来的产品，基本上只有属于用户有“刚性需求”的产品，或者直接就是可以扛得住高价的产品可跑，比如借贷，用户为了借钱是可以忍受更“不方便”的下载流程，或者菠菜产品，价格高点也能回收，还有一些类似“下载电影”，“看小说”等偏向内容型的产品，是可以走web2app实现一步步诱导来增加转化。 剩下的产品里面包含iaa变现的工具，还有网赚产品（类似走路赚钱）这些扛不起价格，又不是刚需的产品，基本直接可以不用尝试，100%的失败率。 3，投放成本上，web2app几乎没有能实现同等价格+同等量级的可能，限定价格跑下来，基本就是比较低的量级（大产品看不上，小产品开发成本太大）。目前已知的数据里面，在印度，非洲这些地区相对能更容易达到目标价格，在发达区域成功率更低。 在投放角度，由于量级小，成本偏高，也不合适大规模迭代素材，只能苟着尽可能养大系列。 4，封户问题，本身大家跑BC的封户就严重了，再加上跑web2app，直接投apk的，被封的概率更是激增，投这类项目还需要再花费大量精力去研究+优化迭代自己的落地页，尽可能的做到伪装+表面合规，降低被封概率，封户同时还会造成本身投放学习难度加大，导致量级起不来。 除了上述问题，其实在web2app量级上不去的问题上，也有一些分析： 1，用户心态，跑apk下载的时候在穷地，尤其是非洲可能以前就有大量apk分享+下载的习惯，所以在穷地区整体转化率还算ok，在发达一点的区域或者移动网络发达的区域，用户应该是已经有段时间不用apk安装，本来抵抗风险，在安装环节流失比较多。 2，厂商拦截，没有办法在本地验证，但是大概和国内装apk相似，厂商在安装apk的时候弹出提醒告知用户风险，从而导致安装被取消，但是这里其实反而也有一些策略可能能有帮助，比如在各个厂商的应用商店都传上去后，可能厂商会提示替换成自己的包，只不过这个模式下的安装如果是走了Preinstall之类的方式和厂商提交了专门的包会导致转化无法通过web2app回传到广告平台。 往期web2app的投放总结： Web2App在小说/短剧的应用 web2app在电商产品的应用 Web2app在新闻产品的投放应用
什么是Web2app Web2app是通过网页投放APP广告的一种方法，正常大家在FB，GG，TT上面都有直接投放APP广告，不过很少给App投放网页的广告，再从网页点击去下载App，我们现在介绍的就是这种。 在效果追踪上，App广告通过三方或者FB SDK、 FIREBASE 之类直接追踪，但是web2app是投放网页的，需要重新对接追踪相关的技术细节来实现追踪。 重点：在绝大部分的产品上面，Web2app都是脱裤子放屁，没啥用。 主要是在能正常投放App广告的产品上搞Web2app其实只会多了一个转化步骤导致用户增加流失，成本更高。 但是既然有人研究出来了Web2app，肯定有他的用处，目前能想到的一些应用场景： 1，灰色的，GP不能上架，直接通过Web2app投放APK。 2，类似小说，资讯等，通过Web2app先投放到网页看一半（小说前面几个章节），然后再引导下载App，通过“裤子脱一半”的效果，提高转化率。 3，iOS解决Skan看数据慢半拍的问题，直接走web2app看概率归因的数据，同时也可以不限定campaign数量。 4，电商，不以推广App作为主要目标，而是先网页下单，之后引导下载App追踪订单或者获得免单机会或者一些优惠券等等。 Web2App大概什么原理 Web2app 基本还是要借助三方的统计来实现，同时对接三方sdk，再对接facebook的conversion api，Google要对接pixel，走GA4回传参数之类。 大致原理不打算写详细的过程了，一方面第三方统计都出了对应的文档，你们可以找对应的三方销售去索要（如果没有，我可以介绍各家三方的销售给大家），另一方面是我真没自己去动手看文档，团队有同学全搞定了。 我出一个粗略的实现思路帮助大家理解原理： 对接facebook的conversion api后，在大家投放出去的网页广告后，在网页能收到一个fbp，fbc的参数，把这两个参数再通过三方，比如appsflyer的Onelink填写到网页的点击下载link里面的某些参数字段，等用户安装了App之后，这些参数可以再通过三方的push api拿到安装的原始信息，再找到对应onelink设定pid的渠道里面的日志，再通过回来的fbp，fbc参数去走conversion api把转化信息回传给FB，整个追踪过程就是通过这两个参数走三方那边再传递回来。 其他渠道基本也是同样原理，都是去实现一些参数传递，通过三方传递回来到网页的服务端再回传回去给广告平台。 上面这个流程都是技术细节，实现过程其实挺麻烦的，几个渠道都走通所有逻辑至少研究2周以上。而且很可能会出现蛮多小问题，比如能追到安装了追不到后续events，涉及到投放的events还要选择回传到FB用什么标准事件或者其他。 有没有办法快速实现Web2App？ 有。 考虑开发这套还挺麻烦，我们（盈量），直接把我们研究好的直接开发成了一个通用傻瓜版本的Web2App模块，如果你想尝试产品也走Web2App来投放，可以试着通过我们对接投放（代投），客户需要做的是在三方后台选择我们的渠道ID，打开渠道推广，再给我们网页页面（或者走我们的标准通用页面模板），然后直接我们来投放，数据直接就在三方后台上看我们渠道id下的数据即可，能有对应的campaign信息和后续的转化等等，或者你也可以直接包给我们（包含APK)，我们直接按照cpi方式结算。目前我们已经实现了Appsflyer，估计接下来马上实现adjust的（正在读文档）。 Web2App投放的现状如何 坦白说，我感觉其实挺鸡肋的，主要是正经产品能老老实实投的根本没必要折腾，投Web2App的成本其实很难控制到投App水平，毕竟多了一个步骤后增流失。在我们测试的产品里面，除非是帮一些有GP问题，或者本身过审有难度的产品通过Web2app做一些规避之外，正经产品都会因为价格放弃。 小说+资讯，或者漫画之类我觉得其实是很有希望的，不过我还没有类似的客户来给我尝试（欢迎胆大的客户来试试哦），毕竟小说可以实现网页上直接看免费章节，再web2app引导看其他的，相比直接下个大包会好点，而且可以解决IOS deeplink传递的问题。我估计头部的小说，短剧，漫画这些都应该已经实现。 其他产品其实也应该可以通过优化流程来实现提高转化，比如小贷产品如果只是常规投web2app肯定价格下不来，但是如果能改进流程，直接网页上完成借贷的绝大部分流程，只留下生物验证+放贷的环节去App，这样估计有可能整体的小贷的成本能控制住成本，并且也许能获取到一些新的流量空间，可以把这个当做一个扩量的思路。 当然肯定还有灰色产品的需求，确实Web2App能解决一些不能投放的产品的问题，但是同样既然GP下架就是有点灰，去投APK的时候同样会遇到审核问题，规避不是100%有效的，目前测下来量级不能太大，大了之后就会被广告系统抓。 各位老板们如果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投放的原理实现方法以及应用场景，可以查看文章： Web2App投放现状，解决方案还是鸡肋？快速无开发实现Web2App 所以重点介绍一下，我们Web2app的解决方案实现到了什么程度。 1，不需要用户做开发，只需要提供APK，或者GP产品link，以及部分基本的产品信息，用于我们生成产品下载页面。 2，所有的数据回传部分，可以直接通过Appsflyer后台搜到我们的渠道，选择打开渠道。 之后我们会根据产品信息生成下载页面，页面会直接对接好facebook，Google，Tiktok，Kwai等渠道的数据回传（安装+events）。不需要客户去设计制作网页，也不需要客户去实现三方数据回传给广告平台，这部分我们也都直接实现免开发配置。 合作方式： 1，按照消耗结算，我们可以给每个产品生成下载页面，同时也可以给同一个客户的多个产品生成多产品的下载页面。 单产品页面长的比较像GP，多产品页面有点像应用商店，可以同时给客户挂多产品同时一起推广。这种方式下我们可以选择按照广告消耗结算，我们尽量按照客户的推广目标优化。 2，按照转化结算，比如CPI或者CPA，我们可能会单独投放单产品页面，也可能会把多客户的产品放在同一页面做推广，但是按照最终CPI来结算。 合作产品类型： 1，小贷，apk或者GP均可，ios也可。 2，BC， apk或者GP均可。 3，小说，短剧等，一般都是在线包，但是我们可以实现通过Web2app来投放ios 带deeplink的广告。 4，News类型，一般都为在线产品。 5，电商，安卓/ios解决网页查看商品再App下单，并且实现deeplink等。包含投放到搜索广告，扫长尾词再到手机下单。 可能还会有些其他应用场景，我们可以到时候根据需求再次开发。 各个应用场景我会尽量把解决方案写成文档到时候分享给大家。 我们优势： 免开发，我们实现了全部流程，并且做成后台配置，可以快速上线。对于想尝试web2app获得结论的或者解决不能上架问题的均可实现。 结算也比较灵活，可CPI或者消耗。 程序化投放，我们做代投有两三年，所有广告平台都api开发对接好，针对电商，News等领域我们可以直接批量上传广告，自动优化等，对大规模扩量很有帮助。 合作联系： 微信 narkuh 请特殊标记为web2app合作。 欢迎各位老板支持，快来下单。
这个需求其实相对比较小众，毕竟在做新闻应用的公司不多，需要用到web2app的可能更少，不过相比小贷，Web2app的投放价值可能会更大一些。 先说新闻App的基本情况，国内有今日头条，还有腾讯新闻，网页新闻等App，海外头部的几家： News Break（一点资讯海外），Smart News（日本地区），Opera News（非洲+美国），Local News，还有传音系的News等等。 海外真跑大的也就这几个（可能会有漏掉的），并不是没人做，其实我们对接过中小团队都不少，但是真能做大的就几家，主要是这领域其实“太难了一些”，算法，内容，这几个方向想做好的难度其实挺大。 常规新闻App的推广思路，简单点归纳就是“假新闻”，或者“标题党新闻”，News和其他App不同，主要推广思路是把某些热点新闻（或者震惊）批量投放到facebook上，之后deferred deeplink到App内打开对应的新闻，大规模投放后找到单价便宜留存更高的新闻，扩量。 但是这个操作在安卓上行得通，在iOS上比较麻烦。 投放News这个领域的难点： 1，程序化大规模投放News内容到facebook。 2，iOS没办法实现延迟deeplink逻辑。 第一个难点其实是在投放层面，至少有解决方案，想办法自己通过api实现新闻内容自动生成广告大规模批量投放，再程序化自动优化（这里不好展开说了，其实实现的坑蛮大）。 第二个点，因为iOS14之后不能走Facebook实现deferred deeplink，所以没办法直接投放新闻内容到下载App后直接看到新闻内容，导致承接差，留存降低。 针对第二点可以引入解决的解决方案： 使用Web2app投放iOS，先到网页看新闻，再点击下载APP，同时在网页上实现deferred deepLink逻辑，从而解决假新闻精准跳转的问题。这里主要通过Web2app走概率归因，之后再通过三方的deeplink解决方案实现。 具体Web2app可实现的效果： 1，使用新闻内容当做广告内容投放到facebook，投放目标为网页，不是App下载。 2，用户到达网页，正好打开看到的新闻生成的广告内容，查看新闻（但是只看到一半），同时最底下提示下载App查看全篇。 3，用户点击下载App，再到商店下载App，并且通过网页传递的deferred deeplink，在App内打开正确的新闻，让用户看完全篇。 4，解决新闻当做广告IOS限制广告数量问题，投放网页可以无视campaign数量限制。 通过Web2app的方式其实可以实现到和安卓类似的效果，走这个方式还有一个好处，解决iOS skan数据延迟问题，这里走web后是通过三方的概率归因实现追踪统计，数据虽然有误差，但是实时。 投放方式上面还可以投放后续的事件目标，比如阅读新闻次数或者一些其他点位，通过三方回传到网页服务端再回传给facebook，按照这个模式实现iOS投放AEO的实时效果。 缺点： 用户多了一个网页的步骤，理论上其实是会增加流失风险，尤其是新闻内容并不给力的情况下（并不能达到看一半好奇必须看完的时候） 但是这个也需要测试，保不准其实通过概率归因的数据更及时，以及新闻阅读一半的方式可以实现诱导用户完成下载和启动。而且也能靠deferred deeplink传递数据信息，帮助算法优化，可能提升投放后留存效果。 以上实际上还并未经过测试，但是值得一试。 盈量目前Web2app解决方案已经实现了用户无需开发，只需要在三方后台打开渠道即可完成对接，如果后续要投放新闻类，也应该只需要通过api回传部分新闻内容，盈量生成网页后再批量投放出去，通过盈量自动化上传+自动优化，也许…可能能解决iOS投放新闻类的问题，欢迎同行老板下单子支持！