廣告投放費錢效果差，

該如何解？

廣告投放是企業(yè)宣傳營銷不可或缺的一部分。尤其是在新媒體發(fā)展白熱化的當下，不僅廣告渠道多樣化，投放模式也更細節(jié)化和個性化。

隨著客戶廣告投放產(chǎn)出比意識的加強，以短視頻平臺、微博等渠道為例，在投放目標選擇上，廣告主通常需要通過配置年齡、性別、學(xué)歷等偏好規(guī)則，才能將廣告投放給滿足標簽的受眾，投放中這一靈活性不足的限制，常常會讓廣告主難以抉擇，導(dǎo)致投放效果不佳。

普通廣告投放僅支持有限的人群標簽，投放效果一般

廣告主企業(yè)往往每年需花費數(shù)億甚至數(shù)十億廣告費，卻依然難以準確觸達目標用戶，造成大量資金浪費。那該如何解決“讓廣告主對每一條廣告請求，有投遞或者拒絕的自主權(quán)”這一問題呢？

廣告 RTA 應(yīng)運而生！

廣告 RTA 業(yè)務(wù)流程大揭秘

RTA（Realtime API），是一種用于滿足廣告主實時、個性化的投放需求的技術(shù)手段。其廣告投放流程如下舉例：

小王在刷短視頻或文章資訊過程中，平臺在短時間內(nèi)做出反應(yīng)，我要給小王曝光廣告；

緊接著，媒體側(cè)會詢問多個廣告主是否要投遞廣告；

多個廣告主收到消息后，會迅速作出反應(yīng)，將這個用戶與設(shè)定的投放標準一一對比。如果符合要求，就會答復(fù)要參與競價投放；如果不符合要求，答復(fù)本次不投放；

媒體側(cè)收到每個廣告主的反饋后，如果有投放意愿的廣告主，通過競價排序等環(huán)節(jié)，向用戶（小王）曝光一則廣告；反之，小王也就沒看到其廣告；

對于超時未答復(fù)的廣告主，媒體側(cè)采取自帶默認策略，就會導(dǎo)致投放效果不佳。

廣告 RTA 業(yè)務(wù)流程

廣告 RTA 要想效果好，

數(shù)據(jù)庫挑戰(zhàn)少不了

廣告主的 RTA 系統(tǒng)，是從核心的畫像數(shù)據(jù)庫讀取數(shù)據(jù)并進行投放決策的，數(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è)對時效性要求很嚴苛，通常需要廣告主在 40-100ms 內(nèi)返回決策結(jié)果，排除掉復(fù)雜的業(yè)務(wù)決策計算，留給數(shù)據(jù)庫的時間非常短，必須在個位數(shù)毫秒內(nèi)執(zhí)行完請求，對數(shù)據(jù)庫挑戰(zhàn)非常大。

一旦響應(yīng)超時，平臺會認為棄投或者默認投遞，投放效果差，損害了廣告主商業(yè)利益。

海量數(shù)據(jù)快速導(dǎo)入，確保決策精準性

離線業(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ā)負擔。

放眼數(shù)據(jù)庫，

誰能滿足廣告 RTA 高要求？

隨著數(shù)字化進程的加深，應(yīng)用端數(shù)據(jù)量呈幾何式增長，業(yè)務(wù)場景和用戶需求也更加多元化。數(shù)據(jù)庫作為數(shù)據(jù)存儲的底座，勢必會面臨巨大的挑戰(zhàn)。廣告 RTA 以在“高并發(fā)、低時延”有嚴苛著稱，究竟哪個數(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é)摿薮螅环矫嬉獫M足媒體側(cè)的性能指標要求，另一方面又要承擔企業(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折起

審核編輯 黃宇