Skip to content

AEO/UAC 2.5投放事件占比多少投放效果更好

跑AEO或者UAC2.5的时候我们都知道要选合适的事件点来投,但是事件点的比例比较重要,选的好投出来的效果会更好一些。 结论:选择大概在10-25区间比例(唯一用户人数)的事件点做投放,效果会相对更好,我自己一般都喜欢控制在15%附近的点位做投放。 这里讨论的主要是事件比例,默认大家选择的点位都是有价值的点位,而不是随便选一个比例接近的点就投放,有价值的点位比如电商的购物(而不是某个商品类目浏览),或者金融的有效交易,或者放贷,授信等等,游戏可能是付费,或者一些其他高等级的级别达成等等。 为何事件比例能影响到广告投放的效果? 换个通俗点的解释方法: 广告系统FB,Google这些在广告学习的时候,差不多是类似于找相同,在一堆人里面找相似的人,合理的达成人数占比能帮助系统学到更精准的人群。 比如从100个人里面,找到15个人来,要分析这15个人的相同点,根据这个相同点再从一万个人里面去找到和这15个人相似的人。这个时候15个人的特征的交集就是他们的相同点,15个人能找到的交集相对来说会比较精准一点,并且也不至于特征太少,找不到相似,也不至于特征太多,发现全都是相似。 人少了比如不到8个人,那可能会存在一定的概率8个人都不相同,系统懵逼,我找谁去? 这也就解释有时候转化率比较低的产品,学习进度慢,攒了一些转化之后也没学出来,因为系统没找到相同点。 又比如有30-40个人,那可能又发现这30-40个人的特征放在一起,好像相似的地方又太多了点,比如里面有10个人都喜欢打篮球,有10个人又喜欢踢足球,还有10个人一起都喜欢斗蛐蛐,系统在学习的时候只能分多个方向去尝试,打篮球的,踢足球斗蛐蛐的分几个方向都再学学,跑回来发现都达标,然后跑到的人群就听宽泛,要是比如80个人都达标的,这时候擦不多就和投安装类似了,系统学到的人也就更宽泛。 太多,太少都不合适,在以往投放测试中完成人数在15-25附近,会更容易学出来比较精准的人群。 一定会出现一些情况,我的核心事件点的转化率就是贼高怎么办? 比如放贷的授信跑出来30%以上,或者游戏付费率到了50%(这肯定发财了) 确实,如果某些点位完成比例很高,又是核心目标完成事件,不可能修改的时候,其实可以再考虑在完成事件的人上面在分一个三六九等出来,比如游戏付费率50%,但是这50的人里面总有大中小额玩家,挑出来一部分大额玩家单独投放,效果会更好,比如放贷的授信,也挑出来比如授信了的人里面信用程度更好的50%的人出来投放,跑到的用户质量会更高。 存在一些产品,完成人数是比如20%,但是多次回传一天完成超十次怎么办? 先前其实提过一个思路,按照Google UAC 2.0的思路去投放AEO或者2.5,虽然出价给到了event上,但严格控制CPI的方式可以控制成本,出现这类现象的通常可能是iAA产品模拟回传价值之类。 投放转化率始终没办法满足比较合理比例怎么办? 这个在搞重度游戏付费率,或者社交产品付费率低,或者某些小贷投放贷转化比例不高的时候遇到比较多,这个时候其实就能明显感觉到投放难度剧增。 这时候两个思路: 1,重新找打点,转化率低的比如付费,始终就3-4%的时候学的太难了,可以考虑找一些靠前的行为,但是和最终目标非常正相关的点位投放。比如小贷在放贷之前有授信,投授信比例更高点,也能准确代表用户价值,但是这个有很多产品并不能随意调整。 2,考虑到不能重新找点,那只能在现有的点上面尽可能学出来,通常做法是在素材上和人群上想办法先做一些限定,比如素材上上一些能促进事件达成的活动,游戏充值礼包,BC的提现诱惑,放贷的减息等等,人群上面比如游戏先限定竞品关键词的量之类,或者直接核心事件的FB相似人群之类。 投放过程中,点位达成率比较低的产品还可以考虑养大系列,跑Google UAC2.5,跑FB AAA之类,或者普通广告在有潜力的时候尽可能养大,虽然100人只有3-4人能达成事件,学习困难,但是可以想办法投出来1000人,有30-40人满足条件,这时候也有足够多数据帮助系统学到正确人群,坚持下来还是有希望跑成。

