SSP项目平台调查

发表于 分类于 阅读次数：

ssp平台

基础概念

1
SSP(Supply-Side Platform), 供应方平台

目的

1
2
3
代表媒体端的利益, 提高媒体的变现能力
大型媒体进行最优化售卖、中小媒体直接介入广告交易
满足媒体在广告定位、投放、分析、反馈等环节中的自动化与定制需求

功能

1
2
3
4
5
6
7
SDK/API接入下载
账号->应用->代码位管理
应用/代码位审核
报表/报告
财务管理
过滤条件?
流量分配?

应该具有的特性

  • 支持SDK/API快速接入

    1
    2
    3
    与媒体资源、ADX、DSP等进行对接，实现即时售卖，获得最优化的展示收益

    自动化管理广告资源、内部系统集成、定制特殊功能、单个平台管理多个账户

  • 高数据响应速度

    1
    SSP平台需要从接收请求 —— 流量竞价 —— 获取竞价素材 —— 返回媒体数据的流程控制在100ms以内

  • 媒体管理能力- 媒体账号体系
    SSP 平台需要为每个媒体分配一个登录账号，该账号支持媒体登录、信息创建、数据报表查看；
    ​ 

       SSP 平台还需要对媒体中每一个广告位创建唯一的广告位id, 根据请求中广告位id的不同来决定本次申请的素材类型、素材尺寸，竞价价格以便告知DSP返回合适的广告素材

  • 媒体管理能力- 媒体流量控制分配

    1
    2
    3
    SSP应在努力提高营收的同时保证媒体流量的真实性. 进一步帮助媒体提高变现能力

    在不影响媒体产品体验的情况下，具体流量如何进行分配，分配给哪些渠道，如何最优化设置配比，一般由SSP来决定，媒体不过问细节，只需查看最终收益即可。

  • 广告约束条件
    SSP需要承诺媒体对应的安全性。考虑到媒体用户体验, 不能无约束的推送随意题材广告
    ​ 

       SSP平台需要有完备的广告筛检功能. SSP应严格按照媒体约定对所有的素材信息进行过滤和筛选，保证媒体产品不会因此受到负面影响。

   允许媒体自行定义可接受的广告素材和禁止投放的广告素材, 比如竞品信息、违反广告法素材、涉嫌黄赌毒素材等。

  • 充足的广告素材

  • 全方位的报表数据

    1
    SSP平台需要提供全面的、公开透明的报表数据，该数据包括所有广告请求量、曝光量、点击、转化以及收入情况

  • 数据开放性

    1
    DSP广告投放的核心在于用户的精准识别，所以关于用户的数据，SSP方传输的越多，DSP的分析会越精准，而其在该媒体的投放可能性就更大。

  • 运营规范

    1
    SSP平台与媒体、DSP、广告主之间的技术文档，必须有明确的规范流程，帮助相互之间的对接打通，避免因为技术问题导致的损害

  • 精准用户画像分析

    1
    针对媒体用户的属性进行多维度，多层级的分析，并为APP运营、广告投放等提供数据支持；

总结

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
在广告发布的整个流程中, ssp平台代表作为供应侧平台, 代表媒体的利益, 连接沟通媒体下游与需求方上游.
- 一方面, ssp平台需要服务于媒体, 帮助媒体提高变现能力. 
- 一方面, ssp平台也需要面对需求方, 审核广告内容, 把控流量分配, 以共同提高营收能力

ssp平台具备的能力:
从基础能力方面 
	- 需要支持SDK和API快速接入, 方便媒体快速接入本ssp平台
    - 以及较快的数据响应能力, 保证从接收流量到返回数据在100ms内
从服务对象方面看, 主要服务对象是媒体, 接入的问题解决后, 媒体最关心的就是流量变现数据
	- 后台需要有全面、完善的报表统计能力, 为媒体提供包括请求, 展现, 点击和收入的状况
从提高流量利用率及变现效率的方面, 需要ssp采取多种方式, 保障媒体和本平台的利益
	- ssp平台后台需要提供媒体账号管理体系, 方便媒体登录, 创建广告位及查看报表
	- ssp平台需要控制分配媒体流量, 在不影响媒体产品体验的状况下, 保障媒体流量真实性, 共同提高营收
	- ssp平台需要对广告进行约束筛选, 不能无限制随意发布任意题材广告, 避免媒体收到负面影响
	- ssp平台后台需要允许媒体自定义广告内容筛检, 禁止如竞品信息,违反广告法素材的广告发布

