How to Import Captain Compliance Configuration Elements into GTM

Google Tag Manager (GTM) configurations are rarely one-size-fits-all. To simplify initial setup and provide a structured starting point, Captain Compliance provides a GTM JSON import file containing commonly used tags, triggers, and variables.

This article explains what is included in the import file and how the elements are intended to be used. The imported items are designed to be adapted to your existing GTM architecture, not to replace it wholesale.

The JSON import file is intended to:

• Accelerate initial GTM setup

• Provide reusable consent-aware triggers and variables

• Support both opt-in and opt-out consent models

• Serve as a foundation for more advanced GTM configurations

It should be viewed as a starting framework, not a required or final configuration.

Captain Compliance CMP (Strictly Necessary)

This tag contains the Captain Compliance banner script itself and is required for the banner to load.

Before publishing your GTM container, you must update this tag to reflect your actual banner instance:

• Edit the Custom HTML

• Replace the placeholder accessToken with the token from your Captain Compliance application

This tag should be categorized as Strictly Necessary and should load early.

Captain Compliance CMP – Consent Normalization (Strictly Necessary)

This tag supports more advanced deployments.

It is used in scenarios where you want tags to:

• Fire immediately when a user clicks “Accept”

• Continue firing on subsequent page loads once consent has been granted

Recommended Tag Naming Convention

Much like the Captain Compliance–provided tags include the consent category in the tag name (for example, Strictly Necessary), we recommend applying the same convention to all GTM tags as you introduce consent logic.

Including the consent category directly in the tag name makes it immediately clear what type of consent is expected in the firing conditions. For example, a tag named “Hotjar” can be renamed to “Hotjar (Performance)” to clearly indicate that performance-level consent logic applies.

This naming approach improves readability, simplifies audits and troubleshooting, and helps ensure long-term consistency as containers grow.

Active Consent Triggers (Explicit Opt-In)

The following triggers evaluate consent using data layer variables and are designed to fire only after a user has explicitly opted in to the relevant category:

• CCTrigger_Functionality_Allowed

• CCTrigger_Performance_Allowed

• CCTrigger_Targeting_Allowed

These triggers can be applied directly to tags that do not have complex firing requirements.

Example: Rather than firing an analytics tool like Hotjar on all pages, you can attach CCTrigger_Performance_Allowed so it fires only when performance consent has been granted.

There is intentionally no Strictly Necessary “Allow” trigger included in the import file. In most cases, if a tag is strictly necessary, it should not be gated by consent logic at all.

All active consent triggers initialize on the captainComplianceConsentNormalized event, which is derived from the Captain Compliance CMP – Consent Normalization tag.

Passive Consent Trigger (Opt-Out Model Support)

The following trigger is used to support opt-out consent models:

• CCTrigger_Passive_Mode (Opt-Out Regions)

If a tag only uses an active consent trigger, it will fire only after explicit consent. While this may be appropriate in opt-in regions, it is often not desired in opt-out jurisdictions.

The passive trigger:

• Fires immediately on gtm.init

• Checks whether the banner has been interacted with (CaptainConsentStatus is undefined)

• Ensures the visitor is not located in a region that requires opt-in consent

To fire a tag by default in opt-out regions while still respecting opt-in rules elsewhere, apply both:

• The relevant active consent trigger

• CCTrigger_Passive_Mode (Opt-Out Regions)

Example: To fire Hotjar by default in opt-out regions but require explicit consent elsewhere, apply both:

• CCTrigger_Performance_Active (Allow)

• CCTriggerPassive (Opt-Out Regions)

Many GTM containers already include triggers with logic more complex than “All Pages.” In these cases, replacing triggers outright is usually not appropriate.

Instead, Captain Compliance provides variables that can be incorporated into existing trigger logic.

Active Consent Variables

• CaptainFunctionality

• CaptainPerformance

• CaptainTargeting

These data layer variables require explicit opt-in for the relevant category.

Passive Consent Variables

• CaptainFunctionalityPassive

• CaptainPerformancePassive

• CaptainTargetingPassive

These evaluate to true if either:

• Explicit consent has been granted, or

• Passive (opt-out) mode applies

The following variable is used to identify visitors from regions that require opt-in consent and supports the passive trigger logic described above:

• CaptainOptInRegion

Important Notes:

• The included region list is provided as a starting point only

• It is not a legal determination or a definitive compliance list

• You are encouraged to review and adjust region codes as needed

You may also extend this logic to:

• Countries

• Sub-regions (states, provinces)

• Custom jurisdictional rules

Any changes made here should be reflected consistently with banner configuration within the Captain Compliance application. If you enforce opt-in logic for a region in GTM, the corresponding banner should default toggles to “off” for that region.

1. Define your consent model (opt-in, opt-out, or mixed by region or tag type)

2. Import the JSON file into GTM

   • Admin → Import Container

   • Choose Container File

   • Select Existing

   • Use Merge (Important)

3. Update the Captain Compliance CMP tag with your specific banner access token

4. Test the banner independently before adding consent logic

   • Use GTM Preview mode, or

   • Fire the banner under a temporary test condition (for example, a query parameter mapped to a testing URL, such as one including "?cmp-testing")

5. Add consent logic to tags

   • Simple tags can use the provided triggers

   • Complex tags should incorporate the provided variables

6. Validate geolocation behavior using VPN testing