媒體渠道的“廣告投放轉化”數據回傳API,對接需求怎么寫?
本文將以某款金融產品對接快手廣告平臺為例,介紹廣告主商業產品經理的入門級需求策劃任務——對接廣告平臺的標準接口,把轉化數據準確上報。
一款有強變現能力的產品(比如金融、游戲、電商),免不了在各種媒體渠道投放廣告(比如快手、頭條、抖音)。而從用戶點擊廣告到下載、注冊、登錄、付費等一系列關鍵行為轉化的數據統計,一方面關系到廣告結費,另一方面也可以分析廣告投放效果、及時調整策略縮減成本提升轉化率。
但是,媒體方只有用戶點擊廣告的數據,投放廣告的廣告主也只有自身產品相關的轉化數據,要做到整體漏斗的統計分析,就需要整合雙方數據,許多廣告平臺應運而生(比如鳳巢、廣點通、多彩互動)。廣告主商業產品經理的入門級需求策劃任務,就是要對接廣告平臺的標準接口,把轉化數據準確上報。
需要注意的是,媒體方和廣告主不會共用一套賬戶體系,如何把一個用戶在兩端產生的數據匹配到一起就大有文章:
- 首先,手機號是最為準確的匹配字段,如果媒體方和廣告主的賬號綁定的是同一個手機號,就可以認定這是同一個用戶,數據可統一歸集。
- 然而,不是所有的媒體渠道都需要用戶注冊登錄,一些游客也會點擊廣告帶來轉化。這時,安卓的IMEI設備號、蘋果的IDFA設備號就有了用武之地,即時你沒有注冊賬號,但你手機的設備號總不會變,如果媒體方和廣告主采集的行為數據對應的設備號是一致的,那也可匹配上兩端的數據。
- 可是這樣也不能100%解決問題,有些用戶并不會授權給客戶端獲取它的設備號,那就壓根拿不到他的IMEI和IDFA。不過,我們還有手機的MAC網卡地址、Android下的AndroidID、IP地址等可以用來匹配用戶身份的字段??傮w來說,IMEI和IDFA的采集率最高,其它匹配方式可作為備選或補充。(其實,IMEI和IDFA之外的字段媒體方也不一定會采集、廣告平臺接口也不一定會提供)
(以某款金融產品對接快手廣告平臺為例)
一、業務概述
1.1?背景
****、***在快手信息流投放缺少轉化數據統計分析,轉化量及成本有優化空間。
如下表所示,從歷史數據來看對接轉化數據回傳API,收益明顯。
另外,需求實施的前置條件是達標的設備號獲取率,經調研已滿足要求:
- 快手的IMEI和IDFA獲取率95%左右;
- APP客戶端優化于5月7日上線:V*.*.*版本(****)的IMEI獲取率為91.53%,V*.*.*版本(***)的IMEI獲取率為91.21%,達到預期要求;
- ****和***的IDFA抓取率在98%以上。
1.2 目標
如下表所示,通過本次對接轉化數據回傳API,實現****、***在快手信息流投放的量級增長、成本降低。
1.3?業務主流程示意圖
- 快手用戶點擊快手客戶端展示的廣告。
- 快手客戶端請求廣告平臺中設置的監測鏈接(廣告主自行開發或者托管第三方監測平臺),通過宏替換的方式把點擊數據詳細信息實時同步給廣告主或者第三方監測平臺(具體見接口一)。
- 廣告主或者第三方監測平臺接收到快手接口一上報的點擊請求后,記錄請求參數中的用戶信息(例如用戶的IDFA-MD5、IMEI-MD5等)和callback信息,后續從產生相關轉化的用戶中,匹配出由快手推廣渠道帶來的用戶及其轉化數據。
- 廣告主或者第三方監測平臺將匹配出的轉化數據,通過請求相應的callback通知快手效果統計服務器(具體見接口二)。
- 快手效果統計服務器將接收到的轉化信息和廣告點擊數據匹配,在投放平臺報表中披露出對應廣告計劃-廣告組-廣告創意的轉化數據。
1.4?名詞解釋
1.4.1?廣告主
本次對接快手API,****、***兩款產品流程、需求一致,統稱為在快手媒體渠道投放信息流廣告的“廣告主”。
1.4.2?新增注冊
用戶手機號本次注冊是首次注冊,對于同一個手機號****和***是獨立分開的,即同一個手機號可以在****和***各新增注冊一次。
1.4.3?廣告點擊
當快手用戶點擊廣告可互動區域時,觸發點擊事件,該事件被認為是一次有效的廣告點擊。進入指定落地頁后點擊內部相關鏈接等行為,不算作點擊。
1.4.4?轉化數
快手后臺報表中展現的轉化數據,時間上以快手服務器收到回調請求的時間為準,量級上以客戶實際上報請求數為準。
二、API對接流程
2.1?流程圖
作為廣告主,****、***對接快手API的流程分為記錄點擊用戶的設備號相關信息、新增注冊用戶判斷、獲取注冊用戶的設備號相關信息、設備號匹配、發送注冊用戶的設備號相關信息5個環節。
需要注意的是,記錄點擊用戶的設備號相關信息對其它4個環節來說是異步的、前置的。
2.2?流程說明
2.2.1?記錄點擊用戶的設備號相關信息
1. 快手客戶端請求點擊監測URL(廣告主預先在快手廣告平臺設置),把用戶點擊數據詳細信息實時通過接口一同步給廣告主服務端;
2. 廣告主服務端接收到快手接口一上報的點擊請求后,記錄請求參數中的用戶信息,其中包括用戶的IDFA-MD5或IMEI-MD5、用戶點擊廣告的AID、CID、DID和DNAME、用戶點擊廣告的時間TS和callback信息;(參數說明如下表)
需要額外說明的是,用戶每一次點擊行為都會上報,都需要完整記錄參數信息;
其中:
- www.example.com是廣告主接收點擊上報數據的地址,需服務端給出
- channel=kuaishou是廣告主自定義用來區分渠道的參數信息,快手上報時原樣返回,不做任何修改
- channel/aid/cid/did/dname/ts/idfaMD5/imeiMD5/callback這幾個參數名稱僅作為參考,最終使用的參數名稱可由服務端自行設定
- __CALLBACK__為必填參數,快手客戶端在上報的時候會替換成http形式的地址(已編碼一次),廣告主在接收到上報數據后,需要保存該地址,當用戶在應用內完成注冊時,請求該地址來上報轉化數據(需要拼接相應參數)。
4. 響應要求:響應方式為JSON數據格式,HTTP標準狀態碼,響應內容不做要求。
2.2.2?新增注冊用戶判斷
- 用戶首次登錄APP,廣告主服務端判斷用戶是否為新增注冊的用戶,若用戶不是新增注冊則流程結束;
- 若用戶本次是新增注冊,則廣告主服務端獲取該用戶安裝來源的注冊渠道號,若獲取的注冊渠道號不是快手渠道號(****、***的快手渠道號詳見附件《快手&**渠道號》),則流程結束;
- 若獲取的注冊渠道號是快手渠道號,則流程進入下一環節2.2.3.。
2.2.3?獲取注冊用戶的設備號相關信息
經過廣告主服務端判斷,通過快手信息流渠道下載APP且為新增注冊的用戶通過篩選。
針對這一部分用戶,獲取他們的MD5加密后的設備ID、用戶注冊時間兩個字段信息,若獲取失敗則流程結束,若獲取成功則流程進入下一環節2.2.4。
其中:
- 安卓imei雙卡手機可能有兩個,取默認的一個
- iOS下的idfa計算MD5,規則為32位十六進制數字+4位連接符“-”的原文(比如:32ED3EE5-9968-4F25-A015-DE3CFF569568),再計算MD5,再轉大寫
- 用戶注冊時間需為13位毫秒級時間戳
2.2.4?設備號匹配
將獲取到的注冊用戶MD5加密設備號與2.2.1.記錄的點擊用戶的MD5加密設備號進行匹配,具體匹配規則為:注冊用戶的MD5加密設備號存在于點擊用戶的MD5加密設備號名單中,且最近一次的點擊行為發生在注冊前7天之內(天數可配置)視為匹配成功,否則為不成功。
若匹配不成功則流程結束,若匹配成功則進入下一環節2.2.5。
2.2.5?發送注冊用戶的設備號相關信息
1. 發送地址:廣告主通過接口一接收的注冊前7天內最近一次點擊行為的__CALLBACK__替換后的http地址(需要拼接相應參數);
2. 需要拼接的參數:
- event_type,事件類型,參數值回傳2,含義是轉化事件為注冊
- event_time,事件時間,13位毫秒級時間戳(若請求中攜帶event_type參數,則必須同時攜帶event_time參數,否則報錯)
- callback,接口一接收的__CALLBACK__替換后的http地址中的callback參數(參考下方示例中標紅處)
3. 回調的請求URL(接口一中__CALLBACK__的對應值,鏈接地址Decode后再拼接相關參數)點擊查看示例(“callback=”后字段的字符每次都會不同)
4. 響應內容:回調后response里的result=1代表回調請求上報成功。
2.3?時序說明
三、其他說明
3.1?異常處理
若接口二響應異常,廣告主最多上報3次同一條應用內轉化數據;如果發送仍失敗,則放棄本次發送,并記錄異常日志。
3.2?異常報警
廣告主上報應用內轉化數據到快手廣告平臺,采用即時策略,如果連續3次同一條應用內轉化數據發送失敗,就短信或郵件報警提醒到相應人員,每天最多發送一次報警,具體發送名單如下:
姓名***,手機號**********,郵箱**********
3.3?數據需求
需要記錄注冊轉化用戶設備號相關信息的發送、響應數據,具體需求字段如下:
? channel:渠道
? aid:廣告組id
? cid:廣告創意ID
? did:廣告計劃Id
? dname:廣告計劃名稱
? dt:廣告點擊事件發生的UTC時間戳
? idfaMD5:iOS下的idfa計算MD5
? imeiMD5:對15位數字的IMEI進行MD5
? event_type:轉化事件類型
? event_time:轉化事件時間
? sendNumber:第幾次發送(1~3)
? sendTime:發送時間
? returnCode:返回碼
? returnTime:返回時間
3.4?信息資料
3.4.1?快手廣告平臺轉化數據API文檔v1.4
3.4.2 快手&**渠道號?
本文由 @魚缸外的魚 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
大佬
有這方面的業務系統需求嗎?我有完整的買量(主要國內媒體)系統方案
暈 你這個流程很有問題,怎么能先判斷渠道號再匹配點擊呢? 那被廠商劫持的量怎么辦? 要是按照你這種來做的話 那信息流渠道直接沒法做了。。
應該怎么做呢,感覺你懂。。。
我是單純學習
方便加V交流一下嗎 18718653506
大神,加微 18676888829 高報酬求解決API對接
頭條文章推廣
求交流 加微信 18801014985
加微信 263423280 高報酬解決對接
還需要嗎
求個通訊,想交流一下
作者方便留下微信號嗎,近期在開展類似的業務,希望能夠交流下
請問您提到的兩款產品在快手的ROI如何?
我特意打碼了你還問。。 ?? ??
老鐵 高報酬解決API 對接 兼職做的 加微信263423280