Discussions

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.

Developers will often choose to send a foreign key or reference ID to Sprig, instead of the exact user ID stored in their services. While a foreign key is not a strict requirement, Sprig is fully flexible in meeting companies’ security practices and needs.

For any sensitive data that users do not want exposed or surfaced in their application, Sprig offers a REST API. The `/users/` endpoint allows teams to create, or update, visitor records from your backend. If the `userId` sent to the API does not already exist in the specified environment, a new visitor record will be created. If the `userId` already exists, any new data will be appended to that visitor record.