Our team at Braze wants to bring real-time triggering in-app message (IAM) functionality to Canvas. Today, real-time triggering IAM functionality only exists in Campaigns.If anyone has a few minutes, we’d appreciate it if you could answer the questions in bold below. We can add you to the early access when the feature is available in exchange as well.Let me know if you have any questions and thank you in advance! Also, if you’d prefer to chat over a call, happy to do so instead (please schedule here).Thank you,Rishi Product Manager at Braze Questionnaire - Triggered IAMs in Canvas The current state of triggered IAMs: In Campaigns, marketers can specify a custom event that triggers/shows an IAM to a user in real-time In Canvas, marketers can specify a custom event within an Action Path that triggers/shows an IAM to the user once they do the following: (1) perform the action, then (2) restart the app (they’ll then see the IAM once the app opens) Our ask: We are considering one of the following approaches for providing more real-time triggered IAMs in Canvas and would like your input. Approach 1 Approach 2 Allow real-time triggering of IAMs via the Action Path Allow real-time triggering based off actions specified within an IAM Message Step Benefits: Branching actions. Marketers can define several triggers/actions that all show different IAMs and qualify the user for all of them, but only display the IAM for the first action performed (and disqualify the rest) Ranking actions. If multiple actions are performed by the user within the action path’s time window, Braze will show the associated IAM then send the user through the highest-ranked action path only Benefits: Independent control of IAM message triggers/actions. Actions will be defined within the IAM Message (similar to IAM expiration), giving the marketer more control This approach/feature is easier for Braze to build, so we can deliver it to customers faster A couple of questions for you here: Among the two approaches, which would you favor, and what are the reasons for your preference? On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach? We are also seeking feedback on how “real-time” the Canvas<>SDK information refresh/exchange needs to be. Today, the SDK (which is the agent that shows IAMs) only refreshes information from Braze when the user opens the app, and users may not necessarily open their apps as quickly as they move through a Canvas. Consider the following hypothetical example of how triggered IAMs could work: 9:00 am: In Canvas, UserA reaches the Canvas step where they are qualified to be shown IAM_1 immediately after they perform ActionX 9:20 am: UserA performs ActionX. No IAM is shown 9:30 am: UserA leaves the app and reopens it. Note: at this time, the SDK refreshes information from Braze 10 am: UserA performs ActionX. This time, they are shown IAM_1 immediately since the SDK has the latest information from Canvas The need for the user to leave/reopen the app may not be ideal, but if you feel the feature is still usable, we can deliver a first version of the feature (triggered IAMs in Canvas) to you sooner. With this in mind, we had a few additional questions: On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information? Would you still be able to use triggered IAMs if this was the case? How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?

Among the two approaches, which would you favor, and what are the reasons for your preference?Approach 2 as it provides the marketer more control on the IAM to serve to a user based on different criteria in each message stepOn a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?4 = very much disappointed. In this use case ideally if someone purchased "Shoes" I'd want to serve them an IAM right away with the next action to take in app. So having the delay of needing the SDK to refresh and serve on the next app session isn't timely and still not incredibly useful. In this case instead of sending a real time IAM for a 'purchase survey' or 'You might also like' IAM, i'd look to send a less time sensitive IAM in the canvas such as on the next app session 'Review your order' if it had been deliveredWould you still be able to use triggered IAMs if this was the case?Only for non time sensitive use cases as serving any post custom event / purchase IAM still wouldn't be possible due to the SDK refreshHow frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?Totally dependent on the app use case, some have daily usage patterns, but others have more WAU or MAU frequencies, so if i'm working with a client that tracks weekly or monthly app usage we likely wouldn't use IAM in a canvas

So good to know this is on the works!Among the two approaches, which would you favor, and what are the reasons for your preference?So Approach 2 (Allow real-time triggering based off actions specified within an IAM Message Step). It feels more specific to the use case of trying to replicate the behaviour we see in campaigns. Action paths may be useful to trigger multiple messages but the fact that we're missing in Canvas the behaviour we see in Campaigns for IAMS I feel would be better addressed if the change happens inside the IAM step.On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?Probably 2. Slightly disappointed. On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?4 = Very disappointed. Then I don't see how this is different from the current scenario where the triggering is not immediate like it happens in campaigns?Would you still be able to use triggered IAMs if this was the case?I wouldn't see any difference to how they're being used right now, so I'd have to continue to use them for cases where immediacy is not needed but with my needs not being covered. How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?Not frequently. Users average behaviour is only 1-2 days a week of using the app.

