For verifying we can look at the local-storage for the entry with the prefix spr-chat-token. Which will be sent in the api calls in the header x-chat-token

For verifying we can look at the local-storage for the entry with the prefix spr-chat-token.

1. User Profile Details

   1. One can paste in the cookie token in the JWT.IO to check what exactly it contains.

1. Currently below are the sizing based on the creative type

   1. Feedback Button

      1. Web View  

         1. width - 560px

         2. height - 65vh

      2. Mobile View 

         1. Width - 100vw

         2. Height - 80%

   2. Popup Creative / Popup Direct Display

      1. Web View 

         1. Height - 64vh

         2. width - 560px

      2. Mobile View

         1. Height - 64vh

         2. width - 100% - Some Buffer

   3. Positioned Popup / Direct Display

      1. Web View 

         1. Height - 65vh

         2. Width - Maximum of 560px and popup width configured in creative Builder

      2. Mobile View

         1. Height - 85vh

         2. Width - 100vw

For each intercept event like intercept triggered we store event in BE database along with the user ID. When we evaluate whether to show an intercept, the backend checks the intercept’s configured conditions against the current user. For intercept event-based conditions like Intercept Triggered, we look up whether that user has already had that event for the given intercept (and apply any time-based rule, such as frequency or cooldown). These event checks are combined with other conditions like URL, device, page behaviour, and schedule. The intercept is shown only if all configured conditions are satisfied.

hydration errors are just the warnings that what is rendered on the server is having a mismatch with the client rendered one, so react switches to client side rendering. They should not break anything in the production, they arrive due to server side mismatch of the rendered HTML

No. Website survey triggering does not depend on customer-identifiable attributes. Surveys can be triggered using behavioural conditions, page interactions, session events, exit intent, or SDK-driven custom events. Customer identity is optional and is only required when customers want authenticated-user targeting, profile stitching, or response attribution

The Website Distribution implementation uses the existing Sprinklr web embed infrastructure, which maintains a session token for visitor continuity and survey/chat functionality. System information such as IP based geolocation, Device, OS would flow through SDK and can be reported on.

Yes. If the implementation is designed so that only approved non-PII business events, anonymous identifiers, and behavioural signals are exchanged, then it is reasonable to characterise the solution as a PII-free SDK implementation. The Website Distribution SDK does not inherently require personal information for survey triggering. PII is only involved when customers choose to enable optional profile authentication, response stitching, or identity-based targeting

Survey is rendered via iFrame setup