广告行业的反作弊
2018-05-23

加载中

来源:360图书馆

广告行业的反作弊

作弊背后必然有一个或者一堆的人从众有获利,比如制造垃圾站挂广告获利的总是扎堆出现的。如果你抓到了一个网站流量异常,在用工具刷量,那肯定不会只是这一个网站在用这个模式在刷量;如果一个人有多个网站,如果有一个网站在刷量,那他的其他网站也应该检查一下了。

在广告反作弊的过程中,为了找出刷量的垃圾站背后都有哪些人,这些人有哪些网站,针对DSP平台流量80%的网站域名去重,通过whois信息查询到域名注册邮箱,归类出哪些域名属于哪个注册邮箱,发现其中一个刷量,则对同一邮箱下的其他域名进行严查。

上图是主要的一些广告反作弊的思路,广告作弊是有成本的,有人作弊,还是背后有利益驱动,找出利益链条是反作弊的关键
下面对之前我们做广告反作弊工作过程中遇到的几类例子:

P2P流量互刷

互刷作弊有代表性的软件是:流量宝和流量精灵

均通过客户端软件向服务器提交互刷任务请求,客户端收到服务器分发的互刷任务后执行隐藏的浏览任务,每天可达到数千个IP的访问量,IP布局分散,UA随机生成,很难通过浏览记录寻找作弊痕迹。现在唯一有效的反作弊方法需要通过蜜罐主机进行跟踪和分析。下面介绍一下我们对于p2p刷量所采用的蜜罐主机的结构:

其中虚线框中是我们的的蜜罐系统,虚线框外面的灰色部分是我们要寻找的作弊目标
如果是对信息安全有一定了解的人对于蜜罐系统一定不陌生,也就是系统设计上有意抛一些破绽出来,让攻击者自己跳出来,通过对攻击者行为的观摩来寻找破解攻击的思路。

由于流量宝、流量精灵一类的刷量工具多集中于windows平台下,安装windows vm并将系统代理指向nginx反向代理,通过刷量工具提交刷量任务。提交刷量任务的站点没有任何真实流量,只要是访问这个站点的IP基本上都是通过刷量工具来的流量,IP可以在RTB引擎对相关IP端进行封杀,不再进行投放;

Nginx反向代理落详细日志通过Logstash收集、解析发送给ElasticSearch建立索引,通过kibana做可视化,统计出刷量最多的IP,域名和URL地址出来,可以作为后续模式识别的模型输入。搜集相关证据,域名可以向adx反馈对媒体进行封杀,同时可以根据筛选出的刷量作弊域名在DSP投放过程中减少投放以避免自身损失。

CPS引流作弊

我们遇到的另外一种对于DSP投放效果有非常大影响的一类作弊手段是:CPS引流作弊

引流作弊可以帮助引流网站“提高”CPC,“提高”CPS。但对广告主不产生实际有效的流量。

目前发现的引流作弊行为有3种:

  1. 作弊代理通过回帖作弊(对媒体网站无控制权)

  2. 作弊代理伙同媒体网站作弊(对媒体网站有控制权)

  3. 作弊代理伙同媒体网站通过网盟作弊

也就是说在DSP投放了广告的网站里被插入了跳转到CPS计费链接的302跳转的图片,虽然DSP花钱从adx买了流量投放了广告,但是这个页面里还有大量的CPS结算的链接跳转,如果广告主既在网盟,又在DSP投放广告的话,任何看过这类页面的人在广告主网站下的单,就有可能被劫持走。整个过程中,用户都不知道有'广告主'的存在。但是对应的'广告主'会认为是特定CPS链接带来了一个点击,后续的cps应该是记在相应的CPS合作方名下。

Q & A

Q1:请问付总dmp数据存哪里?HBase?

