小編給大家分享一下怎么實現(xiàn)廣告彈窗觸達頻率的控制，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

成都創(chuàng)新互聯(lián)公司是一家專注于網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計與策劃設(shè)計,路北網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)10多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:路北等地區(qū)。路北做網(wǎng)站價格咨詢:18980820575

如何實現(xiàn)廣告彈窗觸達頻率的控制

今天我們聊聊實際工作中遇到的一個問題：

產(chǎn)品提出想在我們的產(chǎn)品的首頁做個彈窗廣告，但是又不希望用戶每次進來都給用戶彈窗，每個用戶每天進來只彈一次就好了。

這個如何實現(xiàn)？

方法一（暴力破解）

或許有些人會覺得這個挺簡單的，這個問題抽象出來不就是要記錄用戶的行為么，這個將用戶的每一次行為都存在redis或數(shù)據(jù)庫中，每次訪問的時候都查一下數(shù)據(jù)庫或redis判斷一下，有沒有。

以redis舉例， 如果用戶今天訪問過一次，就在Redis里面設(shè)置一個以用戶為維度的key。

真爽，這么簡單，然后我們就高高興興的玩去了，突然某一天，運維找到你，告訴你Redis服務(wù)被擠爆了，內(nèi)存不足。什么鬼？你抬起腦袋，暗暗一想，你們的用戶有1個億用戶。

打算一個用戶占用14個字節(jié)，14B*100000000/1024/1024=1335MB，我去，這么一個小功能，都占用至少1G的內(nèi)存了。

 方法二（Bitmap數(shù)據(jù)結(jié)構(gòu)）

為了實現(xiàn)這樣的小的效果，花費了1G的寶貴的Redis內(nèi)存空間，顯然是劃不來的。有沒有一種辦法或數(shù)據(jù)結(jié)構(gòu)可以即實現(xiàn)想要達到的一天一次彈窗效果，又能占用內(nèi)存最小。

這個時候，你突然想到用戶的唯一標識符(uid),是一個從0到1個億遞增的整數(shù)。一天一次彈窗對應(yīng)一個01二進制值。那能否分配一個大的數(shù)組，數(shù)組的值是boolean值，這個時候你突然想到了Redis的Bitmap數(shù)據(jù)結(jié)構(gòu)。

抬起頭算了算，一個用戶uid為1bit位，1億用戶，大概：100000000b/8/1024/1024=11MB。到這里，需要1個G的內(nèi)存的功能現(xiàn)在只需要11MB就能存儲下來。

方法三(布隆過濾器)

以為到使用bitmap解決問題就完了么？如果現(xiàn)在不止有一個彈層呢，比如1000個？亦或者用戶的唯一標識符并不是一個自增的整數(shù)。這個時候如何處理呢？

如果我們愿意犧牲少了的準確度，達到比較大的存儲量的話，你可能會考慮到布隆過濾器（Bloom Filter）。

在方案二中的分配一大片的bitmap基礎(chǔ)上，將要保存的uid或key通過若干個哈希函數(shù)映射到不同的bit上保存。

這種方案有個好處就幾十MB內(nèi)存可以存儲幾十億的數(shù)據(jù)去重判斷。當然壞處就是會犧牲掉少量的準確性。

方案四（前端存儲）

在上面三種方案的基礎(chǔ)上，我們會發(fā)現(xiàn)想這些控制內(nèi)存的方法，我們想得老細胞都要死掉好多。有沒有一種簡單有效的方式呢？

如果產(chǎn)品不需要強制要求必須用戶一天只彈一次，那能不能將這個控制任務(wù)交給前端來控制呢，比如存儲在cookie或locolstorage中?,這樣就完全不用擔心存儲內(nèi)存的問題了。

但是這樣有個缺點就是如果用戶在不同的客戶端（H5或APP）中打開，會出現(xiàn)一天彈多次的情況，控制可能沒那么精準。

沒有完美的技術(shù)方案，只有最合適的技術(shù)方案。

看完了這篇文章，相信你對“怎么實現(xiàn)廣告彈窗觸達頻率的控制”有了一定的了解，如果想了解更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！