廣告投放系統:聚合廣告SDK與技術設計方案
本文跟大家講講廣告投放系統,看商業化廣告各方的協作流程是怎樣的,以及有什么樣的難點,其中SDK的接口又是如何設計的?
一、商業化廣告各方協作流程
上游:
- 對接基礎服務端提供基礎服務;
- 對接SSP、直投等等自有廣告資源;
- 對接第三方廣告SDK(廣點通、百度白青藤、頭條穿山甲)。
下游:
- 提供給集團公司各個客戶端使用;
- 為大數據分析提供數據。
二、廣告SDK工作流程
(1)客戶端初始化SDK,SDK初始化并獲取配置(基本配置(默認),流量控制配置等)。
(2)客戶端傳入廣告位從SDK獲取廣告,SDK根據流量配置獲取廣告返回(SSP、廣點通)。
(3)客戶端負責展示廣告,SDK上報曝光和點擊等統計事件,同時也給客戶端回調接口。
(4)處理失敗打點數據,緩存和上報。
三、難點
(1)版本兼容
其中包括SDK自身配置和數據庫緩存的的版本兼容,其實更重要的是對客戶端接口的版本兼容。SDK在版本迭代中會去對接多個第三方廣告投放方,也會增加各類廣告展示類型,為保證app升級SDK的無縫對接,需要對app端提供一致的接口設計,保證聚合SDK新增其他第三方和其他廣告類型時能完美支持。
(2)數據準確性
廣告的打點數據是結算的重要依據,需保證上報的數據的準確性,不丟失,且可靠。這里設計到一系列的優化項,對廣告數據獲取的成功率提升,對廣告展示、點擊的數據準確性保證的技術運用,同時提供監測手段的手段運用。
(3)SDK的健壯性要求
尤其處理廣告請求并發,數據打點并發的情況下的線程安全問題。
(4)SDK的其他性能指標的關注
執行時間、內存、cpu、無crash。特殊廣告類型,如開屏廣告的性能要求。展示流暢,加載需要控制在1-3s內。
四、SDK的接口設計
- 初始化接口。如果后臺不處理多方SDK的應用ID兼容情況。則需要讓app傳入第三方SDK的應用ID列表。可通過配置model傳入SDK。包含我們定義的app Id、第三方SDK注冊定義的應用ID、以及其他公共參數。
- 各類廣告類型的廣告view或者實體接口,需要傳入廣告位ID。
- 加載廣告接口,加載成功的數據自動裝載該view。
- 各類事件回調接口。處理加載成功、加載失敗、曝光、關閉、點擊、廣告落地頁即將展示、即將關閉展示、已經展示,已經關閉等回調。(需要定制廣告投放系統聯系微信:136837241)
五、SDK的功能設計
(1)配置的獲取和版本緩存和更新支持。
- 帶版本號請求接口、app Id等信息請求配置,成功后緩存。
- 在app啟動和退出后臺、回到前臺均更新配置。
(2)數據獲取支持超時和重試。
超時時間根據配置控制、重試次數根據配置控制。
(3)數據打點上報
- SSP的點擊、曝光
- 上報到大數據所有事件
(4)失敗打點數據的緩存和上報處理
- 失敗的打點需緩存到本地數據庫,再定時上報。
- 定時間隔由服務器控制,默認值60s。
- 無網絡不上報。
- 上報成功后刪除本地緩存數據。
- 失敗繼續上報,每個緩存數據重試若干次后舍棄。重試次數由配置控制,默認3次。
(5)流量控制功能支持
SSP、第三方SDK分流控制。根據配置,按優先級去分配。
(6)配置及時更新
- 部分廣告類型需確保等待最新配置返回;
- 靜默推送更新app端配置。
六、開屏廣告功能設計
如果展示第三方SDK的廣告,扔給第三方處理即可。如果是SSP或者DSP,需要實現所有展示和功能邏輯。
1)接口
- 傳入廣告位創建開屏視圖方法
- 允許app控制超時時間方法,SDK提供默認值
- 控制背景色方法(百度不支持)
- 控制背景圖方法(百度不支持)
- 支持logo視圖方法
- 支持跳出按鈕的位置控制方法(百度不支持)
- 加載廣告方法
2)廣告獲取展示
- 客戶端請求廣告,SDK根據配置優先級決定交給SSP還是廣點通處理。(并發也可能按需)
- 如是SSP處理,則請求SSP接口(需上傳參數確定),獲取廣告后,繪制視圖展示(需要單張圖),點擊跳轉支持deeplink、webview展示功能。
3)圖片、視頻的緩存
七、其他廣告類型設計
略過
八、SDK架構圖
本文由 @相見恨晚 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
請問,能不能再寫一篇詳細一點的?或者能否推薦一下學習廣告SDK產品設計的書籍或者課程?
現在我司也在構建自己的廣告系統
缺產品嗎?哈哈哈哈哈
我們這缺,聊一下?
app嗎,我司最近在尋找合適app進行廣告投放合作
這里邊的幾個角色關系還需要再理一下,媒體應該是在SSP平臺發布廣告位資源,SDK做的事情是從DSP或者第三方(穿山甲/優量匯等)獲取廣告“放到”SSP平臺上的廣告位里在相應的媒體位置展示
因為最近在構建自有廣告系統(已上線),所以很認真看了本文,作者寫得很詳細,流程和實現也很完善。但我也有幾個疑問哈。
第一個疑問,是流程中的第二點:
“(2)客戶端傳入廣告位從SDK獲取廣告,SDK根據流量配置獲取廣告返回(SSP、廣點通)?!?br /> 因為SSP是供應方平臺,也就是做媒體管理,而不是做廣告投放的。所以客戶端(媒體)應該才是和SSP打交道的。因此我給改了下文字描述,不知是否正確:
“(2)客戶端從SSP獲取廣告位,并在觸發對應廣告位時,把廣告位傳給廣告SDK。廣告SDK根據流量配置,從廣告后臺獲取對應廣告位的廣告,并返回給客戶端(廣告后臺會對接DSP和直客、廣點通等,獲取廣告)?!?/p>
第二個疑問,是這段話,感覺沒有描述清楚。
“SDK在版本迭代中會去對接多個第三方廣告投放方(DSP,或者直投,或者廣點通等),也會增加各類廣告展示類型。為保證app升級SDK的無縫對接,需要對app端提供一致的接口設計,保證聚合SDK新增其他第三方和其他廣告類型時能完美支持。”
中間的這句“為保證app升級SDK的無縫對接”,我的理解,是不是指廣告SDK升級時,應該盡量對已有APP造成的影響最低?所以這段話我修改一下:
“廣告SDK在版本迭代過程中,會持續對接多個第三方廣告投放方(DSP,或者直投,或者廣點通等),或增加更多的廣告展示類型。為保證APP對廣告SDK各個版本的無縫對接,需要對APP端提供一致的接口設計,以確保廣告SDK在升級過程中,即便新增了其他第三方廣告投放方或其他廣告類型,老的APP也能完美支持/兼容。”
第三個疑問,是“接口設計”的“初始化接口”部分。
“如果后臺不處理多方SDK的應用ID兼容情況,則需要讓app傳入第三方SDK的應用ID列表。”這里的需求,是不是指為了實現激活與鑒權,需要將本應用的AppID,或者注冊開發者時生成的AppID,傳給接入的各家廣告SDK。
第四個疑問,是“開屏廣告功能設計”里的描述:“如果是SSP或者DSP,需要實現所有展示和功能邏輯?!?br /> 因為DSP是廣告主關注的,而SDK其實并不關注這一塊,所以這里是不是應該只有SSP,而沒有DSP。
你這個做的是自己公司產品的商業化嗎?把你們的流量位接入到穿山甲、廣點通等平臺,來實現流量變現?
不是接入到穿山甲、廣點通等平臺,而是完全自己構建的商業化系統。因為我們既有流量,也有廣告主,所以并不需要對接穿山甲等平臺
現在公司也在構建商業化系統,可以加微信相互溝通一下嘛
可以加個微信認識一下嘛?
怎么聯系你?