4

媒体如何做广告流量的分配与管理

 2 years ago
source link: http://www.woshipm.com/marketing/5321978.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

编辑导语:当下互联网时代,流量的分配与管理成为了媒体们的重要工作之一。那媒体如何做广告流量的分配与管理?本文从底层逻辑出发,跟大家一起分析广告流量分配的原则和方式。一起来看看吧。

AGGoIAXjusWP6Bm4XSge.png

本文面向读者

产品(APP)已经进入商业化阶段,并且选择了广告流量变现。

在面对接入的多家广告供应商(联盟、代理、直客)等,不知如何更优的分配流量的媒体。

接下来,我们从业务的底层逻辑开始进行思路分析,我将带领大家逐步分析出广告流量分配的原则和方式。

一、优先级原理

从媒体的角度出发,广告变现的目的很单纯,即:收入。

那么和收入最相关的因素是什么呢?

根据如下广告收入公式(广告收入=eCPM*曝光PV/1000),很清楚的可以发现和广告收入直接相关的因素有2个:eCPM和曝光PV,曝光PV是我们APP可以提供给广告变现的流量。

那么,我们这里主要讨论下eCPM。

eCPM的波动因素比较复杂,有外部因素,有内部因素,例如:

le9U9koD4B6rviVXxUJG.png

在实际操作过程中,产品属性、用户属性是我们无法改变或者短期内无法快速改变的,而广告位的设计和样式优化与本文主题无关,外部因素的市场和季节影响对所有媒体都一样,所以这些内容在这里不进行展开。

广告供应商平台的资源和能力其实可以和内部因素的广告平台选择作为同一个维度进行分析,投放策略也就是我们这篇文章的核心讨论点。

市面上有很多广告平台,有的是联盟,例如腾讯的优量汇、头条的穿山甲等,也有很多代理公司以及直接做直客的供应商,每一个渠道的平均eCPM都不同,有的甚至差距很大,这和渠道的商务资源能力及技术能力有关。

那么我们在分配流量的时候,很自然的可以想到,要把流量先分配给eCPM更高的渠道。

这里就有了一个优先级的事情,哪个渠道的eCPM更高,就优先展示这个渠道的广告,当广告展示失败的时候,再展示次级eCPM价格的渠道广告,以此类推。

这里提到的“优先级”,就是广告流量分配的基础原则。

当然,eCPM是一个动态变化的事情,渠道广告预算的变化及市场经济经济的波动都会影响到eCPM,所以需要运营同学随时关注数据,及时调整。

刚才提到广告展示失败的时候,展示次级eCPM的渠道的广告。

那么,什么时候广告会展示失败呢?广告展示的流程为:请求-请求返回成功-曝光。

“请求返回成功-曝光”这个过程的成功率为展示率,这个展示率和媒体的耗时限制有关。

这里我们主要讨论“请求-请求返回成功”的过程,这个过程的成功率为填充率,填充率映射的是每一家渠道的广告商务能力,像Google这样的公司,哪怕位置很差的广告位,填充率基本都是接近100%的,而国内的主流联盟公司的填充率差别也是比较大的。

因为广告的请求到曝光是有耗时控制的,因此肯定希望在限定时间内,有更多的广告请求得到了有效的曝光,这样才不会浪费流量。

因此,自然而然的可以想到,填充率高的渠道应该给更高的流量优先级。

至此,关于“优先级”,我们已经提出了2个因素:eCPM和填充率,两者都是更高值的渠道给更高的优先级,那么,如果两者冲突怎么办?

比如:A渠道的填充率很高,但是eCPM很低。

在实际操作过程中,这是一个基本都会遇到的问题,所以我们在考虑优先级的时候可以按照如下几个标准去分析优先级:

原则上,基础优先级按照eCPM排列,前一个层级展示失败或者填充失败的时候请求下一个层级。

如果渠道的填充率非常低,甚至低于1%,那么除非eCPM比其他渠道高很多,否则可以根据媒体的耗时情况酌情考虑剔除该渠道的流量,或者将该渠道的优先级降低,尤其是耗时问题比较严重的媒体。

eCPM很低但是填充率很高的渠道可以排较低优先级作为打底广告,根据经验这种渠道在市场上是非常多的。

如果有几个渠道,eCPM和填充率差不多,可以将这些渠道设置成平级。

渠道提供的广告接入方式一般有API和SDK两种。

SDK广告一般只能由客户端发起请求,而针对API渠道的广告,不同媒体的技术实现方式不同。

如果API广告是由服务端发起请求的,那么API渠道的广告优先级只能高于SDK广告。

这个时候媒体商务在对接的时候,必须要求API渠道的底价eCPM不低于SDK渠道。

当然这样的风险就是API渠道的填充率可能会比较低,尤其是市面上的主流大公司基本不提供API接入方式。