Among the two approaches, which would you favor, and what are the reasons for your preference?Approach 2 without a doubt. I get tons of clients who need this functionality. Happy to see you guys working on this!On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?4 - very disappointed. Triggered in-app messages allow for really great personalized and segmented messaging to the user in real time. This is what Braze is about and the true power of Braze. Would you still be able to use triggered IAMs if this was the case?Only for non time sensitive use cases as serving any post custom event / purchase IAM still wouldn't be possible due to the SDK refreshHow frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?Very dependent on the app, however I would argue that in the event of a fresh install and a tutorial driven in-app, you have the first sessions to capture the user. If you do not, the chances they uninstall / dont event open again grows exponentially. Give marketers the tools to do everything in their power to guide / direct / help the users complete a critical action.

Love that this is happening!Among the two approaches, which would you favor, and what are the reasons for your preference?Option 2, especially if the MVP was quicker to release for the Braze team anyhow On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?2. I'm not going to cry about it, it'll still provide a level of useful functionality and I'm sure the team would iterate on this over time to improve it. On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?4 In our use case where messages need to be delivered as the action is performed, this would reduce the usefulness of the adding triggered messaging.Would you still be able to use triggered IAMs if this was the case?Yes but it would be a lot harder to speak to users at the time they are best spoken to How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?As noted above we try to deliver messaging as close to the trigger action as possible. We may not have a user coming back for 3-7 days, at which point some messaging would become redundant.

