廣告中的頻次控制是指控制乙個使用者最多在指定時間內看到乙個廣告（或相似廣告）的次數，比如廣告主可以限制乙個使用者最多只能一天看到乙個廣告3次（頻次控制也可以讓publisher來指定，但本文不考慮publisher）。
本文所說的頻次控制不是硬性的，也就是說展示的次數多隻會降低相同廣告出現的概率，而不是達到一定次數後徹底不出。兩者的區別是：前者廣告主需要自己去試到底多長的時間段最多出幾次合適，比較麻煩，但如果他得到了接近事實的次數，會對他有利。後者是廣告主省事了，代價是廣告平台只會去優化ecpm，不會去考慮廣告主的利益。
引入頻次控制有以下優點：
1. 增加觸達受眾數量。頻次控制可以讓更多的受眾看到廣告。因為頻次控制消除了廣告主有限的預算總是消耗在了不斷地向同一群人展示廣告上。
2. 提高ctr。頻次控制是提高廣告ctr的有效手段之一。ctr大約在相同廣告展示4次之後就很低了，因為使用者已經開始對這個廣告無視了。
3. 提高cvr**化率），與ctr相似，在第一次展示時轉化率最高，在展示4-6次後基本無轉化。
見上圖，橫座標是展示次數，縱座標是cpm，曲線是不同的廣告（是的，我知道圖和我說的不是一回事，但道理和資料真的差不多，因為我沒法把公司的資料拿出來講）。需要注意的是：
1. 所有的廣告都是隨著展示次數的增加，cpm減小。
2. 以藍線和紅線為例，藍色的廣告展示1次的cpm是高於紅色的展示一次的cpm，但藍色展示兩次後cpm是低於紅色展示一次的cpm。
3. 每個折線下降的速度是有差異的。
回憶一下公式：cpm = ctr * bid，ecpm = pctr * bid。公式中的bid是已知且固定的，那麼也就是ecpm因為展示次數的變化是因為展示次數影響了pctr，那麼如果基於展示次數對pctr進行了調整，那麼ecpm就更加合理了。
考慮了已經展示的次數對pctr進行調整，理想情況我們會收穫更高的cpm，也就是公司能賺到更多的錢了。（請問你能想象我打這句話時的心情嗎？）
實現頻次控制後的圖應該是這樣，紫色的線就是優化後的效果，如果你看不明白，最左邊其實少了一根黑化的豎線（我再強調一下，圖里的ad network把它想成廣告，如果你是ssp，那就不要想了）。可以看到紫色的線明顯高於藍線。
首先基於展示次數對pctr進行調整是否本身就是pctr自己的問題，這個我一直有點疑問，展示次數明顯可以作為乙個特徵加入到pctr的模型中去，但我自己沒有試過。但無論展示次數是否作為特徵加入，做法都差不多，重要的是如何得到資料。
資料分兩部分，一部分實時資料，另一部分離線資料。需要storm收集實時資料的原因是寫hive資料庫一般有小時級的延時。kv db中儲存的是聚合了實時資料和離線資料的結果，key是user，value是[ad_n, count_n]的列表。
如果是展示次數作為特徵放到pctr學習中，那一切ok了，如果不這樣做，那就麻煩了，首先，要得到前面圖中的折線，得到展示次數對每個廣告pctr的影響。這裡就有問題了，廣告**不足怎麼辦？點選就幾十個，怎麼統計？是維度向上計算推廣計畫？**還不夠怎麼辦？再向上到廣告類別？廣告主維度？還是更直接點，假裝沒看到這些資料，直接忽略，目標只去解決有統計意義的廣告。
想多一點還有更多的問題，人群a可能看過一次不點就不會再點了，人群b看過一次點選的概率並和從未看過點選概率差不多。人群的定義可以是無限多種。另外乙個廣告被展示到了頂部廣告位，和底部廣告位，難道都認為被展示了一次？所以我雖然沒試過，但我認為展示次數放到pctr模型裡作為乙個特徵應該是最簡單合理的。
部分內部引自：
Redis構建頻次訪問控制器（二）
在昨天的基礎上新增了功能 當訪問廣告服務時會自動將頻次加1，當大於等於規定的頻次返回失敗頁面，還有定時任務，並且使用了springcloud分布式的操作 話不多說，直接上 專案結構 這個就是昨天的 改的 改動的 adshowcontroller restcontroller public class...
F 學習筆記（三） 命令列控制
在visual studio的安裝目錄中提供了乙個互動式操作工具fsi.exe，其路徑為 2019 common7 ide commonextensions microsoft fsharp fsi.exe 這樣我們就可以像使用python一樣使用f 可以非常方便地進行函式的除錯。其介面如下 需要注...
STM32F103的PWM電機控制
目錄 選擇tim ch 1 gpio配置輸出 定時器配置 呼叫函式使用 初次易錯點 使用 輸出是首先要看，那個引腳使用可以使用 輸出。高階控制和通用定時器通道引腳分布 高階定時器 通用定時器 tim1 tim8 tim2 tim5 tim3 tim4 ch1 pa8 pe9 pc6pa0 pa15 ...