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