关于NoxMobi

NoxMobi是领先的数字营销和广告平台之一,通过我们强大而独特的技术驱动的人工智能(AI)和大数据(BigData)商业解决方案,为广告商和出版商提供服务。NoxMobi智能移动广告平台将AI+大数据+广告相结合,构建了一个具有不断增长的用户数据库的国际广告系统,为广告商提供高精度、高效率的目标流量。我们的全球交通覆盖了前五大地区,包括亚太地区、东南亚、欧洲、北美和南美洲。NoxMobi是为国内应用程序收购高质量海外用户的优质渠道。我们不仅为世界带来了优秀的产品,而且还带来了先进的技术和新的商业模式。我们的AI+大数据努力引领了应用市场营销的创新。

什么是数字营销

目前全球广告市场规划约6000亿,其中约30%为互联网和移动互联网广告,所以这块蛋糕也是很大的。数字营销、互联网广告、在线广告、计算广告、程序化广告等所说的基本上都是同一件事情,这些主要解决的问题就是如何在互联网媒体上投放广告的问题。

数字营销主要有三方参与者:
  • 广告主(需求方):其需求往往是面对流量和库存的,其最大需求就是如何成本更 低,效果更好。而效果的定义往往是不同的,一般分为品牌和效果两种。对于品牌而 言,比如可口可乐打广告,人们看到广告可能不会立即去买一瓶喝,但是品牌广告会 深植在人们的心里,进而产生长期的效应;而效果广告比如在头条上看到一个广告, 用户当时看到有兴趣可能就会点击之后进行下载了,这样就能发生直接的转化效果, 这种就叫做效果广告。
  • 媒体(供应方):其需求比较简单,就是如何收益更高。收益具有长期和短期之分, 媒体往往不能因为短期的高利益而放弃媒体的形象,这样才能让长期的利益更高。
  • 中间商:主要就是通过连接供需来赚差价。有些广告宣传的中间商不赚差价基本 上是不可能的,只不过是怎么赚和什么时候赚的问题。赚取差价的主要手段就是规模 效应和垄断,而无论是广告主和媒体只要能够垄断就能够具有更高的议价权。
总而言之,数字营销就是应用最新的互联网技术来提高营销效率,会应用比较前沿的人工智能、机器学习、经济学上的博弈论等。广告主会追求减少浪费,让最合适 的人看到广告,这也是数字营销相比传统营销的特点。媒体则是将广告为卖给最需要 的人,最需要的人则将会通过出价体现自己的需要。中间商则是高效地撮合交易。如 下图所示的是广告行业的简单生态图,图中的DSP 大概就是前面提到的需求方,也 就是广告主。其右边是流量方也就是媒体,下面这部分则是赚取差价的中间商。NoxMobi:什么是数字营销

NoxMobi的广告系统

NoxMobi的广告系统包括夜神、NoxInfluencer等平台。

Nox夜神的主要优势:
  • Nox 夜神:Three major product systems support to capture high -LTV users with low cost
    图 1. NoxMobi:广告和业务系统
    NoxMobi:广告和业务系统

    上图中最左边是Noxmobi 广告平台;中间的是Influencer,在国外基本上就是“网红”平台;最右边的NoxPlayer 和NoxCleaner 就是Nox 自有的媒体流量,多点在线的广告也主要会投放在这些广告上。

  • Nox 夜神:Manage Every Marketing Stage
    图 2. NoxMobi:夜神2
    NoxMobi:夜神

    如上图所示的是夜神在发行前期、中期和后期所应该使用的相应产品。

  • Nox 夜神:Pre-Launch and Launch MarketingNoxMobi:夜神3

    如上图所示的就是Nox 流量上的广告位,图中右侧是模拟器的启动图和 Launcher 部分的广告位,这些广告也不会非常影响用户的体验。Nox 主要是做海外 的生意,而国内和海外的广告市场是不同的,所以也是分开来做的。

图 3. NoxInfluencer 示例
NoxInfluencer 示例

如上图所示的是目前主推的Influencer,目前也有一波流量红利,找网红推送 APP,右图是Nox 为Keep 做的广告,比如在健身教练所发出的视频或者直播,给教练一些收益,一起来做视频,也可以看到Keep 的广告收益也是非常好的。目前 Nox 也对于自己的流量端产品用Influencer 进行营销,花费大约10 万,使得自然新增达到了每天1 万,APP 开发者都知道这其实是一个非常可观的数字,因为自然新增能够将应用在GooglePlay 上的排名推到很高的位置,使得NoxCleaner在一些国家直接达到工具排行榜的前三。

