底价优化

RTB中引入了修改后的Second-Price竞价模型,竞价成功的广告不需要向Ad-Exchange付他的出价,而只会付第二名的出价。

Second-Price的理论思想是这样的:假设我在卖莫奈的油画。有许多人想竞得这幅油画,每个人心里都有一个最高出价,但问题是他不想付比能竞得这幅画的出价多一分钱。那么,如果我告诉我的买主们他们竞得后只需要付第二个出价最高的人的价格,那么买主们就很乐意地告诉我他们的最高出价了,因为他们知道他们只需要付第二名的出价。这听起来很美妙不是吗?Second-Price竞价让每个人的生活都更简单了,并且创造了一个简单有效的市场。

问题是:在今天的广告市场中,我们似乎不能完全看到这个理论被应用。看一下下面两幅图,两幅图来自两个不同的exchanges的publishers,图中反应的是收益曲线。两个exchange都使用的是second-price竞价模型。

理解图中的收益曲线比较简单。在X轴上是CPM竞价,在Y轴上是竞得百分比,竞得百分比是指你在竞某个价格时你能从Publisher那得到曝光的比例。在右图中,我们看到一个比较符合逻辑的收益曲线,你在低于$0.4的出价时无法竞得曝光,在$0.5时你大概能竞得10%的曝光,在高于$2.00时你将可以竞得大约70%的曝光。在越高的出价点上,需求就越少,那么就有着更高的竞得比例。

而在左图中,你会看到一个比较奇怪的模式,在低于$0.90时,竞得比例为0,而在$1.00时,总得比例是80-90%。在这种情况下,其实是Publisher对这些流量设置了大约$0.9的底价。

这种情况在今天的RTB中非常常见,Publisher很恐惧RTB会蚕食掉他们的优质流量价目表(Rate card,意思Publish指定了各个广告位指定多少钱卖),并强制对RTB买家设置一个底价。一个非常有意思的现象是如果你去查看竞得率,你会发现其实根本没有多少出价会高于底价,换句话说,这些流量不值那么多钱。那为什么一个Publisher要设置一个底价来损害他们的收入呢?

What the publishers are afraid of

从根本上讲,Publisher是害怕广告主通过博弈出价,而导致更低的eCPM。

让我们看一个假设的Google AdExchange的竞价例子:一个29岁的男性用户在CNN.com中在看一个有关福特小货车的页面的第三个广告,他也被识别为准备购买手机的人。四个买家对这个特定的曝光感兴趣…

-福特买了关键词“小货车”,这个曝光对他的eCPM价值为$5.00(从CPC价格中推算出)。

-AT&T用第三方数据定向了手机购买者,出价CPM为$3.00。

-卡夫品牌广告定向了29岁男性用户,CPM出价为$2.00。

在Second price理论中,每个买家会提交他们的出价,福特的$5.00出价会赢得这次曝光,它将付费$3.00,即AT&T的出价。

现在有一个问题….频次&大量的曝光供给。用户会看多次广告。频次同样是至今为止优化广告效果中最重要的因素。所以每个买家只希望广告触达用户一定量的次数。

为了讨论清楚这个问题,我们假设这个29岁的男性用户,Joe,正在看CNN.com的不同页面的文章,有10次向他展示广告的机会。让我们假设我们的广告主每一次都竞价。为了对频次进行建模,我们假设每次曝光后,广告都只愿为相同的用户下一次的曝光付一半的钱。在这些假设下,下面的表给出了10次竞价的结果。


Auction


Ford


AT&T


Kraft


Price paid


#1


5.00


3.00


$2.00


$3.00


#2


$2.50


$3.00


$2.00


$2.50


#3


$2.50


$1.25


$2.00


$2.00


#4


$1.25


$1.25


$2.00


$1.25


#5


$1.25


$1.25


$1.00


$1.25


#6


$0.63


$1.25


$1.00


$1.00


#7


$0.63


$0.63


$1.00


$0.63


#8


$0.63


$0.63


$0.50


$0.63


#9


$0.31


$0.63


$0.50


$0.50


#10


$0.31


$0.31


$0.50


$0.31

我们看到的结果是Publish通过最大化CPM的收入从$3.00(原文是$2.5,是不是写错了?)很快的降到$0.31(原文是$0.64)。

现在是理论和实践分家的时候了。在上面的场景中,福特平均付了$1.72元CPM去展示他的4次广告。这比平均的CPM高很多,福特决定采用一种新的竞价策略来减少他的成本。他先不出价,等到第6次竞价时,他再出价。