ssp平台需要的功能
- 媒体/广告位管理, 主要用于管理媒体的广告位资源
- 报备媒体信息到第三方平台, 获取第三方应用ID/广告位ID, 存到系统数据中
- 投放管理, 处理将广告物料下发给特定广告位的流程 及 转化结果统计报表生成
- 流量分配管理, 处理流量分配策略, 如优先级, 流量权重等(绑定多家上游时)

ssp平台在程序化中的作用
- 通过RTB/PPB的方式, 与DSP/ADX等需求方对接获取广告收入
- 减少人工参与环节, 提高交易效率
- 评估广告商, 设定出价范围, 实时放置内容

问题

第三方是什么角色, 代码位与第三方代码位有什么区别, 

1
2
3
4
5
6
第三方代表需求方/资方, 包括ADX, DSP以及其他ssp等
将本ssp平台中媒体的代码位上报需求方(adx/dsp), 授权后记录在第三方代码位, 便于本系统中绑定上下游, 为媒体分配流量 

[第三方平台] 记录平台名称, 便于登记代码位选择从属平台

[第三方代码位] 记录在第三方平台上已授权的代码位具体信息, 包括名称,从属平台,从属应用,代码位ID,物料具体资料等

ADX不是做交易平台的么, 为什么会有广告位

1
[ADX广告位信息] 记录在ADX中已授权的广告位清单, 包括名称, ADX系统中从属应用, 应用ID, ADX分配的广告位ID等
1
2
3
4
5
6
7
8
参考资料:

怎样打造ssp平台 https://www.zgdych.com/a/dianshi/844893.html
小米开放平台 https://dev.mi.com/distribute/doc/details?pId=1463
广告系列 https://zhuanlan.zhihu.com/p/148042955
openRTB https://github.com/openrtb/examples/tree/master/brandscreen
广告SSP平台 https://www.woshipm.com/it/5395414.html
在线广告体系发展图谱 https://www.jianshu.com/p/9acb0b5aaa93

其他相关资料

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
一个广告系统的需求方有可能是广告主、代理公司、TD或者DSP。
adx 广告交易市场 主要用于消耗ssp的长尾流量
头部广告主 -> 传统4A广告代理公司 -> DSP -> 媒体资源

adx交易多为长尾流量, RTB交易模式, 
PDB则多为优质流量, 包括优先交易(PD)和程序化保量(PGB)

广告的优先级基本上：直采-PDB-PB-PA-RTB-网盟

ssp-代表媒体利益, 一般处理大媒体长尾流量及中小媒体流量, 通过adx/dsp获取广告内容, 分发到对应流量
一般支持rtb/pdb方式售卖流量

广告业务的收益只能来自于三个方面：数据、流量和品牌属性
大数据就是用来处理第一个方面的内容

广告发展线路包括两条:
1.交易形式: 合约广告(固定位合约|展示量合约 GD)->竞价(催生ADN+TD)->RTB(DMP+ADX+SSP)
2.展现逻辑: 独立广告->原生广告

商业化平台目标: 优化既定商业目标, 而非优化产品功能及体验
- 相对于产品功能，要特别关注产品中的策略部分。
- 要特别关注数据，让运营和产品优化形成闭环。
计算广告定义: 是为 一系列用户与环境的组合 找到 最合适的广告投放策略 以 优化整体广告活动的利润

媒体常用变现方式: 担保式投送的合约售卖方式、自营广告网络、托管给其他广告网络、通过RTB变现
由ssp平台选择

请求到达-> 查询PD->RTB(依据受众标签筛选广告->估算ecpm并获取最高广告->DSP询价并选出最高价)

ssp产品竞价策略
1.根据受众标签计算自有广告库中的 eCPM，选出最高的 eCPM
2.估算合作 adn 的 eCPM，选出最高的
3.以 1、2 中计算的 eCPM 中最高的为底价，通过 RTB 接口向 DSP 查询有更高价值的广告
(eCPM = 点击价值 * 点击率 * 1000(次))

用户标识
- 对于 WEB 通常使用 cookie
- 对于 IOS 使用苹果专用的 IDFA（identifier for advertising）
- 对于 android 一般使用 Android ID 或 IMEI

三方数据划分
- 广告主数据：第一方数据
- 广告平台数据：第二方数据
- 其他来源数据：第三方数据

定向技术
即通过对用户基本数据/行为数据的分析，给每一位用户都打上标签，在广告投放时再找出潜在目标客群的共同行为特征，选择适当的媒体将广告投给具有共同行为特征的受众
包含: 地域/人口属性/频道/上下文/行为/精确位置/重定向/新客推荐等方向

