How to Test Consent Auto-Blocking on a Spartacus Storefront

Consent auto-blocking is an important part of a compliant SAP Commerce Cloud storefront. However, it can silently break features that load only after a customer interacts with the site.

A common example is SAP Customer Data Cloud (Gigya). The identity script may not load when the page first renders. Instead, it may load only after the customer clicks the Sign In link. If that script is incorrectly matched by a consent auto-blocking rule, the page will look healthy, but the sign-in dialog will never open.

In this tutorial, we will cover how to identify, test, and safely deploy consent auto-blocking on a Spartacus storefront.

Why page-load testing is not enough

A normal smoke test may confirm that:

• The home page loads.
• Product and category pages render correctly.
• The account page is accessible.
• There are no console errors.
• The consent banner appears.

These checks are useful, but they do not confirm that interaction-driven functionality still works after consent is rejected.

On a Spartacus storefront, many capabilities are loaded on demand:

• Customer Data Cloud sign-in and registration
• Payment iframes
• Address validation
• Product reviews
• Store locators and maps
• Chat and customer-support tools

A script that is not present during page load can still be blocked later when it is injected into the page.

How consent auto-blocking works

Consent platforms such as OneTrust can prevent a script from running by changing its type to text/plain.

For example, a script may be transformed into:

<script type="text/plain" src="https://example.gigya.com/js/gigya.js"></script>

The browser will not execute that script until the required consent category has been granted.

This creates a specific risk for deferred functionality:

1. The customer loads the storefront.
2. The identity script is not yet present.
3. The customer clicks Sign In.
4. The storefront injects the identity script.
5. The consent rule matches the script URL.
6. The script is held and the sign-in dialog does not open.

No page error is required. No network error is required. The customer simply clicks Sign In and nothing happens.

Step 1: Inventory functionality that loads after interaction

Before enabling auto-blocking, document every feature that loads after a customer action.

Customer action	Capability loaded	Failure if blocked	Visibility
Click Sign In	SAP Customer Data Cloud	Customer cannot sign in or register	Silent
Enter checkout	Payment iframe	Customer cannot complete payment	Visible
Enter address	Address-validation service	Invalid addresses may be accepted	Silent
Scroll to reviews	Ratings and reviews widget	Reviews do not appear	Silent
Open store selector	Maps or store locator	No store results	Visible
Open help	Chat widget	Customer cannot access support	Silent

Start with failures that are silent. A failed payment flow will generate support tickets quickly. A failed sign-in dialog may only show up later as reduced conversion or lower account engagement.

Step 2: Test in the rejected-consent state

Testing with all categories accepted does not validate auto-blocking. Accepted consent releases held scripts.

The important test is the rejected state.

1. Open the storefront in a new browser session.
2. Reject optional consent categories.
3. Confirm that only the strictly necessary consent group remains active.
4. Click the Sign In control.
5. Confirm that the sign-in dialog opens and the identity provider initializes.

The customer-visible result is the key assertion:

When a customer clicks Sign In, the sign-in dialog must open.

Step 3: Inspect the identity script after clicking Sign In

Run the following code in the browser console after clicking the Sign In control:

function identityCheck() {
  const scripts = Array.from(document.scripts);

  const heldScripts = scripts.filter(
    (script) => (script.type || "").toLowerCase() === "text/plain"
  );

  return {
    activeGroups: window.OnetrustActiveGroups,
    scriptPresent: scripts.some((script) =>
      /gigya|cdc/i.test(script.src || "")
    ),
    scriptHeld: heldScripts.some((script) =>
      /gigya|cdc/i.test(script.src || "")
    ),
    apiReady: Boolean(window.gigya && window.gigya.accounts),
    bootstrapCookie: document.cookie.includes("gig_bootstrap"),
    dialogOpen: Boolean(
      document.querySelector('[id*="gigya" i], .gigya-screen')
    ),
  };
}

Review the results carefully.

Result	Meaning
scriptHeld: true	The identity script matched an auto-blocking rule and was prevented from executing.
scriptPresent: false and apiReady: false	The identity script was never injected. This is a separate issue, but it still prevents sign-in.
apiReady: true	The SAP Customer Data Cloud API is available.
dialogOpen: true	The customer can see the sign-in dialog. This is the most important result.

Do not rely only on the existence of the script tag. A script can be present and still fail to initialize correctly.

Step 4: Confirm Spartacus selectors from the rendered storefront

Spartacus storefronts often use cx-* components and project-specific custom elements rather than conventional HTML landmarks.

Do not assume generic selectors such as <nav> will work. Read the live DOM and build your smoke-test selectors from the actual storefront:

const CORE = {
  "app shell": ["<ns>-app-root", "cx-storefront"],
  "main header": ["<ns>-main-header", "header#cx-header"],
  "page slots": ["cx-page-slot"],
  "footer": ["footer", "<ns>-back-to-top"],
};

Replace <ns> with the custom namespace used by your implementation.

This will reduce false failures and make the test suite useful after future Spartacus upgrades.

Step 5: Understand what is stored outside cookies

Consent testing should not assume that all customer state is cookie-based.

For example, Spartacus cart data may be stored in localStorage under a key similar to:

spartacus⚿<basesite>⚿cart

This means that rejecting cookies may not clear the cart, and a cookie inventory will not show cart storage.

Document these behaviors before launch so that privacy, compliance, and business teams understand which application states are affected by a consent decision.

Step 6: Deploy auto-blocking separately

Do not combine code changes, cookie recategorization, and auto-blocking activation into one deployment step.

Use a phased approach:

1. Deploy code changes with auto-blocking disabled. Verify the storefront.
2. Publish consent-category changes. Verify the preference center and consent states.
3. Enable auto-blocking. Verify all interaction-driven capabilities in the rejected-consent state.

This approach makes failures easier to isolate and provides a clean rollback point.

During the final verification, test Sign In first. It is one of the highest-impact failures and one of the easiest to miss.

Auto-blocking checklist

Before enabling consent auto-blocking, confirm the following:

• All interaction-triggered capabilities have been documented.
• Silent failure modes have been identified and tested first.
• Sign In has been tested after rejecting optional consent categories.
• The SAP Customer Data Cloud dialog opens successfully.
• Identity-provider URLs are not incorrectly included in the block list.
• Held scripts are present when expected; zero held scripts may indicate that no rules are matching.
• Core storefront selectors were taken from the live rendered DOM.
• Auto-blocking has its own deployment step and rollback plan.

Conclusion

Consent auto-blocking should be tested as an interaction feature, not only as a page-load feature.

On a Spartacus storefront, the page may render perfectly while sign-in, checkout, reviews, chat, maps, or address validation fail only after the customer clicks. Testing those actions in the rejected-consent state is the only reliable way to confirm that enforcement is working without breaking critical storefront functionality.

Now you know how to test consent auto-blocking on a Spartacus storefront before it becomes a production issue.

We hope this article helps your business or client safely enable cookie consent auto-blocking on SAP Commerce Cloud. If you have any questions about SAP Commerce Cloud, or need implementation help, please contact us at info@hybrisarchitect.com. Thank You!