Forum Discussion

rishi's avatar
rishi
Braze Employee
2 years 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:

  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?

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?

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

  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?

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

  • 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's avatar
    BradRossman
    Active Member II

    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

     

    • TedScott's avatar
      TedScott
      Specialist

      This is exciting news!

      Clarifying question, are you only talking about mobile sdk (in-app messaging) or are you also including web/jsdk (in-browser messaging).

      Thank you