对接腾讯广告平台系统开发（半自动化广告投放系统）

这是我最近刚弄完上线的一套比较有意思的比较大型的系统，因此特意记录一下。

先说这套玩意获得的效果：竞品的投放团队运营团队就算有一百个人，天天996，007加班不睡觉，投放效率也没有我们四五个人的高，这个是人工成本的一次大缩减。在效果反馈和素材投放效果的实时性准确性上，肯定也不及专门定制的系统根据各项指标排序展示准确，这个是实用性价值方面，其余的还有创意素材管理…人群定向管理…批量组合逻辑…等等等等～非常庆幸自己有机会坐拥公司提供的这么多资源，才能有这么有价值的产出～

具体功能详述：

腾讯手握大量用户数据（我们注册时的性别/年龄/住址/姓名/学历/消费能力），又有微信QQ公众号朋友圈等等社交媒体，又有大量的游戏，收集了我们这些数据，能提供很精准的广告投放功能。所以他们有一套广告平台。

这套东西是收费的广告投放系统，在交了“入场费”后，我们就可以进去填写我们的投放计划，我们的广告落地页，我们的广告图，广告文案，创意设计等等，以及我们自己填写的出价策略+日预算来增加曝光度等等一大堆复杂的功能。

我公司做的线上教育嘛，为了跟猿辅导，作业帮，学而思那些竞品瓜分市场大蛋糕，自然也要借助这么好用的一个工具，将广告打到家长们的朋友圈，QQ动态，公众号，网页插图等等地方（类似下面）。

其实这个跟公众号运营一样，你可以直接在腾讯提供的后台操作，但是就比较多限制，不够人性化，不能满足公司特殊的业务需求，比如这个广告平台，图文素材上传问题就是每个投手都有一个账号一套，素材不共享，投放批次无法区分，沟通成本大，一次只能选择单图文单定向，无法批量创建，投手们和设计师们苦不堪言。于是作为负责对外招生线的后端开发同学们，就有事可做来。

这里有几个概念简单说明一下：

（1）推广计划：其实就是整个广告的投放推广的计划，是最大的一层，包含了投放时间段和计划预算（预算金额高的腾讯会增加该计划的曝光量），所有后序操作都必须基于推广计划才能继续做。
（2）广告创意：其实就是设计师们做出来的图，还有投手们运营们绞尽脑汁想出来的广告台词文案拼接成的，还包含你的落地页链接，下单也链接，支持商城小程序和商城网页等等。
（3）广告组：一个推广计划下会有1～10个广告组，广告组也有预算，有它各自的定向类型，扩量，投放目标类型等等一大堆参数。
（4）广告：记录了广告组ID，创意ID，计划ID，只有创建完毕广告，整个计划才算创建完整。
（5）投手账号：开通了能新建广告功能权限的投手的微信账号。
（6）定向：分为人群定向和地域定向，人群定向其实是限定人的年龄区间，性别，受教育程度，消费能力等等一堆数据，比如你不可能推送一个游戏的广告给那些老年人，不可能推送卖房子的广告给小学生吧？地域定向就是经纬度，生活的城市地区，毕竟你不可能推送卖泳衣的给撒哈拉沙漠地区人民，推荐防晒霜给四川人民，推荐广州的房地产广告给黑龙江人民吧？
（7）素材：分为文案素材和图片素材和视频素材。有各自的规格，大小多少M，多少像素，800*680…等等，腾讯很多复杂的组合限制。

简单介绍完概念，如果是有需要的同学可以再详细看腾讯的接口文档：https://developers.e.qq.com/docs/start?version=1.1（友情提示：右下角有人工客服，点开输入人工就可以问问题，它很多文档的参数写的都是错的）

下面开始具体说说踩的坑：

（1）做了60%才发现整个流程缺少了一大块！

我们完全按照腾讯的格式，分层建表，在素材管理那一块，我们做了一套类似高级文件夹功能的系统让投手们共享素材，再也不怕沟通不到位的问题了，大家都知道现在投放线的最新素材版本。然而，我们创建创意的时候，发现所有的素材不能存在我们的资源服务器上，而是要上传到腾讯那边的资源库，然后他们返回一个ID，我们创建广告时候拿的其实是这个ID。于是我们又改了流程，要在上传后将返回的ID全部共享到全部投手账号下，也就是每个账号都上传一遍。

（2）循环逻辑太复杂了吧？！

由于投手们饱受腾讯限定的一条一条创建的苦，他们必须不断重复毫无意义的重复创建工作。所以它们要求能批量创建，但是这个批量功能，复杂程度远超乎我的想象！

功能点一：能多选文案和图片素材/视频素材。

功能点二：能够多选人群定向和多个地域定向进行组合。

功能点三：能够自己输入创建N份推广计划，而不用一条条输入创建。

功能点四：能够自己输入创建N份广告组，而不是创建一条再创建一条。

