There is currently no default way to have an in-app message removed from the message stream when the user leaves the audience that initially triggered it. This is fine for messages which should be kept permanently, but there may be a requirement for a contextual message that should only live for the duration of time the user is a member of the audience. Examples of such messages could be -
- Messages directed towards users of an old operating system version which should be removed once the user upgrades.
- Offers or discounts which should be removed if/when the user claims them.
- Any temporary message which becomes irrelevant when the user leaves the audience.
it's possible to implement a solution which suppressed the message on audience exit by using a combination of Custom Message Attributes and custom handlers within the app code to inspect the message before it is displayed:
1. Create two automated messages for the same audience and have one trigger on audience entry and one on audience exit. Each message should contain a message attribute key pair with values of "entry" and "exit" respectively. The key of the attribute should describe the pair so that it can be differentiated from other messages. For example, if the audience is segmenting any user running iOS 10, the key for both messages could be named "iOS10".
2. Using custom message handling, inspect and loop through each available message in the app code before displaying it to the user using the following logic -
- If a message attribute is present, inspect its value. If "entry", check all other messages for a corresponding "exit" value for its key name.
- If "entry" exists without "exit", display it.
- If both "entry" and "exit" exists, display neither.
- If no message attribute exists, display as normal.
This allows the app to determine which in-app messages to display to the user each time the message stream loads, based on whether the user is a current member of the audience.
Note that if the nature of the audience is of something where the user can enter and exit multiple times, you may want to consider allowing for this in the app code by counting the number of entry and exit values present and acting accordingly. For example, if there are more "entry" messages than "exit" messages the message should be displayed and if there are an equal amount of "entry" and "exit" messages the messages should be suppressed.