Brands have used third-party cookies for years to track website visitors, improve the user experience, and collect data to target advertising. Website owners also use cookies to learn what other websites visitors are visiting.
Google initially announced the third-party cookie phase-out in February 2020. The announcement was part of a new set of open standards to enhance privacy on the web. Google planned to phase out third-party cookie use by their Chrome browser by 2022.
Still not sure about what first or third-party cookies are?
Here’s a quick breakdown.
First-Party Cookies
Ever wonder how Amazon always remembers your login information, the language you speak, the items in your cart, and other things that make your user experience so smooth? This is because Amazon uses first-party cookies to remember these details.
A first-party cookie is a file generated and saved on your website visitor’s computer by default when they visit your site. This file is often filled with data that can improve the user’s experience – like- like remembering passwords, past orders, or other preferences.
With a first-party cookie, you can learn about what a user did while visiting your website, see how often they visit, and get other basic analytics that can help you develop or automate an effective marketing strategy around them.
However, you can’t see data from when your visitor goes to other websites that aren’t affiliated with your domain.
Third-Party Cookies
Third-party cookies are files containing tracking codes saved on a web visitor’s computer from a website other than your own. When a web visitor comes to your site, the third-party cookie tracks this information and sends it to the third party who created the cookie — which might be an advertiser.
First-party cookies are typically accepted automatically. However, visitors must be informed that they are accepting a third-party cookie due to the data companies can retain from them.
Is there any impact on my SAP SuccessFactors® environment?
Unfortunately, the answer is yes.
Third-party cookie deprecation impacts SAP SuccessFactors by possibly causing some features not to work. Key ones are:
- User authentication and single sign-on (SSO)
- Embedded iFrames where the content is loaded from SAP SuccessFactors products
- SAP SuccessFactors internal product integration
- External UI integrations from partners
Example:
Here is one example of what would happen in the application when the deprecation is in place.
In the diagram below, the SuccessFactors application is open in a browser window (blue in the diagram). The page also embeds other content embedded by a URL (the green rectangle). This other application could well be a partner embedded application or another SuccessFactors application from a domain other than successfactors.com (ex. plateau.com for LMS, or ondemand.com for authentication)
When I interact with the blue application, all my traffic will be directed to the backend web server, and a cookie will be generated and set in my browser. The browser will send cookies only to the domain or server that created them. These are first-party cookies and, therefore, accepted.
However, when I interact with the green application, the browser will not accept the third-party cookie because the green application is embedded in the blue application, and my traffic is directed to the green web server.
As a result, the application will not work correctly, or in the case of a Single Sign On (SSO) scenario, I wouldn’t be able to log in to the embedded application.
What Solution is SAP SuccessFactors Proposing?
SAP SuccessFactors is introducing the Common Super Domain (CSD), which converts third-party cookies into first-party cookies. This common super domain will look like *.cloud.sap or *.sapcloud.cn (in China)
The objective is to migrate all existing customers to the common super domain by June 2024.
SAP SuccessFactors Internal Approach
In SuccessFactors, we already face issues with third-party cookie deprecation, even without including partner extensions, because the application runs in different domains.
Some examples included modules not part of the original SuccessFactors suite and were added later via acquisitions (e.g., Learning, Onboarding 1.0, Recruitment Marketing / Posting).
Other examples relate to recent upgrades such as authentication (IAS) or SAP BTP.
The solution is to adopt the super common domain for all these modules/applications by migrating them to live under the same super common domain.
An example of a learning tenant that looked like customer.plateau.com will now look like customer.lms.hr.cloud.sap.
External Solution Approaches
We have SAP SuccessFactors sorted, but what happens with other external solutions?
Navigation
One of the easiest options is for the system to open the embedded application into a new tab or window. This will make the third-party cookie a first-party cookie, as displayed in the diagram below.
One advantage to this approach is that all it takes is a quick configuration change.
The downside is that having separate tabs or windows breaks dependencies between the parent application and the application being called. The user experience has also slightly changed because of the separate tab or window.
Redirect
This alternative requires changes to the parent application and embedded application.
Let’s run through this approach using the DocuSign SolEx example integrated in the SuccessFactors Recruitment module when signing offer letters.
Here’s the process (illustrated by the diagram below):
The ‘Start Signature’ DocuSign screen is embedded into the SuccessFactors Recruiting UI, allowing the Talent Acquisition team to initiate the signature process in DocuSign.
- (1) (2) When the user presses the ‘signature’ button, the browser makes a call to the SuccessFactors Web Server Backend (https call, get URL-A, and response set cookie A)
- (3) The backend makes an API call into DocuSign by passing certain attributes such as userId, returnURL (URL-A), etc., and in return, passes a newly generated DocuSign URL (URL-B) back to the front-end application.
- (4) The front end then uses the newly generated URL (URL-B) which calls the embedded application.
- (5) The DocuSign Web Server Backend eventually returns a redirect 302 with the previous URL-A from SF and additional information about success.
One upside to this approach is that the context is transferred via URL parameters in both directions while no parallel independent window is created.
On the other hand, a change to the user experience is still required, and extra work is needed on both ends.
Need More?
Please contact us if you need to know more about how third-party cookie deprecation will affect your SuccessFactors platform. We’ll schedule a call to talk more.
