Discussions

This setting is used to dictate how surveys should display and be dismissed with respect to your web application. It can be enabled or disabled for each of your Products within Sprig, by going to `Settings > Configure` in your dashboard and toggling the setting from the `Dismiss on Page Change` section: - When enabled, Sprig will only show a survey if the visitor is still on the same page (URL) that the survey was triggered on. This means that a visitor navigating to another page, before the survey displays, will not see the survey. - When disabled, Sprig will show a survey to your visitor regardless of whether or not your App's URL has changed.

### For web surveys: When an event is tracked through the Sprig Web SDK, we'll return a JSON payload as part of the response. Please note that the recontact waiting period is not enforced in development environments. Inside this payload, you can check the `questions[]` key: - An empty array denotes that the visitor is not eligible for a survey. - If you are expecting a survey to be seen, double check the visitor ID (e.g. `Sprig.visitorID` in your console, or local storage) and ensure you meet all the event and attribute criteria on your survey. - An array of questions denotes that the visitor was seen as eligible for a survey. - If a time delay is set on the survey, we will then wait for that amount of time to lapse before attempting to surface the survey to your visitor. ### For mobile surveys: When an event is tracked through the Sprig iOS or Android SDK, we'll return a JSON payload as part of the response. Please note that the recontact waiting period is not enforced in development environments. If you are able to examine the payload, you can check the `questions[]` key, similar to the Web SDK, to see whether or not a visitor is eligible for a survey. If a survey is not appearing, please double check that you are setting the necessary events and attributes to make your testing visitor record eligible for the survey.

For testing purposes, a Sprig visitor record will always see a survey in development Sprig environments, as long as they meet the qualifying event and attribute filters, regardless of when they last saw a prior survey. The recontact waiting period is enforced in production Sprig environments, and will not show a survey to a Sprig visitor record based on the recontact waiting period defined in your Settings.

Attributes, including the visitor’s user ID, can be sent whenever a visitor is identified. This can be done on instances such as every time a visitor logs in to their account, or as they meet criteria for new segments based on their interactions within your application. Whenever an attribute is set, that value will override any previous existing value. Please see this article for more information on sending sensitive data or server attributes to Sprig.

We suggest sending events to Sprig as they occur. Events should track actions or interactions within your application, such as viewing a certain page, using different modals, or other tracked interactions like scroll depth and exit intent. Sprig’s no code events system can be used to target visitors viewing different pages based on URLs, clicking on elements with specified text, or different HTML elements (e.g. buttons, widgets) through CSS. Teams can use the Sprig API to send asynchronous or server-side tracked events. Similar to the SDK, these events can be sent to us as they occur, or part of a batched job that sends events for each of your users on a recurring cadence.

As new features such as new question types are rolled out, these changes may require an updated version of the SDK on your application. Sprig tracks the visitor’s current SDK version, as part of determining whether or not they are eligible to see a survey. Visitors on an older version of the SDK will be unable to receive or respond to any surveys requiring a newer version, but are still eligible to receive any surveys which they meet all criteria for. The dashboard will warn you of potential SDK compatibilities when creating a survey, and will show you the expected percentage of visitors who can receive a survey based on the questions and features you are using.

User IDs can be anonymized via encryption before being passed to Sprig. When data is exported from Sprig those encrypted IDs can then be decrypted off-platform for reference.

Sprig offers a package through NPM or Yarn, which allows engineers to bundle and host a copy of the Sprig Web SDK as part of your web application. This allows your engineering team to use a static version of Sprig, and receive new updates and features as needed.

Sprig offers customers the ability to choose how often individual users can receive Sprig studies. This is done by adjusting the Recontact Waiting Period on the Settings page. The Recontact Waiting Period is the minimum number of days Sprig waits after a user receives a study before sending them another study.

Once an engineering team has set up Sprig on their application, to track events and attributes, there is no additional work needed to create or launch surveys. Surveys can be launched and maintained solely from within your Sprig dashboard. Sprig often releases new features and new survey question types. Engineering teams can update the Sprig SDK version used in their applications to take advantage of those upgrades. As teams find expanded or new use cases for collecting feedback, engineering teams may be needed to track new visitor events and attributes to qualify visitors into those surveys.