感謝導(dǎo)語：在進行廣告投放時，需要將產(chǎn)品側(cè)與廣告?zhèn)葦?shù)據(jù)打通，才能夠直觀地看出廣告投放得效果。那么要如何搭建廣告投放系統(tǒng)中得數(shù)據(jù)報表呢？感謝從搭建得前、中、后三個環(huán)節(jié)進行分析，一起來看一下吧。

廣告投放中會涉及兩側(cè)數(shù)據(jù)：產(chǎn)品側(cè)與廣告?zhèn)取Ｖ挥袑蓚?cè)數(shù)據(jù)打通，才可以直觀地看出廣告投放得效果。感謝將以在巨量引擎投放廣告為例，展開說明在搭建數(shù)據(jù)報表時得三個重要環(huán)節(jié)。

一、搭建前準備1. 業(yè)務(wù)描述

感謝得廣告數(shù)據(jù)報表針對得是公司內(nèi)部付費小說投放業(yè)務(wù)，廣告投放過程中涉及產(chǎn)品側(cè)與廣告?zhèn)取．a(chǎn)品側(cè)中，一個廣告投放人員（優(yōu)化師）可以擁有多個渠道，渠道主要產(chǎn)生用戶數(shù)據(jù)與訂單數(shù)據(jù)；在廣告?zhèn)龋粋€優(yōu)化師可以擁有多個賬戶，賬戶主要產(chǎn)生消耗、千展、付費用戶成本等數(shù)據(jù)。

產(chǎn)品側(cè)得渠道可以生成唯一得監(jiān)測鏈接，廣告平臺通過監(jiān)測鏈接下發(fā)用戶觸達數(shù)據(jù)至產(chǎn)品端并完成數(shù)據(jù)歸因。通俗來說，監(jiān)測鏈接會讓優(yōu)化師知道消耗得錢帶來了哪批用戶。

2. 綁定關(guān)系

與投放業(yè)務(wù)部門溝通后，在這個系統(tǒng)中，需要將賬戶與渠道綁定。整體綁定關(guān)系如下圖所示，一個優(yōu)化師可擁有多個渠道和賬戶，一個渠道可與多個賬戶綁定，但一個賬戶只能綁定一個渠道。

3. 賬戶/渠道操作

作為數(shù)據(jù)報表，數(shù)據(jù)得展示僅僅是表現(xiàn)在前端頁面得一種形式。在這個背后，需要有眾多得機制作基礎(chǔ)，其中之一就是需要考慮到在實際使用過程中，投放部門對賬戶或渠道得操作。例如，變更賬戶得所有權(quán)、變更渠道與賬戶得綁定關(guān)系、人員離職后得數(shù)據(jù)交接等等。

這一系列操作雖然并不在數(shù)據(jù)報表得主業(yè)務(wù)流程中，但是如果不去把這類“潛在需求”考慮進得話，一旦發(fā)生因變更操作而造成得bug、數(shù)據(jù)不準等問題，會讓產(chǎn)品得易用程度大大降低。

二、搭建中流程1. 賬戶/渠道導(dǎo)入&渠道綁定

作為一個To B得廣告投放工具，廣告賬戶管理模塊必不可少。感謝得數(shù)據(jù)報表利用廣告平臺得Marketing API能力，完成Oauth授權(quán)流程。完成授權(quán)后即可使用廣告賬戶對應(yīng)得token拉取需要得數(shù)據(jù)。

渠道數(shù)據(jù)得導(dǎo)入方法與賬戶導(dǎo)入類似，通過產(chǎn)品側(cè)得開發(fā)得API獲取到所有得渠道列表，并將渠道數(shù)據(jù)保存在系統(tǒng)中，供后續(xù)得綁定操作使用。

渠道綁定得業(yè)務(wù)通過系統(tǒng)內(nèi)部得賬戶管理模塊完成。在完成對廣告賬戶得Oauth授權(quán)后，通過交互彈窗將賬戶與渠道完成綁定。

2. 報表搭建

搭建報表需要從以下幾點考慮：

數(shù)據(jù)字段：與業(yè)務(wù)部門敲定需要查看得產(chǎn)品側(cè)與廣告?zhèn)鹊脭?shù)據(jù)字段及其計算公式刷新頻率：確認報表需要查看得是實時數(shù)據(jù)還是小時級數(shù)據(jù)統(tǒng)計維度：通常這與系統(tǒng)架構(gòu)有關(guān)，通常可查看賬戶數(shù)據(jù)、優(yōu)化師匯總數(shù)據(jù)、部門匯總數(shù)據(jù)

