程序化廣告行業（55/89）：DMP與DSP對接及數據統計原理剖析

大家好呀！在數字化營銷的大趨勢下，程序化廣告已經成為眾多企業實現精準營銷的關鍵手段。上一篇博客我們一起學習了程序化廣告中的人群標簽和Look Alike原理等知識，今天咱們繼續深入探討程序化廣告領域的其他重要內容，包括DMP與DSP的對接，以及網站和App的數據統計原理。希望通過這次分享，能讓大家對程序化廣告有更全面的認識，一起在學習中進步，探索這個充滿機遇的行業。

一、DMP對接DSP：精準營銷的橋梁

在程序化廣告投放過程中，為了精準觸達目標人群，DSP（需求方平臺）常常需要借助廣告主的第一方DMP（數據管理平臺）和第三方DMP的人群數據，這就涉及到DMP與DSP之間的對接工作，這一環節對于實現精準營銷至關重要。

（一）PC人群與移動人群對接差異

對于PC人群對接，首先要進行cookie映射。這就好比給DSP和DMP雙方的人群標識ID建立一個“翻譯對照表”，讓它們能“讀懂”對方的數據。DSP投放的流量越大，能進行Cookie mapping的機會就越多。映射率越高，DSP識別的人群范圍就越大，這樣就能更充分地利用DMP數據，為廣告主找到更多精準的目標人群。想象一下，DSP就像一個尋找寶藏的探險家，DMP數據是寶藏地圖，而Cookie mapping就是讓地圖能被探險家看懂的密碼。

而移動人群對接則有所不同。由于設備號ID是固定的，并且可以在不同App中共享，所以不需要進行cookie映射工作。但是，需要先進行人群匹配度檢驗。人群匹配度指的是DMP發送的設備號ID在DSP設備號ID庫中的占比。匹配度越高，意味著DMP的人群標簽在DSP的流量池中被找到的可能性越大，DSP也就更有可能覆蓋到廣告主需要的人群。行業內一般認為匹配度在40% - 60%比較合適。就好像在一個大倉庫里找特定的貨物，匹配度越高，找到貨物的概率就越大。

（二）對接方式詳解

DMP與DSP的對接方式主要有API接口、FTP傳輸和Pre - bid方式。API和FTP方式可以批量接收人群標識號及對應標簽，就像是用大貨車一次性運輸大量貨物一樣高效。Pre - bid方式則有點不同，它需要在DMP與DSP之間部署一臺前置機。這臺前置機就像是一個中轉站，先接收DMP的數據，然后在DSP投放前實時查詢使用。下面用一段簡單的Python代碼來模擬使用API接口獲取DMP數據的過程（實際應用中涉及更復雜的網絡通信和安全機制）：

import requests# 假設這是DMP提供的API地址，用于獲取人群標簽數據
dmp_api_url = "https://dmp.example.com/api/get_crowd_tags"
# 模擬請求頭，可能包含認證信息等
headers = {"Authorization": "Bearer your_token","Content-Type": "application/json"
}try:response = requests.get(dmp_api_url, headers=headers)if response.status_code == 200:crowd_tags = response.json()print("成功獲取人群標簽數據:", crowd_tags)else:print(f"請求失敗，狀態碼: {response.status_code}")
except requests.exceptions.RequestException as e:print(f"請求出現錯誤: {e}")

（三）對接流程

投放執行人員在DMP平臺精心設置需要投放的人群標簽條件，然后將這些標簽應用到營銷活動中。這一步就像是給即將出發的“廣告大軍”制定目標和路線。
DMP平臺根據營銷活動的人群標簽準備數據，接著向前置機發送初始化數據通知。前置機收到通知后就開始下載數據。而且，DMP的數據會不斷更新，就像河流里的水一直在流動，所以需要持續同步更新數據到前置機。
DSP平臺設置投放活動，并在其中填入DMP平臺對應的營銷活動ID。當DSP收到競價請求時，就像收到了“戰斗信號”，它會向前置機查詢用戶信息是否符合營銷活動的人群標簽條件。
前置機把查詢結果返回給DSP。如果結果顯示用戶滿足條件，DSP就像得到了沖鋒的指令，參與競價；如果不滿足，就只能放棄這次機會。

二、數據統計原理：廣告效果的“晴雨表”

