Discussions

Sprig recommends keeping your logo under the following specs: - Width: 555 pixels - Height: 250 pixels - Size: 10MB When uploaded, Sprig will convert your logo to a PNG, but will not compress the file size or ratio as long as all of the previously mentioned criteria is met.

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.