这样的话，顺序其实跟腾讯那边是相反的，腾讯的顺序是现有计划，再有创意，再有广告组，最后有广告，我们这边却要根据用户输入和多选的素材组合和定向组合来确定要创建多少条计划！！

例：

现在有图片素材A 图片素材B 文案素材T1 文案素材T2

人群定向 P1 P2 地域定向广州 G 深圳S

问：一共生成多少条计划？

答：图文结合： AT1 ， AT2 ， BT1 ，BT2 。人群地域结合：P1G , P1S , P2 G , P2S.

计划参数组合：

AT1-P1G , AT1-P1S , AT1-P2G …好了你们懂我意思了吧？

其实就是组合套组合，循环套循环而已，那我们就先走我们自己的批量逻辑计算出具体会有多少条组合，再通过腾讯接口去依次创建，剩下就是接口对接，上百个参数的对接，枚举类型的定义。

（3）上面的还不算重头戏，重头戏其实在这里：

我花了两天左右时间，把接口调通了，创建流程全部走通，我们这边的分批次分层级入库也没问题了，开心得雅痞！我忽然想起投手们还能自己输入要创建复制同批次的推广计划份数，于是弱弱的问了一句，他们原话：最少一次也复制几百条吧，不然几条几条的没意义啊。

我凌乱了，为什么？！请听分析：

正如我上面最简单的两图两文组合，两地域两人群组合，已经能生成：2222 = 16条计划（以及后序创建计划下面的三个层级），他们假如输入“几百条”复制数量，那我以300为例子，那就是：16300 = 4800条，那么依次创建三个层级，也就是 4800 * 3 = 14400 次接口请求，然后它们还会输入“复制1～10条广告组的条数”，那就是：14400*10 = 144000.

没问题啊老铁，十四万次接口调用，只为了创建一个投手单次操作的广告。我们有上百个投手，嗯，上面的计算量我还是按照最小的数量来进行的，他们如果选择8图8文甚至更多，轻松上百万次接口请求。

那么，假设忽略网络延迟的情况下，我算做你0.1秒请求响应一个接口，不出故障。那也要：14400秒

也就是说，这个投手一次创建的广告，（不出故障，全部创建成功，网络稳定情况下，腾讯接口不针对我做限制情况下）耗时4小时。

真好，我用的是Node，单线程，炸爆服务器。

真好，前端一直转圈圈，用户在四个小时后就能得到创建结果，这四小时可以下班回家煮个饭。

好个球啊！！这很明显是不行的，这已经是存在重大的设计缺陷了！！

中间跟产品撕逼的过程我也不说了，直接给解决方案！！

这种瞬间爆炸数据量得不到即时响应的场景，是不是像秒杀之类，我回忆起自己之前做的一个外包项目的秒杀，就是采用了延时策略。

于是：

创建时候不去请求腾讯接口，只会在我们自己的数据库先进行入库操作，同时为了缓解瞬间大量写入更新造成的压力，我们先将创建请求的参数，对象，通过序列化存在Redis中，后序再通过Linux的CronTab定时任务获取出来，反序列化还原回对象，再进行入库操作，操作成功后记得把该条记录的Key覆盖掉删掉。

把创建流程改为全部先入库，概念从传入单个的“广告条件”，改为传入“广告条件参数包”，将两万个计划和两万个单条创建参数（从前端传入的条件参数包中循环组合拆分出来）组合先insert进数据库，待腾讯返回ID字段留空，并且模仿腾讯广告的层级关系依次创建后续的创意，广告组，广告先入库。然后再通过CronTab定时任务（1分钟）依次从数据库拿status为0的未创建的计划和对应的计划参数和旗下的全部子层级出来，再通过计划的参数依次调用腾讯创建接口，把获得的ID再放到下一层级创建参数中依次循环创建，如果其中一层级失败，记录相关的错误信息（层级+腾讯返回的错误原因）到计划表，整条广告计划创建失败。

用户在运营后台虽然不会等待太久，但是其实我们这边的创建申请，可能要几个小时甚至更久才轮询到再调用腾讯创建接口创建，才会出现在腾讯计划列表，失去了实时性，失败原因得不到及时反馈，紧急情况下不能立即进行修改重投。

协商过后，其实这个已经是最好的解决方案了，这也是没办法的事情，投手们因为已经是批量了，不可能马上能得到反馈，但是我们能够优化它的体验，给个创建进度条给他们看，及时记录失败原因，方便他们修改后重试。

通过这一套大型系统（四套子系统：投手账号管理系统，素材管理系统，定向管理系统，投放管理系统）的创建，真的是非常有意思，但是工期实在太紧张（3星期），搞得压力真的很大。

当然，这还不是结束，这还仅仅是开始，后期还有动态商品类型迭代（包含商品库和商品目录等关系子系统），还有一堆又一堆的新需求迭代～把它打造得更完善～

PS：刚上线一个月就有顾客闻讯而来希望买这套系统，这对于作为父亲的我来说，真是莫大的幸福～