Frequency Policy

Campaign frequency management is important to ensure your customers don’t get overloaded by your campaigns. Exponea’s frequency policies allow you to set generic frequency rules for the entire audience or intelligently limit the number of campaigns by dynamically adapting to the customer's level of interactions and engagement. This is so that customers are informed – but not overwhelmed. The reduction of the frequency of emails is a proven tactic for re-engaging a less engaged audience.

Exponea offers a pre-built “Smart Newsletter Policy” that you can use out of the box, but you can also edit or create your own segments and adjust the rules for those separately.

Setting up frequency policies

To create frequency policies, go to Settings > Project settings > Privacy management > Frequency policy. You can choose multiple settings for a single policy. To do so, click on the edit button.

Policies

A single policy is identified using a unique ID (used in campaign events, property name campaign_policy), a user-facing name, and at least one segment with defined limits.

Each defined policy can then be applied in a campaign. All the different campaigns that have the same frequency policy set, will respect the policy limits together. For example, if the policy limit is no more than 2 campaigns a day and we have 3 campaigns triggered that day for the same customer using this policy, the first two campaigns will be sent out, while the third one will not be sent, in the order of when the campaigns are triggered. Campaigns that have different frequency policies will not influence each other's volumes.

Frequency policies can be set up for email campaigns or scenario action nodes (SMS campaigns, webhooks, mobile and browser notifications) under the Settings tab.

Segments

Each policy can contain multiple segments that will define the policy's behavior for customers matching the segment. Simpler policies will use just a single segment matching all customers, with the same set of rules applying to all customers. Different customers may, however, have different preferences, so you may define multiple segments (using customer filters) with different rules. So for example, one segment matching customers with a high email open rate may allow multiple emails per week, while the segment catching the rest of customers with a low open rate will limit the communication to just one email per week.

One policy may contain up to 12 segments. The last segment must always catch the rest of the customers, i.e. those not matched by any of the previous segments.

Max. messages per customer/period

Max. messages per customer/period define how many messages can be sent within a relative time frame. It is composed of an integer limit and a duration, for example, 3 messages per 7 days. Up to 4 different rules may be defined per one segment, once at least one of the rules is fulfilled the messages will not be sent.

You can choose from 6 relative time periods: minutes, hours, days (24 hours), weeks (7 days), months, and years. The periods are evaluated as relative time frames such as 1 day means in 24 hours - e.g. if your campaign was sent at 2 p.m., the policy does not reset at midnight for this specific subscriber, but at 2 p.m. the next day.

A limit of 0 per any duration can be used to suppress all communication for a segment. It's also possible for a segment to define no 'max. messages per customer/period' constraints, which means no communication limits will be imposed.

Smart newsletter policy

With the help of our email deliverability experts and data scientists, we have created an out-of-the-box email sending policy that can be used for e.g. newsletters. It is designed to limit the number of emails sent to inactive and lapsing segments, but distinguish those who recently visited the website. Also, it identifies the segment of subscribers that opens a majority of the emails they receive, who can receive an extra email per day.

Updated 6 months ago

Frequency Policy


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.


We rely on cookies

to optimize our communication and to enhance your customer experience. By clicking on the Accept and Close button, you agree to the collection of cookies. You can also adjust your preferences by clicking on Manage Preferences. For more information please see our Privacy policy.

Manage cookies
Accept & close

Cookies preferences

Accept & close
Back