Triggering IAMs in Canvas - Questions from Braze Product Team

Love that you're working on this. Is there an ETA on this?

Regarding your questions:

1. I'd chose approach 1 as it gives more flexibility
2. I think both approaches are a significant improvement to Canvas, so 2
3. I'd say 4. Having campaigns/SDKs synch on session start only is a limitation for all real-time cases as well as cases that need to work within one session (e.g. have different 1st session on-boarding depending on what user does within the first session)
4. Yes, probably.
5. We're a news app so users come several times during the day. We'd be interested to see if we could setup metering/dynamic paywall cases using Braze, once this functionality is available.

Thanks everyone for the responses! We've been using them to design the solution.

No detailed news yet on this feature, but it's something we plan to work on.

Hi Rishi, curious if there's any news to share about this functionality? Thanks!

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

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.

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.

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. 

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.  

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?

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.