本文主要是介绍架构设计内容分享(八十五):电商系统之广告系统,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
前言
业务模型
计费方式
定价方式
投放计划
广告形式
架构设计
抽象模型
实际场景
系统架构
总结
前言
广告是为了某种特定的需要,通过一定形式的媒体,公开而广泛地向公众传递信息的宣传手段。
狭义广告仅指经济广告,又称商业广告,是指以盈利为目的的广告,通常是商品生产者、经营者和消费者之间沟通信息的重要手段,或企业占领市场、推销产品、提供劳务的重要形式,主要目的是扩大经济效益。
广告也成为了目前互联网平台的主要收入来源之一,所以广告平台的建设也是互联网平台重要的系统之一,接下来我们讲解电商系统中广告系统的建设过程。
广告使命
为客户创造价值下,把流量转化成现金。
业务模型
计费方式
一个网络媒体(网站)会包含有数十个甚至成千上万个页面,网络广告所投放的位置和价格 就牵涉到特定的页面以及浏览人数的多寡。这好比平面媒体(如报纸)的“版位”、“发行 量”,或者电波媒体(如电视)的“时段”、“收视率”的概念。网络媒体常见的广告收费模式有以下几种:
说明
CPM:按展示付费
CPM—英文全称Cost Per Mille 或者是Cost Per ThousandImpression, 也称千人印象成本。CPM是一种展示付费广告,只要展示了广告主的广告内容,广告主就为此付费。这种广告的效果不是很好,但是却能给有一定流量的网站、博客带来稳定的收入。
CPTM:定位用户千次印象费用
CPTM,英文全称“Cost per Targeted Thousand Impressions”,是指经过定位的用户(如根据人口统计信息定位)的千次印象费用。CPTM与CPM广告的区别在于,CPM是所有用户的印象数,而CPTM只是经过定位的用户的印象数。
CPT:按时长付费
CPT—英文全称Cost Per Time。CPT是一种以时间来计费的广告,国内很多的网站都是按照“一个月多少钱”这种固定收费模式来收费的,这种广告形式很粗糙,无法保障客户的利益。但是CPT的确是一种很省心的广告,能给你的网站、博客带来稳定的收入。
CPC:按点击付费
CPC—英文全称Cost Per Click。CPC是一种点击付费广告,根据广告被点击的次数收费。如关键词广告一般采用这种定价模式,比较典型的有Google的AdSense for Content、百度联盟的百度竞价广告以及淘宝的直通车广告。
CPL:按引导数、按注册成功支付佣金
CPL,英文全称“Cost per Lead/Cost-Per-Acquisition”。是以搜集潜在客户名单多少来收费;即每次通过特定链接,进行应答询问或调查、提供其它信息、注册会员等等事先约定的事宜时,向联盟会员支付事先约定佣金费用的方式。注册成功后付费的一个常见广告模式。
CPA:按行为付费
CPA—英文全称Cost Per Action。CPA是一种按广告投放实际效果计价方式的广告,即按回应的有效问卷或定单来计费,而不限广告投放量。CPA的计价方式对于网站而言有一定的风险,但若广告投放成功,其收益也比CPM的计价方式要大得多。
CPP:每购买成本
CPP,英文全称“Cost Per Purchase”,是指广告主为规避广告费用风险,只有在网络用户点击旗帜广告并进行在线交易后,才按销售笔数付给广告站点费用。无论是CPA广告还是CPP广告,广告主都要求发生目标消费者的“点击”,甚至进一步形成购买,才予付费:CPM广告则只要求发生“目击”(或称“展露”、“印象”),就产生广告付费。
CPS:按销售付费
CPS—英文全称Cost Per Sales。CPS是一种以实际销售产品数量来计算广告费用的广告,这种广告更多的适合购物类、导购类、网址导航类的网站,需要精准的流量才能带来转化。
CPR: 每回应成本
CPR,英文全称“Cost Per Response”,是指以浏览者的每一个回应计费。CPR广告计费充分体现了网络广告“及时反应、直接互动、准确记录”的特点,但是,这个显然是属于辅助销售的广告模式,对于那些实际只要亮出名字就已经有一半满足的品牌广告要求,大概所有的网站都会给予拒绝,因为得到广告费的机会比CPC广告还要渺茫。
CPE:按参与付费
CPE,英文全称“Click per Engagement”,是一种新的关于广告营销的计费方式。在这里,所谓的Engagement(参与)可以表达为多种形式,比如点击一次Facebook上的Likes、输入一些内容、发一条微博、看完一整段视频或是完成一份问卷调查。通畅情况下,当用户进行Engagement时,是希望能完成达到某一下一步的目的。同时,网络商和发布商控制着Engagement的环节,参与者通过与发布商信息的参与获取他们所希望的东西。
包月广告
包月广告是按照每月固定位置来进行固定的广告费用计算。很多国内的网站是按照“一个月多少钱”这种固定收费模式来收费的,这对客户和网站都不公平,无法保障广告客户的利益。
小结
按照广告收费类型不同,在广告展位的应用上,我们可以根据不同计费类型来设计和出售广告位。
定价方式
-
固定价格
-
市场竞价
-
定向溢价
投放计划
-
确定广告渠道,例如选择广告位或网站;(哪里投放?)
-
确定投放时间,哪天或哪个时间段;(何时投放?)
-
界定广告受众;(希望谁看到?)
-
愿意出的价格;(我愿意出多高的价格?)
-
希望投放的创意;(我想展现啥?)
广告形式
Banner
Banner是指横幅广告,是最普遍的移动广告形式,一般在APP界面的顶部或底部出现,有静态图、GIF图、文字链,也有多帧图片滚动的动画图。从形式上,Banner可以分为:静态横幅、动画横幅、互动式横幅。从内容上,Banner可以分为:纯图片、图文、纯文字。计费方式一般以CPC(每点击成本)结算为主,价格浮动较大,纯工具类APP使用底部banner较为常见。
公告
公告在电商类或社区类APP的首页,公告样式的广告位特别多。
插屏广告
插屏广告在游戏类或视频类APP较为常见,例如下图的保卫萝卜APP。插屏广告也分静态图和GIF图,一般都是精准广告推广形式,视觉冲击力更强,广告效果更好。广告效果与用户体验一般成负相关,插屏广告比banner的广告效果好、收益更高,但比较影响用户体验。
计费方式一般以CPA(例如用户下载注册)为主,也存在以CPM(千人展示成本)和CPC(每点击成本)的付费方式。
全屏广告
全屏广告(Full Screen Ads)几乎每家APP都用过。当用户打开APP时,以全屏方式出现3秒左右(一般可跳过),可以是静态图片,也可以是多帧的动画,也可以是Flash效果。
除了进入APP时的开屏广告,有时游戏中误操作也会出现全屏广告。上海地铁连接花生地铁wifi时也会出现强制停留3秒的全屏广告。全屏广告收费较高,主要以CPM(千人展示成本)的计费方式。
富媒体广告
富媒体(Rich Media),是相对于图片类而言的,因为它具有动画、声音、视频或交互式信息传播方式。一句话概述:富媒体是一种信息传播方式,富媒体广告是指以这种传播方式来表现的广告形式。富媒体广告,对用户来说就是看到的广告比较酷炫,对广告主说可以更好的展示产品,对互联网公司来说就是要加载更多的广告素材。
信息流广告
信息流广告(Feeds Ads),常常在timeline上和正常的信息混在一起,不容易被识别,用户不知不觉中将广告阅读完了。常见在社交类APP,例如朋友圈、微博、Instagram,还有资讯类APP,例如今日头条、网易新闻等。
积分墙
积分墙常见在一些游戏类APP中,通过给予玩家免费的游戏币,来激励玩家去下载注册别的游戏APP,从而达到盈利或互相导流的目的。除此之外,一些第三方平台为了高额的广告收入,通过积分或话费的奖励形式,来激励用户下载推广的APP。
移动视频广告
在爱奇艺优酷等移动视频平台,常见的广告形式主要是两种:贴片和角标。
1)贴片:如果是非会员,一般在视频开始之前都会看到一小段精准推送的短视频广告。如下图,是爱奇艺APP的贴片广告截图。允许观看几秒后跳过贴片广告是种很聪明的选择,观众不喜欢看还强迫看,用户体验差,对广告主也没有收益。不如允许用户跳过,并且通过标记跳过时间点来判断这个用户对哪类广告更感兴趣,进而做到更精准的广告推送。
2)角标:以透明的样式出现在视频播放窗口旁边的广告形式,一般有动态效果,以便能在观看过程引起用户的注意。角标是允许用户关闭的。
竞价排名
竞价排名一般是按CPC(每点击成本)进行付费,最有名的就是百度和淘宝的搜索结果案例。
架构设计
抽象模型
实际场景
肯德基要在xx平台投放广告,签订了投放合同,涉及ABC三个热门广告位,那么广告投放人员首选会在系统中创建一个订单,订单包含广告主(肯德基)、合同编号(实际签订的合同)、投放总金额、涉及广告位(ABC)等信息(订单在后面的数据报告当中也会用到),系统给每个订单自动生成一个唯一编号;订单确认后,投放人员在订单下进行广告投放,即广告是依附于订单存在。投放第一个广告,选择广告位A(广告位要提前配置好,广告位代码要由开发添加到对应的页面),然后在广告位创建广告,上文讲到广告是投放策略,投放人员这样设置的广告:
投放时间:2018年11月11日到2018年11月21日
定向条件:
-
投放地域:南京、上海
-
投放人群:15-40岁白领人群(取决于技术、数据条件)
-
展现限制:每天最多展现5w次,每个独立访客每天最多展现2次
最后一步,关联物料,上传由广告主提供的广告内容,广告投放完成
系统架构
广告系统的技术要求
投放引擎:响应时间
一个典型的广告投放系统主要由三个部分组成:索引、CTR模块、投放服务。其中投放服务处理前端传过来的请求,把请求转化为查询条件到索引中进行检索,再把检索结果通过CTR模块进行排序(Ranking),最后数据最终结果并记录投放日志。其中,CTR模块根据实时计算的eCPM对广告检索结果进行从大到小的排序。
关于eCPM:全称expected cost per mile,意思是每进行一千次投放的预期收入。具体计算方法为eCPM = CTR(点击率) * bid(出价),CTR可以理解为用户点击该广告的概率,因此CTR与bid相乘就是这一次投放的预期收入,广告业务希望收入最大化,因此CTR的计算就是核心中的核心。
对任何To C的服务来说,响应时间都是最重要的技术指标,对于一个广告投放系统尤为如此。因为媒体数量会不断增长,因此广告投放系统是具有高并发、低延迟的特点。常规的分布式Web系统架构都可以应用在上面,另外通常还会使用提高检索效率的Lucene相关组件(如Solr或ElasticSearch等)作为索引部分。
计费系统:数据实时
计费系统的构成不会特别复杂,它是前端广告位与投放系统之间的桥梁,核心任务是保证广告投放在预算范围之内,尽可能地避免发生超投——即广告投放的次数与相应费用超出广告主预设的范围。
为了保证这一点,我们要求计费系统应重点保证数据的实时性,具体环节包括广告位展示信息的埋点数据收集、处理与费用计算等。从用户查看或点击一次广告到进行广告下线反馈,这一过程应保持分钟级以内的延迟。由于广告位曝光或用户点击行为的数据量相当庞大,目前流行的方案是使用Kafka提供日志消息分发。
聪明的你可能会发现,对于CPC广告来说,即使计费系统及时发出下线反馈,但那些已经投放出去、尚未产生点击的广告仍然会可能产生超投。因此超投只能控制在一定范围之内,并不能完全杜绝。广告系统到达一定规模、超投率超出可以接受的范围之后,计费系统应具备预测消耗的能力,即每进行一次投放,计费系统预测出可能产生的费用,并提前进行费用计算、对预测预算将被耗尽的广告计划在点击尚未发生之前就先进行下线操作(笔者曾经翻译过一篇文章,介绍Pinterest广告团队如何构建消耗预测系统,感兴趣的话可查看这里)。另外,对预算将近的广告计划,投放系统也应该降低投放频率,使预算极可能平滑地达到上限。
结算系统:数据准确
结算系统与计费系统虽然都提供了费用计算的功能,但侧重点不同。结算系统提供的是广告平台与广告主之间费用结算服务,关注的是数据准确度;而计费系统则重点关注的是计费实时性,其根本目标是保证流量的有效利用。
结算系统一般会以离线数据为基础进行计算,首先,这样可以以较少的成本保证数据完整性,因为如果像计费系统那样一来实时流计算,就不可避免地要面临服务可用性问题。如上文所说,假如流计算服务宕机,对计费系统来说最多也就是造成流量的浪费,但对结算系统来说,则意味着广告平台利益的无辜损失。其次,广告结算系统通常会引入“反作弊”的功能(比如一个用户短时间内多次点击,只收取一次点击的费用),基于离线数据,便于引入更先进(可能也意味着耗时更高,这与计费系统的要求相悖)的反作弊算法,以保障广告主的权益。
可用性要求
这一点比较容易理解,分分钟都是钱,所以广告系统一般都有大量的热备冗余机器,部署在多地多个机房。除了常见的分布式系统高可用方案之外,广告系统还有如下两个重要的方案。
自动降级
广告系统很难像传统用户类网站一样,提供一些静态的只读内容,以备在集群全体宕机的时候使用。但在系统内部设计中,可以做到模块级别的容灾,系统化点的称为叫自动降级。即当某些模块出现问题的时候,或者系统资源不够用的时候,系统能够自动地移除出问题的模块,或者非核心模块,保证基本功能可用。比较典型的例子是,如果某一种策略的计算逻辑出现问题,或者CTR(Click-Through-Rate, CTR,点击率)预估集群整体宕机,系统还能够正常返回广告,只是收益不如原来高。当然,自动降级只是一种防御手段,当发生这种情况的时候,应该视为线上集群整体宕机同等严重的事故,必须第一时间处理。例外的情况是自动降级是人为预期的,例如有些业务激增场景一年只发生一次,公司不可能为此常年准备大量机器,此时也可以用自动降级的手段保证业务基本可用。
减少启动时间
大型广告系统使用的数据量甚至会超过单机内存极限,这时系统的启动时间会非常可观。之前开发过的广告系统,即使进行了水平拆库,单机使用内存仍然达到20G以上,启动时间在15分钟左右,经过后续的优化减少到5分钟。减少启动时间,主要好处有两个:减少运维成本,减少容灾成本。
-
减少运维成本。和其他互联网系统一样,广告系统也会采用快速迭代的上线方案。有N台服务器的广告系统,可能会一周多次上线。上线时,为了使服务仍然可用,会分批操作,例如一次只操作5%的机器。这对运维人员是非常痛苦的一个过程。例如50台机器,每次操作10%,每台机器启动时间在10分钟,整体上线流程将达到8小时,这样的事情每周发生几次,显然是无法接受的。当然,可以选择流量低谷的时间段上线,增加每次操作的机器数量,这样又引入了运维成本。因此减少系统启动时间意义重大。
-
减少容灾成本。很长的启动时间,会使系统在请求量激增的情况下无法及时使用冷备机器扩容,而增加很多热备机器,第一会增加成本,第二实际情况还是可能会超出预留。而且,当热备机器也难以处理所有请求时,很可能会导致刚刚启动完毕的机器也被打满而无法正常提供服务,触发雪崩效应。此时,必须切断所有服务,重启集群,等所有服务都重启并检验数据完毕后,才能开始对外提供服务。一般来说,当我们听说一些大型网站发生整体宕机,若干小时后才恢复,很可能都是发生了雪崩事故。
系统容灾
系统幂等性
计费系统“幂等”功能,对于有状态环节,同一数 据结果必须幂等,实现计费链路去重逻辑
-
日志生产端: 构造单条扣费日志唯一性主键(GUID),保证每条日志都有自己的唯一标识
-
反作弊: 保证同一条日志结果一致,校验层同一条日志结果幂等,基于缓存保存每条反作弊的校验结果
-
计费: 保证同一条日志只会被扣费一次,加入去重逻辑,保证日志恢复阶段也不会重复扣费,DB唯一索引
扣费时效性
导致系统低效原因分析
-
第三方依赖(DB,redis)链接及数据传输网络开销
-
第三方逻辑耦合在主流程中,占用主链路的开销
-
线程的频繁创建与销毁,频繁的上下文切换
-
热点数据的分布不均匀,不能高效的利用CPU
解决方案:减少不必要的依赖:强依赖转弱依赖
-
第三方依赖异步化(kafka/sentry/数据统计),保证主流程安全,同时提高主流程效率。
-
弱依赖埋好开关,在出现性能瓶颈时可以及时关闭。
-
连接池应用及网络部署优化
扣费时效性(热点数据)
问题描述:
实际投放过程中,存在热点商家或者热点流量,一种情况很多大商家全部被分到同一个线 程队列中处理,则会导致某些线程阻塞而某些线程空闲,未能最大化并发效果, 处理不好同时 还有可能造成系统雪崩;
1.过程中如果只是以特定的线程来处理一个队列,由于点击在商家维度的不均衡性,一定 会出现某些队列堵塞。
2. 大队列堵塞会导致大量的缓存点击,会影响收入。
解决方案
分而治之
1. 按照userId的方式进行hash队列拆分,分拆合适粒度的队列,多队列并行,消费程
序(billingWorker)分布式部署分配接管队列消费
2. 线程和队列分离,按队列数据长度,动态分配线程,提高热点数据消费效率.
限流降级方案
-
三板斧
缓存:提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹
降级:暂时屏蔽掉非核心流程,避免对主流程造成影响,待高峰或者问题解决后再打开
限流:一个时间窗口内的的请求进行限速来保护系统 常见的限流算法有:令牌桶、漏桶、计数器也可以进行粗暴限流实现
-
三级限流保护
一级:接入层限流
数据总入口,根据入口流量及系统流量瓶颈,进行限流。
二级:系统级限流
程序本身计费逻辑限流,保证队列不会出现堵塞:在程序数据拉取过程中,判断计费队列 中的消息数量,比如当数量大于某个阈值(10000)时,限制流量进入(如:当前队列数据10240个, 在QPS 4500时计费队列平均10000个),同时控制总量,避免内存队列堆积大量数据。 当出现断电式故障时,可以快速确定丢失的数量,进行数据恢复。
三级:重试机制限流
程序拉取上游数据限流:当程序下游雪崩时,程序会出现大量异常,异常数据会存储入fail 队列,计费程序将根据异常的出现次数,fail队列的长度,决定是否继续从上游获取数据、是否进 行不进行重试,走fail队列消费逻辑进行数据恢复。
总结
俗话说,离开业务谈架构都是耍流氓。用一句标准的报告性语言介绍大型广告系统的特点就是:处理的数据量特别巨大,响应速度要求特别快,数据实时性要求特别高,系统可用性要求特别高。面对种种不可思议的困难,最初的一批误打误撞进入广告行业的的互联网工程师们,本着赚钱的目的,通过演杂技一般的对各种技术的拼接,出色地完成了任务。广告系统中广告反作弊、广告系统监控接下来的文章会继续详细设计。
这篇关于架构设计内容分享(八十五):电商系统之广告系统的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!