小贷风控和推广稳定性的关联

做的久的小贷都会有个现象,老产品在后面一定都会是Google的量为主,从流量的角度来说可以说学出来了,或者老产品有很多的老用户搜索回访之类。 不过有个因素可能大家不一定会注意到: Google投放稳定的广告系列,实际上对风控来说,是比较“招喜欢”的一种。 广告系统跑的越久,学到的人群属性就会越趋向于一致,人群属性越一致,也就越符合风控的诉求。 考虑到我们投放的一般都是授信和放贷行为,如果养的足够长时间,广告系统最终能学出合适的价格,产生转化的人慢慢积累都会变成很相似的人群。 Google广告撇开前面类似搜索,老用户,或者GP版位的优质量不说,还有比较关键的是Google的投放方式就是“佛”,这样跑的时间长了之后学习出来的人群也是相对稳定的人群结构,风控比较喜欢。 Facebook后续有了AAA,或者用CBO养大的系列跑起来后其实也能相对更稳一些。 而其他渠道类似TT之类,由于要经常迭代所以到后面人群属性不一定是稳定形式,所以观察到的产品一般TT后面风控通过率都不太高,这里不一定是人群真不行,而是不稳定的人群特征,估计风控也保守一些,只挑确定能过的。 站在投放角度,投放小贷其实有个思路: 1,集中大部分预算给到稳定的广告形式上,比如Google,或者FB AAA之类,争取养大。 2,砍掉绝大部分或者所有来源不清晰/不稳定的渠道,尤其网盟。 再结合之前分享过的文章,投放网盟对FB GG这些渠道投放影响,可能砍掉了网盟最终减少了抢归因对广告平台学习的影响,也许能在同等预算下,获得同等更优质的量,并且由于人群属性的稳定能让整体的转化率更高,逐步走向一个正向循环。 再考虑小贷目前都需要开始考虑给守信用户做分层,只投优质用户,网盟这种无法区分或者优化的渠道,确实也越来越没空间。 虽然说了放弃网盟,但是有一些特殊的存在,比如贷超,这个属于垂直领域的流量,估计属性相对稳定,不过估计还有撸贷的人群也会集中在这类渠道,所以风控同样也要特殊关注,避免被坑。 对了,如果你产品都是740类型,本着“来的都是客”+“催收无敌”的模式运作,那你当我前面都没说吧。

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在小贷投放上的数据和场景。 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 所以重点介绍一下,我们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合作。 欢迎各位老板支持,快来下单。

跑崩了的小贷怎么在投放上抢救回来

最近接到的小贷需求里面,偶尔会遇到有的产品投放数据跑崩了,大致表现为投放出去的跑授信回来的用户在后续的表现中基本都是逾期,继续收缩转化率之后回来的用户依旧还是逾期严重。 分析原因: 风控通过的人群不准确后导致逾期变差,但是授信的信息已经给到了广告平台,广告投放的是授信,在广告平台看来,只要通过了授信就是满足要求的用户,广告学习的方向就是授信成功的相似用户。 这个时候只要预期的用户(坏用户)占比比较大,那么广告学习授信用户的相似时候,实际学到的就是坏用户+部分好用户的相似,只要坏用户比重偏大,广告就有比较大概率往坏用户的方向去学。 如果风控不能及时拦截掉这些用户,那么就进入一个恶性循环。 最后跑崩。 这时候如果继续跑授信,其实即便风控调整通过率其实也还是很艰难,毕竟来的都是坏的为主,要么都拦截掉,要么就只能继续恶性循环(当然如果比重不大还能挽救,崩了就彻底没救了) 解决办法: 核心思路就是把好用户挑选回来,并且不要再给广告平台坏用户的数据。 和卫总讨论后给了一些想法: 1,跑白名单,直接拿到历史的白名单,明确的好用户先跑。 2,正常跑(申请),但是在回传数据的时候只回传白名单内的用户数据,其他的可能正常授信了,但是不确定是不是好用户,先不做数据回传。 3,跑白名单/还款用户的相似人群,但是可能不一定合适跑授信(毕竟风控还没法挑出来优质的,可能选出来一些坏用户跑一段时间后还会崩) 4,根据相似人群的属性,在campaign信息或者deepLink内增加一些标识,让风控知道某些用户属于广告系统认定的优质相似人群,比如拿白名单或者还款名单做相似出来的人群,让风控在判断的时候给这部分用户放点水。 5,原本有个想法,比如不回传授信,但是在用户还款后回传授信,这部分在三方上可以看到转化情况,但是实际上在FB上可能并不可行,主要是归因窗口问题导致,用户还款的时候已经超过7天。 存在另一种情况,FB崩了,Google没事(其实也正常,Google有商店的量,洗到的人群范围更广,FB由于优先推送的人群都是更容易产生转化的用户-撸贷的和常年借贷的坏用户就是这个特征),这个时候其实也可以考虑判断渠道后限定回传,比如FB的,不回传不能明确是好用户的数据,但是Google还是可以回传全部授信(如果逾期没问题的话),这时候由于Google的数据回传,加上FB是自归因也能收到这部分数据,相当于也在积累优质名单。 跑崩了这个现象近期发现其实在成熟市场上相对比较常见,分析原因可能还是成熟市场FB积累了太多数据,某些用户常年借贷,在算法上学习下来就属于高转化的高价值人群,但是FB不知道还款情况,所以遇到职业刷子,撸贷的都在FB标记成高转化人群,每次投放优先曝光。并不是全部用户都这样,FB还是会覆盖到一些老实人,只是说刷子撸贷的概率在老市场会相对常见。 但是在新市场缺少数据,FB学习时候还是相对偏向于小白多一些,Google刚好是给新机用户或者扩散的人群更宽泛一些会相对好一点。 换个角度想,也许在成熟市场跑跑注册,或者申请也不一定多差,也可能投放躺平了,风控也躺平,结果数据反而更好的可能。因为都躺平之后没准就真覆盖到了一波“新韭菜”。  (有风险,只是YY一下,不可取)

