The Test tab seeks to represent a general depiction of how the in-app will be rendered, without taking into account specific device measurements or your application setup. You can use our preview generation feature to achieve a more accurate result, but the best representation should be achieved by testing the in-app live in your mobile application.
Barring setup errors, there are several cases in which the in-app may not be shown.
- The in-apps are fetched and subsequently shown from the platform after the customer has been identified in the app, using built-in mobile SDK methods.
- The in-apps are also cached in the application to reduce the number of requests your application needs to make to the platform.
- The in-apps are reloaded on customer identification, anonymization, or when any event (except a campaign with status open or clicked, or a session_end) is tracked from the application
- The In-app messages cache is older than 30 minutes.
In practice, it may lead to a situation when the trigger event for the in-app has been tracked before the customer identification. Then the identification happens later but no other trigger events are being tracked. In this case, the in-app will not be shown as the only trigger event was tracked before the in-app was loaded to the application
Please keep in mind these rules when working with in-app messages. You can always refer to the SDK Github documentation:
- Set up individual ratings as static links, then track these clicks as events.
- Combine buttons and custom in-app action SDK methods to build the logic fully in the application code, then track the rating as an event.
Updated 28 days ago
You can find more information about using In-App messages in the following articles.