Frequency cap has always been discussed, seen and used during digital campaigning. It is the parameter to restrict user to see frequent ad from the same campaign. It sounds like a limit but for advertisers it is a parameter for the campaign to get successful.
Currently, I am working for a digital advertising firm, where we used to take part in real-time advertising auctions, our system handles around 400k-500k bid-requests per second, our cloud servers (we call them bidder-servers) are constantly bidding & serving a large number of ads globally. We are using Redis as well for realtime data retrieval. It's really important for bidder-servers to look after the maximum impressions allowed per user (The frequency cap) while bidding on the ad request.
Frequency cap is a parameter being set in any digital advertising campaign which refers to the restriction of number of times a single unique user sees an ad within a time period. It limits number of times your ad appears to the same person.
In digital advertising, frequency cap is very helpful:
For advertisers to reach out to large number of audiences with same budget rather than spending whole budget on a small number of audiences who has already watched the ad more than sufficient time.
For user who has seen the ad, it maintains the experience of advertising. It is a good advertising if more new users sees the ad than same users will see the same ad frequently.
Frequency cap = 5, Duration = 1 day
Here, the ad will be seen (called
impression) by the same user maximum 5 times a day. From advertiser side, the unique users who sees the ad will increase by setting up the frequency cap.
Period / Duration
Majorly, there are two possible duration can be set fro Frequency cap
Number of impression per user per (DaY or Week or 15 Days etc)
Number of impressions per user for lifetime of the campaign
In many platform it refers to average frequency can be set or viewed at the end of campaign. For example
Average frequency=1.5 It means on average all audiences have seen the ad 1.5 times.
For example If you see the end result of a successful campaign after setting an avg. frequency to 2. It is possible as result that;
large number of the audience have seen the ad around 2 times and;
small number of audiences have seen the ad more than 2 times
Redis works as in-memory Key=Value date store. However, to solve this purpose Redis being K=V datastore isn't sufficient. Redis gives a feature of replication as well where you can define read-replicas to make your computing distributed. Now here, in-memory data-store and replication makes a perfect combination to solve this problem.
There are multiple ways to solve this problem, each ad-tech organization has their own level of difficulty & challenges on top of frequency cap. However, this is one of the approaches to study and refer to how to solve the frequency cap implementation in advertising in-general without having much complexity around it.
There are 3 main parts to maintain in-order to solve this problem:
Campaign may provide maximum frquecny target(or cap) number, it becomes the maximum target for the
bid-servers to follow. In the above example, target frequency for campaign 1234
maxFreqCampaign_ is shared using redis, written to master makes it available to all the slaves immediately (eventually consistent). And each bid-servers has to follow the given target for the campaign.
Redis plays a key role in maintaining and sharing counters with their latest value. Each bid-server follows the counters to take decision on received ad-requests. Counter has to be updated with the latest values representing userID and campaignID. Whenever the impression confirmation comes to the endpoint/server for any ad being seen by the user. It is required to increment the counter for that user's pair right away. So that whenever new upcoming requests comes to the bid-server, it gets checked agains the latest counters with it's target cap. Delivering updated counter values in real-time can be done by Redis and it fits exactly as expected.
Real-time updates & re-setting
As mentioned above, to process request faster and efficiently, the mentioned counters requires real-time updates on values. Counters gets updated in Redis master and gets synced to read-replicas exist in each bid-servers. Here Bid-servers are able to read latest values from the same instance, hence it's faster and no need to worry about the network latency.
Resetting requires when the provided duration (period) ends. For example 1Day/1Week/etc. Resetting includes action of flushing all the counters in master, it will force imp-server to start those counters again from 0 for each user per campaign, to achieve periodic goal of frequency.
The main risk-factor is the time between bidder bids to the ad-request and server receives the win/impression notification for it. Larger the
wait-time, bigger the risk. However, usually impression notification will be received by server within few seconds for 95-98% of the time.
Wait-time delays the counter to update, so during this wait-time if same user appears again, bidder-server may send the same advertisement again. But it's very unlikely to happen that often hence this is one of the balanced good solution to go with.