下面是这种策略带来的影响:


Auction


Ford


AT&T


Kraft


Price Paid


#1


no bid


$3.00


$2.00


$2.00


#2


no bid


$1.50


$2.00


$1.50


#3


no bid


$1.25


$1.00


$1.00


#4


no bid


$0.63


$0.50


$0.63


#5


no bid


$0.33


$0.50


$0.33


#6


$3.00


$0.33


$0.25


$0.33


#7


$1.50


$0.33


$0.25


$0.33


#8


$0.75


$0.33


$0.25


$0.33


#9


$0.38


$0.33


$0.25


$0.33


#10


$0.19


$0.33


$0.25


$0.25

你从上图可以看到福特现在购买4次曝光,只是在用户的浏览时间靠后一些,但平均的CPM只用了$0.33,相比它之前每一次都出价时,便宜了81%。

当然这是一个假设的场景,但它表明了一个问题:如果需求是有限的,那么对于买家一个很简单的竞价策略会对付费有很大的影响,并可以显著地提高ROI

现在我们假设Publisher意识到了广告主的这种做法,并且设置了一个底价来保护它的边界收益$1.50。如果低于$1.50,他就展示一个自己公司的广告。

现在竞价的结果如下所示:


Auction


Ford


AT&T


Kraft


Price Paid


#1


no bid


$3.00


$2.00


$2.00


#2


no bid


$1.50


$2.00


$1.50


#3


no bid


$1.25


$1.00


psa


#4


no bid


$0.63


$0.50


psa


#5


no bid


$0.33


$0.50


psa


#6


$3.00


$0.33


$0.25


$1.50


#7


$1.50


$0.33


$0.25


$1.50


#8


$0.75


$0.33


$0.25


psa


#9


$0.38


$0.33


$0.25


psa


#10


$0.19


$0.33


$0.25


psa

现在Publisher已经成功地将福特的平均CPM从先前的$0.33,拉回到了$1.50。平均CPM却是从上张表的0.71下降到0.65。

这次我们看到为什么设置的高底价限制了曝光的售卖,导致了整体收入下降。

当然,如果你足够用心,你会指出低的底价是可能会相比没有底价提升整体的收入。

So what gives?

直销商们几年前已经知道上面的情况了。这就是为什么在ESPN主页上几乎没有效果广告主去竞价。令Publisher担心的就是品牌广告主也会通过竞价的方式去购买流量。所以他们的条件反射就是设置一个非常高的底价,以避免渠道冲突。

底价本身并不意味着不好。事实上有一些很好的理由去设置他们。首先,一些品牌广告主按价目表购买合约式广告流量,那么就没有理由让其它用户在市场上以相比之下很低的价格可以买到这些流量。而在其它情况中,一个Publisher可能会选择展示自己公司的广告,而不愿以很低的CPM去展示一个很糟糕的广告而引起用户的反感。

例如,假设你是ESPN,并且你有一个新的连续剧,你在这个连续剧片头插入$30 CPM的广告。如果ESPN展示一些CPM $0.10的垃圾广告,他们可能会损失一小部分他们的观众。并且如果他们不播这些垃圾广告,而去广告一些他们的新剧,就可以同时增加他们的网站流量和用户忠诚度,并且这同样会增加收入。如果在一千次曝光中有5次点击ESPN自己的广告,他们就可以从这个5个点南击中得到$0.15的纯收入。

Going back to market mechanics

让我们先回到市场机制的讨论。今天我们需要去避免的是条件反射性地去设置丧失理智的高低价——一个非常高的低价只会导致对Publisher来讲低的RPM。Publisher必须要明白有一个非常广阔的市场需求,特别是ROI & 效果驱动的需求方,他们是不会按价目表的价格来买流量的。

时间: 2024-11-07 10:29:42

底价优化的相关文章

如何让你的ASO优化效果提升10倍?

现在APP推广成本在不断上升,如何利用有限的预算达到最大的推广效果是我们必须要考虑的事情.ASO优化作为APP推广中常用的方法之一,可以使得App Store榜单排名和关键词搜索排名得到显著提高,迅速获取大量自然新增的用户.由于其推广效果较好,是众多开发商最热衷的一种推广方式.但是,我们如何从ASO优化服务中获得最大化的收益呢? 了解一些基本概念 我们在做ASO优化之前,需要对ASO优化有清晰的认识,对于ASO优化的基本概念,不清楚的朋友可以看看什么是ASO优化和如何做ASO优化两篇文章,对AS

用AI思维给成本降温,腾讯WeTest兼容性测试直击底价!