所以这个时候就需要运营同学根据媒体情况,和所有渠道的eCPM和填充率情况,做一个综合决定。

可按照如下公式进行策略ROI的对比:

第一层渠道广告收入=总广告请求PV*第一层渠道的填充率*第一层渠道eCPM/1000*第一层渠道广告展示率。

第二层渠道广告收入=(总广告请PV-第一层渠道展示后剩余PV)*第二层渠道的填充率*第二层渠道eCPM/1000*第二层渠道广告展示率。

以此类推,可以算出每一层的预估广告收入,然后将所有层的广告收入相加,即可大概的预估出该策略的收入,通过这种方法可以简单的进行不同策略间的ROI分析。

当然有技术条件的媒体可以对所有策略进行AB测试,直接用在线上数据做效果对比。

目前为止,我们已经分析完流量分配策略的基本原理,即优先级原理,当然在实操过程中,要综合考虑耗时、各渠道的eCPM和填充率差距等,进行综合计算和分析。

二、权重和包量

前面讲到,有些渠道我们设置成了平级,针对平级的渠道,有时候我们可以根据实际情况进行流量权重的分配。

比如渠道A和渠道B虽然平级,但是A权重为60%,那么当流量流到A和B这一层的时候, A会有60%的机会拿到流量,B有40%的机会。

这种流量分配策略,主要用于几家渠道评估下来效果差不多情况下的灵活运营,以及我们和渠道方谈的流量相对固定的情况,当然这种情况为了满足渠道方的需求,需要运营做相对精准的流量计算,来计算出这个权重比值。

对于有技术条件的媒体来说,也可以通过一个包量的方式满足渠道的这种固定数量流量的需求。

当然包的流量总值需要按照全天的APP活跃波动进行至少以小时为单位的流量动态分配,并且包量的流量分配是独立于优先级和权重分配的。

三、更复杂的策略

以上,基本讲完了广告流量分配的基础原则,按照这种方式进行流量分配的思考和管理,基本可以满足业务的基础运营需求。当然进一步还有一些更复杂的策略,以下做一些简单的描述:

广告请求和展示不要以渠道的方式进行,而以订单的方式进行,这样每个渠道可以有多个订单,我们就可以针对每个渠道设置一些高价订单和低价订单。

我们从订单的维度进行流量的分配,因为每个渠道可以有多个订单,这我们可以分配的流量请求单元变多。

例如:有4个渠道,按照渠道分级,我们可以分为4层进行广告请求,如果我们变成订单维度,假设4个渠道里有3个渠道分别有2个订单,1个渠道有1个订单,那么一共有7个订单,从订单维度分级,就可以分7级,这7个层级的eCPM和填充率都有一定的差别。

当然,不是说所有的渠道一定要多个订单,这个还是要根据渠道和媒体实际情况来判断的,有的渠道也许一个订单就足够了,毕竟订单层级变多了,耗时也会变多,所以需要综合考虑。

另外,可以在渠道和订单维度都增加优先级功能,在运营实际制定和配置策略过程中会更加方便,但是这样对产品经理的后台设计要求也会更高。

上述提到的包量和权重分配同样可以在订单维度设置同样的功能,这样就可以针对同一个渠道,进行单个订单(往往和底价有关)的包量和权重分配,这样我们和渠道的合作会更加的灵活,策略也可以更加丰富。

前面讲到eCPM的影响因素的时候,投放策略里提到了素材和人群等。

每个媒体的用户往往是有群体划分的,最基本的也会有城市级别(一二三四线)和性别的划分,而往往不同群体的eCPM是不同的,例如不同城市级别用户的eCPM不同,男性和女性的eCPM也不同。

那么我们在分析策略的时候,可以针对不同的用户群体设置不同的订单,配置不同的底价,配置不同的渠道和流量优先级。

这个需要媒体在广告业务已经运营了一段时间,且对自己的用户画像和不同画像之间的广告数据差异已经有了非常明确的认知才可以有效的运营。

前面我们提到的所有流量策略,都是基于串行的流量请求逻辑。

当媒体的广告业务运营到一定阶段,且渠道多到很难再输出策略的时候,就要进行并行,或者RTB竞价的运营模式,这种模式相对复杂,而本文主要面向刚开始进行广告流量变现的媒体,因此这里不再展开,后续将单独开文描述。

根据如上的分析和描述,广告流量分配的基本原则就是优先级原则,在耗时允许的前提下,将填充率和eCPM作为主要因素,同时搭配流量权重和包量策略,综合计算并分析出适合自己媒体的流量分配规则。

同时,也提供了一些相较更复杂的策略方式,例如:订单&渠道结合的优先级/权重/包量的方式,用户分群精细化运营等。

最后,希望本文可以给刚开始做广告流量变现的媒体有一些帮助和启发。

本文由 @小木 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK