Intro 📖
In this post, we’ll take a look at a couple Sitecore SDKs commonly used to build XM Cloud head applications. Specifically, we’ll be looking at how to disable cookies used by these SDKs. This can be useful for data privacy and/or regulatory compliance reasons. These SDKs allow your application to integrate with other composable Sitecore services like analytics, personalization, and search. The cookies these SDKs use need to be considered as part of your application’s overall data protection strategy.
It’s worth noting that, even without any additional SDKs, an XM Cloud head application can issue cookies; see XM Cloud visitor cookies for more information.
Sitecore Cloud SDK ☁
The Sitecore Cloud SDK allows developers to integrate with Sitecore’s Digital Experience Platform (DXP) products. These include Sitecore CDP, Sitecore Personalize, etc. You can read the official documentation here. To learn more about the first-party cookies used by this SDK, see Cloud SDK cookies. These cookies include:
- sc_{SitecoreEdgeContextId}
- Stored in the browser when the SDK’s initialization function is called (more on this function later).
- sc_{SitecoreEdgeContextId}_personalize
- Needed to run A/B/n tests; configured in the addPersonalize() function. Also stored in the browser when the initialization function is called.
📝 Sitecore are actively working on integrating the disparate Sitecore SDKs into the Sitecore Cloud SDK. The latest version, 0.5, was released on January 29, 2025, and added search capabilities (see the XM Cloud changelog entry here). As Sitecore’s Technical Product Manager Christian Hahn put it in this recent Discover Sitecore YouTube video:
“…[the] Cloud SDK is not another Sitecore SDK–it is the Sitecore SDK.”
It’s safe to assume that, eventually, the Sitecore Cloud SDK will be the only Sitecore SDK developers need to include in their head applications to integrate with any other Sitecore DXP offerings (which will be nice 👌).
ℹ For the remainder of this post, assume that a pre-0.5 version of the Cloud SDK is in use, say, 0.3.0—any version that doesn’t include search widgets (such that the Search JS SDK for React is still required).
Sitecore Search JS SDK for React 🔍
The Search JS SDK for React allows developers to create components such as search bars, search results components, etc. These components interact with search sources defined and indexed in Sitecore Search. You can read the official documentation here. While the latest version of the Cloud SDK includes some search dependencies, for older Next.js applications using older versions of the Cloud SDK, the Search JS SDK for React can still be used to build search interfaces.
The Search JS SDK for React uses a cookie to track events context called __ec (reference). This SDK is historically based on Sitecore Discover whose cookies are similarly documented here, e.g., __rutma.
ℹ For the remainder of this post, assume that version 2.5.5 of the Search JS SDK for React is in use.
The Problem 🙅♂️
Let’s say your XM Cloud project leverages JSS for Next.js, including the multisite add-on. This add-on (which is included in the official starter kit by default) allows a single Next.js application to drive multiple headless sites. Next, let’s assume that some of these sites operate outside of the United States and are potentially subject to different data protection and privacy laws. Finally, let’s assume that not all of the sites will use the full feature set from these SDKs. For example, what if a couple of the sites are small and don’t need to integrate with Sitecore Search at all?
How do you disable the cookies written to the browser when the Search SDK’s <WidgetsProvider> component is initialized? Even though the smaller sites aren’t using search widgets on any of their pages, the <WidgetsProvider> component is (usually) included in the Layout.tsx file and is still initialized. We don’t want to remove the component since other sites do use search widgets and require the <WidgetsProvider> component.
Can these SDKs be configured to (conditionally) not create cookies on the client browser?
The Solution ✅
🚨 First and foremost (before we get into how to disable cookies used by these SDKs), know that you must ensure that your application is compliant with any and all data privacy and data protection laws to which it is subject. This includes allowing users to opt-out of all browser cookies. Cookie preferences, their management, third-party solutions, GDPR, CCPA, etc. are all great topics but are well outside the scope of this post. To get started, refer to Sitecore’s documentation on data privacy to understand who is responsible for what when building an XM Cloud application.
With that small disclaimer out of the way, the programmatic hooks discussed in the sections below can be used in conjunction with whatever cookie management solution that makes sense for your application. Let’s assume that, for these smaller sites operating in different geographies that require neither CDP nor search, we just want to disable cookies from these SDKs altogether.
To disable Cloud SDK cookies:
The short version: just don’t call the SDK’s init() function 😅. One way this can be done is to add an environment variable and check its value within the .\src\<rendering-host>\src\lib\context\sdk\events.ts file and either return early or throw before the call to Events.init():
import * as Events from '@sitecore-cloudsdk/events/browser';
import { SDK } from '@sitecore-jss/sitecore-jss-nextjs/context';
const sdkModule: SDK<typeof Events> = {
sdk: Events,
init: async (props) => {
// Events module can't be initialized on the server side
// We also don't want to initialize it in development mode
if (typeof window === 'undefined')
throw 'Browser Events SDK is not initialized in server context';
if (process.env.NODE_ENV === 'development')
throw 'Browser Events SDK is not initialized in development environment';
// We don't want to initialize if the application doesn't require it
if (process.env.DISABLE_CLOUD_SDK === 'true') // <===== HERE
throw 'Browser Events SDK is not initialized for this site';
await Events.init({
siteName: props.siteName,
sitecoreEdgeUrl: props.sitecoreEdgeUrl,
sitecoreEdgeContextId: props.sitecoreEdgeContextId,
// Replace with the top level cookie domain of the website that is being integrated e.g ".example.com" and not "www.example.com"
cookieDomain: window.location.hostname.replace(/^www\./, ''),
// Cookie may be created in personalize middleware (server), but if not we should create it here
enableBrowserCookie: true,
});
},
};
export default sdkModule;
By not calling Events.init(), the cookies aren’t written to the browser.
📝 Note that in newer versions of the XM Cloud starter kit using the Cloud SDK, the initialize function may be in the Bootstrap.tsx file; however, the same principle applies—don’t call the initialize() function by either returning early or setting up conditions such that the function is never called.
For consistency, assuming your application uses the OOTB CdpPageView.tsx component, you’d probably want to do something similar within that component. By default, page view events are turned off when in development mode. Simply add another condition to ensure that the return value of disabled() is true:
import {
CdpHelper,
LayoutServicePageState,
useSitecoreContext,
} from '@sitecore-jss/sitecore-jss-nextjs';
import { useEffect } from 'react';
import config from 'temp/config';
import { context } from 'lib/context';
/**
* This is the CDP page view component.
* It uses the Sitecore Cloud SDK to enable page view events on the client-side.
* See Sitecore Cloud SDK documentation for details.
* https://www.npmjs.com/package/@sitecore-cloudsdk/events
*/
const CdpPageView = (): JSX.Element => {
...
/**
* Determines if the page view events should be turned off.
* IMPORTANT: You should implement based on your cookie consent management solution of choice.
* By default it is disabled in development mode
*/
const disabled = () => {
return process.env.NODE_ENV === 'development' || process.env.DISABLE_CLOUD_SDK === 'true'; // <===== HERE
};
...
return <></>;
};
export default CdpPageView;
To disable Search JS SDK for React (Sitecore Discover) cookies:
The <WidgetsProvider> component (imported from @sitecore-search/react) includes a property named trackConsent (documented here) and it controls exactly that—whether or not tracking cookies related to visitor actions are created. Setting the value of this property to false disables the various cookies. In the Layout.tsx file, assuming we added another environment variable, the code would look something like this:
ata-enlighter-language="typescript">/**
* This Layout is needed for Starter Kit.
*/
import React from 'react';
...
import { Environment, WidgetsProvider } from '@sitecore-search/react';
const Layout = ({ layoutData, headLinks }: LayoutProps): JSX.Element => {
...
return (
<>
...
<div className="App">
<WidgetsProvider
env={process.env.NEXT_CEC_APP_ENV as Environment}
customerKey={process.env.NEXT_CEC_CUSTOMER_KEY}
apiKey={process.env.NEXT_CEC_API_KEY}
publicSuffix={true}
trackConsent={!(process.env.DISABLE_TRACK_CONSENT === 'true') /* <===== HERE */}
>
...
</WidgetsProvider>
</div>
...
</>
);
};
export default Layout;
If trackConsent is false, then the various __r… cookies are not written to the browser.
⚠ It’s worth mentioning that, by default, trackConsent is true. To opt-out of cookies, developers must set the property to false.
Whether you control the use of cookies by using environment variables as described in this post or by integrating a more complex cookie preference and consent management system, the onus is on you and your XM Cloud head application to avoid using cookies without a user’s consent.
Thanks for the read! 🙏
