Forum Discussion
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
- TedScott2 months agoSpecialist
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
Related Content
- 8 months ago
- 10 months ago
- 9 months ago
- 8 months ago