分析：在线广告系统的技术架构及数据流向

01 本文分析了偏技术和数据逻辑的整体在线广告系统的技术架构和数据流。在进行正式分析之前，我们将首先绘制计算广告中涉及的技术架构图（没有必要重新绘制，手拍一张，先看，然后根据逻辑理解绘制数据巢）：事实上，从整体的角度来看，它相对完美，基本上阐述了整个广告技术逻辑和角色的各个部分，但从个人的角度来看，更期待更多的技术逻辑，即使是数据流的逻辑也能理解整个技术系统。因此，我们可能更容易理解整个在线广告的技术架构逻辑，重点关注具体的技术选择方案和数据流通趋势。02在我们重新理解绘制的“在线广告技术架构图”之前，让我们看看推荐系统架构逻辑图：我们以前提到推荐系统和广告系统有一些自然的联系，关于业务逻辑，我们可以参考第二个“数据和广告系列2：计算广告和推荐系统”。在这里，我们回到技术维度，从推荐的技术架构来推断广告的技术架构和类似的数据流逻辑。回到上图，推荐的核心逻辑步骤是：1。做推荐候选人的召回处理2。做推荐候选人的排名逻辑3。推荐策略规则干预逻辑4。推荐服务输出召回部分有许多推荐相对特殊的召回算法或召回逻辑，这是候选人的初步筛选逻辑，关于项目实现部分的差异，当然，大多数是离线模式下的召回，实时召回逻辑也强烈依赖于工程数据流通。这部分处理广告候选人的初步筛选。当然，逻辑会有所不同，实时要求可能会更强，所以算法的复杂性会更弱，但对标签系统的要求会更高。这部分处理广告候选人的初步筛选。当然，逻辑会有所不同，实时要求可能会更强，所以算法的复杂性会更弱，但对标签系统的要求会更高。在排序部分，实际上是根据点击估计的特征，追求点击转换率。这个维度和广告的相似性很高，但是广告对点击估计的要求会更高。毕竟都涉及到真金白银，所以点击估计会投入更多的技术成本，无论是处理特征还是提高算法的复杂性。核心目标是点击估计率高。事实上，规则引擎的逻辑部分是各种人为因素的干预部分，这几乎与广告部分无关，因为推荐是一种介于用户体验和广告中间状态的逻辑，所以我们必须考虑一些人为因素。事实上，服务部分与广告的最终服务没有太大区别，承受并发压力、各种实验标志的传输和输出等。其中一些非常核心的是推荐的实验平台，其核心目标是推荐的效果优化，类似的广告逻辑也有类似的逻辑模块，包括数据BI分析逻辑和战略优化逻辑。差异很大的是，广告的BI数据逻辑部分需要向广告商开放，不仅需要内部使用，还需要包装成外部数据查看逻辑，而推荐基本上是自用的辅助实验平台。这是技术逻辑结构差异的核心主逻辑部分。更多的逻辑结合了数据巢重新理解的“在线广告技术架构图”。毕竟，我们的主题是广告。让我们来看看具体的技术逻辑架构图：首先看看在线广告的主要逻辑部分（深橙色部分）:1.广告搜索2。点击估计部分3。广告排名部分4。广告输出服务广告搜索，实际上是广告召回部分，做广告资源候选召回，这里的广告搜索召回，大多数时候实时要求较高，不同于各种推荐的离线推荐召回算法，这里更依赖于auc三源(a广告、u用户、c投放环境)的标签，通过标签匹配直接快速检索，所以很多时候会大规模使用与倒排索引相关的技术。如果是开源解决方案，推荐Elasticsearch等检索引擎。在点击估计部分，追求单一广告输出的转化率，因为在最终排名逻辑中，点击转化率发挥了非常核心的影响（没有转化保证，其他因素可以忽略），所以CTR模型输出算法要求，特征处理要求非常严格，大多数时候为了确保CTR的准确性，实时特征流通要求非常严格，要求能够快速获得特征输入的实时特征。在特征部分，它也是一个巨大的工程系统，涉及如何计算实时和离线特征，如何快速扩展特征，如何存储扩展后10万甚至1000万维度的特征，以及如何解决稀疏和高效存储计算的问题。在最终的排名部分，这部分与推荐有最大的不同，需要综合考虑上一步的点击估计转化率和商业因素（Money），平台方要赚长远的钱(不是一次性消费)，所以结合上一个逻辑计算的CTR评分和用户的竞价(具体竞价逻辑参考第四篇文章《数据与广告系列4:搜索广告来源和竞价策略》)。以及广告商的质量评价（高质量、可持续投资的广告商更受广告平台的欢迎），最终加权计算排名，通过排名确定有效广告资源的所有权。特别需要提出的是，在广告商评分计算逻辑中，对于有投放记录的广告商来说，评分相对容易。毕竟之前有各种投放记录，甚至包括投入预算等。，可以通过相对合理的估计来评估广告商的有效长期价值。对于新的广告商来说，可能更需要依靠人工操作/标签，以及一些外部舆论手段来做出辅助判断。当然，从整体逻辑的角度来看，结合上述文章的逻辑，我们可以估计整个质量评分仍然偏向于辅助效果，更依赖于点击估计和出价。当然，从整体逻辑的角度来看，结合上述文章的逻辑，我们可以估计整个质量评分仍然倾向于辅助作用，更依赖于点击估计和投标。在服务层面，更多的是与投标逻辑相结合的预算管理模块。事实上，在投标逻辑中，每次投标都需要限制预算。04以上是主逻辑部分，整个在线广告技术逻辑架构比推荐逻辑相对复杂。此外，还有几个非常重要的部分。让我们从数据流动逻辑开始。广告部分对数据的实时性有更高的要求，而不仅仅是实时特征部分的特殊性要求。即使在数据BI维度上，实时性要求也非常高。此外，由于Money结算涉及多种结算，不同于推荐的单一主平台，因此对数据风险控制有很高的要求，如点击异常数据进行判断。另一个外部部分是整个广告逻辑的优化策略部分。对于召回策略，点击估计算法、排名策略、竞价策略，甚至与数据关系不大的创业自动生成策略，可以像推荐一样进行各种精细的流量分配控制，然后结合数据回流进行调整和优化。另一部分是非常核心的新客户发现逻辑，即依靠一方数据（广告商数据）、二方数据（广告平台积累数据）和三方数据（购买第三方数据）集成种子人群，通过种子人群计算种子人群标签肖像，结合一些用户资源池进行人群扩散计算。对于Look-Alike人群的传播，实际上有很多方法，比如简单地计算人群的相似关系，这似乎很简单，但一旦规模很大，计算相似关系也需要面临很多挑战，如数据处理、类似关系计算的成本等。当然，有很多方法可以应对，比如做人群聚集，然后计算类似的关系，召回标签上的类似关系。此外，在当前移动互联网如此“猖獗”的时代，社会关系的传播非常有效。如果你感兴趣，你可以了解腾讯人口传播的相关信息。除了从技术架构图中可以看到的一些信息流通道、实时离线计算、仓库应用等，还需要注意解决与大规模使用标签相关的问题，如如何大规模存储和计算标签，以及相对麻烦的标签维护、扩展和维护。综上所述，我们应该对整体在线广告的技术逻辑架构和围绕技术架构的数据流通有一个认知。当然，每个部分都有很多值得研究的东西，比如简单的标签，有很多事情可以做。标签维度的设计、标签的计算、存储、维护和更新都可以成为一个研究课题。还包括CTR如何做得更好，优化召回排序模型，并发压力和服务效率等。在接下来的一段时间里，该系列将继续补充，甚至进行一些细节分析和深入，但该系列可能会在短时间内结束，大约几个月后进行新的衍生补充。当然，如果有时间，也可以补充一篇关于广告数据分析维度的文章，看时间。这篇文章也应该在一周前发表，因为个人离开三年的坑，跑去度假，所以推迟一点，下周进入新坑，所以不一定有时间写这么严肃的文章（严肃的文章真的很麻烦），发现一件非常悲剧的事情是，一旦涉及严肃的文章，阅读就会下降，哈哈。