之前做sdk毕荐，才做了不到一個月东跪，視頻部分還沒做好，然后領(lǐng)導(dǎo)說要做深度鏈接廣告api虽填，讓我ios開發(fā)確定api與sdk交互的參數(shù)斋日，確定api與廣告主交互流程，包括數(shù)據(jù)跟蹤第献。國內(nèi)沒有做專門的深度鏈接的api兔港，大部分做的是
雖然一些sdk，廣點(diǎn)通飒赃、穿山甲等包含深度鏈接科侈，但是不是只做深度鏈接臀栈。重點(diǎn)是不是api，百度有api包含深度鏈接权薯，但卻不是cpa，不是以效果收費(fèi)的肋联。我們要做cpa橄仍，這種是跪舔廣告主的模式。盡管我只是一個移動端侮繁，領(lǐng)導(dǎo)給我的任務(wù)不是十分貼切我的職責(zé)宪哩，但我還是做了，自認(rèn)為還可以彬祖，就貼出來分享品抽。
這是與sdk交互所需要傳的參數(shù)：
這是整個流程圖
其中2.4如果廣告主不支持調(diào)api對效果實(shí)時匯報突倍，而是一天的數(shù)據(jù)匯總后分發(fā)盆昙，也可以省去2.4，我們拿到匯總數(shù)據(jù)后秕磷，再與sdk上報數(shù)據(jù)對比炼团。我們api對接多個廣告主们镜，多個sdk润歉，每一個流程都是這樣。之所以加上時間也方便與下游adk根據(jù)iemi去給各個渠道的sdk分配數(shù)據(jù)嚼鹉，有可能一天中，同一個設(shè)備锚赤，通過多個sdk线脚，同一個廣告主的廣告被喚醒了兩次以上。也好分配數(shù)據(jù)浑侥，如果廣告主以一天一個設(shè)備只支付一次喚醒的費(fèi)用寓落，也好區(qū)分誰先誰后。在這個效果追蹤分發(fā)下游sdk上伶选，我是建議用時間+imei去給各sdk分配計費(fèi)的數(shù)據(jù)仰税，廣告主在深度鏈接里一定要加上我們的渠道id，如果可以加上下游sdk渠道的參數(shù)蚯窥，我們更容易對下游分發(fā)數(shù)據(jù)塞帐。
以上是Android的流程，ios如果沒有idfa荷鼠，以ip+ua為唯一標(biāo)識榔幸。友盟U-ADPlus里廣告主只能監(jiān)測數(shù)據(jù)的sdk里沒有深度鏈接喚醒監(jiān)測。國內(nèi)深度鏈接喚醒整個體系還不成熟牍疏。廣告主也沒有形成規(guī)范拨齐，API也沒有一個規(guī)范瞻惋，尤其是對效果數(shù)據(jù)的計費(fèi)統(tǒng)計規(guī)則，廣告主的數(shù)據(jù)的可靠性的保證掏导，因?yàn)橄裼衙诉@樣的第三方平臺還沒有提供喚醒監(jiān)測統(tǒng)計趟咆，畢竟第三方中立的平臺作為數(shù)據(jù)的統(tǒng)計，可以讓api與廣告主都放心仰坦。如果沒有三方平臺计雌，廣告主的數(shù)據(jù)有作假扣量的嫌疑，畢竟模式是cpa妈橄，所以需要sdk方的數(shù)據(jù)對比翁脆，在合理誤差范圍內(nèi)是可以接受的，比如超過10%的誤差沙热，則需要聯(lián)調(diào)了罢缸。如果廣告主沒有在app里埋點(diǎn)進(jìn)行數(shù)據(jù)統(tǒng)計枫疆，那么只能以sdk的統(tǒng)計數(shù)據(jù)作為依據(jù)了，然后乘以誤差范圍的系數(shù)定價寝贡。