Hi everyone, thank you so much for the responses so far. These are so helpful for me and the team.I wanted to clarify the approaches and was wondering if that would change anyone's answers.First, approach 1 can do everything approach 2 can do. In approach 1, the action path contains the trigger action and the message step contains the IAM. In approach 2, the message step contains the trigger action and the IAM. That's the only difference.Second, approach 1 can actually do a little more than approach 2, with regards to branching capabilities. For example, if you wanted to trigger different IAMs on different custom events, or the same custom event with different properties, approach 1 would be able to support this, but not approach 2.Given the above information, how would you answer the following questions? (if you'd answer differently)Among the two approaches, which would you favor, and what are the reasons for your preference?On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?

Forum Discussion

rishi

Braze Employee

11 months ago

Triggering IAMs in Canvas - Questions from Braze Product Team

Our team at Braze wants to bring real-time triggering in-app message (IAM) functionality to Canvas. Today, real-time triggering IAM functionality only exists in Campaigns.

If anyone has a few minutes, we’d appreciate it if you could answer the questions in bold below. We can add you to the early access when the feature is available in exchange as well.

Let me know if you have any questions and thank you in advance! Also, if you’d prefer to chat over a call, happy to do so instead (please schedule here).

Thank you,
Rishi

Product Manager at Braze

Questionnaire - Triggered IAMs in Canvas

The current state of triggered IAMs:

In Campaigns, marketers can specify a custom event that triggers/shows an IAM to a user in real-time
In Canvas, marketers can specify a custom event within an Action Path that triggers/shows an IAM to the user once they do the following: (1) perform the action, then (2) restart the app (they’ll then see the IAM once the app opens)

Our ask:

We are considering one of the following approaches for providing more real-time triggered IAMs in Canvas and would like your input.

Approach 1	Approach 2
Allow real-time triggering of IAMs via the Action Path	Allow real-time triggering based off actions specified within an IAM Message Step

Benefits: Branching actions. Marketers can define several triggers/actions that all show different IAMs and qualify the user for all of them, but only display the IAM for the first action performed (and disqualify the rest) Ranking actions. If multiple actions are performed by the user within the action path’s time window, Braze will show the associated IAM then send the user through the highest-ranked action path only	Benefits: Independent control of IAM message triggers/actions. Actions will be defined within the IAM Message (similar to IAM expiration), giving the marketer more control This approach/feature is easier for Braze to build, so we can deliver it to customers faster

A couple of questions for you here:

Among the two approaches, which would you favor, and what are the reasons for your preference?
On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?

We are also seeking feedback on how “real-time” the Canvas<>SDK information refresh/exchange needs to be. Today, the SDK (which is the agent that shows IAMs) only refreshes information from Braze when the user opens the app, and users may not necessarily open their apps as quickly as they move through a Canvas. Consider the following hypothetical example of how triggered IAMs could work:

9:00 am: In Canvas, UserA reaches the Canvas step where they are qualified to be shown IAM_1 immediately after they perform ActionX
9:20 am: UserA performs ActionX. No IAM is shown
9:30 am: UserA leaves the app and reopens it. Note: at this time, the SDK refreshes information from Braze
10 am: UserA performs ActionX. This time, they are shown IAM_1 immediately since the SDK has the latest information from Canvas

The need for the user to leave/reopen the app may not be ideal, but if you feel the feature is still usable, we can deliver a first version of the feature (triggered IAMs in Canvas) to you sooner. With this in mind, we had a few additional questions:

On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?
Would you still be able to use triggered IAMs if this was the case?
How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?

In-App Message

BenLerner-Paio
Specialist
11 months ago
Among the two approaches, which would you favor, and what are the reasons for your preference?
Approach 2 without a doubt. I get tons of clients who need this functionality. Happy to see you guys working on this!
On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?
4 - very disappointed. Triggered in-app messages allow for really great personalized and segmented messaging to the user in real time. This is what Braze is about and the true power of Braze.
Would you still be able to use triggered IAMs if this was the case?
Only for non time sensitive use cases as serving any post custom event / purchase IAM still wouldn't be possible due to the SDK refresh
How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?
Very dependent on the app, however I would argue that in the event of a fresh install and a tutorial driven in-app, you have the first sessions to capture the user. If you do not, the chances they uninstall / dont event open again grows exponentially. Give marketers the tools to do everything in their power to guide / direct / help the users complete a critical action.
dauradominguez
Active Member
11 months ago
So good to know this is on the works!

Among the two approaches, which would you favor, and what are the reasons for your preference?So
Approach 2 (Allow real-time triggering based off actions specified within an IAM Message Step). It feels more specific to the use case of trying to replicate the behaviour we see in campaigns. Action paths may be useful to trigger multiple messages but the fact that we're missing in Canvas the behaviour we see in Campaigns for IAMS I feel would be better addressed if the change happens inside the IAM step.
On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?
Probably 2. Slightly disappointed.

On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?
4 = Very disappointed. Then I don't see how this is different from the current scenario where the triggering is not immediate like it happens in campaigns?

Would you still be able to use triggered IAMs if this was the case?
I wouldn't see any difference to how they're being used right now, so I'd have to continue to use them for cases where immediacy is not needed but with my needs not being covered.

How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?

Not frequently. Users average behaviour is only 1-2 days a week of using the app.
BradRossman
Active Member II
11 months ago
Among the two approaches, which would you favor, and what are the reasons for your preference?
Approach 2 as it provides the marketer more control on the IAM to serve to a user based on different criteria in each message step
On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if users needed to reopen the app to allow the SDK to refresh information?
4 = very much disappointed. In this use case ideally if someone purchased "Shoes" I'd want to serve them an IAM right away with the next action to take in app. So having the delay of needing the SDK to refresh and serve on the next app session isn't timely and still not incredibly useful. In this case instead of sending a real time IAM for a 'purchase survey' or 'You might also like' IAM, i'd look to send a less time sensitive IAM in the canvas such as on the next app session 'Review your order' if it had been delivered
Would you still be able to use triggered IAMs if this was the case?
Only for non time sensitive use cases as serving any post custom event / purchase IAM still wouldn't be possible due to the SDK refresh
How frequently do your users typically leave/reopen their app? What scenarios, if any, do you foresee where users are unable to be shown IAMs due to them not reopening the app?
Totally dependent on the app use case, some have daily usage patterns, but others have more WAU or MAU frequencies, so if i'm working with a client that tracks weekly or monthly app usage we likely wouldn't use IAM in a canvas

Forum Discussion

Triggering IAMs in Canvas - Questions from Braze Product Team

Related Content

Freelance Braze Production Specialist

Product Owner II

Product Marketing Manager

Director of Product (Retention) @ CSGORoll

Sr Product Manager - Digital

Recent Discussions

Triggering IAMs in Canvas - Questions from Braze Product Team

Email HTML/CSS Consultant

IN-APP Inspiration

Find user in catalog

Canvas error - action path/event properties