核心技术逻辑：

1，facebook通过deferred deeplink实现获取投放时候campaign，adset，ad信息。

2，Google通过Google提供的s2s对接实现获取投放时候的campaign adgroup信息。（大致可以把自己当做一个三方类对接自己的产品数据） 

3，通过拿到对应的campaign信息，实现bi统计分渠道，分campaign的投放效果统计，以及后续行为追踪。

解析：

2，在每个发布上去的ad里面，都带上deeplink，并且写入一个随机参数，类似sourceid =123456789，保证这个sourceid唯一。

3，客户端技术在启动的时候获取到设备信息，以及这个deeplink回传过来的sourceid，服务端保存记录。

4，通过sourceid来查询对应的campaign，adset，ad基本信息，如果有必要，双方约定好在deeplink里面增加字段就好。

通过这个逻辑，可以实现服务端知道哪一个设备来自于哪一个campaign的基本信息。

这里是通过API发布facebook的方式，用程序记录和自动生成deeplink+sourceid，但是如果你没有条件通过api来实现，你也可以通过用excel拉表的方式，直接把自己的campaign name，adset name和ad name用自己可以看明白的格式，直接写死到deeplink中，用数字编号的形式可以在未来BI中直接搜索编号来查询自己的campaign之类。

Google获取campaign信息，这个需要Google的直客协助，对方提供S2S的对接文档（我不便公开了），你再申请MCC的dev token ，创建Link ID， 再让技术按照Google提供的文档开发接受数据的部分。

这里实现的流程和你直接去三方里面获取link id比较接近，但是需要自己申请dev token，再申请API权限，这个过程最大的坑就是周期特别长，即便申请下来后也会发现把自己的mcc填到申请linkID的地方也需要等很久才能填进去生效，太早了直接都是报错。

总之按照这两个思路是可以拿到自己安装后的设备信息，以及对应安装时候的campaign，adset等信息。但是这里肯定不出意外是要有意外的：

1，可能存在一个用户会被记录到多次安装，Google+facebook都会记录他的安装，理论上我觉得应该有Google referreal之类实现分析用户的点击时间，再可以实现具体的最后一次点击是谁贡献的来判断到底应该归因给谁（这个事情好像就是第三方在干的），但是这个环节我没去研究，所以没办法给大家分析，勤奋的同学可以尝试看看referral的文档，理论上应该是可以拿到。

2，重复安装的坑，FB GG都存用户不活跃后再次曝光，卸载重装的人再次重装，这个地方我们怎么记录数据，要想做的完善基本又要考虑和三方一样去实现一大堆定义类似re-install，re-engagemtn等等，这个坑不建议你跳，既然都自己开发不想掏钱给三方，干脆就别介意这点误差数据，都给他算新增算了。

3，只跑FB GG可能还好，想跑跑别的渠道就只能拜拜。

之后的重要内容就是实现自己的BI系统。

核心的需求点：

1，7天内（或者更多时间段）分渠道的柱状图，也可自定时间，点开对应渠道的柱状图位置直接展开到campaign层级数据，再点开到了adset层级等。

2，最简单的计算各个event在不同campaign/adset/ad中间的数据表现，并且通过BI展示出来数据，比例等等。

3，计算campaign各个层级的的留存信息。按照用户留存情况计算分campaign，adset等的留存数据。

其他很多功能，考虑到大家看这个文章的通常都是搞休闲游戏+工具之类的。所以 更多功能开发就不写了，写了这些IAA产品最关心的留存+event足够，自己设计BI的难点其实可能是大量数据的整理分析，存储，还要保证自己算数据的时候的查询效率等等。技术上也要同时考虑老用户，新用户不断产生的events之类的数据统计，数据查询时间长后估计服务器计算量也蛮大的。