廣告投放費(fèi)錢(qián)效果差，

該如何解？

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

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

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

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

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

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

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

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

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

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

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

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

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

廣告 RTA 要想效果好，

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

廣告主的 RTA 系統(tǒng)，是從核心的畫(huà)像數(shù)據(jù)庫(kù)讀取數(shù)據(jù)并進(jìn)行投放決策的，數(shù)據(jù)越“新鮮”，投放效果越好。因此，大數(shù)據(jù)平臺(tái)生成的最新數(shù)據(jù)，需要及時(shí)寫(xiě)入畫(huà)像數(shù)據(jù)庫(kù)。綜合來(lái)看，廣告 RTA 對(duì)核心畫(huà)像數(shù)據(jù)庫(kù)有以下訴求：

能承載高并發(fā)訪問(wèn)

廣告主往往會(huì)在多個(gè)媒體側(cè)投放廣告，因此，RTA 系統(tǒng)要承接大量的實(shí)時(shí)競(jìng)價(jià)請(qǐng)求。以電商、金融客戶的 RTA 系統(tǒng)為例，經(jīng)驗(yàn)上，日常數(shù)據(jù)庫(kù)QPS 通常在幾十萬(wàn)到數(shù)百萬(wàn)之間。

保持穩(wěn)定的低時(shí)延

媒體側(cè)對(duì)時(shí)效性要求很?chē)?yán)苛，通常需要廣告主在 40-100ms 內(nèi)返回決策結(jié)果，排除掉復(fù)雜的業(yè)務(wù)決策計(jì)算，留給數(shù)據(jù)庫(kù)的時(shí)間非常短，必須在個(gè)位數(shù)毫秒內(nèi)執(zhí)行完請(qǐng)求，對(duì)數(shù)據(jù)庫(kù)挑戰(zhàn)非常大。

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

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

離線業(yè)務(wù)會(huì)定期生成全量畫(huà)像數(shù)據(jù)，如果能把這些成百 GB 甚至數(shù) TB 的價(jià)值數(shù)據(jù)第一時(shí)間導(dǎo)入畫(huà)像庫(kù)，就會(huì)極大提升 RTA 投放效果。但并非所有數(shù)據(jù)庫(kù)都能在短時(shí)間內(nèi)導(dǎo)入成百 GB 甚至數(shù) TB 級(jí)的離線數(shù)據(jù)。因此，有時(shí)業(yè)務(wù)不得不舍棄數(shù)據(jù)實(shí)時(shí)性，將數(shù)據(jù)分組，連續(xù)數(shù)晚，利用業(yè)務(wù)低峰才能將數(shù)據(jù)低效導(dǎo)入。

除此之外，降本也是廣告主對(duì)數(shù)據(jù)庫(kù)的核心訴求。部分客戶會(huì)選擇將畫(huà)像數(shù)據(jù)壓縮后存儲(chǔ)，讀取后再解壓，以降低成本，這樣給業(yè)務(wù)帶來(lái)比較大的資源和開(kāi)發(fā)負(fù)擔(dān)。

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

誰(shuí)能滿足廣告 RTA 高要求？

隨著數(shù)字化進(jìn)程的加深，應(yīng)用端數(shù)據(jù)量呈幾何式增長(zhǎng)，業(yè)務(wù)場(chǎng)景和用戶需求也更加多元化。數(shù)據(jù)庫(kù)作為數(shù)據(jù)存儲(chǔ)的底座，勢(shì)必會(huì)面臨巨大的挑戰(zhàn)。廣告 RTA 以在“高并發(fā)、低時(shí)延”有嚴(yán)苛著稱，究竟哪個(gè)數(shù)據(jù)庫(kù)才能承受的住來(lái)自廣告 RTA 的挑戰(zhàn)呢？

以常用的幾個(gè)數(shù)據(jù)庫(kù)為例，

MySQL：難以承載數(shù)十萬(wàn)至百萬(wàn) QPS 并發(fā)；

Hbase/MongoDB：容量大，無(wú)法滿足穩(wěn)定低時(shí)延訴求，很容易導(dǎo)致投放超時(shí)；

Redis：基于并發(fā)和時(shí)延性能考慮，業(yè)界比較多的 RTA 選擇使用開(kāi)源自建 Redis。但是隨著業(yè)務(wù)增長(zhǎng)，開(kāi)源自建 Redis 會(huì)面臨存儲(chǔ)成本和離線數(shù)據(jù)導(dǎo)入慢這兩大瓶頸問(wèn)題。

華為云 GeminiDB Redis 接口在廣告 RTA 場(chǎng)景上，不僅解決了開(kāi)源自建 Redis 存儲(chǔ)成本和離線數(shù)據(jù)導(dǎo)入慢的瓶頸問(wèn)題，還具備"穩(wěn)定低時(shí)延、節(jié)約存儲(chǔ)成本、FastLoad 極速導(dǎo)入" 三大核心能力，擁有豐富的線上廣告、推薦類(lèi)業(yè)務(wù)的實(shí)踐案例。

總結(jié)

RTA 廣告競(jìng)價(jià)業(yè)務(wù)近年來(lái)發(fā)展?jié)摿薮?，一方面要滿足媒體側(cè)的性能指標(biāo)要求，另一方面又要承擔(dān)企業(yè)降本重任。在這類(lèi)典型大數(shù)據(jù)業(yè)務(wù)中，無(wú)論從性能、穩(wěn)定性，還是大容量、低成本，華為云數(shù)據(jù)庫(kù) GeminiDB Redis 接口能夠兼顧性能與存儲(chǔ)降本需求，是其最佳存儲(chǔ)選型，歡迎做廣告推薦類(lèi)業(yè)務(wù)的小伙伴使用體驗(yàn)。

開(kāi)年采購(gòu)季云數(shù)據(jù)庫(kù)特惠
活動(dòng)時(shí)間：3月1日-31日
云數(shù)據(jù)庫(kù)新用戶1年19元起
不限新老1年6.5折起

審核編輯 黃宇