本文將以某款金融產(chǎn)品對接快手廣告平臺為例，介紹廣告主商業(yè)產(chǎn)品經(jīng)理的入門級需求策劃任務(wù)——對接廣告平臺的標準接口，把轉(zhuǎn)化數(shù)據(jù)準確上報。

一款有強變現(xiàn)能力的產(chǎn)品（比如金融、游戲、電商），免不了在各種媒體渠道投放廣告（比如快手、頭條、抖音）。而從用戶點擊廣告到下載、注冊、登錄、付費等一系列關(guān)鍵行為轉(zhuǎn)化的數(shù)據(jù)統(tǒng)計，一方面關(guān)系到廣告結(jié)費，另一方面也可以分析廣告投放效果、及時調(diào)整策略縮減成本提升轉(zhuǎn)化率。

但是，媒體方只有用戶點擊廣告的數(shù)據(jù)，投放廣告的廣告主也只有自身產(chǎn)品相關(guān)的轉(zhuǎn)化數(shù)據(jù)，要做到整體漏斗的統(tǒng)計分析，就需要整合雙方數(shù)據(jù)，許多廣告平臺應(yīng)運而生（比如鳳巢、廣點通、多彩互動）。廣告主商業(yè)產(chǎn)品經(jīng)理的入門級需求策劃任務(wù)，就是要對接廣告平臺的標準接口，把轉(zhuǎn)化數(shù)據(jù)準確上報。

需要注意的是，媒體方和廣告主不會共用一套賬戶體系，如何把一個用戶在兩端產(chǎn)生的數(shù)據(jù)匹配到一起就大有文章：

1. 首先，手機號是最為準確的匹配字段，如果媒體方和廣告主的賬號綁定的是同一個手機號，就可以認定這是同一個用戶，數(shù)據(jù)可統(tǒng)一歸集。
2. 然而，不是所有的媒體渠道都需要用戶注冊登錄，一些游客也會點擊廣告帶來轉(zhuǎn)化。這時，安卓的IMEI設(shè)備號、蘋果的IDFA設(shè)備號就有了用武之地，即時你沒有注冊賬號，但你手機的設(shè)備號總不會變，如果媒體方和廣告主采集的行為數(shù)據(jù)對應(yīng)的設(shè)備號是一致的，那也可匹配上兩端的數(shù)據(jù)。
3. 可是這樣也不能100%解決問題，有些用戶并不會授權(quán)給客戶端獲取它的設(shè)備號，那就壓根拿不到他的IMEI和IDFA。不過，我們還有手機的MAC網(wǎng)卡地址、Android下的AndroidID、IP地址等可以用來匹配用戶身份的字段?？傮w來說，IMEI和IDFA的采集率最高，其它匹配方式可作為備選或補充。（其實，IMEI和IDFA之外的字段媒體方也不一定會采集、廣告平臺接口也不一定會提供）

（以某款金融產(chǎn)品對接快手廣告平臺為例）

一、業(yè)務(wù)概述

1.1?背景

****、***在快手信息流投放缺少轉(zhuǎn)化數(shù)據(jù)統(tǒng)計分析，轉(zhuǎn)化量及成本有優(yōu)化空間。

如下表所示，從歷史數(shù)據(jù)來看對接轉(zhuǎn)化數(shù)據(jù)回傳API，收益明顯。

另外，需求實施的前置條件是達標的設(shè)備號獲取率，經(jīng)調(diào)研已滿足要求：

1. 快手的IMEI和IDFA獲取率95%左右；
2. APP客戶端優(yōu)化于5月7日上線：V*.*.*版本（****）的IMEI獲取率為91.53%，V*.*.*版本（***）的IMEI獲取率為91.21%，達到預(yù)期要求；
3. ****和***的IDFA抓取率在98%以上。

1.2 目標

如下表所示，通過本次對接轉(zhuǎn)化數(shù)據(jù)回傳API，實現(xiàn)****、***在快手信息流投放的量級增長、成本降低。

1.3?業(yè)務(wù)主流程示意圖

