The Gainsight PX team recommends that you build and test your engagements on the staging environment as well as production version of your product.
Testing on production is safe and advised 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 and Test before Going Live with your Engagements
Gainsight PX recommends the following workflow / process:
Build and 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 Qualification Scope so that you can test your engagement with below options:
- Only Once: Choosing this scope means the user will see the engagement a single time across any number of visits under the specified date range.
- Once per visit: Choosing this scope means the user will be qualified once per visit, mostly used for 'continues critical announcements' or testing purposes.
- Every Time (Every Event): Choosing this scope means the user will be qualified on every event level, mostly used for 'Paywall or access control'.
For Every Time (Every Event) tracking usage: Gainsight PX tracks all events once per visit. For example, if the user completes NPS Survey multiple times, Gainsight PX considers and counts it only once.
- Show Attempts: Choosing this scope means the user will see the engagement every
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 Qualification scope to Only Once (so that your users only see the engagement once)
- Rename the Engagement Name (i.e. [LIVE] New User Guide)
- Launch the engagement
Apply Role Based Access Control
Gainsight PX provides powerful role based access control. It is advised to apply role based access control and assign different permissions to the relevant users. Note that its granularity varies from instrumentation, admin settings, engagement to template creation.
- Template Manager is able to create and control in-app & email templates
- Engagement is split to viewer, editor and manager. Users with manager permissions are allowed to launch and in-app.
To learn about all frequently asked questions, refer In-App Engagements FAQs article.