竞价广告
- 主要参与玩家为TD和ADN
- ADN 广告网络: 
	将大型媒体以合约方式无法或不便售卖的边角或长尾流量 与小媒体的流量 整合后进行精加工,按照人群的流量切割方式售卖给广告主, 淡化了媒体的概念, 加强了人群概念
	ADN价格决策: 收到请求流量时, 判断用户受众标签, 依据受众标签检索广告库, 生成匹配广告集合, 然后对集合广告依据eCPM排序, 以价格最高者展示给用户,并收取相应价格 
	弊端: 广告相关度底下, 竞价逻辑封闭, 需求方控制度较低, 媒体体验降低
- TD 交易终端:
	将多个竞价网络或媒体通过API聚合, 提供一个统一的市场给广告主进行一站式采买并优化ROI;
	
搜索广告(搜索引擎广告/垂直搜索引擎广告)
- 特点: 高变现能力、精准的受众定向、高结果相关性
- 展示策略: 多个广告主队关键词竞价,广告进入广告库.  用户搜索该关键词后, 引擎根据关键词对广告库进行检索,匹配,排序,依据相关性及RPM放置北东南区,定价
	
搜索引擎营销（SEM）
- 通过竞价采买关键词, 帮助广告主做推广, 优化价格及ROI

竞价机制
- 定价
	GSP广义第二高价
	VCG策略
- 市场保留价MRP: 赢得拍卖位置的最低价格
- 价格挤压: 通过调整eCPM排序规则, 使得排序结果是依照 点击率为主(促使市场提高广告质量) 还是 点击价值为主(刺激广告主出价)

实时竞价
- 实时竞价和程序化交易都特指需求方而言的，供给方在很早以前，也就是在竞价产生的一开始就是程序化、实时的了

优选(PPB)
只有一个需求方的程序化交易, 比市场价格更高的CPM单价, 广告延迟增大

私有市场PMP
保证广告主质量、同时保留了竞价关系。

实时竞价RTB
ADX 广告交易平台
不保存广告库, 不需要检索流程, 简单排序, 关注询价优化问题(多个DSP发请求)

DSP 需求方平台

ADX / DSP数据同步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
ADX <=> DSP 
为了保证询价-出价-竞价-竞得的顺利进行，并最终促成广告曝光的发生, ADX与DSP之间需要数据同步

辅助类信息:
1.用于身份验证及前期约定相关记录
  - DSP平台注册ADX, 完善身份信息(IP,ID,Token,竞价地址,通知地址,加密方式,资质,流量偏向等)
  - DSP通过白名单IP,DSP_ID,Token验证,调用ADX接口登录进行后续操作
  - ADX有流量请求时向DSP发起询价, 并通知获胜DSP, 过程加密
  - ADX可以按照配置, 选择偏向流量分发给DSP询价操作
2.广告主相关信息,通过ADX接口上传至ADX审核, 包括广告主的公司主体、品牌名称、行业信息、联系人信息及资质
3.广告素材信息,依据信任度执行不同审核机制
4.财务数据信息, 约定打款方式
5.广告结果数据
  - 竞价数据, 包含请求数、响应数、放弃竞价数、竞价超时数、解析错误数、无效竞价数、竞价失败数、竞得数
  - 效果数据, 包含曝光数、点击数、点击率、消耗数、cpc(点击单价)、cpm(千次曝光单价)
6.广告位信息
  - DSP需要同步ADX的广告位信息, 确保ADX发起竞价时认识该位置, 包括ID、名称、代码位类型、所在位置、所属媒体、支持的模板、素材尺寸大小、素材类型、交易方式、过滤规则(特定行业、应用包名、网址域名、应用类型、关键词）等

实时竞价类信息:
1.ADX发起竞价请求Request, 携带参数包括imp、媒体(site/app)、设备(device)、地理位置等
  - imp 包含广告位相关信息. 如id、所处位置、计费方式、底价、允许返回的素材数量、过滤要求、宽高、支持的交易方式、支持的广告位类型等
  - 媒体(site/app) 广告位所属媒体的信息. site包括网站名称、网址、主题频道、标签关键词等；app包括应用名称、包名、所属系统、分类等
  - 设备(device) 发起请求的设备信息. 包括 IP、系统及版本、设备类型、制造商、运营商、网络环境、屏幕宽高、设备标识等
  - 地理位置(GEO) 经纬度、国家、省份、城市等
2.DMP回复竞价参与响应Response
  - 接收到ADX的请求后，DSP根据设备识别出用户，利用DMP得出用户画像，
  - 并结合其他请求信息（广告位/媒体/设备/位置信息等）与广告主的定向条件匹配，过滤不符合的广告，
  - 如果有满足条件的广告则选择出价并返回创意（广告位素材/落地页/上报链接等)
