With the version 80 update of Google Chrome, there comes a criterion where the cookies can be accessed with 3rd party context only when its ‘SameSite’ attribute is set to ‘None and secure’. Setting the SameSite attribute to ‘None’ means that you intentionally allow the cookie to be accessed with a third-party context. To know more about the ‘SameSite’ cookie attribute, refer to SameSite Cookie.
This improves privacy by preventing cross-domain information leakage, but this update might affect how visitors are uniquely tracked if parts of your website (or the entire website) load in an iframe.
Recent Updates
April 3rd, 2020: Google decides to temporarily roll-back the SameSite changes due to the COVID-19 pandemic. To know more, read this.
May 28, 2020: Google has confirmed that the rollout of SameSite will resume in July. Exact dates were not given, we think it will be rolled out in a phased manner. To know more, read this.
Let's take a deeper look at how Wingify tracks visitors and delivers experiences, and how to best configure Wingify based on your website implementation.
What is the First and Third-party Context for Accessing a Website?
If the website's content is accessed directly, which means that the website's domain is the same as the one present in the address bar of the browser, then access to the website is considered to be with a First-party context.
If your website loads in an iframe on another website, which means that the iframe's domain is different from the one present in the address bar of the browser, then access to the website is considered to be with a Third-party context.
To learn more about how websites are accessed, read this.
SameSite = ‘None and Secure’ in Wingify
By default, Wingify sets ‘SameSite=Lax’, however, you can change it to SameSite= ‘None and Secure’. To do this, go to Account Settings > Accounts > Privacy Center > Data Security section, and enable the Set Samesite = None and Secure for visitors option.
Not Sure If this Option Should Be Enabled Your Wingify Account or Not? Don’t Worry, We’re Going to Help You Out.
Choosing the SameSite configuration for Wingify cookies that best suits you is purely dependent on:
- How your website is implemented, and
- How visitors access domain names of the website in eTLD+1 your website.
We recommend that you follow this simple two-step process in order to know what configurations you should make in your Wingify account.
- The first step is to align the implementation of your website with the correct row in the first column.
- Next, for that row, match with the column (from columns 2 to 4) that best describes how visitors access your website based on their connection status.
| How is your website implemented? | Website visitor’s connection type | ||
| Secure (HTTPS only) | Mix of secure and insecure (HTTPS and HTTP) | Insecure (HTTP only) | |
| Visitors access the website directly; it does not load in an iframe on another website. (Website is accessed with the first-party context) | Do not enable it | Do not enable it | Do not enable it |
| Visitors access the website via an iframe on another website. (Website is accessed with the third-party context) | Enable the option The net effect here will be zero, as all users are on HTTPS only. | Enable the option For visitors using the Chrome browser, only those on Secure connection (HTTPS) will be tracked. Any visitor using the Chrome browser on a non-secure connection (HTTP) will NOT be tracked and WILL NOT become part of any campaign. | Do not enable Wingify CANNOT track visitors uniquely. WARNING: Tracking will completely stop if the option is enabled! |
| Visitors can access the website directly and also via an iframe on another website. (website exists by itself as well as in another website in an iframe, having the first or third-party context in its access) Both instances of your website can have the same SameSite setting only. | Enable the option The net effect here will be zero, as all users are on HTTPS only. | Enable the option For visitors using the Chrome browser, only those on Secure connection (HTTPS) will be tracked. Any visitor using the Chrome browser on a non-secure connection (HTTP) will NOT be tracked and WILL NOT become part of any campaign. | Do not enable Wingify CANNOT track visitors uniquely. WARNING: Tracking stops if the option is enabled! |
Configuring the Samesite Settings in Wingify
Once you have decided if the Samesite setting needs to be set to None and Secure, you can enable the option for all of your websites in the account by selecting Apply to all websites.
If you are using a single Wingify account for multiple websites and the setting needs to be applied to only certain websites, choose the Apply to specific websites option, and in the field that appears, enter the domain names of the website (for example, wingify.com or myproject.github.io).
What is the eTLD+1 format?
Effective top-level domain (eTLD) is typically a catalog of certain internet domain names. Another name for eTLD is Public Suffix List. Generally, your website is a level below eTLD, which is referred to as ‘eTLD+1’ level. To know more about effective TLDs, and what eTLD+1 means, read this.
NOTE: SameSite settings can be applied at the eTLD+1 level only. Thus, this is the format in which you must enter your domain name.
In this table, we have briefly explained a few examples of correct and incorrect inputs for eTLD+1.
| Input | Validity | Reason |
|---|---|---|
| wingify.com | Correct | Here, eTLD is ‘.com’. wingify.com is a level below the eTLD, hence in eTLD+1 format. |
| blog.wingify.com | Incorrect | Here, eTLD is ‘.com’ and this ‘blog.wingify.com’ is 2 levels below it, and hence not eTLD+1. |
| gihub.io | Incorrect | github.io is an eTLD and hence this is not at the eTLD+1 level. |
| myproject.github.io | Correct | This is at the eTLD+1 level, hence valid. |
NOTE
1. Wingify will not accept ‘/’ characters in the domain name.
2. Do not include ‘http’ or ‘https’.
3. Do not enter subdomains, since SameSite applies at the eTLD+1 level and not at the subdomain level. Different subdomains of your website cannot have different SameSite settings.
4. This setting is at a sub-account level. It applies only to the websites for which Wingify is used in that sub-account. It is not a central control for all the sub-accounts in your Wingify account. Please set this option for each sub-account individually.
Things to Consider If Your Website is Accessed With a Third-party Context
- If all your website visitors are on an insecure connection (HTTP) only SameSite attribute cannot be set to ‘none’ (as it will have to be over a secure connection) Wingify cannot count visitors uniquely, i.e., Multiple visits of the same visitor will be counted as separate visits. This can lead to skew in test results (for example, if test experience and goal conversion happen in two separate sessions for that visitor) and disconnected experiences (where different variations are shown to the same visitor on their different sessions). In this scenario, we strongly recommend moving the website to a secure protocol (HTTPS). This allows Wingify to set the Samesite as None, and track your visitors accurately. There is no other work-around to accurately track your visitors in a secure manner.
- If the visitor’s access to the website is a mix of secure and insecure connections (HTTP and HTTPS) By setting SameSite to None, Wingify will ensure that HTTPS visitors are counted accurately (by connecting sessions of the same visitor). Wingify ignores all HTTP visitors since they cannot be counted accurately. This is because, accurate tracking is more important than tracking all visitors inaccurately, which can skew test results. For visitors on HTTP connections, Wingify will not work. This means, visitor behavior will not be tracked in Wingify Insights, and the Testing/Personalization/Deploy campaigns will not be displayed to the visitors.
Need more help?
For further assistance or more information, contact Wingify Support.