How to Gate Non-Essential Scripts and Beacons Using Explicit Consent Logic

Captain Compliance provides a lightweight execution-gating helper script that allows you to control when specific scripts or beacons execute, based on user consent status.

This technique can help reduce privacy litigation risk by ensuring that non-essential scripts do not execute or transmit data unless the appropriate consent has been granted.

While Captain Compliance does support in-app script blocking configuration, the most reliable method for preventing risky third-party transmissions is to gate execution directly on the website itself.

This approach is primarily intended for scenarios where scripts or beacons are not managed through Google Tag Manager or another tag management system. When scripts are deployed via GTM, consent-based firing rules and tag sequencing are often sufficient to prevent execution prior to consent. Execution gating becomes most important when third-party code is hard-coded directly into the site, embedded inline, injected by vendor SDKs, or otherwise executed outside of GTM’s control.

Additionally, this technique is not about cookies.

Execution gating does not rely on setting, blocking, clearing, or nullifying cookies. Instead, it controls whether JavaScript code is allowed to run at all. If a script never executes, no network request is made, regardless of whether cookies are present, blocked, or nullified. This distinction is critical because many litigated data transmissions do not rely on cookies in the first place.

This helper script does not block network traffic retroactively. Instead, it prevents JavaScript from executing unless the required consent category has been granted. If the code never runs, the network request never occurs.

Scripts embedded directly in HTML execute immediately during page load and cannot be controlled after the fact. To apply execution gating, these scripts must be removed from static HTML and reintroduced using consent-aware JavaScript loaders.

The helper must load before any scripts you intend to gate, typically in the head.

The examples below demonstrate how to prevent third-party network requests that commonly appear in privacy demand letters. These scenarios focus on situations where URL search terms or page context are transmitted to third parties, even when cookies are blocked or nullified.

Example 1: Hard-Coded Page Context Script Leaks Search Terms

Risk Scenario: A hard-coded inline script reads the current page URL or search parameters and exposes that data to analytics, personalization, or testing tools. Even if analytics is governed via GTM or cookie logic, the originating page context comes from a separate hard-coded script.

What to Look For: After Reject and performing a search:

• Inline scripts referencing location.href, document.referrer, or URLSearchParams(location.search)

• Third-party requests that include search terms even though analytics is otherwise controlled

• Search values appearing in analytics-related request payloads

Remediation: Gate execution of the page-context script and avoid exposing raw search values.

<script>
  CaptainCompliance.executeIfConsent("PERFORMANCE", function () {
    const params = new URLSearchParams(location.search);

    window.pageContext = {
      page: location.origin + location.pathname,
      search_present: params.has("q")
    };
  });
</script>

Success Criteria: After selecting Reject and performing a site search, no third-party network request contains the search term in the request URL, referrer, or payload.

Example 2: Gate a Hard-Coded Beacon That Transmits Search Data

Risk Scenario: An inline beacon or fetch request sends the current page URL or search term to a third-party endpoint. These transmissions often do not rely on cookies and are frequently cited directly in demand letters.

What to Look For:

• Requests to third-party domains after Reject

• Request URLs or payloads containing location.href

• Query parameters such as ?q=

• Raw search values

Remediation: Gate execution so the request never occurs unless consent exists, and minimize what is transmitted.

<script>
  CaptainCompliance.executeIfConsent("TARGETING", function () {
    const params = new URLSearchParams(location.search);

    fetch("https://vendor.example/collect", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        page: location.origin + location.pathname,
        search_present: params.has("q")
      })
    });
  });
</script>

Success Criteria: After selecting Reject and performing a site search, no third-party network request contains the search term in the request URL, referrer, or payload.

Example 3: Replace a Hard-Coded Third-Party Script With a Consent-Aware Loader

Risk Scenario: A third-party script is embedded directly in HTML and executes immediately on page load, transmitting contextual data such as URL, referrer, or page content before any consent decision exists.

What to Look For:

• A script tag present in page source

• Third-party network requests firing immediately on page load, before or regardless of consent

Remediation: Remove the hard-coded script and reintroduce it using a consent-aware loader.

<script>
  CaptainCompliance.loadScriptIfConsent(
    "TARGETING",
    "https://cdn.vendor.com/sdk.js"
  );
</script>

Success Criteria: After selecting Reject and performing a site search, no third-party network request contains the search term in the request URL, referrer, or payload.