The ForeSee® Web SDK is used to implement the suite of measurement tools for desktop, mobile, and tablet websites, Feedback projects, and Replay.
Our ForeSee code has been designed with performance, security, and reliability in mind. Refer to this article for details.
- Google Mobile Invitation policy change on Jan 10, 2017.
- Updated mobile invitation look and feel.
- Ability to customize invitation.
- iOS change for mobile in Sept. 2016 prevents invitations in iOS 10.
- Latest versions work correctly in supported browsers.
- Smaller, encrypted, compressed cookie is more secure.
There are several options available for changing the look of desktop and mobile invitations. There is also an extension point for creating your own invitation. Read more about this in the Customized Invitations section.
The client code can be configured to "exclude" pages from presenting the invitation by using the following:
- URL pattern - Do not show the invitation if the URL contains '/checkout/'.
- Variable - Do not show the invitation if the page contains a variable called 'internalIP' with a value of '10.9.8.7'.
- Cookie - Do not show the invitation if there is a cookie called 'loggedIn' with a value of 'Yes'.
- userAgent - Do not show the invitation when the userAgent contains 'selenium'.
- Browser - Do not show the invitation on IE 10 browsers.
- Referring URL - Do not show the invitation if the site visitor comes from 'google.com'.
See Testing Client Code section.
We have found over the years that this is the best way to show the questionnaire only when the consumer has finished their visit to your site and is ready to provide feedback from a holistic view point. The child (tracker) window is waiting for the main window/tab to be closed or for the domain to change, and then shows the survey.
It is possible to present the survey immediately after accepting the invitation. However, this is typically reserved for questions at the end of an experience, such as a purchase.
Remove any and all references on your site to:
Then, follow the instructions for implementing the ForeSee® Web SDK. Once the legacy code has been removed, the Foresee directory/directories can also be removed. ForeSee® Cloud Deployment replaces the existing implementation.
I'm currently using ForeSee® Cloud Deployment. Should I test upgraded code before deploying to my production environment?
Yes. While you should not need to make any revisions to your code snippet or code itself, it is recommended to test the upgrade in a safe environment to ensure there is no negative impact on your site.
This is the of the two client folders hosted by ForeSee; the Staging folder and the Production folder. Whenever we upgrade the code, we do some local testing to ensure that the code is configured correctly for your business needs. We then push the new code into your ForeSee® Cloud Deployment Staging folder. This prevents any possible interruptions to your live site while you are testing.
For testing instructions, see Testing Client Code.
Contact ForeSee when your testing is complete and you are ready to deploy the upgrade to your live site. We will then push the new code to your ForeSee® Cloud Deployment Production folder.
In some cases, such as when upgrading from an 18x code (or older) package to the current version, a call does need to be scheduled for a live deployment to your Production folder in order to ensure a smooth transition to the upgraded code. In this case, your ForeSee contact will schedule a live call and web meeting with a member of our Implementation Services team and a technical resource for your organization to deploy the code.
At this time, any sampling criteria requests are handled through the ForeSee Implementation Team. Contact your analyst or send a request to email@example.com.
Data points that you have on your website may be sent with the response data. This helps with the segmentation of the satisfaction data for deeper insight. See Customer Passed Parameters for more information.
Typically we configure the re-invite period to be 90 days. However, this is configurable and may be different for those that accept the invitation and those that decline.
Yes, the four major browsers handle our child (tracker) window differently. This is expected behavior and we have provided more information in the Desktop Invitation section.
We use the WURFL device detection service to determine if a visitor is on a mobile or desktop device.