1. 快手用戶點擊快手客戶端展示的廣告。
2. 快手客戶端請求廣告平臺中設(shè)置的監(jiān)測鏈接（廣告主自行開發(fā)或者托管第三方監(jiān)測平臺），通過宏替換的方式把點擊數(shù)據(jù)詳細信息實時同步給廣告主或者第三方監(jiān)測平臺（具體見接口一）。
3. 廣告主或者第三方監(jiān)測平臺接收到快手接口一上報的點擊請求后，記錄請求參數(shù)中的用戶信息（例如用戶的IDFA-MD5、IMEI-MD5等）和callback信息，后續(xù)從產(chǎn)生相關(guān)轉(zhuǎn)化的用戶中，匹配出由快手推廣渠道帶來的用戶及其轉(zhuǎn)化數(shù)據(jù)。
4. 廣告主或者第三方監(jiān)測平臺將匹配出的轉(zhuǎn)化數(shù)據(jù)，通過請求相應(yīng)的callback通知快手效果統(tǒng)計服務(wù)器（具體見接口二）。
5. 快手效果統(tǒng)計服務(wù)器將接收到的轉(zhuǎn)化信息和廣告點擊數(shù)據(jù)匹配，在投放平臺報表中披露出對應(yīng)廣告計劃-廣告組-廣告創(chuàng)意的轉(zhuǎn)化數(shù)據(jù)。

1.4?名詞解釋

1.4.1?廣告主

本次對接快手API，****、***兩款產(chǎn)品流程、需求一致，統(tǒng)稱為在快手媒體渠道投放信息流廣告的“廣告主”。

1.4.2?新增注冊

用戶手機號本次注冊是首次注冊，對于同一個手機號****和***是獨立分開的，即同一個手機號可以在****和***各新增注冊一次。

1.4.3?廣告點擊

當快手用戶點擊廣告可互動區(qū)域時，觸發(fā)點擊事件，該事件被認為是一次有效的廣告點擊。進入指定落地頁后點擊內(nèi)部相關(guān)鏈接等行為，不算作點擊。

1.4.4?轉(zhuǎn)化數(shù)

快手后臺報表中展現(xiàn)的轉(zhuǎn)化數(shù)據(jù)，時間上以快手服務(wù)器收到回調(diào)請求的時間為準，量級上以客戶實際上報請求數(shù)為準。

二、API對接流程

2.1?流程圖

作為廣告主，****、***對接快手API的流程分為記錄點擊用戶的設(shè)備號相關(guān)信息、新增注冊用戶判斷、獲取注冊用戶的設(shè)備號相關(guān)信息、設(shè)備號匹配、發(fā)送注冊用戶的設(shè)備號相關(guān)信息5個環(huán)節(jié)。

需要注意的是，記錄點擊用戶的設(shè)備號相關(guān)信息對其它4個環(huán)節(jié)來說是異步的、前置的。

2.2?流程說明

2.2.1?記錄點擊用戶的設(shè)備號相關(guān)信息

1. 快手客戶端請求點擊監(jiān)測URL（廣告主預(yù)先在快手廣告平臺設(shè)置），把用戶點擊數(shù)據(jù)詳細信息實時通過接口一同步給廣告主服務(wù)端；

2. 廣告主服務(wù)端接收到快手接口一上報的點擊請求后，記錄請求參數(shù)中的用戶信息，其中包括用戶的IDFA-MD5或IMEI-MD5、用戶點擊廣告的AID、CID、DID和DNAME、用戶點擊廣告的時間TS和callback信息；（參數(shù)說明如下表）

需要額外說明的是，用戶每一次點擊行為都會上報，都需要完整記錄參數(shù)信息；

3. 點擊監(jiān)測URL的iOS格式

點擊監(jiān)測URL的Android格式

其中：

• www.example.com是廣告主接收點擊上報數(shù)據(jù)的地址，需服務(wù)端給出
• channel=kuaishou是廣告主自定義用來區(qū)分渠道的參數(shù)信息，快手上報時原樣返回，不做任何修改
• channel/aid/cid/did/dname/ts/idfaMD5/imeiMD5/callback這幾個參數(shù)名稱僅作為參考，最終使用的參數(shù)名稱可由服務(wù)端自行設(shè)定
• __CALLBACK__為必填參數(shù)，快手客戶端在上報的時候會替換成http形式的地址（已編碼一次），廣告主在接收到上報數(shù)據(jù)后，需要保存該地址，當用戶在應(yīng)用內(nèi)完成注冊時，請求該地址來上報轉(zhuǎn)化數(shù)據(jù)（需要拼接相應(yīng)參數(shù)）。

4. 響應(yīng)要求：響應(yīng)方式為JSON數(shù)據(jù)格式，HTTP標準狀態(tài)碼，響應(yīng)內(nèi)容不做要求。

2.2.2?新增注冊用戶判斷

1. 用戶首次登錄APP，廣告主服務(wù)端判斷用戶是否為新增注冊的用戶，若用戶不是新增注冊則流程結(jié)束；
2. 若用戶本次是新增注冊，則廣告主服務(wù)端獲取該用戶安裝來源的注冊渠道號，若獲取的注冊渠道號不是快手渠道號（****、***的快手渠道號詳見附件《快手&**渠道號》），則流程結(jié)束；
3. 若獲取的注冊渠道號是快手渠道號，則流程進入下一環(huán)節(jié)2.2.3.。

