标签：
比如优酷与秒针这种情况，
从结果上看
宝洁在优酷的xx系统下单，生成了一些dealid
宝洁又在秒针的xx系统下单，生成了一些dealid
实际上是宝洁代理商制作一份大排期，然后根据各家媒体和秒针的排期要求拆分成小排期，然后给到媒体和秒针
然后媒体和秒针各自导入自己的系统中，然后媒体会生成一波dealid，秒针也会生成一波dealid
dealid是什么？
类似网购的订单id，但更确切的是一个购物单下的单个商品的“子订单”
比如我下了一个订单，买了一个鼠标一个键盘，是同一个订单号，但是鼠标个键盘各自有一个“deal”
实际上不同媒体不同DSP不同Adserving对dealid的定义是不一样的
但基本会遵循一个原则，就是从用途上讲，dealid就是用来系统间一次投放的标示
比如优酷请求秒针带了一个dealid为AAA，秒针收到后就知道，哦，这个AAA是xx客户的，xx媒体的，xx地域的，xx广告位的
既然媒体和DSP&Adserving各自生成各自的dealid，那如何在投放前做这个映射呢
目前采用的是沟通成本非常高的人工方式：
比如秒针的AE从优酷拿到优酷的dealid列表，然后根据优酷dealid所对应的广告位、流量等属性和秒针自己的dealid对应上，
然后导入秒针的xx系统中
当优酷发出投放请求时，带的是优酷dealid，秒针会将此dealid映射到秒针dealid后再执行投放逻辑
很多商务人员第一反应是，这种看似简单的功能，技术不能实现吗？！
那么，从dealid的本质上看，dealid=A*B*C*D，媒体和DSP或Adserving之间理论上可以达成某个统一的协议来识别dealid
比如优酷和秒针之间，dealid=广告主*广告位*地域*广告活动
假如让秒针来适应优酷，则优酷需要将广告主字典、地域字典、广告位字典给到秒针
双方在代理商的协调下对广告活动的名称或ID达成一致
优酷提供基于广告活动的dealid获取API
秒针调用这类API，再结合上述三个字典，就能自动生成dealid的映射关系
当然，我们并不排斥DSP&Adserving对于地域和广告位信息完全按照媒体的定义来，这种形式在理论上更加合理
应用了上述策略后，流程上就去掉了人工的部分，如果再配合投放前的试投功能，就能保证映射的正确性
但这套方案一个是实现起来比较麻烦，另一个是涉及到信息更新的问题是比较难处理的，比如如何应对媒体的页面改版
媒体方和DSP或Adserving之间，S2S对接中解决dealid映射的解决方案
标签：
原文地址：http://www.cnblogs.com/zuohongming/p/4499997.html
