Feature Recommendation: Move InApp Message 'read' data from local storage to API

[jehartzog]

TL/DR

The read field on all InApp messages is stored locally on a single device, so this field is reset if a user logs out, and then logs back in, or switches device. We had expected this to be stored on the API, to ensure a user doesn't seen old messages already seen, even if they switch devices or have to re-auth.

Long version

We recently integrated the InApp messages to replace some of our custom built announcement features. Overall the integration went very smoothly, but there was one case where the iOS and Android sdks (and by extension, this one) worked counter to how we expected, and how the documentation implies it works.

Looking at this statement from the docs:

Iterable will not show the same in-app message to the same user more than once unless the message has been re-sent or selected in a mobile inbox.

There is a huge exception to this that wasn't clear until we completed our integration and did testing.

When a message is consumed, the SDK's update the API (android, ios)

When a message is read, no API call is made (android, ios).

These docs indicate that the only API calls made by the Iterable SDK when a Message is read is to track In-App Open event, which seems to indicate this was a deliberate decision to not create an API endpoint for storing this read data field.

Effort on our use case

This means if we leave messages in the state of not consumed but read sitting in the message inbox, if the user re-auths, switches devices, then they will re-receive all those messages as they will all be immediately reset to read = false.

Recommendation

It would be nice to have this read field stored on the API, rather than locally on the device, so that this state is persisted through app re-installs or device switches.

[jehartzog]

I realize this may not be correct place to post this. Technically this would be a change in both iOS and Android SDKs, as well as API.

[jehartzog]

Just found the place in api docs which explicitly state this:

This endpoint returns new messages and messages that have already been saved to a user’s mobile inbox. Since a message’s read status is local to a mobile device, there is not currently a way to differentiate between the two.

[roninopf]

We've now fully released this on every platform, so we'll close this out. Of course, if there's a problem, please feel free to reach out through your CSM and/or here!