近期App投放被FB禁投问题(APP被FB拉黑)

近端时间在小贷App投放的时候偶尔会遇到一些产品开户之后直接投放报错,并且开新户也无法解决,有反馈重新设置新的FB APP同样无法解决。 大致的报错类似: 从目前已知的信息来看: 1,被封的产品,重新开户+重新设置新的FB APP 无效 2,找直客申诉基本无效,拿不回来。(谣传这几天能解决了) 3,CC客服不懂或者无法解决。 其实就是等于“死刑”,标记在了App包名上。 为何会这样: 从已知的信息看,是FB开始逐步清理他们觉得有问题的产品,禁投。尤其是在小贷负面舆论严重的地区,墨西哥和印度这些区域目前看比较频繁。 但是为何有的新产品也会被标记,目前未知,不确定是否有一些技术细节导致被标记,或者开发者某些标记被抓到。 如何处理: 整体重来,只能重新打包上架,更换新的FB App。 有直客管理的客户,可以再努力努力,等直客看能不能协助推动解决。(直客有概率能解决,没直客多半回不来) 未来的担忧: 其实从FB的操作来看,估计只会越来越严重,预测未来可能监管会越来越严格。 比如 1,没有直客的小贷客户,有比较大概率会出现更高频次的禁投。 2,有可能会走白名单制度。稳定投放得有直客加白名单,没白名单的打游击。 3,政府合规牌照问题,申请报名单可能就要提交牌照等。 需要提前准备的: 1,合规搞,拿牌照。 2,多包策略不一定可行了,或者至少多包投放扩大后赶紧提前找好大腿(直客), 3,更多样化的流量来源,或者产品形态(App不能投,改网页)。

广告系统投放标准事件对人群的影响

