编辑导语:市场环境正在发生急剧变化,各行各业的盈利增收也因此受到了一定影响或冲击,那么当下,互联网广告行业要如何提升盈利变现的可能性?本篇文章里,作者从业务角度对该问题做出了解答,不妨来看一下。
转眼又至岁末,在过去的一年中广告行业发生诸多的变化。从市场上来看,经济下行导致各行各业在广告上的预算都不同程度有所缩减,作为广告行业头部“金主”的教育行业在下半年迎来监管之后整体预算极速下滑;从政策上来看,个保法、开屏监管和iOS新规次第推出,以前大家常用的手段现在受到了很大限制。
从产品上来看,(笔者所处工具行业)自Q2以来,由于产品本身门槛极低,竞争对手日益增多,加之变现日渐乏力,整体回收效果下滑明显。
总的来看,不管是市场还是政策都体现了互联网广告行业已逐渐告别那个高速增长的时代,未来大家比拼的是如何精细化运营,如何有效地提升用户留存、广告价值以实现用户价值的提升。
但换种思路来看,环境的转变也正倒逼着我们去思考广告的本质。从产品设计上来看,如何去设计产品以更好地承载广告;从转化链路上来看,如何去优化链路以减少转化折损;从转化结果上来看,如何提升广告与目标用户的契合度以达到最优转化……这些问题就是指引着我们向前走的下个方向。
在本文中,笔者想基于业务的角度与大家一同思考,在当前环境下提升广告变现收益的下一个增长点在何方。
一、商业本质在以CPM(展示计费)为结算方式的效果广告中,平台作为中间枢纽链接流量需求方(广告主)与供给方(开发者)。
在整个链路中,广告平台既充当着规则制定者,制定各种模式/玩法的;同时也扮演着裁判的角色,维持着生态的稳定及平衡。因此平台会兼顾开发者与广告主利益,在整个链路中帮助开发者优化效率,提升流量转化,同时也为广告主的用户质量(转化效率)负责。
作为开发者而言,熟悉并运用广告平台的规则是提升变现收益的必经之路。谈到变现,我们需要引入一个公式:
收益=广告曝光次数*广告ecpm*留存
在此需要留意下,收益≠收入,计算收入还需减去支出(买量成本),因不同产品不同阶段不同平台收益及支出波动非常大。因此,笔者在本文中主要描述的是提升收益的方式,非具体数据。
由公式我们可以得出几个结论,在以CPM(展示计费)为结算方式的效果广告中,提升变现收益的方式无外乎三点:广告曝光次数、广告ecpm以及留存。
其中,广告曝光次数及留存是由产品属性决定的,例:游戏类产品(休闲游戏)主要是激励视频及信息流为主,资讯类产品主要是信息流为主等等。广告ecpm是由用户质量决定的。
由于产品属性不同,其内部广告类型也不同,同时其买量成本也不同。因此提升收益的关键就放在了如何提升转化效率、增加广告曝光次数以及平衡广告曝光次数及留存的关系上,即优化广告链路;以及如何买到高质量(高回本率)用户,以及如何提升转化效率提升用户价值(ecpm)。
二、广告链路在优化广告链路之前,我们先看下整体的广告链路具体包含哪些环节。
如下图所示,从广告请求为起点来看,总共有7个步骤;从参与者的主导(引导)的角度来看,主要是分为平台、开发者以及用户。
1. 平台在广告链路最开始的环节是应用向广告平台进行广告请求,广告平台返回广告,应用展示广告。在此过程中由于广告平台众多,会涉及到应用具体向哪个平台请求的问题。
当前,主流的形式是采用瀑布流,从上向下请求。由于整个过程请求量大,且平台较多,目前采用的是聚合的形式。即向聚合请求,聚合向广告平台采用多家竞价的形式请求。但是这种方式有比较大的弊端,主要是:
1)运营配置耗时长
运营需要一款产品运营需要配置不同的广告位,一个广告位又有多层瀑布流。在每个广告位和瀑布流之间需要考虑使用哪个广告平台,还需定期进行维护调整瀑布流。整个过程,耗时太长。
2)实际效果仍可提升
由于不同广告平台的广告在不同瀑布流上效果是不同的,运营需要综合考虑进行配置,但是人力所能做到的效果未必是最好的,仍有优化空间。
因为有以上条件的限制,所以各广告平台陆续推出了各种聚合和bidding来帮提升更高ecpm的填充,比如Gromore、穿山甲bidding、优量汇bidding等。
相较于原先的瀑布流请求的方式,bidding具有的优势是减少人力消耗,运营无需像原先那般在瀑布流配置上花费大量的时间。但是bidding存在几个问题:
效果有局限:由于各平台对于不同ecpm层级的填充效果不同导致一个广告位不能只使用一家bidding,譬如在200ecpm以上穿山甲的填充更好,那么可以在200ecpm以上用穿山甲的bidding;而200以下,优量汇的填充更好,那么在200ecpm以下用优量汇的bidding显然更好。竞对限制:这个主要是各广告平台的,譬如同个广告位上使用穿山甲的bidding,那么这个广告位就不能使用优量汇的bidding。基于以上几点原因,所以现在有的一种方式是bidding+瀑布流的形式。即针对某广告位的某层ecpm使用bidding,其余的使用瀑布流。
从效果上看,提升明显,但是会有很大局限。理想情况下,是有个bidding聚合(聚合各家bidding),省心又省力,但是这是短期很难实现的。目前各广告平台bidding这一块还在探索中,后续作为开发者而言,只能逐步去尝试。
2. 开发者对于开发者而言,在广告链路中能做的主要是中间环节,包含广告展示、广告点击、下载安装、打开激活。其中,提升广告展示和广告点击是最为普遍的方法。
1)广告曝光
由于产品属性的不同,其所具有的广告类型及广告数量也是不同的。
以工具产品为例,由于产品本身无太多功能,且用户大多用完就走。因此,在优先的使用时长内,需要塞尽可能多的广告(以信息流广告)。但是这样会导致本身不高的留存会降得更低,因此有一种方式就是在产品端外弹广告(但是由于转化低所以这种广告是广告平台所不喜欢的),俗称“外广”。
“外广”即端外的广告,通常是以用户的某些行为来主动触发或者定时触发。具体行为包括但不限于:解锁、Home键、充电、断开充电、安装、卸载(参照下图)。具体涉及到是广告类型以全屏视频、信息流为主,部分(开发者)也会增加开屏和激励视频。
由于外广+端内广告+产品属性原因,用户留存极差,通常7日后用户基本就走完了。因此,首日arpu值至关重要。通常来说,收入需要达到60%以上的回本率才可刚刚回本。
由于外广导致的用户体验极差,所以经常会收到投诉,再加之外广的广告转化效果差,所以2021年各开发者都经历过多次应用报毒事件。
2)广告点击
在广告点击这一环节,主要是通过广告样式渲染,关闭按钮延迟弹出、广告触发时机同功能相结合,来对用户误导从而提升广告点击率。
3)下载安装打开激活
通常来说,这两个环节没有太多操作空间,主要还是取决于用户的主动行为。但是部分开发者会通过一些手法,来提升这两个环节的转化率,具体见本文后续的“作弊、反作弊与黑产”部分。
3. 用户后续转化主要是用户的主动行为,在这里能改变的主要是结合用户实际情况来做广告个性化。
目前头部广告主已于广告平台做信息共享,即通过在广告主内的一些行为反映到广告上,或者反之。但是目前信息共享也只停留在最近的信息并非代表用户实际的画像,这一块广告平台仍有探索空间。
三、用户价值“用户价值”这一概念是笔者为了说明ecpm变化而引入的,本文中所提到的用户价值只是为了说明ecpm的变化,并非实际用户价值,实际用户价值应当是LTV。在效果广告中,单个广告的ecpm主要依据用户历史行为、当前(短时间内)行为以及广告主预算决定的。
除去广告主预算波动的情况来看,用户历史行为是用户价值的重要判定标准。从变现的思路看最好是买到适合价值的用户,这样才能创造高ROI,具体如何买量方式有关键行为、UROI、自定义激活等方式,在此不做赘述,本文重点站在变现的角度来思考提升的方向。
1. 判定标准广告平台掌握了大量的用户数据,包含但不限于广告数据(广告转化数据)、用户画像等。
广告平台会结合用户的历史数据做CTR和CVR预估,并结合广告主预算综合给出一个预估ecpm(广告返回环节可以拿到),该ecpm即该用户某种类型广告的预估价值。但随着用户在产品内行为的加深,广告平台会结合实际转化的情况,对后续ecpm值有所校正。但大体而言,用户的前几次ecpm值即为该用户在广告平台的判断体系下真实ecpm。
如上图所示,笔者选取某产品新增用户激励视频次数及ecpm情况发现:
前几次ecpm值基本为该用户ecpm的峰值。ecpm值是会变化的,具体与瀑布流的设置、广告的实际转化等因素有关。用户的ecpm值是很难在短时间内改变的,即用户初始高ecpm,那么其很难在短时间内衰落;用户初始低ecpm值,那么其很难在短时间内跃升。以上可以理解为,用户买回来是什么价值,那他就是什么价值。
2. 变化条件用户初始ecpm是根据其既往行为来预估的,但是实际用户在使用产品过程中,由于产品设计不同、广告设计(类型/样式/触发时机)的不同、以及广告内容和用户主观感受不同导致广告转化会存在差异,即实际转化效果与预估模型存在差距。
正是因为有这些因素的存在,所以导致广告ecpm会发生变化。在正常使用(产品)过程中,这种变化一般是变化长时间的,且大多会随着广告主预算的调整而变化。在非正常使用(产品)过程中,这种变化是较快的。
非正常使用包含,过多的广告曝光、过短的广告曝光、点击率的异常等等。即开发者通过产品的设计or用户主动的行为来改变广告转化情况以提升ecpm。
如上图所示,在开屏未改版之前,通过改变开屏的点击率可有效提升ecpm。
3. 如何改变从链路上来看,在应用内主要涉及到的链路有广告展示、广告点击、下载安装、打开激活四个环节。
1)广告展示
在本环节中,重点考虑的是减少低ecpm或者低点击率的广告展示,在减少展示次数的同时提升ecpm,两者算下来,调整后的收益可能会大于调整前的收益。
也就是说在减少广告展示的同时,也增加了广告价值。由于产品的不同,因此侧重调整的场景也不同。以休闲游戏为例,减少低价值广告信息流的曝光同时,还能优化用户体验。
2)广告点击
在产品设计上需要考虑的是广告弹出的时机、文案及样式、诱导点击等方式(如下图)。
3)下载安装及打开激活
随着广告主及广告预算的减少,广告平台对后续转化越来越重视了。由此应用商店、广告平台都对用户以不同形式的引导(如下图),以促进用户在下载完成后进行安装,安装后并打开。
作为开发者,能做的很有限,一个方向是增加打开提醒,但是这一块本身引导就比较弱,实际效果未必明显,而且平台目前已经在做了。还有一个方向是,强制拉起,即通过检测到用户通过本应该广告下载应用并安装完成,就对该应用强制拉起。
但是会存在一个问题,就是强制拉起的目的是拉活该应用从而完成用户从广告曝光到激活的转化。
但是各应用实际计算激活的条件不同,有些应用以APP启动即计算激活,有些应用通过用户在应用内某些行为的触发来激活,激活条件不同,激活难度也不同。
常规的做法是通过多次拉起来激活,但是这样体验非常差。看了下目前友商的一些操作,主要是针对头部某几款APP做结合误点击做强制激活。由于该产品有部分拉活预算,所以就算吃不到平台的激活预算,也能通过返回拉活吃到平台的拉活预算。
四、作弊、反作弊与黑产提到广告变现不得不提到作弊,在PC时代就有层出不穷的作弊手段。在《计算广告》中刘鹏博士将作弊分为三类:以结算方式为主的作弊(常见于CPM/CPC作弊以及CPA/CPA作弊)、以流量属性为主的作弊(主要是虚假流量和流量归因)、以作弊主体为主的作弊(机器作弊人工作弊)。
随着技术的发展,目前很多作弊手法都玩不转了。在笔者的实际工作中,主要接触到的是第一类,即通过提升广告中间转化流程来进行作弊的。
1. 作弊在聊到作弊之前,我们先看下面一张图,笔者拉取了某产品广告点击到完成安装的链路(如下图)。
由图可看出,通过正常链路走下来,在广告点击到下载安装这一环节转化率仅有8.5%,转化极低。
由此可想,广告链路的前半段(广告请求-广告点击)以及广告链路的后半段(下载安装-打开激活)整个走下来,实际转化率有多低。因此友商通常会在广告曝光-打开激活环节做调整,通过增加这一环节的转化率来提升整体转化率,实际上广告平台关注的也是这几个环节。
1)广告曝光——广告点击
在广告点击上,常规的做法是做误点击、诱导点击、点击劫持等。
例1:
如上图,左侧的关闭按钮偏下是假的按钮,点击关闭即点击广告;右侧的关闭按钮是真实的按钮,点击即关闭广告。
例2:
如上图,开发者通过将信息流广告位置迁移,实际信息流位置上移,点击红色框内“开心收下”相当于点击了下层的广告。
需要注意的是,误点击、诱导点击、点击劫持等仅仅为手段,作弊的关键在于策略。即需要对用户、广告主、广告平台、点击间隔、点击频率等参数做控制,让用户明白自己的点击是不小心点到的;让广告主认为这是正常点击,只不过频率较之前更高;让开发者在不知不觉中赚到收益。
除了通过改变点击率,拉高ecpm外,笔者还发现一种模式。对于一个新投放的产品而言,一般有几天的学习期,在这个学习期内,是广告平台推送不同的广告以完成对这个产品以及其用户群体的粗略判断。在学习期过了之后,再吐出对应的广告。
因此,部分开发者会在学习期内通过对某类广告点击率的改变再加上高单价的买量策略,影响到平台的算法机制。从而实现在完成学习期之后,产品内的ecpm被拉升的情况。
2)下载安装——打开激活
部分开发者的做法是通过特定事件or固定时间,进行强制拉起。
由于各应用激活条件不同,故而采取多次拉起,以保证激活率。
由于多次拉起会导致用户流失严重,常用的做法是针对指定几款(头部)应用做强制拉起,一来尽可能确保激活,二来头部产品通常是国民级产品用户不容易卸载,往往后续会主动打开。
2. 反作弊对于反作弊这一块,笔者了解的不对。就目前的经验来看,常用的反作弊方式主要有点击热力图(如下图)。主要是针对点击率作弊的,通常来说有两个特点大概率是存在作弊行为的:
点击非常均匀出现在一个区域,这种一般是机刷的。点击非常集中在一个点,这种做的一般是诱导点击。图源:《计算广告》
还有的就是一些数据异常的情况,譬如点击间隔、点击频率等。
3. 黑产笔者所了解到的黑产主要分为两类,一类是在网赚产品中通过批量刷广告赚取金币以提现的用户(主要针对开发者),另一类是通过刷app内的广告来获得收益(主要针对广告主和广告平台),笔者重点介绍第一种。
在说到针对开发者的黑产,不得不提“网赚产品”这一产品类型。
网赚产品指的是将游戏与广告相结合,用户通过玩游戏看广告赚取金币,并可将金币兑换成现实货币提现,该类产品大多将金币与激励视频ecpm挂钩。由于产品独特的机制,黑产(俗称“刷子”)会针对该类产品进行批量刷广告以赚取金币。笔者深入其内,了解到部分的工具(如下图)。
如上图所示,刷子通过工具来控制手机进行批量刷广告,然后定期提现。
由于有多参数的调节,所以作为平台or开发者很难短期内发现产品内存在刷子,而且刷子的行为和正常用户无二,正常的广告点击-下载安装。
笔者通过与技术同学沟通后发现,他们的做法是:用户在自动刷前需手动体验一遍并完成提现,用户开启无障碍权限,(该软件)会获取当前活动窗体的控件,根据控件的id或者显示的文本来查找对应的控件,然后根据业务来点击控件,并通过点击or滑动时的偏移来尽可能保证行为是无序的。
后续刷子还向笔者推销他们的手机,即通过他们的手机刷可以改变用户价值。笔者体验后发现,并非如他们所言。
首先,用户价值是无法短期改变的,之所以能刷到高ecpm广告,是由于当激励视频广告点击率提升时,会刷到平台的搜索广告,而搜索广告的价值是激励视频广告的3倍。看起来是用户价值提升了,其实不然,只是达到阈值刷到更高价值广告罢了。
而他们所兜售的手机是root过的,即他们可以充分控制这部手机对广告点击、安装、打开的控制。由于权限的过分敞开,若一般人贪图小利购买手机刷广告没做好个人信息保护的话,那么其信息在刷子面前就是公开的,非常危险。
如果说以上刷子通过刷广告是给平台和广告主带来损失但有利于开发者,那么近期我们发现刷子更新了手段,不再是通过真实点击来刷广告了。
刷子通过抓包,拿到了产品每次请求瀑布流的所有数据包,比如一次请求在第20层填充,实际上会返回20个不同的request_id,实际填充的是第20个,也就是只有那一个才有效。刷子混用了上面那19个request_id,篡改代码位为首个请求的代码位(最高价值),然后伪造了曝光。
要防御这个,本质就是要拿到每次真实填充的那个广告的ATAinfo解出request_id,然后等用户曝光后,校验它是不是用的填充的那个真实有效的request_id。
这里的技术难点在于,通过Topon拿load后这个request_id,需要主动调用load,从loaded回调拿ATAinfo,而Topon自己的那个自动加载逻辑是没有loaded回调的。这就要求我们产品前端自己实现自动加载和缓存。
其实,作为开发者而言,是欢迎刷子用户的,因为他们可以带来高ecpm、高曝光的广告。作为广告平台,对此也是支持的,因为开发者可以依靠刷子把产品做起来以带动更多人来做产品,一起做大这个市场盘子。对于广告主而言,尤其是中小广告主,刷子用户给他们带来过多的无效转化,损失太大。
先前经济好的时候,广告主多且广告预算足,因此在中间环节稍微提升一点,在结果上就会提升很多。但当经济下行的时候,广告主更多的考虑是有效转化,那么改变中间环节的意义就不是很大了,因为收益太低,除非对每个环节都调整,但这种就是把用户当机器来刷广告,非但对用户极其不友好而且也是广告平台及广告主非常不愿意看到的。
作弊与反作弊之路任重而道远,未来对于平台方而言,大概只会存在抓不抓的问题了。对于开发者而言,通过作弊换取微薄的利润,可能是大家会尝试的一条路。只希望有所克制,别把市场搞乱,当整个市场都在做的时候,平台也会改变策略的,也就意味着更卷了。
对于广告主而言,只要肯花钱,用户还是有的,只是更贵罢了,质量也被平台捏的死死的,花1块钱,绝对不会买到1.1的用户。毕竟行情不好的时候,大家都得缩紧裤腰带过日子。
五、展望过去的2021年,对于广告行业,笔者认为这只是一股寒流,并非凛冬将至。虽然受到了经济下行、政策监管等因素的影响。但是就行业本身而言,需求不会消失,有需求就有市场,市场仍会存在。行业不会变,变的是表现形式。因此在可预见的未来,作为开发者、作为平台在自身建设上仍需努力。
1. 关于平台就当前市场上的广告而言,笔者发现仍有相当一部分广告存在诱导点击的设置(平台以及开发者都参与)。
笔者认为提升广告转化率的思路不应该是通过诱导来让用户点击下载,更重要的是需要结合用户实际需求来推送个性化的广告,让有需求的人看到他想看到的广告。
当然这一块平台目前已经在做了,笔者前段时间在某东上买了一款商品,后面在微信朋友圈内看到这款商品的信息流广告,甚是震惊。广告主与平台信息共享是提升广告转化率的关键,但是其中也会涉及到用户隐私的情况,不过这又是另一个问题了。
2. 关于开发者作为开发者,夹在用户与平台中间属实不易。既要考虑用户体验,又要广告收益,在单一依靠广告收益的情况下,更难。因此开拓新的变现模式极为重要,尝试内购+广告变现或客成为下一个方向。
对于产品内,还可延伸两个方向,一个是如何做用户分层,做差异化运营,不仅在产品功能上,也在广告上,在细小的环节尽量扣出更多的利润。还有一个深度挖掘用户行为,将买量与变现打通,让合适的流量以合适的价格买入通过其正常的行为来变现产生收益。
还有第三个思路就是换市场、换广告平台,扬帆出海,开拓海外市场。
本文由 @谁持白羽静风尘 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Pexels,基于CC0协议。