Cloud SDK cookies

Version: 0.5

To comply with cookie regulations, the Cloud SDK does not store any cookies by default. However, the SDK must store first-party cookies in the web browser to function properly. As a result, if your site visitor grants consent, you need to opt in to setting cookies so that the SDK can function properly in your app.

First-party cookies are set by the domain that appears in the web browser's address bar. If you opt in to setting them, the Cloud SDK stores the following first-party cookies:

Cookie name

Description

Configuration options

sc_{SitecoreEdgeContextId}

Persists the browser ID between sessions, which is required for all calls that the Cloud SDK makes to Sitecore.

Assigns a universally unique identifier (UUID) that is unique per browser until the cookie expires or is deleted.

After the cookie expires or is deleted, a new UUID is generated the next time the site visitor returns.

Configured in the CloudSDK function, and stored in the web browser when the function's initialize method runs. See also Initializing the Cloud SDK.

sc_{SitecoreEdgeContextId}_personalize

Persists the guest ID between sessions, which is required to run XM Cloud A/B/n tests.

Assigns a universally unique identifier (UUID) that is unique per site visitor until the cookie expires or is deleted.

After the cookie expires or is deleted, a new UUID is generated the next time the site visitor returns.

Configured in the CloudSDK.addPersonalize method, and stored in the web browser when the CloudSDK function's initialize method runs. See also Initializing the Cloud SDK.

bx_bucket_number

Allocates the site visitor to the variant of a web experience or web experiment by using a bucket number. The allocation is performed for each web personalization that is live on your site during a particular session.

Stored only for the duration of the session, and only if you enable web personalizations in your app.

Configured in CloudSDK.addPersonalize.webPersonalization, and stored in the web browser when the CloudSDK function's initialize method runs. See also Initializing the Cloud SDK.

Note

Depending on your site configuration, XM Cloud may issue other cookies to website visitors, as well.

Here's a code example that initializes the Cloud SDK only if a site visitor has accepted cookies.

Your own cookie consent implementation will depend on your application requirements, legal regulations, and user experience design. This example is for illustrative purposes only and will not work unless you customize it with your own code.

RequestResponse
"use client";
import { useEffect } from "react";

// Import SDK modules ...

// Import your custom logic that checks whether the site visitor has accepted cookies:
import { useCookieConsent, cleanup } from "<YOUR_CUSTOM_LOGIC_PATH>";

export default function CloudSDKComponent() {
  // Your custom hook to check whether the site visitor has accepted cookies:
  const { hasConsent } = useCookieConsent();

  useEffect(() => {
    // If the site visitor accepts cookies, run the CloudSDK function:
    if (hasConsent) {
      CloudSDK({
        // Your initialization settings ...
      })
        // Decide which packages to initialize ...
        .initialize();
    } else {
      // If the site visitor rejects cookies, run the cleanup logic:
      cleanup();
    }
  }, [hasConsent]);

  return null;
}

Opting in to setting cookies

Important

Only initialize the Cloud SDK and set cookies if your site visitor grants consent.

The Cloud SDK lets you opt in to setting cookies when you initialize the SDK using the CloudSDK function of the core package. To initialize the SDK, you have to set cookies either from the browser or from the server, not both.

In the core package, the browser module lets you set cookies from the browser (client-set cookies), and the server module lets you set them from the server (server-set cookies).

Client-set cookies

You can set the sc_{SitecoreEdgeContextId} cookie from the browser by setting enableBrowserCookie to true in the CloudSDK function of the browser module of the core package. If you're also using the server modules, make sure to set enableServerCookie to false in the server-side CloudSDK function.

To be able to run XM Cloud A/B/n tests, you also need to set the sc_{SitecoreEdgeContextId}_personalize cookie by setting enablePersonalizeCookie to true in the CloudSDK.addPersonalize method either on the browser or the server.

Server-set cookies

You can set the sc_{SitecoreEdgeContextId} cookie from the server by setting enableServerCookie to true in the CloudSDK function of the server module of the core package. If you're also using the browser modules, make sure to set enableBrowserCookie to false in the browser-side CloudSDK function.

To be able to run XM Cloud A/B/n tests, you also need to set the sc_{SitecoreEdgeContextId}_personalize cookie by setting enablePersonalizeCookie to true in the CloudSDK.addPersonalize method either on the browser or the server.

When you set cookies from the server, you create and manage cookies on your web server. Then, the web server sends the cookies to the client app. Finally, the client app stores the cookie in the web browser.

Setting cookies from the server has the following benefits:

  • Increases security by adding the httpOnly attribute to cookies. This helps prevent browser-side JavaScript from accessing the cookies and mitigate cross-site scripting (XSS) attacks.

  • Mitigates the impact of Intelligent Tracking Prevention (ITP) on cookies. For example, unlike client-set cookies, server-set cookies don't expire automatically after 7 days.

Optionally, when you run the CloudSDK function, you can configure the cookie domain, the cookie path, and the number of days before cookies expire.

Do you have some feedback for us?

If you have suggestions for improving this article,