网站地图 | Tags | 热门标准 | 最新标准 | 订阅

GB/T 34941-2017 信息技术服务 数字化营销服务 程序化营销技术要求

  • 名  称:GB/T 34941-2017 信息技术服务 数字化营销服务 程序化营销技术要求 - 下载地址2
  • 下载地址:[[下载地址1]][[下载地址2]]
  • 提 取 码
  • 浏览次数:3
下载帮助: 发表评论 加入收藏夹 错误报告目录
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
新闻评论(共有 0 条评论)

资料介绍

  ICS 35 . 240 L 77

  中 华 人 民 共 和 国 国 家 标 准

  GB/T 34941—2017

  信息技术服务 数字化营销服务

  程序化营销技术要求

  Informationtechnologyservice—Digitizemarketing—

  programmaticmarketingtechnologyrequirements

  2017-1 1-01 发布 2018-05-01 实施

  中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

  发

  布

  GB/T 34941—20 17

  GB/T 34941—20 17

  前 言

  本标准按照 GB/T 1 . 1—2009 给出的规则起草。

  请注意本文件的某些内容可能涉及专利。 本文件的发布机构不承担识别这些专利的责任。

  本标准由全国信息技术标准化技术委员会(SAC/TC 28)提出并归口 。

  本标准起草单位:上海市信息服务业行业协会、杭州阿里妈妈软件服务有限公司、百度在线网络技术(北京)有限公司、苏宁云商集团股份有限公司、京东世纪贸易有限公司、腾讯科技(北京)有限公司、中国电子技术标准化研究院、中国广告主协会、上海传漾广告有限公司、上海嘉道信息技术有限公司、北京品友互动信息技术股份公司、北京奇虎科技有限公司、新浪网技术(中国)有限公司、上海艾瑞市场咨询有限公司、上海荷格信息科技有限公司、合一网络技术(北京)有限公司、互动通天图信息技术有限公司、精硕世纪科技(北京)有限公司、上海晶樵网络信息技术有限公司、广州筷子信息科技有限公司、北京力美传媒科技股份有限公司、奇楚(上海)数码科技有限公司、上海胜思广告有限公司、北京搜狗科技发展有限公司、上海氩氪广告有限公司、友盟同欣(北京)科技有限公司、云联传媒(上海)有限公司。

  本标准主要起草人:陈雪原、霍尔查、张瑜、吴昊、薛思源、司洪霞、韩淑华、牛国柱、王勇军、侯斯靓、王翔博、向前、顾中祥、王辰、庄雯雯、徐伟、徐庆、李克、鲍硕、徐成吉、薄立兴、周平、王志鹏、陆雷、贺静、宋跃武、张明英、职亮亮、王跃、王建岗、钟昌铣、王啸天、陈雁冰、沈丕豪、谢鹏、沈学华、曹玉骥、杨炯纬、胡宁、陆振宇、姜安琦、孙世民、张春生、郝新诚、张迪、袁龙宝、周盛、沈昭阳、韩啸、洪倍、任佩禹、潘争、陈万锋、谢统玲、舒义、陈昱、陈雄、黄煜、严颢、刘永强、宋永晖、孙茂伟、张璐、秦雯、由恒军、江兰、曾庆荣、肖逸民、高远、周朝剑、程士安、方利军、马良骏、刘伟、陈岩、李霄、张天、须聪、赵崔华。

  GB/T 34941—20 17

  引

  言

  随着互联网和移动互联网技术的不断发展与普及,数字化营销产业的发展更加快速迅猛,2014 年开始,数字化营销已经成为最重要的广告投放方式和渠道。 数字化营销行业的快速发展也带来一些问题和挑战:广告样式百花齐放而繁杂多样造成产业资源效能低下;衡量基准不统一,阻碍了产业扩张与融合;数据分类定义不能互通;特别是在程序化营销产业生态中的广告供应方平台、广告需求方平台、广告交易平台、广告数据管理平台之间在对接过程中,执行的接口协议各不相同,造成跨平台/跨产品合作困难;加之多屏时代到来,更是提出了对跨平台/跨产品合作的进一步要求。 作为数字化营销最重要的组成部分和发展趋势的程序化营销,合作效能低、扩张难、融合差,已成为目前数字营销产业创新发展面临的最大阻碍。 为解决以上问题,本标准从接口协议、执行过程和数据分类等三个方面规范了程序化营销参与各平台之间交互执行的标准,为程序化营销行业提供持续健康发展的保障。

  GB/T 34941—20 17

  信息技术服务 数字化营销服务

  程序化营销技术要求

  1 范围

  本标准规定了数字化营销中各程序化营销平台之间的接口,程序化营销执行过程的基本活动和任务,以及程序化营销中涉及的各类数据的定义、来源、分类和应用。

  本标准适用于各个广告交易(平台)与需求方平台之间的竞价和 ID 映射,广告主资质和广告物料审核,数据测量与计费,以及用户、媒体、广告主数据的分类及应用。

  2 规范性引用文件

  下列文件对于本文件的应用是必不可少的。 凡是注 日期的引用文件,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。

  GB/T 2260—2007 中华人民共和国行政区划代码

  GB/T 4880 . 1—2005 语种名称代码 第 1 部分:2 字母代码

  GB/T 12406—2008 表示货币和资金的代码

  3 术语和定义

  下列术语和定义适用于本文件。

  3.1

  程序化营销 programmaticmarketing

  通过自动化程序和大数据技术实现广告主与媒体之间的广告交易的营销方式,包括实时竞价模式和非实时竞价模式。

  3.2

  实时竞价 realtimebidding

  利用第三方技术在数以百万计的数字媒体上,针对每一个用户的广告展示进行评估,以及实时出价的竞价技术。

  3.3

  广告交易(平台)advertisingexchange(platform)

  开放的、能够将 SSP 或媒体和 DSP联系在一起,提供广告数据交换、分析匹配和交易结算等服务的在线广告交易平台。

  3.4

  需求方平台 demandsideplatform

  整合广告主需求,为广告主提供发布服务的广告主服务平台。

  3.5

  供应方平台 supplysideplatform

  整合媒介方资源,为媒介所有者或管理者提供程序化的广告分配和筛选的媒介服务平台。

  GB/T 34941—20 17

  3.6

  广告主资质 advertisersqualification

  广告主投放广告具有的法律规定的必备资质,分为基本资质和特殊行业资质两类。

  3.7

  302 重定向 302 redirect

  302 暂时性转移 302 temporary redirect

  当用户点击一个网址时,通过技术手段,跳转到指定的一个网站。

  3.8

  广告主数据 advertisersdata

  作为品牌商品的拥有者和营销推广者的广告主,在生产经营过程中所积累产生的相关数据。

  3.9

  应用程序 application

  移动设备中可独立运行的程序。

  3 . 10

  数据管理平台 datamanagementplatform

  帮助所有涉及程序化营销的各方,用于管理其数据的系统平台。

  3 . 1 1

  用户数据 userdata

  与用户身份或活动相关的数据,包括可用于识别出用户身份的个人信息,以及反映用户网络活动的行为数据。

  3 . 12

  媒体数据 mediadata

  以互联网媒体为主体,描述互联网媒体类型与媒体所属行业的分类数据。

  4 缩略语

  下列缩略语适用于本文件。

  Ad Exchange:广告交易(平台)(Advertising Exchange)

  APP:应用程序(Application)

  CRM:客户关系管理(Customer Relationship Management)

  DMP:数据管理平台(Data Management Platform)

  DSP:需求方平台(Demand Side Platform)

  ERP:企业资源计划(Enterprise Resource Planning)

  FLV:流媒体格式(Flash Video)

  GIF:图像互换格式(Graphics Interchange Format)

  HTTP:超文本传送协议(HyperText Transfer Protocol)

  HMAC:散列消息鉴别码(Hash-based Message Authentication Code)

  ID:标识符 (Identifier)

  IP:因特网协议(Internet Protocol)

  JPG:联合图像专家组格式(Joint Photographic Experts Group)

  JPEG:联合图像专家组格式(Joint Photographic Experts Group)

  GB/T 34941—20 17

  MIME:多用途因特网邮件扩展类型(Multipurpose Internet Mail Extensions)

  MP4:动态图像专家组第四版格式(Moving Picture Experts Group 4)

  MRAID:移动富媒体广告接口定义(Mobile Rich Media Advertising Interface Definitions)

  Protobuf:协议缓冲区(Protocol Buffer)

  PNG:可移植网络图形格式(Portable Network Graphic Format)

  QPS:每秒查询率(Query Per Second)

  RTB:实时竞价(Real Time Bidding)

  SHA:安全散列算法(Secure Hash Algorithm)

  SSL:安全套接层(Secure Sockets Layer)

  SSP:供应方平台(Supply Side Platform)

  SWF: Flash文件格式(Shock Wave Flash)

  URL:统一资源定位符(Uniform Resoure Locator)

  VAST:视频广告投放模板(Video Advertising Serving Template)

  XHTML:可扩展超文本置标语言(Extensible HyperText Markup Language)

  XML:可扩展置标语言(Extensible Markup Language)

  5 接口协议

  5 . 1 概述

  5 . 1 . 1 实时竞价过程

  在程序化营销中,通常采用实时竞价模式完成营销过程。 实时竞价是指在 SSP、Ad Exchange 和多个 DSP 之间完成的实时竞价采买广告的过程,如图 1 所示。

  图 1 实时竞价流程

  如图 1 所描述,用户访问包含广告的网页或者启动其他带有广告的应用程序,媒体或 SSP 将会发起广告展现请求,Ad Exchange 收到该请求后,发出竞价请求给与之对接的多个 DSP,各个 DSP发出竞价响应,Ad Exchange根据竞价规则将获胜的 DSP 的广告播放信息及广告胜出通知返回供媒体,媒体在广告展现后向获胜的 DSP返回广告胜出通知。 为了建立 Ad Exchange 与 DSP之间的标识符映射关

  GB/T 34941—20 17

  系,Ad Exchange会在广告页面上发起标识符映射请求,将 Ad Exchange方的用户标识符传递给 DSP。

  图 1 流程中每个步骤即是本标准实时竞价协议需要定义的接口,说明如下:

  a) 广告展现请求,此为 SSP 和 Ad Exchange 间的接口,SSP 向 Ad Exchange请求广告,本标准不包含对此接口的规定;

  b) 竞价请求,Ad Exchange 和 DSP 之间的接 口,Ad Exchange 向 DSP发起竞价;

  c) 竞价响应,Ad Exchange 和 DSP 之间的接 口,DSP 向 Ad Exchange返回竞价;

  d) 广告播放信息,Ad Exchange 和媒体之间的接 口,Ad Exchange 返回广告给媒体,本标准不包含对此接口的规定;

  e) 广告胜出通知,媒体和 DSP 之间的接口,媒体通知 DSP在竞价中胜出;

  f) 标识符映射,Ad Exchange 和 DSP 之间的接 口,Ad Exchange 和 DSP进行标识符映射。

  竞价请求、竞价响应、广告胜出通知和标识符映射环节的具体内容将在随后的章条中进行详细规定。

  5 . 1 . 2 数据传输

  在 Ad Exchange 与 DSP 之间的网络连接基本采用 HTTP协议,并且为了减少连接的处理时间,宜开启长连接模式。 由于 HTTP POST相比 HTTP GET方式能更好地处理二进制数据,能传递更大数

  据,要求发送竞价请求给 DSP 时采用 HTTP POST 方式。 DSP 与 Ad Exchange 之间的超时时间不应超过 200 ms。

  在媒体/SSP 与 Ad Exchange之间的网络连接基本采用 HTTP协议,由 Ad Exchange 提供广告对应的请求链接地址,并返回对应的广告播放信息(包含 Ad Exchange 以及获胜 DSP 的广告胜出通知)。

  5 . 1 . 3 安全

  服务器对服务器的连接,会带来额外的处理负担,不宜使用 SSL协议,也不宜在应用层协议中提供额外的安全验证手段。 服务器间通信的安全措施可由交易双方确定。

  5 . 1 . 4 数据格式

  竞价请求与响应的应用层数据格式约定为 Protobuf(一种高效数据交换协议),具体的字段描述见5 . 2 和 5 . 3 。请求和回复消息内容的 MIME类型应填写为:

  a) Content-Type: application/x-protobuf;

  b) 广告播放信息数据格式采用超级文本标记语言(HTML) 。

  5 . 1 . 5 协议标头中的版本信息

  协议版本命名包括协议名称和版本号,名称定义为“x-dmss-pm-version”,版本号分为主版本号和次版本号两级,例如:1 . 2,主版本号和次版本号的变化都表示协议发生了实质改变。 次版本号的变化需要保证向后兼容,主版本的变化不需做到向旧版兼容。

  竞价请求的应带上版本信息,以处理竞价请求的服务识别其版本和相应字段;竞价响应部分宜带上

  系统当前支持的版本信息,例如:x-dmss-pm-version: 1.0。

  5 . 1 . 6 多层级的交易模式

  在程序化营销过程中,为满足广告主对于交易的需求,应支持下面四种交易模式:公开市场竞价、私有市场竞价、程序化优选和程序化包断。 这四种交易模式的示意如图 2,模式说明见表 1 。

  GB/T 34941—20 17

  图 2 多层级交易模式示意

  表 1 多层级交易模式说明

  5 . 2 竞价请求

  5 . 2 . 1 概述

  竞价请求按照 Bid Request协议格式封装请求数据,该数据包含 DSP报价依赖的竞价基本信息(竞价请求信息、广告位信息、创意信息)、受众信息(用户信息、设备信息、位置信息)以及展示环境信息(网站信息、移动应用信息、视频信息),通过对象来封装。

  竞价请求中各个对象的层级关系如图 3 。对象信息的描述和对应的章条见表 2 。

  GB/T 34941—20 17

  图 3 竞价请求接口中对象的层级

  表 2 对象和章条对应关系

  竞价请求实现示例参见附录 A。

  5 . 2 . 2 . 2 展现对象的定义

  展现对象的定义见表 4 。

  表 4 展现对象的定义

  GB/T 34941—20 17

  表 4(续)

  5 . 2 . 2 . 3 创意对象的定义

  创意对象的定义见表 5 。

  表 5 创意对象的定义

  5 . 2 . 2 . 4 用户对象的定义

  用户对象的定义见表 6 。

  表 6 用户对象的定义

  GB/T 34941—20 17

  表 6(续)

  5 . 2 . 2 . 5 设备对象定义

  设备对象的定义见表 7 。

  表 7 设备对象的定义

  GB/T 34941—20 17

  表 7(续)

  5 . 2 . 2 . 6 位置对象定义

  位置对象的定义见表 8 。

  表 8 位置对象的定义

  5 . 2 . 2 . 7 网站对象定义

  网站对象的定义见表 9 。

  表 9 网站对象的定义

  GB/T 34941—20 17

  表 9(续)

  5 . 2 . 2 . 8 移动应用对象的定义

  移动应用对象的定义见表 10 。

  表 10 移动应用对象的定义

  5 . 2 . 2 . 9 视频对象的定义

  视频对象的定义见表 11 。

  表 1 1 视频对象的定义

  5 . 2 . 2 . 10 优先交易信息对象的定义

  优先交易信息对象的定义见表 12 。

  GB/T 34941—20 17

  表 12 优先交易信息对象的定义

  优先交易订单对象的定义见表 13 。

  表 13 优先交易订单对象的定义

  5 . 2 . 2 . 1 1 包断交易信息对象的定义

  包断交易信息对象的定义见表 14 。

  表 14 包断交易信息对象的定义

  5 . 3 竞价响应

  5 . 3 . 1 概述

  DSP 在接到 Ad Exchange 的竞价请求以后,无论是否参与竞价,都应在 Ad Exchange 规定的时间(不宜超过 200 ms) 内处理请求,向 Ad Exchange发送竞价响应。 在规定的时间内,Ad Exchange 没有

  收到或者无法解析 DSP 的竞价响应,则广告交易平台视这次竞价为错误。 对于竞价错误率较高的DSP,广告交易平台将可对其发送给 DSP 的流量作出限制。

  竞价响应按照 Bid Response协议格式封装请求数据,该数据包含对展现机会的出价和广告创意信息 。如果 DSP不参与竞价,则需要把所有字段留空,并把 HTTP状态码设成 204 。

  竞价响应的大小不应该超过 32 千字节。

  竞价响应接口中对象的层级见图 4 。对象的描述和对应的章条见表 15 。

  GB/T 34941—20 17

  图 4 竞价响应接口中对象的层级

  表 15 对象和章条的对应关系

  竞价响应实现示例参见附录 C。

  5 . 3 . 2 竞价响应接口中对象的定义

  5 . 3 . 2 . 1 竞价响应对象的定义

  竞价响应对象的定义见表 16 。

  表 16 竞价响应对象的定义

  5 . 3 . 2 . 2 广告对象的定义

  广告对象的定义见表 17 。

  表 17 广告对象的定义

  GB/T 34941—20 17

  表 17(续)

  5 . 3 . 3 点击链接对象的定义

  点击链接对象的定义见表 18 。

  表 18 点击链接对象的定义

  GB/T 34941—20 17

  5 . 3 . 4 竞价响应的校验规则

  5 . 3 . 4 . 1 竞价响应错误

  当出现以下情况,广告交易平台将竞价响应视为错误:

  a) 规定的时间内无响应;

  b) 无法解析 Bid Response对象,包括 protobuf编码错误和必选项缺失;

  c) 竞价请求的 ID与竞价返回的 ID不匹配;

  d) 竞价请求中无与竞价返回中的广告 ID相匹配的 ID;

  e) 广告落地页面为非法网址或者非最终网址(如访问后会跳转到其他网址);

  f) 广告点击链接为非法网址;

  g) 竞价返回中返回的货币与竞价请求里设定的货币不同;

  h) 广告片段与广告位类型不匹配,如对图文广告位返回 VAST代码;

  i) 在竞价返回中同时填写或者同时不填写动态创意和静态创意部分;

  j) 广告静态创意地址为非法网址或者指向广告位所不支持的文件格式;

  k) 创意的宽度或高度填写了零。

  5 . 3 . 4 . 2 竞价响应被过滤

  在竞价响应填写正确的前提下,Ad Exchange将因如下原因过滤竞价响应:

  a) 媒体限制特定创意属性的广告的展现;

  b) 媒体限制敏感类别的广告内容的展现;

  c) 媒体限制着陆页地址为某些网址的广告的展现;

  d) 媒体限制指定广告主的广告的展现(如该广告主在销售保护名单之列);

  e) 广告返回的价格低于竞价请求里设定的底价。

  5 . 4 广告胜出通知

  5 . 4 . 1 概述

  对于竞价成功的竞价方,广告交易平台会发出胜出通知。 协议为 HTTP GET。 胜出通知的 URL和形式由竞价方定义。 一定量的替换宏可以插入在胜出通知的 URL 中 。 在发出胜出通知前,广告交易平台会对制定的宏进行查找和替换。

  与广告胜出通知相关的宏同样可以置于广告标记中,广告交易平台会将同样的数据替换作为胜出通知地址。 如果竞价方希望从自身设备收到胜出通知,那么可以在广告标记中包含一个追踪像素地址,地址中包含可用的宏。

  可用宏说明见表 19 。

  表 19 可用宏说明

  GB/T 34941—20 17

  替换前,宏数据值出于安全考虑,宜用多种混淆算法或加密算法来编码。 编码方式可由广告交易平台和竞价方确定。

  宏数据应慎重使用。 对于广告交易平台和出价方之间的通信不必编码,但是对于通过媒体使用广告标记里的追踪像素来传送到设备浏览器而产生的宏,宜进行编码。

  5 . 4 . 2 竞价失败反馈

  竞价失败的反馈一般在非实时部分,应通过非实时流程将数据回传给竞价方。

  5 . 4 . 3 点击宏

  当 Ad Exchange 和 DSP跟踪点击情况时,宜在点击地址中采用点击宏。 点击宏说明见表 20 。

  表 20 点击宏说明

  5 . 4 . 4 价格宏

  在广告胜出通知中,交易平台需要将获胜价格通过价格宏 %%WIN_PRICE%%发送给赢得竞价的第三方。

  由于该信息为重要数据,如果是在媒体端通过追踪像素来回传的话,建议使用加密算法。 加密解密算法由交易平台和竞价方确认和实现。

  价格单位由 Ad Exchange 和 DSP确认。

  加密算法可以采用基于 SHA-1 HMAC算法进行加密,例 C++模块,可以直接用 openssl 中的接口实现。 竞价方在注册时获得 32 字节的加密秘钥,用于解密;获取 32 字节的完整性检测密钥,用于价

  GB/T 34941—20 17

  格完整性检查。

  参考加密格式如下:

  {初始化向量(16 bytes)}{加密的价格(8 bytes)}{完整性签名(4 bytes)}

  加密价格的长度固定为 28 个字节,其中包含 16 个字节的初始化矢量、8 个字节的密文以及 4 个字节的完整性签名。

  示例:使用基于 SHA-1 HMAC算法的加密解密。

  加密阶段伪代码:

  pad = hmac(e_key, iv) //取前 8 个字节

  enc_price = pad〈xor〉price

  signature = hmac(i_key, price || iv) //取前 4 个字节

  final_message = WebSafeBase64Encode(iv || enc_price || signature)

  解密阶段伪代码:

  (iv || enc_price || signature) = WebSafeBase64Decode(final_message)

  pad = hmac(e_key, iv)

  price = enc_price〈xor〉pad

  conf_sig = hmac(i_key, price || iv)

  success =(conf_sig = = signature)

  字符与表达式解释见表 21 。

  表 2 1 字符与表达式说明

  5 . 4 . 5 自定义宏

  %%EXT_DATA%%,竞价方提供的扩展参数,用于竞价方自定义内容。 竞价方可以在提前上传的胜出通知地址或者点击监测地址中使用自定义宏,然后在实时竞价时填充相关字段,交易平台会将之前设置了 %%EXT_DATA%%宏的地方用字段中的数据替换。

  例如,竞价方在点击监测地址中使用了 自定义宏:http://click.adserver.com? some_param&click

  _url=clkurl&ext=%%EXT_DATA%%,那么在实时竞价时,如果竞价方传递了替换宏的数据,如 ext_data = some_param, 那么在投放广告时,上述代码会被替换,变为 http://click.adserver.com? some_param&click_url=clkurl&ext=some_param。

  5 . 5 标识符映射

  5 . 5 . 1 概述

  标识符映射(即“ID 映射”)是指将不同域/不同设备中的受众建立映射关系,以便在各种系统中能识别出对方传递过来的受众 ID,对各方信息进行整合。 ID 映射结果不会识别用户的身份信息,与受众在现实生活中的身份信息无关。

  GB/T 34941—20 17

  在 ID 映射中,Ad Exchange会在竞价请求中将 DSP 的受众 ID 和此 ID对应的用户信息一同传给DSP,作为 DSP竞价的依据。 DSP 可以 自 己存储上面所讲的映射表,也可以托管给 Ad Exchange来代为存储。

  5 . 5 . 2 标识符映射流程

  5 . 5 . 2 . 1 准备

  首先,DSP需要向 Ad Exchange 申请自己的 DSP ID,此 DSP ID应出现在每个 ID 映射请求中。 之后,DSP需要向 Ad Exchange 注册一个重定向 URL, Ad Exchange 的 ID 映射服务器会将映射的返回

  结果、非 Ad Exchange 的额外 URL参数等信息拼接到重定向 URL 后,通过 302 重定向给 DSP 的 ID映射服务器。

  5 . 5 . 2 . 2 匹配

  DSP 或者 Ad Exchange在每个需要匹配的流量上植入 ID 映射代码。 在每个需要 ID 映射的广告展现上,用户的浏览器都将访问 Ad Exchange 的 ID 映射服务器 URL,完成一次完整的 ID 映射流程。建议将 ID 的生存周期为 14 d,在生存周期内的 ID,不需要重复的进行 ID 映射。 下面将详细描述一个完整的匹配流程,见图 5 所示。

  图 5 ID映射流程

  图 5 所示的 ID 映射的详细过程如下:

  a) 用户打开浏览器,见图 5 中的 ①;

  b) 浏览器向 Ad Exchange 的 ID 映射服务器发起请求,见图 5 中的 ②;

  c) Ad Exchange 的 ID 映射服务器查找 exchange_id,并重定向到 DSP 的 ID 映射服务器,见图 5中的 ③;

  d) DSP 的 ID 映射服务器接收到 exchange_id, 建立 DSP 的 user_id 与 exchange_id 的映射关系(如果 DSP 不需要 Ad Exchange托管映射表,则直接返回 1 *1 像素图片给用户即可),见图 5中的 ④;

  e) DSP 的 ID 映射服务器查找 DSP user_id,并重定向到 Ad Exchange 的 ID 映射服务器,见图 5中的 ⑤;

  GB/T 34941—20 17

  f) Ad Exchange 的 ID 映射服务器接收到 DSP 的 user_id, 建立 exchange_id 与 DSP 的 user_id 的映射关系,见图 5 中的 ⑥;

  g) Ad Exchange 的 ID 映射服务器返回空白 1 *1 像素图片给用户,见图 5 中的 ⑦。参数设置见表 22 。

  表 22 参数说明

  5 . 6 字段扩展规则

  本标准对竞价过程中的核心信息字段进行了定义,对于各家 Ad Exchange 独有的特性字段应在接口中利用 Protobuf 的 extensions 特性在其设定的字段编号中定义,命名规则需参考本标准中相同命名风格。

  6 执行过程

  6 . 1 执行过程阶段划分及工作内容

  6 . 1 . 1 阶段划分

  程序化营销执行过程划分为执行前准备、执行中数据测量、执行后结算三个阶段。 如图 6 所示。

  图 6 程序化营销执行过程

  6 . 1 . 2 工作内容

  程序化营销执行各阶段的工作内容如下:

  a) 执行前准备工作包括:广告主资质审核、广告素材审核、第三方监测认证;

  b) 执行中数据测量工作包括:程序化广告曝光测量和广告点击测量;

  c) 执行后结算工作包括:结算标准及数据差异核对方法。

  6 . 2 执行前准备

  6 . 2 . 1 广告主资质审核要求

  程序化营销技术平台(包括 DSP、SSP 或 Ad Exchange)应依据国家法律法规及相关部门行政管理

  GB/T 34941—20 17

  的规定对广告主资质进行审核,包括但不限于《中华人民共和国广告法》《互联网广告管理暂行办法》及各行业法律、行政法规等。 如所遵循的法律、行政法规有修改,本标准应按照最新的法律、行政法规执行。

  6 . 2 . 2 广告物料技术审核要求

  程序化营销技术平台(包括 DSP、SSP 或 Ad Exchange)应依据国家法律法规及相关部门行政管理的规定对广告内容进行审核,包括但不限于《中华人民共和国广告法》《互联网广告管理暂行办法》及各行业法律、行政法规等。 同时本标准对广告物料技术审核也做出要求,详见表 23 。

  表 23 广告物料技术审核要求

  6 . 2 . 3 第三方监测认证

  第三方监测认证分为公司资质认证和监测能力认证:

  GB/T 34941—20 17

  a) 公司资质认证:第三方监测公司应提供税务登记证复印件;公司营业执照复印件;法人代表身份证复印件等资料给 Ad Exchange备案审核,提交资料需要清晰、齐全。

  b) 监测能力宜认证以下方面:

  1) 用户信息隐私保护认证:需第三方提供证明和保护方法;

  2) 监测方法认证:需第三方提供不同监测方法说明及示例;

  3) 数据准确性认证:广告展现、点击数据测试对比,第三方监测公司与 Ad exchange 误差应小于 10% ;

  4) 反作弊方法认证:反作弊方法,反作弊涉及指标及结果;

  5) 监测响应时间认证:服务器数量、机房位置、响应时间、QPS。

  6 . 3 执行中数据测量

  6 . 3 . 1 概述

  程序化营销数据测量是指程序化广告投放执行过程中,Ad Exhange 和 DSP 对于投放数据的统计方法,包括广告投放的曝光和点击的测量。 广告投放的曝光数据将作为 DSP 和 Ad Exchange投放结算的依据,所以需要统一的数据统计规则,并确定出现数据差异的核查和处理原则。

  6 . 3 . 2 程序化广告曝光测量

  程序化广告曝光测量流程如图 7 所示。

  图 7 程序化广告曝光测量流程

  图 7 所示的程序化广告曝光测量流程详细说明如下:

  a) 用户向括页面或应用发起广告展示的请求,见图 7 中(1) ;

  b) 广告位代码向 Ad Exchange服务器发起广告请求,见图 7 中(2) ;

  GB/T 34941—20 17

  c) Ad Exchange 向 DSP广播,告知 DSP广告展示机会,见图 7 中(3) ;

  d) DSP在规定时间内出价竞标,见图 7 中(4) ;

  e) Ad Exchange根据竞价规则,展示竞标成功的 DSP 的广告,见图 7 中(5) ;

  f) 展示广告的同时,通知 DSP赢得了竞价,并附带赢得竞价的价格,见图 7 中(6) ;

  g) 展示广告的同时,通知第三方监测平台,见图 7 中(7) ;

  h) 通知 Ad Exchange成功展示广告,见图 7 中(8) 。

  图 7展示了一般曝光测量方法及步骤,其中有些步骤可以省略,如果没有第三方监测,则不需要步骤 g)。

  6 . 3 . 3 程序化广告点击测量

  本标准列举了两种点击测量流程规范。 串行点击测量方法指的是 Ad Exchange 和 DSP 以及第三方测量平台是采用先后执行顺序串联起来执行,即先执行 Ad Exchange 的计数,再由 Ad Exchange 重定向到 DSP, DSP记录数据后再重定向到第三方监测平台或直接重定向到广告主页面。 并行加串行点击测量方式指的是用户发生点击时,同时向 Ad Exchange 和 DSP 提交点击数据,Ad Exchange 和 DSP分别计数,互不影响,有第三方监测时,由 DSP 方串行重定向到第三方监测平台,最后再重定向到广告主页面。

  采用并行加串行点击测量方式,因通常 Ad Exchange 和 DSP 的数据差异较小,故宜采用此种测量方式。

  串行点击测量流程如图 8 所示。

  图 8 串行点击测量流程图

  GB/T 34941—20 17

  图 8 所示的串行点击测量流程说明如下:

  a) 用户点击广告,见图 8 中(1) ;

  b) 点击数据提交到 Ad Exchange,记录点击,并重定向到 DSP 服务器,见图 8 中(2) ;

  c) DSP 收到点击数据,记录,并重定向到第三方点击监测,见图 8 中(3) ;

  d) 第三方点击监测收到数据,记录,重定向到广告主页面,见图 8 中(4) ;

  e) 在新窗口打开广告主页面,见图 8 中(5) 。

  并行加串行点击测量流程图如图 9 所示。

  图 9 并行加串行点击测量流程图

  图 9 所示的并行加串行点击测量流程说明如下:

  a) 用户点击广告,一次点击产生两个事件,即同时将数据提交到 Ad Exchange和 DSP,见图 9 中(1) ;

  b) 点击数据提交到 Ad Exchange,记录点击数据,见图 9 中(2) ;

  c) 点击数据提交到 DSP,记录点击数据,并重定向到第三方监测平台,见图 9 中(3) ;

  d) 第三方监测平台收到数据,记录,重定向到广告主页面,见图 9 中(4) ;

  e) 在新窗口打开广告主页面,见图 9 中(5) 。

  6 . 4 执行后结算

  6 . 4 . 1 结算标准

  在程序化 RTB交易中,Ad Exchange 和 DSP 的计费标准以千次广告曝光为结算单位,双方结算采

  GB/T 34941—20 17

  用广告曝光的定义,建议以 Ad Exchange统计的曝光数据为准。

  由于网络环境,Ad Exchange 和 DSP双方机房条件等的不同,计费数据会出现不等的差异,正常数据误差范围由双方合同自行约定,建议为 5%。

  6 . 4 . 2 结算数据误差争议办法

  Ad Exchange 和 DSP 数据误差如果超过双方约定的范围,一方或双方对数据差异有异议,可请求对方提供广告投放日志进行数据核对。

  日志最少字段包括:时间、素材 ID、竞价请求 ID、IP。 其中,竞价请求 ID是 Ad Exchange 每次发起请求时的唯一标识,全局唯一 。

  各方(包括 DSP 和第三方)都应记录 ID 以便统一排除问题。 日志保存时间建议为结算后 90 d。

  7 数据要求

  7 . 1 概述

  程序化营销数据是指专门服务于程序化营销服务的输出数据与应用型数据。 程序化营销数据是

  Ad Exchange、DSP、SSP、DMP等技术平台整合运转的核心。

  程序化营销数据的来源主要是第一或第三方采集的网页浏览行为数据、社交行为数据、电商购买行为数据、搜索行为数据等。 不同来源的杂乱数据通过整合、结构化处理、合并归一处理,变为可以用程序化营销系统实时调用的有业务含义的数据。

  由于程序化营销业务需求的特殊性,遵从行业适用性原则,可以从客户、用户、媒体三个维度对程序化营销数据进行标准化分类。

  7 . 2 数据类型

  程序化营销数据分为三种类型,包括:

  a) 用户数据:与用户身份或活动相关的数据,包括可用于识别出用户身份的个人信息,以及反映用户网络活动的行为数据;

  b) 媒体数据:数字化媒体类型与媒体所属行业类型数据;

  c) 客户数据:广告主所属行业与旗下商品品类。

  7 . 3 数据采集方法

  7 . 3 . 1 概述

  程序化营销数据主要来源于 PC 互联网和移动互联网媒体,包括网页浏览点击数据、购物交易数据、搜索数据、电信运营商数据等。

  7 . 3 . 2 数据采集方法

  对网民上网行为数据的采集方法主要有以下几种:

  a) 针对普通互联网或移动互联网网站,采用页面嵌码的方式,利用浏览器储存在用户本地终端上的数据(cookies),服务器对网民访问网页的行为进行记录浏览 URL、浏览时间、地域、访问来源等,通过对网页内容解析,将网民进行结构化分类;

  b) 针对移动设备的 APP终端,在 APP 应用端嵌入 SDK(软件开发工具包)代码进行数据采集,数据采集内容的范围则取决于 APP端对其数据的开放程度;

  c) 针对购物交易数据,多数可采用企业自有数据。 企业自有数据主要记录网民在企业自有平台

  GB/T 34941—20 17

  的注册信息、浏览页面信息、购买交易信息等;

  d) 针对网民搜索数据,可主要记录网民搜索关键词、句。

  7 . 3 . 3 数据采集和使用的准则

  数据的采集和使用应遵循基本的准则如下:

  a) 个人信息的采集应合法和公开透明,不应对个人财产造成伤害,保证用户有知情权或者征得用户同意;

  b) 采集的网民用户数据,应告知网民为什么采集信息,以及数据应用场景。 数据实际应用 目 的应与数据采集时所明确的 目的一致。

  7 . 4 用户数据

  7 . 4 . 1 用户数据定义

  用户数据,即与用户身份或活动相关的数据,一般包括:

  a) 用户个人信息:指相关系统在提供服务的过程中采集的,能够单独或者与其他信息结合标识用户的信息,包括用户姓名、出生 日期、身份证件号码、住址等身份信息以及用户使用服务的号码、账号、时间、地点等日志信息;

  b) 用户各种网络行为产生的数据:指用户在网络上的浏览、点击、搜索、网购等行为产生的数据,能够表现出用户的兴趣、关注点、购买需求等特征。

  用户数据主要来源于线上、线下用户行为数据,包括相关系统的 CRM 系统数据、ERP 系统数据,各种搜索、移动、社交等媒体,以及网络分析工具、普查数据以及离线数据等来源。

  7 . 4 . 2 用户数据分类原则

  对用户数据进行分类能够更好的对数据进行整合、分析以及应用,但是用户数据是海量而且复杂的,为了使海量的数据能够被准确、及时的检索到并获得有效的一致性标识。 用户数据分类应遵循的原则如下:

  a) 可识别性:指在不同的分类之间,在概念上可清楚地加以区分;

  b) 便捷性:指用户数据可以容易地被分到某一类别中;

  c) 独立性:指不同类别之间的数据是相互独立、没有交叉关系的;

  d) 穷尽性:指分类能够覆盖所有用户数据;

  e) 无歧义:指分类能够正确表现每类数据的特征,无二义性。

  7 . 4 . 3 用户数据的分类

  根据用户各种网络行为的特性、目前的实践以及细分原则(尤其是可识别性),可从基础信息和兴趣意向两个维度对用户数据进行分类。

  用户数据分类框架如图 10 所示。

  GB/T 34941—20 17

  图 10 用户数据分类框架

  用户数据分类说明如下:

  a) 基础信息:即用户的个人基本信息及用户在网络上表现出来的行为习惯数据,从人口学属性、地域属性、财产属性以及在线习惯四个方面对用户进行描述。 例如用户的姓名、年龄、职业、收入、在网络上的注册信息以及上网时长、上网时段、与广告互动频率等描述信息。

  b) 兴趣意图:能够表现出用户的长期需求、表达出用户的个人兴趣以及购买意图的数据,包括:

  1) 关注话题:用户经常关注的领域、行业或者产品等数据,能够表达用户的长期需求,例如能够表达出用户是车迷、喜爱美食、追求时尚、喜欢奢侈品等的数据;

  2) 个人兴趣:表达出用户兴趣点的数据,例如用户喜欢数码产品,喜欢旅游等兴趣的数据;

  3) 购买意向:能够表现出用户短期需求、有购买意图的数据,例如看相关商品评测、将商品加入购物车等行为的数据。

  由于用户数据应用场景多样,极具个性化,故本标准中的用户数据分类方法仅供行业各方参考,不作为贯彻标准的要求。 用户数据的详细分类示例参见附录 B。

  用户数据分类可应用于表 6 中的参数 user_category 的取值。

  7 . 5 媒体行业分类

  7 . 5 . 1 媒体行业定义

  本标准中的媒体是指互联网媒体,媒体行业是指互联网媒体刊出的内容所属行业分类,如新闻、体育、汽车、科技、旅游等。

  7 . 5 . 2 媒体行业分类原则

  媒体行业分类应遵循的原则如下:

  a) 可区分性:基于行业共识,在不同的媒体行业与类型之间,类的概念可清晰区分;

  b) 通用性:指媒体数据分类要适用目前主流的媒体分类,各类间不重叠,不冲突。

  7 . 5 . 3 媒体行业分类

  根据媒体数据分类原则,对媒体行业进行划分,详见表 24 。

  GB/T 34941—20 17

  表 24 媒体行业分类

  GB/T 34941—20 17

  表 24(续)

  媒体行业分类可应用于表 9 中的参数 page_category 和 site_category 的取值。

  7 . 6 客户行业分类

  7 . 6 . 1 客户行业的定义

  客户是指对通过程序化营销方式投放广告的企业单位,客户行业是对这些企业单位按其生产产品或提供服务的特征作出的分类。 国家建立了国民经济行业分类并对各行业进行编码,但不是所有的行业都会广泛参与营销环节,因此,本标准重点关注营销领域活跃的客户行业。

  7 . 6 . 2 客户行业分类原则

  数字营销中对客户数据进行合理划分主要目的是为了有效的利用客户的行业和商品数据,提高营销的效率。 客户数据的划分应遵循原则如下:

  a) 可区分性:即各个分类之间可以清晰的区分,无交叉;

  b) 规模性:即该分类在数字营销领域达到一定的市场预算规模。

  7 . 6 . 3 客户行业分类

  依据客户行业定义和分类原则,对客户行业进行划分,见表 25 。

  表 25 客户行业分类

  GB/T 34941—20 17

  表 25(续)

  客户数据分类可应用于表 5 中的参数 excluded_product_category 以及表 17 中的参数 category 的

  取值。

  7 . 7 数据应用

  7 . 7 . 1 数据应用概述

  程序化营销的数据,可以应用在数字营销的各个场景。 程序化营销模式流程如图 11 所示。

  图 11 阐述了下面的数据应用场景:

  当一个用户访问一个带有广告的页面时,DSP 实时对这次广告被展现的用户及媒体进行观察分析,识别是否是目标受众、媒体环境是否安全,通过数据预估投放表现,从而判断是否进行广告投放并合理的出价。

  在 DSP 系统中,客户或代理公司可以借助数据自定义用户细分,对广告进行精准的投放或展现不同的创意,或通过数据观察选择购买的媒体。

  对 SSP 系统中,媒体可以清晰了解网站的用户,从而优化媒体内容,实现对不同用户的定制化内容推荐,增加对用户吸引力。

  GB/T 34941—20 17

  图 1 1 程序化营销模式流程图

  7 . 7 . 2 数据安全

  7 . 7 . 2 . 1 数据安全的含义

  数据处理过程可分为 5 个主要环节:

  a) 采集:指获取并记录数据;

  b) 加工:指对数据进行的操作,如录入、存储、修改、标注、比对、挖掘、屏蔽等;

  c) 应用:指将数据应用于系统提供的服务,如根据用户数据投放广告、根据媒体数据挑选优质流量等;

  d) 转移:指将数据提供给数据需求方的行为,如向公众公开、向特定群体披露、由于委托他人加工而将数据复制到其他系统等;

  e) 删除:指使数据在相关系统中不再可用。

  数据处理过程中存在着诸多数据安全问题,包括数据的泄露、丢失、损坏、篡改、不当使用,可能会带来损害数据主体(用户、媒体和广告主)切身利益、危害社会秩序等不良影响。 为了保护互联网用户、媒体、广告主的合法权益,维护网络信息安全,相关系统对其在提供服务过程中处理的数据的安全负责,保护数据主体的隐私。 对数据的保护贯穿于数据处理的所有环节中。

  7 . 7 . 2 . 2 数据处理原则

  在对数据进行处理时,应遵循以下基本原则:

  a) 目的明确:处理数据应具有特定、明确、合理的 目 的,不扩大使用范围,不在数据主体不知情的情况下改变处理数据的 目的;

  b) 最少够用:只处理与处理目的有关的最少数据,达到处理 目 的后,在最短时间内停止使用或者删除能够识别用户身份的相关隐私数据甚至全部数据;

  c) 公开告知:对数据主体要尽到告知、说明和警示的义务,以明确、易懂和适宜的方式如实向数据主体告知处理数据的目的、数据的采集和使用范围、数据保护措施等信息;

  d) 个人同意:处理个人信息前要征得个人信息主体的同意;

  e) 质量保证:保证处理过程中的数据保密、完整、可用,并及时更新数据;

  GB/T 34941—20 17

  f) 安全保障:采取适当的、与数据遭受损害的可能性和严重性相适应的管理措施和技术手段,保护数据安全,防止未经授权的检索、披露及丢失、泄露、损毁和篡改数据;

  g) 诚信履行:按照采集时的承诺,或基于法定事由处理数据,在达到既定 目 的后不再继续处理数据;

  h) 责任明确:明确数据处理过程中的责任,采取相应的措施落实相关责任,并对数据处理过程进行记录以便于追溯。

  除了遵循以上原则,在程序化营销过程中,应当严格遵守国家在信息安全方面制定的相关规定。

  7 . 7 . 2 . 3 数据安全技术

  在实施互联网用户个人信息保护时,可以采取一些技术方案。 例如:

  a) 在跨网络传输用户个人信息时,使用安全版协议,包括安全的 https(超文本传送协议)、SFTP (安全文件传输协议)、SSL等;

  b) 不直接存储用户个人敏感信息,先对个人敏感信息进行加密后再存储;

  c) 对存储用户个人信息的物理环境采取隔离、安装防毒软件等保护措施;

  d) 与外部数据源进行对接时,不直接使用可识别用户身份的用户数据作为标识,可以使用随机生成的没有任何物理意义的编号作为标识。

  7 . 7 . 3 数据权限

  7 . 7 . 3 . 1 概述

  在处理用户数据时,相关系统需要得到数据主体的授权,包括数据拥有权和数据使用权。

  7 . 7 . 3 . 2 数据拥有权

  数据拥有权,即在采集数据之前相关系统需要征得数据主体的同意,包括默许同意或明示同意,使相关系统具有拥有数据的权利。 具体说明如下:

  a) 采集非隐私、可公开的数据,可认为数据主体默许同意,如果数据主体明确反对,应停止采集或删除数据;采集数据主体敏感、不可公开的数据时,应得到数据主体的明示同意;

  b) 为了达到保护用户数据安全的目的,相关系统只采集能够达到已告知目的的最少信息,而且应采用已告知的手段和方式直接向数据主体采集,不采取隐蔽手段或以间接方式采集用户数据;

  c) 持续采集数据时需要提供相关功能,允许数据主体配置、调整、关闭数据采集功能;

  d) 同时,相关系统不能直接向未满 16 周岁的未成年人等限制民事行为能力或无行为能力人采集隐私数据,确定需要采集隐私数据的,应征得其法定监护人的明确同意。

  7 . 7 . 3 . 3 数据使用权

  数据使用权,是相关系统拥有数据之后需要得到数据主体授予使用数据的权利,主要涉及数据处理的应用和转移环节,具体说明如下:

  a) 相关系统不应违背采集阶段已告知的应用和转移 目 的,或超出告知范围和转移范围对用户数据进行使用,而且应采用已告知的方法和手段进行使用;

  b) 应保护用户数据主体的个人信息隐私,保证使用过程中数据不被任何与处理目的无关的个人、组织和机构获知。

  未经数据主体明确同意,不应向其他个人、组织和机构披露其处理的数据,应符合法律法规的其他明确规定。

  GB/T 34941—20 17

  附 录 A

  (资料性附录)

  竞价请求协议示例

  竞价请求协议的 C语言实现示例如下。

  GB/T 34941—20 17

  GB/T 34941—20 17

  GB/T 34941—20 17

  GB/T 34941—20 17

  GB/T 34941—20 17

  附 录 B

  (资料性附录)

  用户数据详细分类示例

  用户数据按基础信息和兴趣意向两个维度进行分类(见 7 . 4 . 1),将这两个维度作为一级类 目 。一级类目下设有二级和三级类目,三级类目下对应若干属性值。 表 B. 1 给出了用户数据的详细分类情况。

  表 B.1 用户数据的分类表

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  表 B.1(续)

  GB/T 34941—20 17

  附 录 C

29141536429
下载排行 | 下载帮助 | 下载声明 | 信息反馈 | 网站地图  360book | 联系我们谢谢