Discussions

### 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.

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.

Sprig does not use cookies in any capacity. Instead of cookies, Sprig uses browser local storage to track the Sprig visitor ID, and IndexedDB as part of our session replay feature.

For security and privacy, Sprig does not track any PII by default. Sprig’s Web SDK tracks the following default attributes for performance, and to help segment your visitors: - Web browser and version - Device - Session count - Page URL - Screen size - Browser language - Operating System and Version