How often does your marketing team send out communications to a subscriber? Are the subscribers in your database getting too many emails in a week? Does this lead to many unsubscribes and deliverability problems? Are you able to control the emails that are sent to a subscriber for a specific duration? We can help resolve this through the technique of Frequency Filtering.
There are multiple ways you can achieve Frequency Filtering – and the solutions can vary for each organization depending on their processes. In this article, we will look at a simple approach on how to implement Frequency Filtering in your Salesforce Marketing Cloud account using the following steps:
Now, let’s look at the detailed steps on how to set this up in your instance. For this solution, we will assume that you wish to restrict emails being sent more than once per day to a subscriber – i.e.
You can tweak these values on the solution as needed – for e.g. some organizations may need the Frequency Duration to be Weekly – i.e. subscribers should receive an email only once a week.
The Pre-Configuration step involves creation of a Profile Attribute to capture the number of maximum Email Sends per duration that should be allowed for a subscriber. You may keep this attribute as hidden if your marketing team would like to control the send frequency. However, if you wish to give the subscribers the option to control the frequency of with which they may receive emails, then this field can be exposed on the Profile Center.
Once the MaxDailyEmailSendCnt profile attribute has been saved, we can move to the next step – which is where we filter the Email Send data based on the desired Frequency Duration.
Send Data Filtering
Option 1: SendLog and Filter Activity
In the case that your organization is using Send Logging, then you may use the SendLog Data Extension to retrieve the Email Send information.
The SendLog DE would now store all Email Send details for the Account / Business Unit (depends on how it has been previously configured). We can filter this Email Send Data for a specific duration and then use the same for the final Exclusion step.
This Filter would segment and provide all subscribers in the SendLog DE that has a SendDate value of the current date – which means, all subscribers who were sent emails today.
Now if you want a different Frequency Duration – let’s say 7 days instead of daily, then all you need to do is change the Filter criteria in this step accordingly. For e.g. you can check for the “SendDate to be after Today – 7 Days”.
Sometimes, you may have a business scenario where you do not want Triggered Sends to be counted towards the Frequency Filtering as it may be used for sending transactional emails. In this case, you can add the Filter criteria to include only the records that have an empty TriggeredSendID. The resulting records in the Filtered Data Extension would not have any subscribers that were the recipients of a Triggered Send – however if they also did receive a non-Triggered Send email, then their record would populate in the data extension.
Please do note that a Filter Activity overwrites the data in the target Data Extension (in our case TodaysSendDE) – so as long as the Filter criteria is met, the data will be populated in the target DE. You will need to choose the appropriate times when this Activity should run daily (probably in between multiple Email Sends that you have) in order to have the updated data available for Exclusion.
Option 2: Data views and Query Activity
In case your organization is not using Send Logging, or you are unable to get all Email Send info in the SendLog DE, then we have another option to retrieve the Subscriber Send information. This time, we will use the System DataViews and a Query Activity.
Now that we have the Email Send information for the desired Frequency Duration in the TodaysSendDE Data Extension, let’s see how we can use this for excluding subscribers from being sent emails beyond the limit that we have set in the Profile Attributes (as part of Pre-Configuration).
In the desired Email Send definition(s), under Target Audience, include the Exclusion Script as shown below:
This Exclusion Script uses AMPscript functions – if the condition in an Exclusion Script evaluates to True, then the Subscriber is excluded from the current Send. The script is evaluated for each individual Subscriber that is in the Target Data Extension of the Send.
The Exclusion Script uses the following functions:
In summary, the Exclusion Script checks for the number of rows a Subscriber has in the TodaysSendDE (which has the list of all subscribers that was sent emails in the desired Frequency Duration – e.g. Daily, Weekly, etc.) and if this is greater than the value that was set in the Profile AttributeMaxDailyEmailSendCntto control Send Frequency, then the condition will return true and the Subscriber will be excluded from the Send.
Let’s say we have a Subscriber A that hasMaxDailyEmailSendCnt = 1and was already sent an email today. If we are going with a Daily Frequency Duration, then we can run the automation workflow and have his data added to the TodaysSendDE. Subsequently, if the Exclusion Script is added for the next Send today, then the condition would return TRUE as (1 >= 1) for this Subscriber A – and hence he would be excluded for this and all future sends today.
We have now seen how we can set up a Frequency Filtering mechanism in our Salesforce Marketing Cloud account. In order to change the limit for the Frequency Duration, teams can just change the profile attribute value. In the above solution, we have used Email Address for the lookup condition – this means that if we have multiple subscribers with the same email id (for e.g. say members of a household), then all of them would be restricted from the subsequent sends based on Frequency Filtering.
In case you wish to use the Subscriber Key instead of the Email Address, then you can use the _subscriberkey system attribute in the Exclusion Script as shown below:
Overall, a marketing team or the ones formulating the strategy whether they are internal resources or agency partners must take into account the number of records in the SendLog or the DataView Query before implementing this solution.
In scenarios where the size of the audience is too large and it may not be feasible to run Refresh and query activities multiple times, then this solution may not be feasible. This is because the effort involved for larger projects may be too complex at times that leaves it open to human error without sufficient time for quality assurance to occur.