3.ADX比较多个DMP报价
  - ADX需要对返回的广告做有效性判断，包括出价、广告素材的类型大小尺寸、行业、包名、关键词等，通过过滤筛选的创意进入比价池。
  - 同一广告位针对各DSP的报价开始竞价，价高者得，胜出后返回给SSP，返回的数据中包含了ADX的监控链接，在行为发生时方便客户端上报用于后续统计分析及计费。

计算广告发展过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
固定位合约广告/展示广告(display ad)
	合同规定时段内某一广告位被特定广告主所独占, 即HTML被当作杂志页面来售卖广告位

定向广告(targeted advertising)
	对不同的受众群体展示不同的广告创意
展示量合约广告  担保式投送(guaranteed delivery)
	媒体只要和广告主签订好合同、在固定时间段内把他的广告展示出来就可以了

竞价广告（Bidding）
	媒体把自己拥有的广告位（关键词标签）拿出来公开拍卖，谁的价格高谁就能获得广告位。
	最先应用于搜索广告（search ad）,上下文广告（ contextual advertising）
广告网络（ Ad Network，ADN）
	批量运营多家媒体的大量广告位资源，按照人群卖给广告主. 对长尾流量进行精加工的方式按照人群进行售卖
	ADN最出名的就要算Google的AdSense了(虽然并不非常典型)，中国则有易传媒(AdChina)或是好耶(AllYes)。
	ADN的竞价逻辑是封闭的，广告主只能在ADN定义好的人群定向标签上预先出价，而不能控制每一次展示的出价
交易终端（Trading Desk，TD）
	为解决面对多个ADN质量层次不齐无法选择的问题
	将多个ADN通过api的方式进行对接、提供一个统一的市场，然后面向多个ADN或媒体按人群帮助广告主一站式采买
	
	
实时竞价（Real Time Bidding，RTB）
	竞价过程开放，在广告展示时由需求方决定来判断是否需要并出价
广告交易平台（Ad Exchange，ADX）
	- 透明开放的比价平台. 聚合各媒体剩余流量并采用RTB的出价方式进行流量售卖的产品
需求方平台（Demand Side Platform，DSP）
	- 帮助广告主们玩转Ad Exchange的中介(agency)
	- DSP同时把主流的Ad Exchange的系统都与自己驳接，然后提供给广告主们一个统一的更加简单的操作界面，能够按照定制化的人群标签帮广告主购买广告，并通过RTB出价。
	
程序化购买（Programmatic Buying）
	- 依赖于两个重要事情：其一，需要受众数据，准确的，海量的；其二，强大的自动化算法，保证最合理的竞价
	
数据管理平台（Data Management Platform，DMP）
	手中握有受众数据，并且能够让DSP驳接到他们这里，从而利用它们所有的数据

供给方平台（Supply Side Platform，SSP）
	打点各个Ad Exchange的关系, 提供使用体验更一致更集成的广告位库存管理环境

加权轮询

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<?php
  
$data = [
    ['id' => 1, 'name' => 'user_tom', 'weight' => 1],
    ['id' => 2, 'name' => 'user_jerry', 'weight' => 3],
    ['id' => 3, 'name' => 'user_dog', 'weight' => 6],
];

function selectByWeight($data)
{
    $weightTotal = 0;
    $weightArray = [];
    foreach ($data as $current) {
        $weight = $current['weight'];
        $weightTotal += $weight;
        for ($i = 0; $i < $weight; $i++) {
            $weightArray[] = $current;
        }
    }
    $randIndex = rand(0, $weightTotal - 1);
    return $weightArray[$randIndex];
}

# 测试
$startTime = microtime(true) * 1000;
$userTime_1 = 0;
$userTime_2 = 0;
$userTime_3 = 0;
for ($i = 0; $i < 100000; $i++) {
    $user = selectByWeight($data);
    $id = $user['id'];
    $valueName = 'userTime_' . $id;
    $$valueName++;
}
$endTime = microtime(true) * 1000;
$costTime = $endTime - $startTime;

var_dump('user1点击次数: '. $userTime_1);
var_dump('user2点击次数: '. $userTime_2);
var_dump('user3点击次数: '. $userTime_3);
var_dump('耗时' . $costTime . '毫秒');

加权轮询2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<?php

$data = [
    ['id' => 1, 'name' => 'user_tom', 'weight' => 10],
    ['id' => 2, 'name' => 'user_jerry', 'weight' => 30],
    ['id' => 3, 'name' => 'user_dog', 'weight' => 60],
];


