廣告投放費錢效果差,
該如何解?
廣告投放是企業宣傳營銷不可或缺的一部分。尤其是在新媒體發展白熱化的當下,不僅廣告渠道多樣化,投放模式也更細節化和個性化。
隨著客戶廣告投放產出比意識的加強,以短視頻平臺、微博等渠道為例,在投放目標選擇上,廣告主通常需要通過配置年齡、性別、學歷等偏好規則,才能將廣告投放給滿足標簽的受眾,投放中這一靈活性不足的限制,常常會讓廣告主難以抉擇,導致投放效果不佳。
普通廣告投放僅支持有限的人群標簽,投放效果一般
廣告主企業往往每年需花費數億甚至數十億廣告費,卻依然難以準確觸達目標用戶,造成大量資金浪費。那該如何解決“讓廣告主對每一條廣告請求,有投遞或者拒絕的自主權”這一問題呢?
廣告 RTA 應運而生!
廣告 RTA 業務流程大揭秘
RTA(Realtime API),是一種用于滿足廣告主實時、個性化的投放需求的技術手段。其廣告投放流程如下舉例:
小王在刷短視頻或文章資訊過程中,平臺在短時間內做出反應,我要給小王曝光廣告;
緊接著,媒體側會詢問多個廣告主是否要投遞廣告;
多個廣告主收到消息后,會迅速作出反應,將這個用戶與設定的投放標準一一對比。如果符合要求,就會答復要參與競價投放;如果不符合要求,答復本次不投放;
媒體側收到每個廣告主的反饋后,如果有投放意愿的廣告主,通過競價排序等環節,向用戶(小王)曝光一則廣告;反之,小王也就沒看到其廣告;
對于超時未答復的廣告主,媒體側采取自帶默認策略,就會導致投放效果不佳。
廣告 RTA 業務流程
廣告 RTA 要想效果好,
數據庫挑戰少不了
廣告主的 RTA 系統,是從核心的畫像數據庫讀取數據并進行投放決策的,數據越“新鮮”,投放效果越好。因此,大數據平臺生成的最新數據,需要及時寫入畫像數據庫。綜合來看,廣告 RTA 對核心畫像數據庫有以下訴求:
能承載高并發訪問
廣告主往往會在多個媒體側投放廣告,因此,RTA 系統要承接大量的實時競價請求。以電商、金融客戶的 RTA 系統為例,經驗上,日常數據庫QPS 通常在幾十萬到數百萬之間。
保持穩定的低時延
媒體側對時效性要求很嚴苛,通常需要廣告主在 40-100ms 內返回決策結果,排除掉復雜的業務決策計算,留給數據庫的時間非常短,必須在個位數毫秒內執行完請求,對數據庫挑戰非常大。
一旦響應超時,平臺會認為棄投或者默認投遞,投放效果差,損害了廣告主商業利益。
海量數據快速導入,確保決策精準性
離線業務會定期生成全量畫像數據,如果能把這些成百 GB 甚至數 TB 的價值數據第一時間導入畫像庫,就會極大提升 RTA 投放效果。但并非所有數據庫都能在短時間內導入成百 GB 甚至數 TB 級的離線數據。因此,有時業務不得不舍棄數據實時性,將數據分組,連續數晚,利用業務低峰才能將數據低效導入。
除此之外,降本也是廣告主對數據庫的核心訴求。部分客戶會選擇將畫像數據壓縮后存儲,讀取后再解壓,以降低成本,這樣給業務帶來比較大的資源和開發負擔。
放眼數據庫,
誰能滿足廣告 RTA 高要求?
隨著數字化進程的加深,應用端數據量呈幾何式增長,業務場景和用戶需求也更加多元化。數據庫作為數據存儲的底座,勢必會面臨巨大的挑戰。廣告 RTA 以在“高并發、低時延”有嚴苛著稱,究竟哪個數據庫才能承受的住來自廣告 RTA 的挑戰呢?
以常用的幾個數據庫為例,
MySQL:難以承載數十萬至百萬 QPS 并發;
Hbase/MongoDB:容量大,無法滿足穩定低時延訴求,很容易導致投放超時;
Redis:基于并發和時延性能考慮,業界比較多的 RTA 選擇使用開源自建 Redis。但是隨著業務增長,開源自建 Redis 會面臨存儲成本和離線數據導入慢這兩大瓶頸問題。
華為云 GeminiDB Redis 接口在廣告 RTA 場景上,不僅解決了開源自建 Redis 存儲成本和離線數據導入慢的瓶頸問題,還具備"穩定低時延、節約存儲成本、FastLoad 極速導入" 三大核心能力,擁有豐富的線上廣告、推薦類業務的實踐案例。
總結
RTA 廣告競價業務近年來發展潛力巨大,一方面要滿足媒體側的性能指標要求,另一方面又要承擔企業降本重任。在這類典型大數據業務中,無論從性能、穩定性,還是大容量、低成本,華為云數據庫 GeminiDB Redis 接口能夠兼顧性能與存儲降本需求,是其最佳存儲選型,歡迎做廣告推薦類業務的小伙伴使用體驗。
開年采購季云數據庫特惠
活動時間:3月1日-31日
云數據庫新用戶1年19元起
不限新老1年6.5折起
審核編輯 黃宇
-
數據庫
+關注
關注
7文章
3846瀏覽量
64685 -
大數據
+關注
關注
64文章
8908瀏覽量
137795
發布評論請先 登錄
相關推薦
評論