这个问题源自上周分享会上的一个提问,大概需要讨论的点: 如果产品投放的事件都是统一个标准事件,是否会让系统学习到同样的人群。 举例:假设我们好几个小贷的打点都用的add to cart 当做申贷,Purchase当做放贷,是否能让Facebook学到同一拨人群。 这里其实涉及到facebook给用户人群打标签的逻辑,但是我估计不会找到有文档佐证,只能猜测。 我估计大致的逻辑: 1,FB 会根据用户的一些基本信息,包含年龄性别,好友关系,以及兴趣爱好(书籍,电影)等各种维度给用户打标签,在广告投放的时候会根据这些标签来决定曝光。 2,FB会根据用户的行为习惯,给用户加标签,包含GPS信息,拍照,以及给page点赞,或者某些post点赞,评论等,具体可能包含了这个post的属性,page的类型,或者甚至同样点赞过的人的人群属性聚类。 3,FB会根据用户曾今产生的广告行为,比如下载过某些产品,曾经在游戏内付费,在电商购物过(不一定知道是购买的什么商品,但可能能根据同一个商品的大量转化聚类找到一些关键信息再打标签)。 我们能理解FB在人群行为,属性上的聚类,但是其实我们可以理解下FB(也包含其他广告平台)在自己的标准事件回传上也是有很强的属性标签。 电商统一用购物,游戏的等级达成,新手引导,付费等等。TT甚至有专门给小贷的申请贷款和发放贷款的点。 这里其实标准事件是有利于广告平台在初期的时候更快的找到同类的用户,都产生申贷,放贷的用户通过标准事件收集起来,给一个单独的用户标签,这个可比根据用户年龄性别,兴趣爱好要更精准。 所以其实我理解我们大量产品在回传Facebook事件的时候都选择了add to cart 和Purchase的时候,facebook其实会考虑从产品类型,还有标准事件的转化上做标记,等到后面再有产品转化的时候会倾向于更多曝光对应有这些事件转化的人群。 实际上背后的逻辑也还是根据产品行为来聚类的人群标签,但是更直白点的猜测可能就是同样产生过这个标准事件的人群,因为这个属性太强,强过一些其他属性标签。 猜测标准事件选择上如果品类不对会有一些其他负面影响,比如用了电商用到的这些标签可能导致冷启动阶段的人群不会太准确,但是看起来也不会太长时间,产品本身积累一段时间后就问题不大。 关于标准事件的影响,小贷这边其实也有头部产品最后都会故意不选择标准事件投放,其实可能有2个考虑: 1,不想用标准事件让其他家蹭他的事件标签。 2,不想被不准确的标准事件影响转化(小贷,没有放贷,申贷的点,用其他品类的点不准确)。 站在投放角度: 产品小无所谓,产品大的确实可以考虑减小标准事件不精准的影响,单独投自定义事件。

项目要不要去找代投公司合作

感谢Meta组织的活动,今天在分享的时候,其实没有特别去准备,所以其实在回答Sarah的提问时候并没有回答的特别好。这也是我个人临场反应能力比较差,通常更喜欢码文字的原因,写文字可以有更长的思考时间,会想的更周全一些。 代投的用处,在会场上提到的: 1,鲶鱼效应,引入一些代投可以激励自己的团队有竞争力后更努力一些。可能会让一些人不开心,但是站在项目角度是可以有利于整体发展。 2,学习,代投团队通常在某些领域其实是更专业的,好多代投团队都会有自己的一个优势项目,比如我们在现金贷领域,还有iaa产品领域,其实还有真人素材拍摄这些领域都是领先同行(包含甲方同行),除了投放操作还有投放策略等,抱着学习的想法其实是可以从代投这边学到一些其他通钢的投放思路。 漏掉的部分: 3,加快项目进度,从我们转入乙方后,在代投领域的优化师可以明显看到大家的变化,整体大家的工作效率会“急速”上升,多线程能力也会更强了,站在甲方角度,如果找到靠谱的代投,可能会发现代投团队可能能在当天就出来素材并且上线推广,这在我以前做甲方的时候几乎不大可能,以前经常会需要准备素材+汇报+推进产品运营一起准备,但是现在看来,以前自己在效率上确实做的不够。 4,拓宽思路,自从我做乙方后,接触到的项目范围就明显比以往要多了,前面有8年单纯的做游戏,之后再有社交,工具,金融,支付,发卡等各类项目,近期还接触到了更多有意思的类型,可能对我们自己,在思路上明显有非常大的提升帮助,在出素材,投放项目策略上明显会更大胆,思维更发散,这些实际上可能站在甲方角度,找到经验丰富的乙方,可能能给自己的项目提供更多有效的思路,包含素材上和投放策略上可能都有帮助。 5,认识新朋友,这个可能并不一定会多明显,但是优势的乙方通常会认识整个领域的其他同行,大家关系好之后,互通有无,可了解到的信息渠道会更多一些。 关于我们: 北京盈量,是20年成立的一个广告代理团队,目前接近70人,我们在金融,社交,工具+资讯(IAA领域),游戏等各类领域都积累比较多,在素材上有一个20+人的真人素材拍摄团队。 希望能有更多的朋友来找我们合作,我们也尽可能把我们积累的经验方法,分享给更多朋友,实现双赢。