pdb连接数_PDB四-数据互通误区多

此篇为PDB之坑的系列四。

误区四：用户的ID需要打通么？

这是必须的，如果要想满足广告主跨媒体频控的基础需求，就需要让PDB能打通各个媒体给过来的用户ID(注意这里的用户ID不是指的媒体会员ID，若广告主需要实现跨屏PC+mobile频控，只能通过媒体会员ID才能打通，不过这个在当前国内媒体的还很难同意开放此类ID。不过国外有些媒体已经有一些开放的案例及广告主借此实现电商产品跨屏的推广案例。)

因为PDB最主要就是有一个第三方的系统能管理好广告主采买的整体的广告流量，不论是实现联合频控、千人千面等等等的投放目标，都是基于整体的所有媒体广告流量来说的，如果仅仅单媒体做频控传统采买就能实现了，也就没有PDB的必要了，正是这样，所以就需要通过PDB作为中介载体打通各个媒体的用户。

说到了打通，就来看看不同的情况大体都是怎么做的吧。

下面我们主要从PC端(移动WAP)及移动APP端两部分来看：

PC端一般用户都是以cookie来标识跟跟踪行为及记录频次。之前有整理过一篇术语的文章提到过cookie，后面我会专题整理一篇专门讲解CookieMapping的文章的。这里就简单概述一下。

“Cookie”是PC电脑中记录用户在PC网络浏览器中的行为的文件；PC端网站可通过Cookie来识别用户是否曾经访问过该网站。

因不同网站域名下Cookie无法跨域名调用，每个域名只能存储使用本域名下的Cookie，所以需要一个“CookieMapping”的环节。形象一点说：就是张三在A网站的名字叫“李四”、在B网站的名字叫“王五”，CookieMapping的目的是让A网站同B网站交换一下关于张三的名片，这样A网站上的“李四”访问B网站的时候，B网站就知道自己B网站的“王五”回来了。

对于PC视频OTV流量一般会存在VAST(关于VAST最近我也会准备一篇专题文章加以介绍)、RTB接口server端对接、少量会使用Flash(VPAID接口协议)广告容器来进行技术对接。

VAST、Flash广告容器都是直接同视频媒体的视频播放客户端对接的。广告请求是在用户浏览视频内容时，直接从用户浏览器中嵌入的视频播放客户端发出的。所以这种广告请求中都会携带PDB服务域名的cookie(如果该用户终端电脑之前请求过PDB服务域名下的广告服务，就能被“种”cookie)，这样能够让PDB系统在收到广告请求的时候查询用户终端电脑上是否已存有该PDB服务域名下的cookie(PDB一般是第三方服务，所以域名与媒体域名不是同一个域名)。若该cookie已存在，则PDB系统直接使用该cookieid来计算该用户在不同媒体的整体频次或分析行为等等工作，然后根据是否超频了来决定是否返回广告进行投放。而如果PDB系统发现该用户之前没有被“种”下PDB域名下的cookie，就在返回广告的时候生成一个cookie并通过HTTP协议的约定通知用户终端浏览器种下这个“cookie”。由此可见这种技术对接模式，仅仅在用户第一次请求广告的时候才涉及cookie是否存在的问题，之后直接使用就行了，基本不用操心CookieMapping的问题了。

那什么时候需要“cookiemapping”呢？目前随着行业发展，大型的视频媒体基本都逐步建立起了自己的adx可以灵活地针对不同的变现模式管理广告流量，所以基本都会采用“RTB接口server端对接”的模式。这样广告请求就不是直接从用户终端的浏览器发出的了，而是从媒体的服务端发出的，而且每个广告请求携带的都是媒体方域名下的“cookie”，媒体方是不可能取到PDB的“cookie”的。若PDB方的“cookie”同媒体方的“cookie”互相不能认识的话，很难做频控等等工作了，这样就必须需要cookiemapping了。(关于CookieMapping我最近会整理一篇专题文章，这里就不展开了)

然后我们看看PC端的固定位广告流量一般会存在JS(JavaScript)广告位代码、RTB接口server端对接两种模式来进行技术对接的。