WeTest 导读 当AI成为各行业提高产业效率的动能,很多人开始疑惑,这架智能化的“无人机”何时在移动应用测试中真正落地?在今年的国际数码互动娱乐博览会(ChinaJoy)上,腾讯WeTest给出了答案. ?借助AI技术,在保证原有质量下,大大提升在问题识别与测试驱动两个环节的效率和识别准确率,深度兼容测试服务直击底价,仅需原市场价三成,所有移动应用开发者即可享用该服务.在测试领域,腾讯WeTest将释放AI的普惠力量! 摆脱人力单兵作战,AI有效降低测试成本 兼容性测试工作往往需要依赖大量设

iOS开发——项目实战总结&UITableView性能优化与卡顿问题

UITableView性能优化与卡顿问题 1.最常用的就是cell的重用, 注册重用标识符 如果不重用cell时,每当一个cell显示到屏幕上时,就会重新创建一个新的cell 如果有很多数据的时候,就会堆积很多cell.如果重用cell,为cell创建一个ID 每当需要显示cell 的时候,都会先去缓冲池中寻找可循环利用的cell,如果没有再重新创建cell 2.避免cell的重新布局 cell的布局填充等操作 比较耗时,一般创建时就布局好 如可以将cell单独放到一个自定义类,初始化时就布局好

Java性能优化之JVM GC(垃圾回收机制)

Java的性能优化,整理出一篇文章,供以后温故知新. JVM GC(垃圾回收机制) 在学习Java GC 之前,我们需要记住一个单词:stop-the-world .它会在任何一种GC算法中发生.stop-the-world 意味着JVM因为需要执行GC而停止了应用程序的执行.当stop-the-world 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到GC任务完成.GC优化很多时候就是减少stop-the-world 的发生. JVM GC回收哪个区域内的垃圾? 需要注意的是,JV

MySQL 索引优化原则

一.索引优化原则 1.最左前缀匹配原则,联合索引,mysql会从做向右匹配直到遇到范围查询(>.<.between.like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整. 2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优

sql优化

1.all: 全表扫描,遍历全表找到匹配的行 index:索引全扫描,遍历整个索引来查询匹配的行 range:索引范围扫描,常见于<,>,>=,between等操作符 ref: 使用非唯一索引扫描或唯一索引的前缀扫描,返回匹配某个单独值的记录行 eq_ref:类似ref,区别就是使用的索引是唯一索引,对于每个索引键值,表中只有一条记录匹配.简单来说,就是多表连接中使用primary key或者unique index 作为关联条件 const/system:单表中最多有一个匹配行,查询起

试试SQLSERVER2014的内存优化表

原文:试试SQLSERVER2014的内存优化表 试试SQLSERVER2014的内存优化表 SQL Server 2014中的内存引擎(代号为Hekaton)将OLTP提升到了新的高度. 现在,存储引擎已整合进当前的数据库管理系统,而使用先进内存技术来支持大规模OLTP工作负载. 就算如此,要利用此新功能,数据库必须包含"内存优化"文件组和表 即所配置的文件组和表使用Hekaton技术. 幸运的是,SQL Server 2014使这一过程变得非常简单直接. 要说明其工作原理,我们来创

Linux性能优化之磁盘优化(三)

前言 关于本章内容,设计的东西比较多.这里会有关于文件系统.磁盘.CPU等方面的知识,以及涉及到关于这方面的性能排查等. 术语 文件系统通过缓存和缓冲以及异步I/O等手段来缓和磁盘的延时对应用程序的影响.为了更详细的了解文件系统,以下就简单介绍一些相关术语: 文件系统:一种把数据组织成文件和目录的存储方式,提供了基于文件的存取接口,并通过文件权限控制访问.另外,一些表示设备.套接字和管道的特殊文件类型,以及包含文件访问时间戳的元数据. 文件系统缓存:主存(通常是DRAM) 的一块区域,用来缓存文

一个配置表优化的想法

今天下班在班车上想了一个关于配置表存储的小优化,起因是早上的时候发现了一个bug,这个bug是由于在运行时动态更改了一个列表配置导致的. 其实关于这种运行时"偷偷"改配置的问题我之前也有考虑过,这种应该是一不小心就会写出的,这不终于都出了一个. 至于如何预防这种问题,我认为在python里面似乎也没有什么好的解决方法,因为它不像c++有const语义,但有一个稍尽人事的预防措施就是把列表型的配置读成元组(tuple).而由此衍生出的一个想法便是:把配置表中所有的列表型配置都读成共享的元