NoxMobi广告业务流程及演进

图 4. 广告业务流程介绍:Online advertising
广告业务流程介绍:Online advertising

在线广告业务的基本流程可以从用户的访问开始,用户首先打开一个APP 或者 访问一个页面,当发生了用户访问行为之后,一般在APP 里面会有广告的SDK,之 后SDK 就会触发展示然后去请求广告的内容。SDK 一般会与一个SSP 关联,属于 某一家SSP,然后去SSP 上请求广告。SSP 再对接ADX,也就是之前所提到的中 间商,其主要负责撮合交易。ADX 又会对接很多的DSP,并向很多的DSP 发起竞 价邀请,DSP 则将会代表广告主决定是否需要投广告以及广告的出价是多少,并在 ADX 进行多家的比较,做一次竞价的拍卖,价高者得,但是按照第二高价收费,再将获胜者一步步返回给用户,用户最终就会看到赢得本次竞价的广告。广告后续还会 发生一些点击、下载、安装等行为,并进行进一步跟踪。

图 5. Nox广告系统演进
Nox广告系统演进

如上图所示的是Nox 广告系统的演进情况,首先可能与小开发者一样直接集 成第三方的SDK,而第三方的SDK 的广告是完全不能被控制的,只不过会每天给 Nox 一定的收益,而在这个阶段其实收益也是比较低的。后来,Nox 就自己做了一 个广告展示模块,由业务同学去接国外的离线Offer,在国外某些广告主或者品牌会 放出来一些离线的Offer,这样的收益就比第一阶段高出了很多,这个阶段的系统会 自己在客户端做展示模块,而在业务Server 里面则会有相应的展示控制模块,再往 后就是在接到Offer 之后做一些简单的CTL 预估,之后再做一些比较并将收益比较 高的投放出去。第三个阶段系统展现图中的中心部分就是广告业务,最外层的两个模 块就是原来的业务系统,最外层两个模块之间的连接就会变得很细,基本上只做流量 切分的工作,而中心部分就是前面所提到的DSP、SSP 以及集成的ADX 模块,从 而形成一个完整的广告生态。在这里,除了自己本身的DSP 还会和第三方的DSP 进行竞价保证流量的收益最大化。此外,SDK 还可以做成融合的,虽然其不开放,

相关技术及MaxCompute 应用

图 6. Dsp 系统数据流及相关服务
Dsp 系统数据流及相关服务

SSP 和ADX 相对而言比较简单,因此在这部分将会重点讲述一下DSP 系统数 据流。Rtb 就是Runtime Bidding,也是DSP 里面比较重要的一个部分,主要是做 实时竞价的。所以广告流程一般而言就是从Rtb 模块开始,在竞价的过程中会产生 Bidding 的Event,并将Bidding 的Event 都输入到Kafka 里面,Kafka 里面会有 订阅的消息,一直更新大的Cache,这里面的数据会通过流式计算做成feature 再反 馈给Rtb 系统。Pixel 就是事件服务,比如发生了展现或者安装之后就会访问到这个 服务,而这个服务将会Tracking 到本次广告的所有Session,这样的数据也会流入 Kafka,同样由Updater 和流式计算进行处理。而从Kafka 里面会另外分出来一只 数据流通过高速通道回流到中心节点,也就是MaxCompute 上面。MaxCompute 会进行一些离线的报表计算和特征,报表就会输出到DSP Report 上面(比如 RDS)。

其实Nox 设计的所有广告的核心数据将会走这样的一套比较复杂的流程,而一 些运营相关的非核心数据则会主要使用了自己搭建在阿里云上的神策这款BI 服务, 其也属于企业级的应用服务。

图 7. 流式计算Spark Streaming应用
流式计算Spark Streaming应用

流式计算Spark Streaming 主要用于实现实时的报表以及实时特征的计算。因为 业务的主要要求是必须稳定并且能够实现7*24 小时的可用。可以接受秒级延迟,比如 广告投出去了,晚10 秒钟展现在报表里也是没问题的。可根据吞吐量横向扩展,比如 突然新接了几家SSP,突然变得流量很大,不能在这个时候让系统挂掉。此外,因为 业务在全球都有,所以需要全球的聚合任务,需要通过一个平台看到各个国家的数据。

