程序化购买必知3:什么是SSP?

SSP-Supply Side Platform的缩写,作为一个技术platform服务于生态圈中的publisher,为媒体方管理和销售自己的广告资源,下游一般为ad exchanges 或者ad networks。

 

SSP工作流

SSP在生态中的工作流如上,所以很显然,SSP的功能集中于自己的上下游,尤其publisher。

 

 

22SS后台

上图可以看出SSP中关于广告的管理,样式、平台、价格、格式,publisher可以结合自己的资源进行创立。

1SSP后台

上图的dashboard是典型的SSP后台,publisher可以看到自己资源的收入、每千次展示收入、展现量、填充率、广告完全展示次数。

 

程序化购买必知2:什么是DSP?

DSP是Demand Side Platform的缩写,顾名思义,DPS是用来服务金主的,满足需求的,数字广告领域,DSP是一个在线的工具满足各种各样差异化广告主购买、投放、优化广告的需求,为此,DSP链接了各种广告资源、研发各种优化工具。

DSP明显特征有,强大的广告管理和优化(基于频率、预算、标签、时间、再营销、DMP)功能,有强大的资源对接功能(PC移动整合、多种广告格式支持、多种投放方式支持)。

强大的广告优化能力或者说流量中介能力(能中介出去也是一种优化)是DSP生存的根本之一。其中一种业务:很多头部的“优质”资源被优先出售后,剩余的流量如何通过各种优化手段满足“双赢”,那么“各种”优化手段就是围绕DSP的产品和竞争力。

两个标准:DSP帮你链接广告资源,指导你明智地投入预算

DSP后台

这是一个典型的DSP后台功能,你可以看到大量的广告资源、预算管理模块、广告管理模块、追踪和转化管理、投放人群的管理等

目标定的小一点,比如先快它个20倍吧

去年Facebook发布Instant Articles(即阅文)时,也只是着眼于publisher的优化方案,目的是“能方便他们创建加载速度快的互动式 Facebook 动态”,本质上是服务于FB的现金牛信息流广告,如不是相关渠道从业者,甚至不知此物为何用。

不久后,Google便发布了AMP计划,一项号召全行业参与的网页加速计划。

如你所知,最近的里程碑——百度推出中文移动网页加速实施方案MIP。

AMP发布的时候引起了不小的震动,甚至连线杂志都发了评论员文章,因为这样的方案解决HTML5页面最大的痛点:速度,且通过一个模糊的容器概念,使这种效果不限于在某个APP内完成。

我们先将两个搜索巨头的解决方案,放在一起对比一下

077EFE7C-DE74-4E7E-97B8-2E8D39CE5E07

这些加速的机制和特点我原封不动地引自两个框架的官方网站,我刻意将相似的技术放在了同一行,如果你已经使用了这样的框架,这些经过自上而下规范过的代码对页面加载速度帮助极大,你甚至可以获得原生APP的感受。

“精简的JS”

“预先告知标准的静态资源”

“不允许且不被信任外部JS”

“特定规范的CSS及动画”

这样的页面犹如一个个加工精准的子弹,而浏览器只需要上膛击发,那些繁多复杂的卡壳问题将一去不复返。

因为,本质和“即阅文”一样,虽不是在指定APP内完成加速,MIP取而代之是增加了更多的代码规范,形成一个抽象上的容器,符合这些规范的页面将进入“容器”完成飞一般的体验,当然我想你要使用百度APP可能效果更好(MIP现在没有未来也会有这样特别的加速吧),你可以感受一下百度APP中打开百度自家产品和打开你的网站的对比。

这是趋势吗?

不定论好坏,我想起码一部分是,比如内容类的资讯页。

或者你应该这么理解,如果你还需要搜索引擎分发的流量,你就要尊重这个产品及其用户的要求,因为速度也是这个产品要解决的痛点。

很常见的一个误解就是,当你我都以为网友们在访问这样的页面时

携程首页

其实网友们大多是看这样的信息

2王宝强马蓉亲子照

有了规范,你不能再为做不出极速的页面找理由,为了利益而拖慢页面速度的事情更不能!你是在和渠道作对,看看这些搜索结果,这些页面上的ad,无序的、低效的HTML5页面,损害的是广告主、浏览者、搜索引擎的利益,不帮助(治)你提高帮(治)谁?

最后,难以回避地,我们还是要面对一下“即阅文”、AMP或是MIP的原罪——这种极权模式下的框架,极其严重地扼杀了新的技术和设计,页面将不再具备美感和用户体验!(OMG,用户体验这神奇的佛挡杀佛的名词啊)

吃饱了吗?就谈艺术

首先,你是内容类页面吗?你成天转来转去的微信公众号的页面扼杀了多少HTML5新技术你两只手数的过来吗?极其严重地影响了优质内容的产生和传播了吗?从渠道优化技术角度看,公众号其实一开始就拿来是和“即阅文”对标的产品,看着不像是吧,公众号、即阅文、AMP、MIP再加一个快出来的应用号,原理和本质上都是一样的,仔细想想容器的概念吧

其次你运用的新技术性能上保证到了多高的水平,说白了你是否连累了你渠道的用户,尤其是免费渠道,比如搜索引擎?做的再好看用户打不开还是白瞎啊。姑且你做到了最牛的技术及最高的性能,行业里你觉得能有几家水平会做、愿意投入去做这样的优化?为你的渠道想想吧,尤其免费的渠道,它不是服务一两个极客做的网站,然后被一叶遮目的嫌弃,你追求的是技术的极致和前卫,可架不住我们大伙想看王宝强啊,(此处突然想艾特这届百度公关)。

如果以上你都不符合,你既不是内容类页面(简单交互类页面),也没法将手里的不是MIP规范的页面优化到MIP的水平,那就多提和推进MIP的产品、研发及运营人员,将MIP尽快做到cover非内容类页面,比如“精致的JS”再OPEN一点?有限度地为我们开放一些自定义JS方法的权限?不同级别的站点“容器”宽松度不同一点?甚至百度CACHE便宜一点?

基于目前H5页面及其发展的进程,我们不要脱离实际生产和效益来说,我的观点是特别悲观的,在一个不稳定的环境(各式各样的浏览器及webview)下,一个充满鸡肋和不确定氛围的研发大潮背景下,H5前端技术再花哨和前卫,也掩盖不了整个生态长尾中那些技术和产品的羸弱,由此造成的产出、投入的惨淡使这种问题陷入死循环,本质上我们连大部分页面中的速度和阅读品质都解决不了,关注那几颗夜明珠又有什么用处呢?为什么不通过一些hero app 来带动一下基础建设,把根基及服务的用户做扎实呢?

还是王健林老师说的好:”要当首富这是对的,先定一个能达到的小目标,比方说我先挣它一个亿,一个亿,亿,亿,亿…”

 

本文的AMP版本