JS广告位代码的模式下广告请求也是用户在浏览媒体内容页的时候，广告位要展示广告了，JS代码会直接在用户的终端浏览器中直接去拉取广告。这样PDB系统顺利获取到用户终端上的cookie，不需要“cookiemapping”的环节。

而“RTB接口server端对接”的模式上面也已经讲过了是需要“cookiemapping”的环节的。

对于WAP(mobile web)端固定位点位是同PC端的模式的，也是用cookie的。这里就不再复述了。

简单小结一下：若PC流量对接是使用的广告位JS代码的方式对接的，PDB方直接就能在用户的浏览器中种下cookie，这样就不需要cookiemapping环节。PC端就可以使用这些cookieid打通各媒体PC端的用户ID。

而PC端若是采用的Server端方式对接还需要增加cookiemapping环节。

前面花了大量的笔墨讲解了PC端的情况，那么移动APP端的情况该是如何的呢？

其实移动APP端因为采用设备ID来标识用户，不存在cookiemapping环节，可能会简单些。但是实际的情况要复杂的许多。

移动端点位技术对接是很多媒体不愿意传递设备ID，或者采用自己私有的加密方式，目的是不想泄露自己的日活、装机量等等数据。

首先来看看移动端设备ID的规则问题：

关于设备ID可以参考如下这个图表：

监测规范参考：

从表中可以看到，主要是imei、mac地址、androidID、IDFA、UDID、openUDID(14年之前openUDID用的较多，所以可能有些媒体android上还会使用，不过IOS6以上openUDID已不可用了。)

对于IOS，一般APP开发者只能获取到IDFA(而且在APP提交AppStore审核的时候还要说明使用了广告，才能被审核通过，才能使用IDFA。)。所以IOS上的APP媒体发送过来的广告请求大部分是IDFA的。

对于android：一般APP开发者能获取到很多ID：mac地址、imei、IDFA(google在14年模仿IOS也推出了IDFA，是集成在google PLAY中的，但google PLAY因某些原因进不了中国，所以在国内几乎无法使用这个ID)、androidID等等。

一般IDFA是专门给“广告用的”，在IOS中“设置”->”隐私”->”广告”打开“限制广告跟踪”就可以关闭IDFA，或者更新IDFA，来保护用户隐私。如下图截图：

而mac地址、imei号相对比较稳定，一般很难更改的，尤其拿着imei号原文是可以到电信运营商处反查出手机号及个人隐私信息的。所以媒体对这部分数据的开放是十分的敏感的。

然后就是加密的问题：

尤其对于mac地址、imei号这样稳定的ID，媒体开放的时候是一定要加密的。一般加密算法有”MD5”、”SHA1”这样的不可逆的加密算法，不可逆加密算法不代表一定不能反解出明文，仅仅是因为加密强度较大，要解出一个ID需要花很多的计算机计算资源和时间(这个时间都要以天来计算)。所以要把海量上亿的数据反解几乎是很不经济的事情，所以是相对安全的做法。当然也有些变态的媒体提出需要在MD5加密基础上再加上不同供应商的名字在MD5加密。这样如果要打通10个媒体基本上从中调停满足各家诉求基础成了一件无法完成的任务了。

14年我花了1年多的时间在推动各个媒体开放这些ID，因为要打通各媒体，需要各媒体给出来的ID必须遵守相同的规格要求和加密规则。

基本大部分媒体最终都是这样的设备ID规范：

Android ：

主要视频媒体：imei(md5)

Mac码

部分adx：androidid

IOS:

>=ios6: idfa

以上供大家参考，具体同媒体对接的时候一定要注意。

所以只有数据真正的互联互动了才能创造价值。

另外就是移动端，如果需要第三方监测考核要出频次或TA报告等等的，这块也需要组织媒体+PDB方+监测方一起沟通，如何让第三方监测获取到这些设备ID。这块我后面再整理一篇专题吧，今天就先到这里了。

所有内容归程序化广告实战微信号所有，转载请注明出处：微信订阅号：ad_automation 。