程序化广告行业(55/89):DMP与DSP对接及数据统计原理剖析
大家好呀!在数字化营销的大趋势下,程序化广告已经成为众多企业实现精准营销的关键手段。上一篇博客我们一起学习了程序化广告中的人群标签和Look Alike原理等知识,今天咱们继续深入探讨程序化广告领域的其他重要内容,包括DMP与DSP的对接,以及网站和App的数据统计原理。希望通过这次分享,能让大家对程序化广告有更全面的认识,一起在学习中进步,探索这个充满机遇的行业。
一、DMP对接DSP:精准营销的桥梁
在程序化广告投放过程中,为了精准触达目标人群,DSP(需求方平台)常常需要借助广告主的第一方DMP(数据管理平台)和第三方DMP的人群数据,这就涉及到DMP与DSP之间的对接工作,这一环节对于实现精准营销至关重要。
(一)PC人群与移动人群对接差异
对于PC人群对接,首先要进行cookie映射。这就好比给DSP和DMP双方的人群标识ID建立一个"翻译对照表",让它们能"读懂"对方的数据。DSP投放的流量越大,能进行Cookie mapping的机会就越多。映射率越高,DSP识别的人群范围就越大,这样就能更充分地利用DMP数据,为广告主找到更多精准的目标人群。想象一下,DSP就像一个寻找宝藏的探险家,DMP数据是宝藏地图,而Cookie mapping就是让地图能被探险家看懂的密码。
而移动人群对接则有所不同。由于设备号ID是固定的,并且可以在不同App中共享,所以不需要进行cookie映射工作。但是,需要先进行人群匹配度检验。人群匹配度指的是DMP发送的设备号ID在DSP设备号ID库中的占比。匹配度越高,意味着DMP的人群标签在DSP的流量池中被找到的可能性越大,DSP也就更有可能覆盖到广告主需要的人群。行业内一般认为匹配度在40% - 60%比较合适。就好像在一个大仓库里找特定的货物,匹配度越高,找到货物的概率就越大。
(二)对接方式详解
DMP与DSP的对接方式主要有API接口、FTP传输和Pre - bid方式。API和FTP方式可以批量接收人群标识号及对应标签,就像是用大货车一次性运输大量货物一样高效。Pre - bid方式则有点不同,它需要在DMP与DSP之间部署一台前置机。这台前置机就像是一个中转站,先接收DMP的数据,然后在DSP投放前实时查询使用。下面用一段简单的Python代码来模拟使用API接口获取DMP数据的过程(实际应用中涉及更复杂的网络通信和安全机制):
python
import requests
# 假设这是DMP提供的API地址,用于获取人群标签数据
dmp_api_url = "https://dmp.example.com/api/get_crowd_tags"
# 模拟请求头,可能包含认证信息等
headers = {
"Authorization": "Bearer your_token",
"Content-Type": "application/json"
}
try:
response = requests.get(dmp_api_url, headers=headers)
if response.status_code == 200:
crowd_tags = response.json()
print("成功获取人群标签数据:", crowd_tags)
else:
print(f"请求失败,状态码: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"请求出现错误: {e}")
(三)对接流程
- 投放执行人员在DMP平台精心设置需要投放的人群标签条件,然后将这些标签应用到营销活动中。这一步就像是给即将出发的"广告大军"制定目标和路线。
- DMP平台根据营销活动的人群标签准备数据,接着向前置机发送初始化数据通知。前置机收到通知后就开始下载数据。而且,DMP的数据会不断更新,就像河流里的水一直在流动,所以需要持续同步更新数据到前置机。
- DSP平台设置投放活动,并在其中填入DMP平台对应的营销活动ID。当DSP收到竞价请求时,就像收到了"战斗信号",它会向前置机查询用户信息是否符合营销活动的人群标签条件。
- 前置机把查询结果返回给DSP。如果结果显示用户满足条件,DSP就像得到了冲锋的指令,参与竞价;如果不满足,就只能放弃这次机会。
二、数据统计原理:广告效果的"晴雨表"
无论是广告投放过程中还是投放后,对广告效果进行验证观察都非常重要。这不仅能帮助我们评估、制定和调整投放策略,还能依据用户行为数据优化广告、网站或App,提高用户转化和留存率。数据统计主要分为网站统计和App统计两种逻辑。
(一)网站统计逻辑
- 当我们在浏览器中输入一个网址,浏览器就会向网站Web Server发起请求URL,这就像是给网站的"门卫"发送了一个进门申请。
- 网站Web Server收到申请后,解析请求URL,并生成Html文档响应返回给浏览器,就好比门卫审核通过后,给我们递出了一份房子的设计图(Html文档)。
- 浏览器拿到这份"设计图"后,开始解析Html文件,加载外部脚本、样式表和图片等,这个过程会触发JS统计代码,就像是房子里的各种机关开始启动。
- JS脚本开始工作,它会收集各种信息,比如域名、URL、页面标题等,还能获取自定义事件(像注册行为)的数据。如果之前在用户浏览器"种"过cookie,就能获取到对应cookie信息;如果没有,就会进入"种"cookie的流程。
- 收集到的信息会被传输给后端脚本,这就像是把收集到的情报传递给后方的指挥官。
- 后端脚本会生成一个透明的1×1像素图片,在浏览器中"种"入cookie标识访客,同时解析并发送收集到的信息,从网站Web Server获取IP、访问时间等信息,然后写入日志Logo队列,就像是指挥官整理情报并记录下来。
- 日志信息被发送至实时统计服务,经过实时统计后进入实时数据库,这就好比把整理好的情报送到了一个临时仓库。
- 从实时数据库调用数据进行离线分析,然后存入离线数据库,就像是把临时仓库的情报送到了一个长期的档案馆。
- 最后,查询数据库,将数据以可视化报表的形式呈现出来,这样我们就能直观地看到网站的各种数据表现,就像是通过地图清晰地看到各个区域的情况。
(二)App统计逻辑
- App应用客户端向App应用服务端发起请求,这就像是手机上的App向服务器"喊话",说自己需要一些东西。
- App应用服务端收到请求后,响应并返回应用信息,就像服务器听到"喊话"后,给App递出了它需要的物品。
- App应用客户端调用统计SDK并初始化,同时通过API接口写入版本、渠道等信息,并进行数据埋点,这就好比在App里安装了一些"小眼睛",用来记录各种数据。
- 开始收集应用运行信息,包括访问者唯一标识(比如IMEI号、Android - ID或IDFA等)、访问时间、应用版本号等。这些信息就像是给每个访问者贴上了独一无二的"标签"。
- 在App启动/关闭或者收集的信息数量达到一定上限时,就把信息传送给后端,就像是装满货物的货车把货物送回仓库。
- 后端脚本解析并发送收到的数据包,写入日志Logo队列,就像仓库管理员整理收到的货物并记录下来。
- 日志信息发送至实时统计服务,进入实时数据库,就像货物被暂时存放在临时仓库。
- 从实时数据库调用数据进行离线分析,再存入离线数据库,就像把临时仓库的货物转移到长期仓库。
- 查询数据库,进行可视化数据报表呈现,这样我们就能清楚地了解App的运行情况,就像通过仪表盘了解汽车的各项指标。
下面用一段简单的Java代码来模拟App数据收集和传输的过程(实际应用中会涉及更多复杂的业务逻辑):
java
import java.util.HashMap;
import java.util.Map;
public class AppDataCollector {
public static void main(String[] args) {
// 模拟收集App运行信息
String visitorId = "1234567890";
String appVersion = "1.0.0";
String operator = "ChinaMobile";
String networkType = "4G";
Map<String, String> appData = new HashMap<>();
appData.put("visitorId", visitorId);
appData.put("appVersion", appVersion);
appData.put("operator", operator);
appData.put("networkType", networkType);
// 模拟数据传输给后端
sendDataToBackend(appData);
}
private static void sendDataToBackend(Map<String, String> data) {
// 这里可以替换为实际的网络请求代码,将数据发送给后端
System.out.println("正在将App数据发送给后端: " + data);
}
}
写作不易,希望这篇文章能让大家对程序化广告行业有新的认识和收获。如果觉得文章对你有帮助,麻烦大家关注我的博客,点赞并评论。你们的支持是我持续创作的动力,后续我还会带来更多程序化广告相关的知识分享,咱们一起在这个领域不断探索!