文章目录
剩余/长尾流量如何售卖广告
“ 在互联网行业中，如何利用流量快速变现，售卖广告绝对是首选手段。尤其是存量市场状态下，流量的整体价值变得弥足珍贵，而如何对尾部资源进行售卖成为变现道路上的绊脚石！”
挖掘长尾流量价值
在互联网广告平台发展中后期，自家媒体的主流调性已经被广大广告主认可。纷纷出手竞拍自洽流量，热门流量更是一路热销。
作为平台，这个阶段为了进一步扩大营收，主要从两个方面着手。一方面，进一步挖掘广告主需求，提升广告曝光/填充，以优质的转化及可量化的效果吸引更多的客户；另一方面，寻求平台无人问津的长尾流量的价值，以实现平台整体流量的价值最大化。
长尾流量，顾名思义即是主流的末尾，被剩下的部分流量。举个例子，在主互娱调性平台中的一些学术流量，这部分流量在平台几乎是卖不出去的，是剩余的；因为这部分的流量是平台主调性外的垂类衍生物，对娱乐互动类广告主没有价值，又对学术类广告主显的鸡肋，这就是剩余的流量。
长尾流量的出路
那么剩余流量该何去何从呢？
其中一种常见的业界做法是，将这部分流量转接给第三方，由第三方进行流量售卖。今天就以此介绍一个进行剩余流量标记到转接第三方的项目。
2.1 长尾流量的判定
从产品角度我们介绍了什么是剩余流量，那么我们在实际流量判定时，该如何做呢？
这里我们采取由数据分析师推荐的一种策略：局部性实时决策。
2.1.1 数据局部性
我们知道在 Linux 系统中，CPU访问存储器时，为了提高存取效率，无论是存取指令还是存取数据，所访问的存储单元都趋于聚集在一个较小的连续区域中，这里就是运用了数据的局部性原理。
局部性原理又分为时间局部性、空间局部性和顺序局部性。
时间局部性：如果一个信息项正在被访问，那么在近期它很可能还会被再次访问。
空间局部性：在最近的将来将用到的信息很可能与正在使用的信息在空间地址上是临近的。
顺序局部性：在典型程序中，除转移类指令外，大部分指令是顺序进行的。
据此我们以广告是否分发作为判定的依据：通过用户维度广告24小时投放频率，判定用户是否为剩余流量。【若存在广告投放，则为非剩余流量；若无广告投放，则为剩余流量并做次数标记】
长尾流量实时标记
我们有了判定的策略，就需要以此去实现，为了策略的效果更佳，我们将设计 “剩余流量实时打标服务”[实时标记剩余流量 —— FlowRemainer]。
我们把服务数据处理模式定位为流处理模式，通过实时消费 Trace 数据流，进行流量标记。部署方式采用基于docker 容器的方式。
3.1 Trace流服务整体链路布局
Trace 是依托于广告系统平台为数据源，这里不做重点，简单描述上下链路关系。
ADS 将 Trace 写入 Kafka ,数据进行 Hive 落地进行大批量的异步任务处理；同时基于 Kafka 消费构建实时的 流处理服务，FlowRemainer 就是其中之一，其他服务可以以此模式进行扩展构建。
3.2 架构层次图
我们以经典的 MVC 架构模式做基础进行业务化进行 FlowRemainer 的架构设计。
整体架构分为三层，入口为代理层，将进行服务通信协议及数据格式的转换；中间为业务层，集中进行业务逻辑的处理；最下层为部署层，支撑服务部署交付。
业务层分为三层，上层为 Service 层，封装各个业务对外接口；中层为 Dao 层，构建业务依赖的实例对象；底层为 Level 层，是支持业务实现的基础服务。
3.3 对象类图
我们以抽象接口为主设计对象类，最大支撑服务的可扩展性及可维护性。
图中的 … 都为可扩展部分。
3.4 逻辑分布图
由于服务目前主要业务是剩余流量的实时标记，比较简单，这里只描述整体逻辑分布。
服务以 Goland 编程语言设计实现，利用其并发编程特性可支持横向扩展，单节点一般可支持 15w+ QPS[具体数据以资源规格为标准]，P99 耗时在 20ms。
服务可观测性
这里的服务遥测，选取拥抱云原生的 prometheus 组件。由于篇幅有限，可关注公众号，见后续文章。