function selectByWeight($data,int $rand)
{
    $start = 0;
    foreach ($data as $current) {
        $weight = intval($current['weight']);
        $end = $weight + $start;
        if ($start <= $rand && $rand <= $end)
            return $current;
        $start = $end;
    }
    return $current;
}

$startTime = microtime(true) * 1000;
$userTime_1 = 0;
$userTime_2 = 0;
$userTime_3 = 0;
$weightTotal = array_sum(array_column($data,'weight'));
for ($i = 0; $i < 1000000; $i++) {
    $rand = mt_rand(0,$weightTotal);
    $user = selectByWeight($data,$rand);
    $id = $user['id'];
    $valueName = 'userTime_' . $id;
    $$valueName++;
}
$endTime = microtime(true) * 1000;
$costTime = $endTime - $startTime;
var_dump('user1点击次数: ' . $userTime_1);
var_dump('user2点击次数: ' . $userTime_2);
var_dump('user3点击次数: ' . $userTime_3);
var_dump('耗时' . $costTime . '毫秒');

/*
F:\wamp64\www\Project\test\weight2.php:36:string 'user1点击次数: 108764' (length=25)
F:\wamp64\www\Project\test\weight2.php:37:string 'user2点击次数: 297341' (length=25)
F:\wamp64\www\Project\test\weight2.php:38:string 'user3点击次数:
593895' (length=25)
F:\wamp64\www\Project\test\weight2.php:39:string '耗时3416.0419921875毫秒' (length=27)
*/

ssp运行流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
1.媒体接入
- 确定接入应用及广告位详细信息
- 确定媒体接入需求, 如广告过滤条件, 拒绝某类或某些域名广告接入
2.运营配置
- 上传媒体应用/广告位信息到ssp平台
- 审核上传数据内容
- 第三方(adx/dsp)备案媒体广告位信息并同步结果到ssp平台
- 绑定上游广告需求到代码位, 分配流量及权重
3.程序化逻辑
- 媒体用户流量到达, 媒体携带广告位标识、当前用户参数及上下文信息请求广告物料
- ssp平台优先检查是否当前曝光广告位是否存在程序化直接购买计划(PDB)
	- 存在, 携带参数请求对应DSP获取广告物料
	- 不存在, 进入交易市场, 携带参数请求ADX发起RTB竞价, 获取竞价胜利平台的广告物料
- 完成广告下发, 并收集记录本次流量处理结果, 供统计报表使用.

修改意见: 
 ssp平台不参与竞价, 仅负责服务于媒体,链接需求方,报备媒体广告位并转发请求下发物料
 ssp平台一般不接大媒体, 他们有自己的平台和规范, 接也是采买我们的流量当上游,而不是出售流量当下游
 确定技术参数如广告位标识,当前用户,上下文等, 需要按照技术文档下发媒体,而不是商议决定
 品牌方PDB不直接对接ssp,也不直接对接媒体(太多), 而是与DSP对接需求, DSP通过ADX对接媒体资源
 物料审核不是由ssp平台做的, 而是广告主需要在DSP平台报备审核, DSP向ADX报备审核, 大媒体可能会需要审核, 一般小媒体不关注这些
 下一步应该基于当前了解的业务流程, 基于当前已有后台, 设计其他缺失模块, 完整系统架构. 但还不到具体设计表/sql的阶段.

广告监测

1
2
3
4
5
6
C2S	(client to server) - 客户端到服务器向监测方服务器上报
S2S (server to server) - 广告平台服务器向监测方服务器API上报，容易造假
监测上报方式分为：API监测、监测SDK 或 JavaScript（简称"JS监测"）。
 - API：实现对监测代码接口上报数据的采集。
 - 监测SDK：实现对监测代码接口上报数据的功能进行封装的模块。
 - JavaScript：实现对监测代码接口上报数据的功能进行封装的脚本语言。
客户端\监测方式 API 监测SDK JS
PC端网页 适用 - 适用
PC端App 适用 - -
移动端网页 适用 - 适用
移动端App 适用 适用 -
OTT端App 适用 适用 - 
1
2
3
4
监测中的常见数据问题:
 数据差异问题（简称"GAP"）
 允许正常误差 5%，行业一般定义 5%为显著性检验的水平，如果超出此范围需基于实证研究进行说明和行业确认：曝光数、点击数、独立访问人数 
 但在实际投放中，平台可与客户在合同中约定可接受的GAP范围，以及在该范围内时，按照哪方的数据进行结算，一般10%之内即可。GAP难以解决时，广告费可以先结算无争议的部分。