数据分不同的形式存在不同的地方,原始日志存放在硬盘上,经过ETL后写入HDFS,结构化存放在Hive表中进行查询,cookiemapping数据经过hadoop计算过后导出成文件,存放在Tair里让RTB查询,用户行为数据存放在hdfs里,画像之后数据存放在redis供rtb查询,跑出来的统计报表存放在mysql供报表系统调用。CM的cookie对应数据有一部分也是存放在hbase的,hbase和hadoop共用hdfs,所以查询速度也会受到hadoop集群资源多少的影响。

Q2:请问 RTB算法模块热插拔大概是怎么实现的?

上面我曾经提到过RTB系统是用Linux C 开发的,如果对于Linux C 比较熟悉的人应该知道Linux下是可以动态加载动态链接库的使用的主要是:

dlopen:打开动态加载库

dlsym:获取接口函数指针

dlcose:关闭库

这三个函数就可以在程序运行时加载动态链接库了。为了达到模块准实时热插拔的目标我们还使用了Linux下的inotify,
inotify是一种文件系统的变化通知机制,如文件增加、删除等事件,可以立刻让用户态得知。我们在RTB程序启动过程中向系统注册了inotify事件来监控配置文件,当配置文件被修改的时候立即通知程序重新加载配置文件

Q3:请问cookiemap是离线map还是实时map?map后数据正确率有多少?移动端map 主要根据那些key来map?

cookieMapping分在线和离线两种,通常情况下广告投放过程中会有几个场景会发起cm

第一种,广告主网站上布码之后当访客访问广告主网站时触发js,dsp会主动向各家对接过后的adx进行cookiemapping

第二种,广告投放过程中,当dsp的出价的同时会带上广告展现代码里面也包含有cm代码,当出价高于其他dsp的时候,广告代码会被吐到媒体网站,相应的也会触发cm

第三种,当在adx消耗金额达到一定水平,像Tanx会按照消耗比例每天向dsp发起一定比例的dsp无法识别用户的cm请求,这个时候dsp也会向其他adx发起cm

除此之外对于运营商数据的使用过程中通常就是离线匹配的了,方法通常是运营商的浏览数据来自于路由设备的DPI信息,里面有用户的adsl账号信息,运营商会找出一定时间内访问过dsp指定的几个域名的人,通常会在这个域名下面的所有页面都布上cm代码,通过http头就能找出dsp的cookieID,找出的这些人都会有adsl账号标识,通过账号就能建立与dsp的cookieID的关系,这类cm就是离线的了。

Q4:请问怎么识别是同一个用户?通过cookie,还是有其他先进的办法?

PC端的用户识别通常是依靠cookie,这类cookie好植入,但生命周期比较短,无法直接跨浏览器/跨设备,同时容易被各类电脑管家/助手清理,所以很容易出现信息苦苦画好的用户画像,过两天这个id就再也不出现了。

在PC端还会用flash cookie的方法来打通不同的浏览器,因为flash storage是同一块存储不同的浏览器可以跨浏览器打通。
当然还有一种叫evercookie的手段集合了包括flash cookie 之内的多种标识方式,感兴趣的可以了解一下这个网址 http://samy.pl/evercookie/

移动端的身份标识,安卓的包括android id,mac地址IMSI和IMEI,而iOS是IDFA。由于移动设备上安装的app里可以嵌入SDK,而app有可能在移动端的权限也不同获取到的标识也会有差异,所以最终也会涉及到用户标识统一识别的问题,当然移动端的用户标识会远比PC端要强很多,移动广告化之后用户画像将会更加的准确。

本文策划 秋翾@百姓网, 内容由国忠,陈刚编辑与发布,其他多位志愿者对本文亦有贡献。读者可以通过搜索“ArchNotes”或长按下面图片,关注“高可用架构”公众号,查看更多架构方面内容,获取通往架构师之路的宝贵经验。转载请注明来自“高可用架构(ArchNotes)”公众号。



暂无评论!
我要评论 只有购买过该商品的用户才能评论。
  • QQ咨询
  • 电话咨询
  • 400-680-9608