Testing your Engagements

Updated 2 months ago by Angelo Matheou

The Aptrinsic team recommends that you build and test your engagements on the production version of your product (and not on a DEV or QA version).

This is a key recommendation in order to minimize issues when building, testing and deploying your engagements as your dev or qa environments may contain subtle differences (i.e. css element class id's and names) that could change / break the behavior of your engagement.

How to Safely Build & Test before Going Live with your Engagements

Aptrinsic recommends the following workflow / process:

Build & Test

  • Use a Naming Convention (i.e. [TESTING] New User Guide )
  • Build your engagement and test using one or both of these methods:

Method 1: Targeted Audience

This test method is used to confirm that the engagement will launch at the desired time. For example, you may want to launch a guide when a user activates a feature in real time. Therefore, you may want to test this against just your user before launching it live for all of your users.

In the below screenshot, you see the Audience Criteria for the engagement defines the engagement to launch when a user activates the "Reports" feature. To test it, you can also include a User filter that targets those on your team who will be testing the engagement (i.e. email contains acme.com)

In the Schedule Criteria, use Session Scope so that you can test your engagement multiple times by clearing your cookie

Method 2: Preview Mode

This test method is used to see how the engagement will look like & behave in your product. It ignores the audience criteria so you can preview the engagement.

In the engagement editor, click on the preview icon to launch your engagement.

Ready to Deploy

  • Remove the Audience criteria that targeted only your team
  • Change session scope to User (so that your users only see the engagement once)
  • Rename the Engagement Name (i.e. [LIVE] New User Guide )
  • Launch the engagement


How did we do?