2.2.3?獲取注冊用戶的設(shè)備號相關(guān)信息

經(jīng)過廣告主服務(wù)端判斷，通過快手信息流渠道下載APP且為新增注冊的用戶通過篩選。

針對這一部分用戶，獲取他們的MD5加密后的設(shè)備ID、用戶注冊時間兩個字段信息，若獲取失敗則流程結(jié)束，若獲取成功則流程進入下一環(huán)節(jié)2.2.4。

其中：

• 安卓imei雙卡手機可能有兩個，取默認的一個
• iOS下的idfa計算MD5，規(guī)則為32位十六進制數(shù)字+4位連接符“-”的原文（比如：32ED3EE5-9968-4F25-A015-DE3CFF569568），再計算MD5，再轉(zhuǎn)大寫
• 用戶注冊時間需為13位毫秒級時間戳

2.2.4?設(shè)備號匹配

將獲取到的注冊用戶MD5加密設(shè)備號與2.2.1.記錄的點擊用戶的MD5加密設(shè)備號進行匹配，具體匹配規(guī)則為：注冊用戶的MD5加密設(shè)備號存在于點擊用戶的MD5加密設(shè)備號名單中，且最近一次的點擊行為發(fā)生在注冊前7天之內(nèi)（天數(shù)可配置）視為匹配成功，否則為不成功。

若匹配不成功則流程結(jié)束，若匹配成功則進入下一環(huán)節(jié)2.2.5。

2.2.5?發(fā)送注冊用戶的設(shè)備號相關(guān)信息

1. 發(fā)送地址：廣告主通過接口一接收的注冊前7天內(nèi)最近一次點擊行為的__CALLBACK__替換后的http地址（需要拼接相應(yīng)參數(shù)）；

2. 需要拼接的參數(shù)：

• event_type，事件類型，參數(shù)值回傳2，含義是轉(zhuǎn)化事件為注冊
• event_time，事件時間，13位毫秒級時間戳（若請求中攜帶event_type參數(shù)，則必須同時攜帶event_time參數(shù)，否則報錯）
• callback，接口一接收的__CALLBACK__替換后的http地址中的callback參數(shù)（參考下方示例中標紅處）

3. 回調(diào)的請求URL（接口一中__CALLBACK__的對應(yīng)值，鏈接地址Decode后再拼接相關(guān)參數(shù)）點擊查看示例（“callback=”后字段的字符每次都會不同）

4. 響應(yīng)內(nèi)容：回調(diào)后response里的result=1代表回調(diào)請求上報成功。

2.3?時序說明

三、其他說明

3.1?異常處理

若接口二響應(yīng)異常，廣告主最多上報3次同一條應(yīng)用內(nèi)轉(zhuǎn)化數(shù)據(jù)；如果發(fā)送仍失敗，則放棄本次發(fā)送，并記錄異常日志。

3.2?異常報警

廣告主上報應(yīng)用內(nèi)轉(zhuǎn)化數(shù)據(jù)到快手廣告平臺，采用即時策略，如果連續(xù)3次同一條應(yīng)用內(nèi)轉(zhuǎn)化數(shù)據(jù)發(fā)送失敗，就短信或郵件報警提醒到相應(yīng)人員，每天最多發(fā)送一次報警，具體發(fā)送名單如下：

姓名***，手機號**********，郵箱**********

3.3?數(shù)據(jù)需求

需要記錄注冊轉(zhuǎn)化用戶設(shè)備號相關(guān)信息的發(fā)送、響應(yīng)數(shù)據(jù)，具體需求字段如下：

? channel：渠道

? aid：廣告組id
? cid：廣告創(chuàng)意ID

? did：廣告計劃Id

? dname：廣告計劃名稱

? dt：廣告點擊事件發(fā)生的UTC時間戳

? idfaMD5：iOS下的idfa計算MD5

? imeiMD5：對15位數(shù)字的IMEI進行MD5

? event_type：轉(zhuǎn)化事件類型

? event_time：轉(zhuǎn)化事件時間

? sendNumber：第幾次發(fā)送（1~3）

? sendTime：發(fā)送時間

? returnCode：返回碼

? returnTime：返回時間

3.4?信息資料

3.4.1?快手廣告平臺轉(zhuǎn)化數(shù)據(jù)API文檔v1.4
3.4.2 快手&**渠道號?

本文由 @魚缸外的魚 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash ，基于 CC0 協(xié)議