Nox 选择的方案就是:Spark Streaming 能够将上面几项需求全部满足,另 外就是配合Kafka、RDS 以及Redis 做输出。在部署上面,需要实现小集群独占, 这里所用到的就是阿里云EMR,其可以帮助客户托管集群,Nox 只需要在阿里云 EMR 上面申请一个小集群,比如三到五台机器,这些机器申请之后就不再释放掉 了,会一直独占着,并且7*24 小时地跑流式计算任务。原始日志压缩流式回传,这个是因为Nox 在各个数据中心都有Bidder 或者Pixel 的服务,会产生很多数据,之 前的一种方案是在每个中心先将数据计算成半成品,之后在进行回传,这样所用的带 宽就会比较小,但是如果采用这样方案,那么所有的功能都需要开发两套,在本地先 计算,之后传回来再进行聚合计算,这样就会比较复杂,因此最终决定将日志进行压 缩,以流式方式进行回传,这样的方案在验证之后发现所占的带宽不是很大,而因为 是流式传输,因此带宽也比较平稳,虽然这里所用的带宽属于高速通道带宽,因此成 本也可以接受。而压缩则使用了Kafka,其是能够支持压缩协议的。此外,中心节点 部署能够方便开发。

上图中最底层就是阿里云的EMR 托管服务,在其上是DSP 平台和SSP 平台, 他们的集群是分开的,如果流量特别大,某一个平台被打挂掉了,另外一个平台是不会 受到影响的。而托管服务的好处就是能够托管很小的集群,对于企业而言也没有什么成 本。Kafka 里面输入的就是Event 的Topic,之后还会输出回Kafka,这样Updater 再将Kafka 里面的数据放到Redis 或者RDS 用于构建模型和计算报表。这样的设计 的唯一问题就是比较依赖于高速通道,这样稳定性和扩展性就有可能受到限制。

图 8. 离线计算MaxCompute应用
离线计算MaxCompute应用

离线计算部分,Nox 主要使用了MaxCompute。几乎使用了MaxCompute 来 解决各类数据计算问题,BI 数据、广告报表、反作弊、标签抽取、特征数据计算、统 一用户标识、爬虫数据处理等。其实在一开始,Nox 也是自建Hadoop 集群,购买 了阿里云的ECS 搭建集群,从最开始的6 台一直到后来的十几台,这时候实在扛不 住了,机器经常宕机,因为使用的是Spark,因此内存很容易占满,某一天用户突然 增多了,数据就没了。此外,这样的成本也非常高,因为当时主要运行BI 数据,所 以基本上都是在晚上运行的,而白天机器则处于空闲状态,因此成本很高。后来采用 了EMR 的按量付费集群,晚上申请之后跑数据,但是白天能够释放掉,但是这样的 过程则是比较漫长的,需要10 到20 分钟。后来Nox 开始接触到MaxCompute, 使用起来非常好,其带来了很多优势。首先,不再需要运维集群了,此外其计算速 度很快,虽然说Spark 的计算速度很快,但是小集群的Spark 和大集群的Hadoop是无法比拟的,所以大集群的Hadoop 其实计算速度是很快的。MaxCompute 是 真正的按量付费,因此成本也能够大大降低,而自建Hadoop、使用EMR 以及使 用MaxCompute 的成本是成量级降低的。差距也是非常大的。主要使用SQL 开发, 效率比较高,也便于调试,文档也比较清晰。此外,MaxCompute 还提供了一个还 不错的调度系统,如果是自己搭建这样调度系统还是比较困难的。

对于数据的导入和导出而言,因为Nox 有很多海外的服务,有些服务是不能覆 盖到的。所以Nox 采取的策略是优先使用数据同步服务,而流式数据则使用SDK, 当数据同步和SDK 都不合适就写脚本+tunnel 导入和导出数据。

如上图所示的文件数据主要是爬虫,因为一些服务的日志是达到OSS 上的,并 且有一些外部数据也是先上传到OSS 上面的。RDS 则是什么都有的,广告业务数 据就是前面所提到的,这些数据会选择合适的方式统一进入到MaxCompute 的分区 表里面。SQL 计算基本上都会用到,MaxCompute 则是在SQL 写起来很费力或者 运行很慢的情况下使用。图计算使用的并不多,只是会在计算同一用户UUID 的情况 下使用,这里应用了最小连通域的算法,比如一个用户使用了多个设备,则需要将这 些设备统一地关联到同一个用户身上。而PAI 平台对于广告的CTL 预估非常重要。

