最近好久没有写文章了，主要是因为太忙了最近，加上前段时间生病了，没有时间学习，最近在做广告的投放，出了蛮多岔子的，总结一下吧。
首先介绍一下前置知识吧，对于ios 和 android 手机的标识。ios手机现在一般用idfa， 但是用户可以关闭广告追踪，那我们获取到的就是一堆 0000-000··这样乱七八糟的东西，毫无价值，为了实验效果，我们一定要开启ios手机的广告追踪。（怎么快速获取当前手机的idfa，可以在appstore中下载一个myidfa,可以快速获取到，注意字母都是大写）。所以要是苹果手机用户关闭了广告跟踪，那么我们就完全追踪不到点击广告的用户信息了，广告的转化率我们必然
android 手机五花八门，之前一般都是用的imei ，然后有的手机可能还有多个，目前没有考虑很多的情况，都是取的默认的第一个。但现在imei好像逐渐开始也获取不到了，国内的手机一般用的都建议用oaid，据说覆盖量已经 80%以上（但是oaid是国内手机联盟定的东西，像海外的安卓机器是没有的，而且现在识货android客户端也是不支持回传oaid的）
主要流程：当我们app（识货）在头条（或者朋友圈）上面投放广告的时候，当用户点击我们投放的广告，会给我们的web server发送一条请求，这个请求包括用户的基本信息，比如ios 的idfa 或者android 的imei,还有个call_back,类似标识这个用户信息是头条回传给我们的，我们拿到这个信息存储下来，当用户启动我们app的时候，我们可以把这个用户的信息（imei 或者 idfa）和 头条回传给我们的信息作比对，如果对应上，然后时间间隔在我们希望之内（比如两天），就可以当做这个用户是头条带来的。
头条
头条应该是接入的几个广告主中最简单的。头条是没有账号区分的（接口中让我们传入sign，但其实可以不用传），所以当我门投放部使用多账户进行广告投放，在我们代码中是没有影响的，我门只需要调用头条的上传用户行为的接口，传入设备信息和call_back 就好了。
坑点：
1.首先我们要区分开发者和广告主两个角色，开发者角色在这次广告对接中基本没啥用处，就是用来看开发者文档的。广告主角色很重要，因为我们配置好监控链接，联调上传行为的时候需要用广告主角色登陆后台管理界面，进行联调（填写头条用户id，然后刷新头条信息流，出现联调广告，点击，观察头条发起调用我们的url，我们可以直接拿这条url测试我们的监控接口是否正常，然后取出callback 和 idfa或者imei，作为参数调用头条的上传用户行为,这就是整个步骤啦，注意imei属于隐私数据，所以会用md5加密）
2.在我们联调的时候需要填写很多信息，比如下载链接，ios就是App Store我们应用的连接，android 需要我们上传apk到头条或者自己上传一个到七牛云，说白了，用户点击广告需要下载，我们给他们提供一个下载地址（好像不能用应用宝地址，因为腾讯？）
3.主要就是上面两个，剩下的就是代码设计方面，首先是对于表的设计，因为头条那边我们回传用户行为不需要去重，所以我们之前的代码中自己检测到属于头条带来的新用户直接就上报了，自己没做任何处理，比如记录日志，比如存表。这样带来一个坏处就是万一逻辑哪里出错了，不好排查，比如我们和bi那边做数据差异对比，完全拿不出证据证明这个用户在我们逻辑中属于新用户，为什么bi那边不算新用户，所以可以把用户的上报行为时间也存下来。
快手
快手和头条内容基本一致，就是快手不支持去重，只能我们这边自己去重，所以我们终究要保存下我们上传的用户信息，再次触发上报条件的时候，需要检测之前是否上报过。
（为什么我们会触发多次激活的上报条件？按理说不正常，但历史原因是识货这边在获取用户启动信息的list里面可能第一次没有获取到imei 或者idfa，这样用户虽然激活了，但是没法匹配到头条那边的点击广告信息，只能在第二次用户启动app的时候去激活）
快手比价坑的就是他的callback往往很长，··长的你不能想象，所以我们要注意数据库是否会自动截断。
广点通
广点通相比较上面二者更加复杂，首先就是多账户系统和开发者。
1.开发者需要把多账户（多个广告主）接通流程，首先开发者需要自己建立一个应用（这个应用不用区分ios 和 android ，目的就是获取一个appkey 和 appsecret, 这个信息在我们上传用户行为的时候需要，头条那边之前以为也需要，但是他那个sign 可以不传，所以这个应用可以不建立）
2.建立好应用之后就需要我们通过腾讯系老一套的oauth2.0 ，把广告主账户挂载在这个应用下面，因为应用需要获取我们的广告主信息，所以需要通过模拟第三方登陆，让我们应用获取到广告主的信息（比如accesstoken）,这个accesstoken 很重要，上传用户行为就靠他了。ps:这个accesstoken 有时间限制的，为了让他一直有效，我们需要通过refreshtoken 一直刷新accesstoken 的时间（感觉上就是类似redis 的set， 不断的刷新有效期，可以写个定时任务）
3.获取到accesstoken ，我们再建立用户行为，（但是激活和次留可以用一个行为id），然后把accesstoken ，行为id，事件回传就可以了
综上，其实各家广告厂商套路其实都差不多，我们提供给他们的广告连接都是可以加上我们自己的参数的，类似微信登陆我们在回调的时候对于scene字段传入我们自定义的值。我们可以利用这个值作为不同的投放计划名称，方便我们不同计划的统计，虽然头条他们本身也能传给我们计划名称。
各家公司对于ios 和 android 需要建立不同的计划，但是我们的检测链接可不需要，因为我们可以从他们回传的内容中获取到os,判断是android 还是 ios，而且毕竟是mysql，关系型数据库，我们只需要把它们返回的内容都保存就好了，有个例外就是快手不行，因为他们的回传内容中获取不到os，我们无法判断是android还是ios，（android 和 ios 匹配头条用户信息的逻辑不一样，所以要区分）难道通过idfa或者imei去判断，显然不保险，不如填写两条不同的检测链接，标识哪个是ios ，哪个是android。
