wordpress如何建企业站,广告公司年终总结,具有营销价值好的网站,wordpress主题 企业广告、增值服务、佣金#xff0c;是互联网企业最常见的三种盈利手段。在这3大经典中#xff0c;又以广告所占的市场份额最大#xff0c;几乎是绝大部分互联网平台最主要的营收途径#xff0c;业务的重要性不言而喻。 从技术角度来说#xff0c;广告业务涉及到 AI算法、大数…广告、增值服务、佣金是互联网企业最常见的三种盈利手段。在这3大经典中又以广告所占的市场份额最大几乎是绝大部分互联网平台最主要的营收途径业务的重要性不言而喻。 从技术角度来说广告业务涉及到 AI算法、大数据处理、检索引擎、高性能和高可用的工程架构 等多个方向同样有着不错的技术吸引力。
我从去年开始接触广告业务到现在差不多一年时间了。这篇文章将结合我的个人经验同时参考业界的优秀案例阐述下广告系统的架构实践方案希望让大家有所收获。内容包括以下3部分
广告业务简介面临的技术挑战广告系统架构详解
01 广告业务简介
广告可以说无处不在。微信、抖音、B站、百度、淘宝等等这些占据用户时间最长的 APP 到处都能看到广告的影子。
我们每天随处可见的广告它背后的业务逻辑到底是什么样的呢在分享广告系统的架构之前先给大家快速普及下业务知识。
1. 广告业务的核心点是平衡
为什么说广告业务的核心点是「平衡」可以从广告的标准定义来理解。
广告被定义为广告主以付费方式通过互联网平台向用户传播商品或者服务信息的手段。这个定义中涉及到 广告主、平台、用户 3个主体但是这3个主体的利益关注点各不相同。
广告主关注ROI花了钱是否能带来预期收益平台拥有流量关注收益能否最大化用户关注体验广告是否足够精准是否影响到了正常功能的使用
有时候这三者的利益是冲突的比如平台增加了广告位数量收益肯定增加但用户体验可能变差因此广告业务最终要寻找的是三方的平衡。
站在平台的角度来看广告业务它在保证用户体验的同时要兼顾绝大部分广告主的ROI确保他们是可以赚到钱的在此基础上再考虑将平台的收入最大化这样才是一个健康的广告生态。
2. 从收入的分解公式认清广告的本质
广告业务发展了几十年广告费用的结算方式也诞生了很多种我们最常见的有以下几种
CPT按时间计费独占性包时段包位置CPM按照每千次曝光计费CPC按照点击计费CPA按照行为计费比如下载、注册等 之所以有不同的结算方式其实也是随着广告市场的发展逐渐衍生出来的最开始流量稀缺平台占优势再到今天逐渐成了买方市场广告主作为需求方的谈判权变大。
上面这个图可以看出由于CPA代表了广告主最终想要的转化效果因此按CPA结算时对广告主最有利但是对平台最不利。结算方式演进到今天其实也是一种平衡所以处于平衡点附近的CPM和CPC是最常见的结算方式。 以CPC为例收入可分解成下面这个公式 其中PV表示系统的访问量PVR和ASN表示广告的填充率CTR表示广告的点击率ACP表示广告的平均点击价格。 上述各个指标都可以通过一系列的广告策略来提升。比如填充率可通过开发更多的广告主来实现CTR可通过AI算法做到精准投放来提升ACP可通过精准流量溢价或者提升广告主ROI来完成。 掌握上面这个收入分解公式对于理解广告业务至关重要任何业务上的动作几乎都能关联到这个公式的某个指标上。
3. 广告的核心业务流程
广告业务发展到今天随着广告主对投放效果的诉求不断加强精准定向以及实时竞价是目前最主流的业务形态。 对互联网平台来说初期一般都是采用「自营的竞价广告网络」来实现商业变现简单理解就是利用平台自有的流量以及自主开发的广告主来实现业务闭环。本文所分享的广告架构主要针对这种业务形态它的核心业务流程如下图所示。
广告主先通过投放平台发布广告可设置一系列的定向条件比如投放城市、投放时间段、人群标签、出价等。投放动作完成后广告会被存放到广告库、同时进入索引库以便能被广告检索引擎召回。C端请求过来后广告引擎会完成召回、算法策略、竞价排序等一系列的逻辑最终筛选出Top N个广告实现广告的千人千面。用户点击广告后会触发广告扣费流程这时候平台才算真正获得收益。
上面是广告业务的核心流程随着平台流量以及广告主规模进一步增大往往会从「自营型竞价网络」逐渐向「联盟广告以及RTB实时竞价」方向发展类似于阿里妈妈、腾讯广点通、头条巨量引擎此时业务复杂度和技术架构会再上一个台阶本文不作展开后续再跟大家详细分享。
02 面临的技术挑战
对广告业务有了初步了解后再来看下广告系统面临的技术挑战 1、高并发广告引擎和C端流量对接请求量大平峰往往有上万QPS要求实时响应必须在几十毫秒内返回结果。
2、业务逻辑复杂一次广告请求涉及到多路召回、算法模型打分、竞价排序等复杂的业务流程策略多执行链路长。
3、稳定性要求高广告系统直接跟收入挂钩广告引擎以及计费平台等核心系统的稳定性要求很高可用性至少要做到3个9。
4、大数据存储和计算随业务发展推广数量以及扣费订单数量很容易达到千万甚至上亿规模另外收入报表的聚合维度多单报表可能达到百亿级别的记录数。
5、账务的准确性广告扣费属于金融性质的操作需要做到不丢失、不重复否则会损害某一方的利益。另外如果收入数据不准确还可能影响到业务决策。
03 广告系统架构详解
了解了广告业务的目标和技术挑战后接下来详细介绍下广告系统的整体架构和技术方案。 上面是我们公司目前的广告系统架构图这个架构适用于广告业务初期针对的是「自营型的竞价网络和站内流量」不涉及联盟广告。
下面针对各个子系统做下说明
广告投放系统供广告主使用核心功能包括会员续费、广告库管理、设定推广条件、设置广告出价、查看投放效果等。广告运营后台供平台的产品运营使用核心功能包括广告位管理、广告策略管理、以及各种运营工具。广告检索平台承接C端的高并发请求负责从海量广告库中筛选出几个或者几十个广告实时性要求高这个平台通常由多个微服务组成。AB实验平台广告业务的稳定器任何广告策略上的调整均可以通过此平台进行灰度实验观察收入指标的变化。广告计费平台面向C端负责实时扣费和收入直接挂钩可用性要求高。账务管理中心广告业务中的财务系统统管金额相关的业务包括充值、冻结、扣费等。大数据平台整个广告系统的底盘需要聚合各种异构数据源完成离线和实时数据分析和统计产出业务报表生产模型特征等。
下面再针对架构中的技术难点展开做下介绍。
1. 广告数据的存储
广告系统要存储的数据多种多样特点各不相同采用的是多模的数据存储方式。
OLTP场景包括广告库、创意库、会员库、广告产品库、广告策略库等这些都存储在MySQL中数据规模较大的广告库和创意库按照广告主ID Hash做分库分表。OLAP场景涉及到非常多的报表聚合维度多单表的记录数可能达到百亿级别底层采用HDFS和HBase存储。面向广告检索场景的索引数据包括正排索引和倒排索引采用Redis和ES来存储。
存储上还需要解决的一个问题是广告的同步问题。广告投放完成后首先会存储在MySQL数据库中接下来需要把广告实时传输到检索系统中完成正排索引以及倒排索引的更新。 索引更新服务有几个要点说明下
各个业务系统在推广、余额等信息变更时发MQ消息索引更新服务订阅MQ来感知变化完成增量同步。变更的消息体中不传递实际变更的字段仅通知有变化的广告ID索引更新服务实时读取最新数据完成更新这样可以有效的解决消息乱序引起的数据不一致问题。当更新索引的并发达到一定量级后可通过合并相同广告的变更、或者将倒排和正排更新分离的方式来提升整体的更新速度。
2. 广告检索平台的整体流程
广告检索平台负责承接C端的流量请求从海量广告库中筛选出最合适的前N个广告并在几十毫秒内返回结果它是一个多级筛选和排序的过程。 Recall层侧重算法模型Search层侧重业务。从下到上计算复杂度逐层增加候选集逐层减少。说明搜索广告场景和推荐广告场景在某些子模块上存在差异但整体流程基本一致这里不作展开
性能设计是检索平台的重点通常有以下手段
做好服务分层各层均可水平扩展。采用Redis缓存避免高并发请求直接打到数据库缓存可按业务规划多套进行分流。采用多线程并行化某些子流程比如多路召回逻辑、多模型打分逻辑。热点数据进行本地缓存比如广告位的配置信息以及策略配置信息在服务启动时就可以预加载到本地然后定时进行同步。非核心流程设置超时熔断走降级逻辑比如溢价策略不溢价只是少赚了不影响广告召回。和主流程无关的逻辑异步执行比如扣费信息缓存、召回结果缓存等。精简RPC返回结果或者Redis缓存对象的结构去掉不必要的字段减少IO数据包大小。GC优化包括JVM堆内存的设置、垃圾收集器的选择、GC频次优化和GC耗时优化。
3. 计费平台的技术方案
计费平台也是一个核心系统主要完成实时扣费功能。比如CPC结算方式下广告主设置的预算是50元每次点击扣1元当扣费金额达到预算时需要将广告及时下线。 除此之外计费平台还需要支持CPM、CPT等多种结算方式以及支持反作弊、余额撞线处理、扣费订单的摊销和对账等功能。 计费平台的特点是并发高、数据量大、同时可用性要求高需要做到不少扣不重复扣。下面以CPC实时点击扣费为例详细说下技术方案。 首先整个扣费流程做了异步化处理当收到实时扣费请求后系统先将扣费时用到的信息缓存到Redis然后发送MQ消息这两步完成后扣费动作就算结束了。 这样做的好处是能确保扣费接口的性能同时利用MQ的可靠性投递和重试机制确保整个扣费流程的最终一致性。 为了提高可用性针对Redis和MQ不可用的情况均采用了降级方案。Redis不可用时切换到TiKV进行持久化MQ投递失败时改成线程池异步处理。 另外每次有效点击都需要生成1条扣费订单面临大数据量的存储问题。目前我们采用的是MySQL分库分表后期会考虑使用HBase等分布式存储。另外订单和账务系统之间的数据一致性采用大数据平台做天级别的增量抽取通过Hive任务完成对账和监控。
4. OLAP海量数据报表的技术方案
数据报表是也是广告平台的核心业务它是广告主、平台运营人员进行投放优化、业务决策的依据。先来看下广告数据仓库的分层结构
源数据层对应各种源数据包括HDFS中实时采集的前后端日志增量或者全量同步的MySQL业务数据表。数据仓库层包含维度表和事实表通常是对源数据进行清洗后的数据宽表比如行为日志表、推广宽表、用户宽表等。数据集市层对数据进行轻粒度的汇总表比如广告效果表、用户行为的全链路表、用户群分析表等。数据应用层上层应用场景直接使用的数据表包括多维分析生成的各种收入报表、Spark任务产出的算法模型特征和画像数据等。
采用这样的分层结构和软件分层思想类似提高了数据的维护性和复用性。 再来看应用层报表部分面临的挑战聚合维度多需要分时、分广告位、分推广等几十个维度单表最大达到百亿级别支持时间范围的实时查询。 这部分由公司的大数据部门维护采用了开源的技术方案离线部分使用Kylin数据存储在HBase中实时部分使用Flink和Spark Streaming数据存储在Druid中。
写在最后
本文详细介绍了广告系统的初期架构和核心技术方案。随着业务演进架构也会随之变得更加复杂但是大数据存储、高并发、高可用始终是广告业务的技术难点。
