广告投放

广告投放的主流程，这里拿字节投放举例：字节投放平台上投放我们 APP → 用户抖音上点击我们 app 的广告 -> 抖音回调我们（我们将广告点击数据收集）→ 用户下载 APP 并打开 APP （我们将“激活数据”回传给字节）

和“激活”类似逻辑，在用户注册账号的时候，我们会回传“注册”数据给字节；用户若满足次留的条件，则我们会回传”次留“数据给字节；若用户发生付费行为，如购买会员，则我们会将”付费“数据回传给字节。

投放具体回传类型，投放平台称之为”归因“，可见 → 转化事件回调服务。我们这里使用了如下

按照以上的流程逻辑，投放业务分为以下几个功能模块：

大致介绍几个模块的实现，以下内容均以字节投放举例，其他投放平台大同小异

1. 广告点击

广告点击的逻辑就是，在字节投放平台上投放我们 app 时，除了上传安装包，配置广告信息外，还要配置告知字节我们的监测链接，监测链接就是一个特定格式的 url。该 url 将会在用户在抖音上看到我们 APP 的广告并点击广告时被抖音调用，抖音会将一些广告的参数、用户设备的参数以及用户在字节平台上的唯一 id（callback）通过 url 传给我们。

在按字节投放文档的监测链接发送服务要求下，配置指定的监测链接，如

https://api.colorv.com/colorv/callback?aid=__AID__&aid_name=__AID_NAME__&advertiser_id=__ADVERTISER_ID__&cid=__CID__&cid_name=__CID_NAME__&campaign_id=__CAMPAIGN_ID__&campaign_name=__CAMPAIGN_NAME__&ctype=__CTYPE__&csite=__CSITE__&convert_id=__CONVERT_ID__&geo=__GEO__&request_id=__REQUEST_ID__&sl=__SL__&imei=__IMEI__&idfa=__IDFA__&androidid=__ANDROIDID__&oaid=__OAID__&oaid_md5=__OAID_MD5__&os=__OS__&mac=__MAC__&mac1=__MAC1__&ip=__IP__&ua=__UA__&ts=__TS__&callback=__CALLBACK_URL__

广告业务所有使用到的监测链接都在 Python 项目中对应，其核心代码里会将抖音方得到的广告和用户参数取出，将参数上报埋点并落库。

分别将广告点击数据计入 Mysql 的两个表：

• 表A：主要记录广告和用户设备相关的参数，如广告名、广告id、广告位置以及 udid 等。业务唯一 id → only_key
• 表B：主要记录该点击广告的用户设备在后续使用 app 中，触发的投放行为情况，如是否”激活“、”注册“、”付费“等，用户若随后打开 app、注册等行为发生时，更新该表；业务唯一 id → only

两张表都通过业务唯一 id 所关联，业务唯一 id 均为点击广告的用户设备标识，唯一 id 和用户设备一一对应。

除了记表外，还会往 redis 中记录一个 k-v，key 为业务唯一 id（和表业务唯一 id 一致），value 为抖音传入的 callback。记录该 k-v 是为了用户打开 app 时，给字节回传”激活“数据。

特别注意：拿安卓举例，有以下三种设备标识 imei | oaid | ua + ip

表 A 的 only_key 和表 B 的 only 为三个字段其中之一，按从左到右优先级，进行记录表和 redis。

注意不是只要满足了上一种情况就不进行下一种了！三种都会记一次，这是因为我们 app 和字节 app 能取到的安卓标识不一定能对应上，比如字节能取到 imei，但我们不一定，我们可能只能取到 oaid，所以每种都存，就是为了哪种能对应上，就用哪种，避免漏掉。那么可能就会问了，如果 imei 和 oaid，我们和字节都有，岂不会多走一次上报？最终激活多收一次钱？其实不会的，因为尽管我们报了两次，但 callback 是唯一的，在字节那，报的两次都是用一个设备。

2. 激活

当用户在抖音里点击广告并下载打开 app 后，app 一启动时就会调用某个接口，安卓会通过他们的技术，将采集到的安卓设备标识如 imei 、oaid、ip 等作为入参上报至该接口。接口内部会分别通过 imei、oaid 或 ua+ip 作为业务唯一 id （only 或 only_key）去查询 表A 和 表B，进行表更新，将我们的 udid 更新到表里，并更新”激活“相关的字段。通过并查询 redis，获得该用户设备对应的字节 callback，回调给字节，告知字节该用户已激活。

在回传告知字节”激活“后，将同步在 redis 里记录两个新 k-v， 两个 k-v 分别是用于后续用户发生”次留“和”支付“行为时，再回传字节。

几处细节：

• 和点击对应，在激活时，imei 、oaid、ua+ip 也都要各走一遍。
• 该接口内部，会通过判断 表B 的 created_at 如果早于广告的点击时间，则认为先有设备再看的广告，则在”激活“时会过滤该老设备。
• 正常情况下，在设备第一次打开 app 就会调用该接口进行字节激活。但有一种特殊情况，可能会导致设备晚激活或无法字节激活，如首次使用或初始几次使用 app，用户并未同意 APP 隐私协议，则我们无法获得 imei、oaid等设备标识，安卓认为所有入参为空，不会调用该接口，则没有完成激活，但实际用户使用了 app。如果用户在初次使用的 7 天内（广告点击redis k-v 7 天有效），同意了隐私协议，则才会在同意那一刻激活成功。

3. 次留

如果用户在”激活“后的次日，依然使用了我们的 app，则会将该用户设备作为”次留“数据回传给字节。

只要有用户次日主动调用接口，则认为用户满足次留条件。调用接口里排除了一些常见非主动接口。

考虑到希望在用户满足”次留“条件的第一时间，及时上报字节，满足一定实时性，并且这种检测”次留“逻辑覆盖几乎所有接口，为了不影响服务端接口性能，这里通过 MQ 异步消费上报。

4. 付费及其他

付费接口 MQ 异步消费上报

除了上述与广告服务商平台的归因交互外，业务内部还在投放业务开展了很多其他业务，如投放承接

可针对于投放买量来的用户定制化路由，如登录后跳转页、弹窗、频道 feed 流，进行流量分发以实现看到不同广告的不同人群在使用 APP 时聚焦在不同业务内。

通过服务端埋点与广告服务商数据拉取等多数据源进行数据看板、数据大盘、数据告警等开发。