無論是廣告投放過程中還是投放后，對廣告效果進行驗證觀察都非常重要。這不僅能幫助我們評估、制定和調整投放策略，還能依據用戶行為數據優化廣告、網站或App，提高用戶轉化和留存率。數據統計主要分為網站統計和App統計兩種邏輯。

（一）網站統計邏輯

當我們在瀏覽器中輸入一個網址，瀏覽器就會向網站Web Server發起請求URL，這就像是給網站的“門衛”發送了一個進門申請。
網站Web Server收到申請后，解析請求URL，并生成Html文檔響應返回給瀏覽器，就好比門衛審核通過后，給我們遞出了一份房子的設計圖（Html文檔）。
瀏覽器拿到這份“設計圖”后，開始解析Html文件，加載外部腳本、樣式表和圖片等，這個過程會觸發JS統計代碼，就像是房子里的各種機關開始啟動。
JS腳本開始工作，它會收集各種信息，比如域名、URL、頁面標題等，還能獲取自定義事件（像注冊行為）的數據。如果之前在用戶瀏覽器“種”過cookie，就能獲取到對應cookie信息；如果沒有，就會進入“種”cookie的流程。
收集到的信息會被傳輸給后端腳本，這就像是把收集到的情報傳遞給后方的指揮官。
后端腳本會生成一個透明的1×1像素圖片，在瀏覽器中“種”入cookie標識訪客，同時解析并發送收集到的信息，從網站Web Server獲取IP、訪問時間等信息，然后寫入日志Logo隊列，就像是指揮官整理情報并記錄下來。
日志信息被發送至實時統計服務，經過實時統計后進入實時數據庫，這就好比把整理好的情報送到了一個臨時倉庫。
從實時數據庫調用數據進行離線分析，然后存入離線數據庫，就像是把臨時倉庫的情報送到了一個長期的檔案館。
最后，查詢數據庫，將數據以可視化報表的形式呈現出來，這樣我們就能直觀地看到網站的各種數據表現，就像是通過地圖清晰地看到各個區域的情況。

（二）App統計邏輯

App應用客戶端向App應用服務端發起請求，這就像是手機上的App向服務器“喊話”，說自己需要一些東西。
App應用服務端收到請求后，響應并返回應用信息，就像服務器聽到“喊話”后，給App遞出了它需要的物品。
App應用客戶端調用統計SDK并初始化，同時通過API接口寫入版本、渠道等信息，并進行數據埋點，這就好比在App里安裝了一些“小眼睛”，用來記錄各種數據。
開始收集應用運行信息，包括訪問者唯一標識（比如IMEI號、Android - ID或IDFA等）、訪問時間、應用版本號等。這些信息就像是給每個訪問者貼上了獨一無二的“標簽”。
在App啟動/關閉或者收集的信息數量達到一定上限時，就把信息傳送給后端，就像是裝滿貨物的貨車把貨物送回倉庫。
后端腳本解析并發送收到的數據包，寫入日志Logo隊列，就像倉庫管理員整理收到的貨物并記錄下來。
日志信息發送至實時統計服務，進入實時數據庫，就像貨物被暫時存放在臨時倉庫。
從實時數據庫調用數據進行離線分析，再存入離線數據庫，就像把臨時倉庫的貨物轉移到長期倉庫。
查詢數據庫，進行可視化數據報表呈現，這樣我們就能清楚地了解App的運行情況，就像通過儀表盤了解汽車的各項指標。

下面用一段簡單的Java代碼來模擬App數據收集和傳輸的過程（實際應用中會涉及更多復雜的業務邏輯）：

import java.util.HashMap;
import java.util.Map;public class AppDataCollector {public static void main(String[] args) {// 模擬收集App運行信息String visitorId = "1234567890";String appVersion = "1.0.0";String operator = "ChinaMobile";String networkType = "4G";Map<String, String> appData = new HashMap<>();appData.put("visitorId", visitorId);appData.put("appVersion", appVersion);appData.put("operator", operator);appData.put("networkType", networkType);// 模擬數據傳輸給后端sendDataToBackend(appData);}private static void sendDataToBackend(Map<String, String> data) {// 這里可以替換為實際的網絡請求代碼，將數據發送給后端System.out.println("正在將App數據發送給后端: " + data);}
}