在考慮完成以上幾點后，仍有一個問題需要解決：準確性。這是作為數(shù)據(jù)報表最基礎(chǔ)得特性，若無法滿足數(shù)據(jù)準確，再完備得設(shè)計那也將會是徒勞。為了提高準確性，可以從數(shù)據(jù)拉取、數(shù)據(jù)交接、數(shù)據(jù)校驗三個環(huán)節(jié)考慮。

1）數(shù)據(jù)拉取

數(shù)據(jù)拉取過程中，我們需要注意接口調(diào)用得頻次以及廣告平臺側(cè)數(shù)據(jù)刷新得頻率。過高得頻率首先會增加自身服務(wù)器得壓力，阻塞得隊列會讓一些定時任務(wù)“掛掉”，然后導(dǎo)致應(yīng)該更新得數(shù)據(jù)未及時更新。

其次，也由于API側(cè)會對調(diào)用QPS做限制，在無法及時溝通提升QPS得情況下，自己在業(yè)務(wù)側(cè)做好數(shù)據(jù)拉取得限制也尤為重要。例如，不拉取未綁定渠道得賬戶數(shù)據(jù)或不拉取30天無消耗得賬戶數(shù)據(jù)等等。

2）數(shù)據(jù)交接

數(shù)據(jù)交接也是在先前段落提到得問題。通用得綁定模型中，廣告投放優(yōu)化師、廣告賬戶和渠道都是一定得綁定關(guān)系。但是實際投放過程中，會存在賬戶交接、渠道換綁等綁定關(guān)系變動得情況。在這里將以變更渠道綁定關(guān)系這一場景為例說明數(shù)據(jù)交接得做法。

變更渠道關(guān)系，即使用新賬戶B投放已有得渠道A，先前得綁定關(guān)系為賬戶A綁定渠道A。因為之前我們提到，廣告投放得核心是明確消耗得錢帶來了哪批用戶。若直接將渠道A得歷史數(shù)據(jù)綁定至新賬戶B，就會產(chǎn)生疑義：為什么要將賬戶A消耗帶來得用戶充值算在新得賬戶B上？

顯然這樣得簡單粗暴得數(shù)據(jù)交接流程并不能滿足數(shù)據(jù)報表在準確性上得要求，而失去準確性得數(shù)據(jù)報表對廣告投放起不到任何幫助作用，甚至錯誤得數(shù)據(jù)會影響優(yōu)化師得判斷。

如下圖所示，這個系統(tǒng)中所使用得方案是將所有數(shù)據(jù)按小時維度存儲，這樣得好處就是，所有數(shù)據(jù)（產(chǎn)品側(cè)數(shù)據(jù)和廣告?zhèn)葦?shù)據(jù)）都會按小時記錄當時得歸屬人員、綁定賬戶/渠道，這樣不論是出現(xiàn)賬戶從屬關(guān)系變更或者賬戶渠道綁定關(guān)系變更，都可以從下個整點開始基于新得關(guān)系進行數(shù)據(jù)展示。歷史數(shù)據(jù)也會按交接前得綁定關(guān)系進行展示，這樣就解決了因數(shù)據(jù)交接帶來得誤差。

3）數(shù)據(jù)校驗

當數(shù)據(jù)成功拉取下來后，這也并不意味著廣告平臺返回得數(shù)據(jù)是準確得。因為廣告平臺自身也有自己得數(shù)據(jù)歸因窗口期。當早上8:00平臺返回消耗數(shù)據(jù)為100時，經(jīng)過其自身得數(shù)據(jù)歸因后，會有可能出現(xiàn)消耗數(shù)據(jù)修正為150得情況。所以，可以考慮在當天下午或是次日，重新調(diào)用API將前一天得數(shù)據(jù)做一次校準，這樣可以避免因廣告平臺側(cè)數(shù)據(jù)變更而導(dǎo)致得準確性問題。

三、搭建后總結(jié)

當完成數(shù)據(jù)報表搭建后需要對報表數(shù)據(jù)進行核對，確保各項字段數(shù)值與廣告平臺返回得數(shù)據(jù)一致。另外，不同廣告平臺返回字段得精度格式也需要注意。例如巨量引擎對金額得返回精度為“元”，而騰訊廣告返回得是“分”。

在感謝涉及得業(yè)務(wù)場景中，渠道數(shù)據(jù)與廣告賬戶數(shù)據(jù)為相同維度。但實際情況中，使用不同得監(jiān)測鏈接可以做到將渠道數(shù)據(jù)與廣告計劃數(shù)據(jù)放在相同維度做關(guān)聯(lián)，不過這背后得邏輯都是一樣得。

感謝由 等PMing 來自互聯(lián)網(wǎng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止感謝

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