Does anyone know a way to prevent this from happening?
Not sure if anyone else has come across this issue before, but we have noticed that if we add the Gainsight tracking links into emails when a customer clicks on the link they are taken to an unsecure page - screenshot below.
Does anyone know a way to prevent this from happening?
Does anyone know a way to prevent this from happening?
Page 1 / 1
I've experienced this before and had to remove the Link Tracking to ensure the links were working.
Thanks, Kate! We've removed the links for now and are hoping to use them in the future once this is fixed.
Based on the error it looks there is problem with the web certificate. If you click on the "Not Secure" in the address bar then Certificates you should be able to see the chain of trust to determine which certificate is the problem and likely needs to be rebuild.
This is what shows in Safari
Hi Elisa,
Is this for a survey by chance? I checked and your company has white labelling all configured so there shouldn't be any issues with the links. If this is happening for end users and not just for you on your company network the most common reason I have found this happens is in 1.0 surveys where there is a mismatch between the published survey url and what is setup as the survey site in SFDC.
For example, most SFDC sites are http but I have seen this when "https" is published in Gainsight for the survey site. Even though the "Require https connections" is required for the survey page, the initial mismatch between what is clicked and the initial http site is enough for Chrome to see it as a unsecure site. If you are using 1.0 surveys this doc should help show you how to see what is set up in SFDC to check this!
To further test, try removing the "s" from https from the link in the url bar screenshot that you shared and see if the link works.
Is this for a survey by chance? I checked and your company has white labelling all configured so there shouldn't be any issues with the links. If this is happening for end users and not just for you on your company network the most common reason I have found this happens is in 1.0 surveys where there is a mismatch between the published survey url and what is setup as the survey site in SFDC.
For example, most SFDC sites are http but I have seen this when "https" is published in Gainsight for the survey site. Even though the "Require https connections" is required for the survey page, the initial mismatch between what is clicked and the initial http site is enough for Chrome to see it as a unsecure site. If you are using 1.0 surveys this doc should help show you how to see what is set up in SFDC to check this!
To further test, try removing the "s" from https from the link in the url bar screenshot that you shared and see if the link works.
Hey Alex,
Thanks for the context. It is happening on marketing drip emails that are sent through JO. I can't get the error to repro, but all the users on the marketing team are recieving this error. We haven't sent it out to end users because we don't want to risk them encountering an "unsecure" site.
We do use Surveys 1.0 but haven't encountered this in any of the survey programs.
Thanks for the context. It is happening on marketing drip emails that are sent through JO. I can't get the error to repro, but all the users on the marketing team are recieving this error. We haven't sent it out to end users because we don't want to risk them encountering an "unsecure" site.
We do use Surveys 1.0 but haven't encountered this in any of the survey programs.
Hey Alex,
I am experiencing a similar issue with surveys and link tracking during JO testing. I have communicated with some GS contacts in the past and they have mentioned the 'White Labeling' that you mention above.
I am concerned with requiring our customers to white label the links in order to get the desired customer experience through our digital outreach. I have realized similar to Elisa and Kate, that when I remove the 'link tracking' option that the link acts correctly.
Do you know of any way to navigate this issue, retain the link tracking, and not require customers to 'White Label' the URL?
I am experiencing a similar issue with surveys and link tracking during JO testing. I have communicated with some GS contacts in the past and they have mentioned the 'White Labeling' that you mention above.
I am concerned with requiring our customers to white label the links in order to get the desired customer experience through our digital outreach. I have realized similar to Elisa and Kate, that when I remove the 'link tracking' option that the link acts correctly.
Do you know of any way to navigate this issue, retain the link tracking, and not require customers to 'White Label' the URL?
@srkardel
I connected with Spencer on this and he made mention that you weren't seeing the issue while not on a company connection like at home. If that is the case then I suspect internal DNS may be playing a part. The white labelling part you mention is outlined here and mainly involves adding CNAME records to public DNS. Two of the CNAME records are for authorizing links and are used utilized when link tracking is turned on. For example, you would see the link preface with something like gslink.(domain) when using link tracking.
I have seen on a few occassions these CNAMES also need to be added to internal DNS based on security for your organization.
With the information I have I wouldn't expect any end users to see issues like you are seeing when on a company connection. What I would suggest is reaching out to us in support (support @ gainsight.com) and we can send over those CNAMES that we set up already to see if adding them to internal dns can fix the links when link tracking is on and while on a company connection.
I connected with Spencer on this and he made mention that you weren't seeing the issue while not on a company connection like at home. If that is the case then I suspect internal DNS may be playing a part. The white labelling part you mention is outlined here and mainly involves adding CNAME records to public DNS. Two of the CNAME records are for authorizing links and are used utilized when link tracking is turned on. For example, you would see the link preface with something like gslink.(domain) when using link tracking.
I have seen on a few occassions these CNAMES also need to be added to internal DNS based on security for your organization.
With the information I have I wouldn't expect any end users to see issues like you are seeing when on a company connection. What I would suggest is reaching out to us in support (support @ gainsight.com) and we can send over those CNAMES that we set up already to see if adding them to internal dns can fix the links when link tracking is on and while on a company connection.
@All,Please refer to this article, hope it would resolve your query. Please let us know if you need more info here.
Thank you, @sai_ram_pulluri is this also the same for emails sent outside of surveys? We are seeing this mainly in JO programs sent out by marketing.
Reply
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.