Triggering IAMs in Canvas - Questions from Braze Product Team

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?

1. 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?

1. 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?

1. 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?

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.

Love that this is happening!

1. 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 

2. 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.

1. 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.

2. 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 

3. 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)

1. Among the two approaches, which would you favor, and what are the reasons for your preference?

2. On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?

Very excited for this feature.

1. Among the two approaches, which would you favor, and what are the reasons for your preference
   
   Approach 2. It gives the marketer more control over how and when we want messages to show. Action Paths are great there are instances where we might want more than one IAM to show depending on a user's actions. 

2. 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 - a little bit. It would still be a marked improvement being able to have real time IAMs. 

1. 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. It's not fit for purpose for a lot of the use cases I can think of where we need actual real time triggered messages. 

2. Would you still be able to use triggered IAMs if this was the case?
   Yes but not for time-sensitive messaging.

3. 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?
   Reopens aren't frequent - we talk in MAU, not DAU.  This would limit IAM usefulness in canvases for onboarding, post transaction flows (i.e. you now have access to XY&Z), error events (i.e. helping with troubleshooting) to name a few.  

The update we've been waiting for-excited to see this one coming! 

1. Among the two approaches, which would you favor, and what are the reasons for your preference?
   Provided approach one can do everything that approach two can do, then approach one because it will allow us to use specific event properties to trigger the IAM. 

2. 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

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:

1. 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?
   3- it really removes the utility if we have to get the user back an app. We'd better using another channel. If refresh can't be achieved without closing/opening, perhaps we could have the ability to query the message queue as we do with content cards 

2. Would you still be able to use triggered IAMs if this was the case?
   Yes but it would be the same as our use today which is relatively limited because of this.

3. 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?
   We send a lot of time sensitive deals, typically expiring within 24 hours. We see that our best users will create a session a day, and are most likely to be unsubscribed to email so we'd miss a large amount of organic traffic. 

1. Among the two approaches, which would you favor, and what are the reasons for your preference?
   I prefer option 1 as it allows for the most flexibility, however option 2 still would have a ton of use-cases for messages that don't need to be send in order.

2. On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?
   3, I think the approach where the decision-making is built into the message component makes a canvas less readable. However, any approach to making in-app message real-time in a Canvas is super 🙂

3. 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, how is that different from the current situation? Reopening the app uncouples the in-app message from the user behaviour.

4. Would you still be able to use triggered IAMs if this was the case?
   No

5. 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?
   User visit our app at most once or twice a day, that means the chance of them reopening the app on the same day is very low. So the message would be delivered uncoupled from the action, making a action-based campaign an option that currently exists.

Among the two approaches, which would you favor, and what are the reasons for your preference?

Approach 2. Much more valuable for our use cases 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 we implemented the other approach?

4 = very disappointed. Approach 1 doesn't provide nearly as much value to our team.

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. We would want to serve them an IAM right away with the next action to take in app. 

Would you still be able to use triggered IAMs if this was the case?

Yes, it just wouldn't be ideal. 

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?

They leave and reopen fairly often but for the purpose of IAMs in a canvas, we'd want immediate action.

Sounds really nice! It's a feature we're really looking into as we use a lot of in-app messaging and it's always a pain to create additional IAM campaigns for large flows.

1. Among the two approaches, which would you favor, and what are the reasons for your preference?

Approach 2 might be a good solution, but how would I control that a user stays in the canvas step? What if I need to keep the IAM in the application longer than the canvas flow? How do I make sure that a customer has not already entered the next step? Would the IAM still be possible to get triggered?

However, the downside of approach 1 would be that customers could only get 1 IAM with the ranking and I like to have more control, so approach 2 would be the best option.

2. On a scale of 1-4 (1 = not at all, 4 = very much), how disappointed would you be if we implemented the other approach?

Since both approaches would be great -> 2

3. 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?

Clear a 4. Our goal is to keep the customer in the app and show the right communication at the right time. Reopening the app would mean that we would not be able to verify that the customer received the correct communication during the journey.

4. Would you still be able to use triggered IAMs if this was the case?

Would use campaigns

5. 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 often in one session. When they open the app, they usually stay in the app to complete their order. They may close and re-open to check competitors.

Really looking forward to test this new IAM approach! That would make many lives easier ;).