图 9. 特征计算和标签抽取
特征计算和标签抽取

如下图所示的某第三方DMP 的对外标签体系的示例,大概分了几类,比如人口 学、设备信息等大类,在每个大类下面还会有多个标签。特征一般而言就是连续值, 标签则是指将连续值做一些规则之后所打的标签。举例而言,定义特征,最近一周内 活跃天数,则有0~7 的取值。而定义标签规则,则是一周内活跃0 天、1 天、2~3 天、4~5 天、6~7 天的分别是不活跃、低活跃、中活跃、高活跃、极高活跃用户。当 在做好定义之后,就要看大家的SQL 写的是好是坏了。之前在不支持with 的时候, SQL 代码一般都要写很大一堆,而且很难改动。此外,在写SQL 的时候注意代码 分隔还是很重要的。另外的一些建议就是优先使用內建函数,虽然一些內建函数和 UDF 的功能差不多,可能一个UDF 能够实现两三个內建函数的功能,但是效率却相 差了很多,虽然使用內建函数会让代码看起来丑一些,但是绝对比UDF 运行速度要 快得很多,所以在內建函数无法满足需求的时候再去考虑UDF,实在不行就可以用 MapReduce 实现,比如对一大批特征做等频离散化。

上述这些都是DMP 的标准功能,但是Nox 目前还没将其实现平台化,都是使 用标签写的。而阿里云上有标签服务,目前也在考虑使用。

图 10. Targeting
Targeting

所谓Targeting 就是人群定向,相对于把特征输入模型而言,标签式Targeting 主要是方便人来操作,使用投放人的经验通过标签定向的方式来优化表达。比如在 广告投放初期可以比较好地缩放盲打范围。另外一种则是Look-alike 方式,Lookalike 方式的定向为寻找相似的人,种子用户为正例,从所有用户中找到正例概率较 大的人群。以上就是定向的两种主要方式。

如上图所示的定向的主要做法就是将内部和外部的数据输入到MaxCompute 里 面,经过各种计算将标签化的数据或者用机器学习标注好的数据同步到线上并缓存 好。之后在进行实时竞价RTB 里面查询缓存,命中之后就在DSP 里面由广告主配 置,命中了就投放广告,否则就不投放。

图 11. Ctr预估
Ctr预估

Ctr 预估是Nox 投入比较多的一项工作。Ctr 预估并不一定是预估Ctr,还可 能去预估Cvr 甚至是Ctr 和Cvr 的乘积,这些统称为Ctr 预估。其作用是首先计算 Ecpm 的值,Ecpm 就是每次展现的期望收益,期望是一个概率论上的概念,其等于 用单价乘上本次收益可能的概率。Ecpm 也将指导绝大部分投放相关策略。

如上图所示,主要分为两条线,一条是离线数据会走MaxCompute,而在线则 会走Spark Streaming。总体最后会输入到标签和特征的大Cache 里面,Cache 中的数据有一部分直接加载到内存里面,另外一部分比如用户特征无法加入内存就会 在Inference 服务查询缓存,这里就会组合出一个特征的向量,用来计算Ctr 的值, 并将值返回给Rtb 的Bidder,在Bidder 做一系列的策略,最终得出竞价的决策。竞 价完成之后,是否参与、是否竞价成功以及是否展现等日志都会灌入回MaxCompute 或者Spark Streaming 进行模型训练,最终对已有模型进行更新,形成一个整 体的闭环。Online model 需要使用Spark Streaming,而Deep learning 就需要用 TensorFlow 等了。

Pacing

Pacing 比较复杂一些,其就是不止考虑单次展现的收益,而要在单次竞价时 考虑对全局收益的影响,比如考虑一天之内总收益如何,比如可能将转化率最高的 Offer 在一天开始的两小时内都投完了,但是其他的Offer 都没有投出去,这样计 算下来总收益并不如将全部广告都投完的收益高。Pacing 的整体思路就是通过对 流量分层和分时的统计和预估,用数学方法来保证全局收益的最大化。Nox 则根据 Yahoo 的论文实现了自己的方案,这里面最核心的就是将Ctr 估算准确,并将分层和分时的各种统计值计算好,然后按照其策略执行即可。

Nox 目前也在寻求更多的合作伙伴,希望更多与具有出海意向的开发者进行深入 合作。