Test your Engagements
This article outlines the steps to test your engagements in different environments.
Overview
Gainsight PX recommends that you build and test your engagements on the staging environment as well as the production version of your product.
You need to test your engagements in your production environment in order to minimize engagement performance issues as there might be subtle differences between your development or QA environments (such as CSS element class IDs and names) that can change or 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 "Charts" feature. To test it, you can also include a User filter that targets those on your team who will be testing the engagement (email that contains acme.com)
In the Schedule Criteria, use Qualification Scope so that you can test your engagement with the 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.
- Intervals: The user will see the engagement over a specified period of time. When the number of presentations is met, the engagement will be snoozed until the next interval.
- 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.
To learn more about Qualification Scope, refer to the In-app Engagement Qualification Scope article from the Additional Resources section.
Method 2: Preview Mode
This test method is used to see how the engagement will look and behave in your selected environment. It ignores the audience criteria so that you can preview the engagement.
On the engagement header, click the preview icon to launch your engagement.
Ready to Deploy
Perform the following deployment steps to ensure a foolproof launching of your engagement:
- Remove the Audience criteria that targeted only your team.
- Ensure that the Qualification Scope is set to only once.
- Rename the Engagement Name (such as [LIVE] New User Guide)
- Launch the engagement.
Apply Role-Based Access Control
Gainsight PX provides powerful role-based access control. Gainsight PX recommends to apply role-based access control and assign different permissions to the relevant users.
Notes:
- The granularity of role-based access control varies from instrumentation, admin settings, engagement to template creation.
- Template Manager is capable of creating and controlling in-app and email templates.
- Engagement is split into the viewer, editor, and manager. Users with manager permissions are allowed to launch in-app.
To learn about all frequently asked questions, refer In-App Engagements FAQs article from the Additional Resources section.
Additional Resources
| In-app Engagement Qualification Scope |
| In-App Engagements FAQs |
| NPS, Net Promoter, and Net Promoter Score are registered trademarks of Satmetrix Systems, Inc., Bain & Company and Fred Reichheld. |