Leanplum's user guides and developer documentation.

Leanplum Documentation

Leanplum's user guides, SDK setup, API docs, and more resources are here to help you get the most out of A/B testing, Campaigns, Messaging, and Analytics.

Limiting message sends with targets

Delivery caps and limits allow you to control the number of messages a user will receive, but you can also use some strategic target phrases to limit messages sends.

Target with Occurrences of Event

You can limit the number of times some triggered messages are sent to a single user with the Targeting of your message.

  1. Set Target segment for your new message as Behavioral > Occurrences of Event.
  1. Select the Event for your specific message (e.g. "Occurrences of CartMessage view").


The messages you are trying to limit must have Events associated with them to use targeting. Leanplum will automatically create an event for your new message when you send the message to preview on one of your devices.

  1. Set the operator and values for your target (e.g. "Occurrences of CartMessage View" is less than 3).

Using the "less than 3" operator for will exclude users who have already received your message three or more times.

Things to consider when using targets to limit sends:


Triggered in-app and Inbox messages may be delivered more than the Target limit.

Targets for in-app messages and app inbox messages are synced and evaluated at app start. So, if a user falls into your target segment at the beginning of their session, they will be eligible to trigger your message an unlimited number of times until their next session starts, when their target status is re-evaluated.

This means that in-app or app inbox message may be delivered more than the Target number of occurrences within a single session. If you want to limit delivery of an in-app or inbox message within a single session, you should use the delivery limit in your message’s delivery settings. See Limit how often a user can receive messages for more.

Example: Let’s say your Target segment for the in-app message “CartMessage” is set to “Occurrences of CartMessage Send is less than 3.”

If a user has only received this message once, they will fall into your target segment, and the message will be synced to their device.

Now, if that same user triggers CartMessage to send six more times in a single session, the message will send all six times, breaking our limit of less than three sends. This is because Leanplum won’t re-evaluate the user’s target criteria until the next session starts.


This is only true for triggered in-app and app inbox messages. Targets for push notifications and email messages, unlike in-app and app inbox messages, are evaluated at the time of the send. This means the target criteria will be updated and followed as soon as the user triggers the message. In the example above, if the message was an email or push notification, the user would only receive the message a maximum of 3 times.

See How and when are targets evaluated? for more.

Delivery limits for individual message sends

Our built-in Delivery limits feature will apply as soon as the user reaches the limit for an In-app message. All the delivery settings will be synced with the message at app start. Limits can be applied to any message with triggered delivery.

So, if you set a delivery limit of “Up to 3 times ever,” the user won’t receive the message after the fourth trigger, regardless of whether or not the triggers all happened in a single session.


Users who have multiple devices may trigger an in-app or app inbox message more than the delivery limit. For example, if your limit is "Up to 5 times ever," a user could fire a message 3 times on an iPad + 4 times on a phone = 7 total sends.

If you need to prevent users from receiving the same in-app message across multiple devices, consider using the Target phrase instead of the delivery limit.

Updated 3 years ago

Limiting message sends with targets

Suggested Edits are limited on API Reference Pages

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