怎么實現廣告彈窗觸達頻率的控制

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

如何實現廣告彈窗觸達頻率的控制

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

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

這個如何實現？

方法一（暴力破解）

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

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

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

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

 方法二（Bitmap數據結構）

為了實現這樣的小的效果，花費了1G的寶貴的Redis內存空間，顯然是劃不來的。有沒有一種辦法或數據結構可以即實現想要達到的一天一次彈窗效果，又能占用內存最小。

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

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

方法三(布隆過濾器)

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

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

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

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

方案四（前端存儲）

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

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

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

沒有完美的技術方案，只有最合適的技術方案。

看完了這篇文章，相信你對“怎么實現廣告彈窗觸達頻率的控制”有了一定的了解，如果想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！