Privacy & Data Handling

The Hood Web SDK is built with privacy by design.

This page explains what data the SDK stores, how it behaves with or without consent, and what developers need to configure in their Consent Management Provider (CMP).

Our goal is to keep integration simple while remaining fully compliant with GDPR and other privacy standards — without unnecessary legal complexity.

Overview

Apart from that cookie, all data is stored directly in the browser using:

• sessionStorage – temporary data automatically removed at the end of a browser session
• localStorage – persistent data such as consent preferences and technical keys that last between sessions

All SDK data is kept under a single storage key called _opc (lowercase).
Inside it, values are namespaced by your configuration tag, so several configurations on one page never overwrite each other.

Example structure:

{
  "_opc": {
    "YOUR_TAG_ID": {
      "uid": "1736412000.4821.0",
      "userConsent": { "analytics": true, "advertising": false, "functional": true, "consent": true }
    }
  }
}

Storage Overview

Session Data (Without Consent)

When no consent is given, the SDK will:

• create a temporary session ID (random and non-persistent),
• store it as uid inside sessionStorage,
• use it to group analytics events within the same browser session.

This ID is deleted automatically when the session ends.
It cannot identify a user and does not require consent.

Example session data:

{
  "_opc": {
    "YOUR_TAG_ID": {
      "uid": "1736412000.4821.0"
    }
  }
}

This allows the SDK to measure simple things like page views or event counts — fully anonymous.

Persistent Data (With Consent)

If the user gives consent via your CMP, the SDK can:

• keep the consent state,
• track campaign parameters (utm_*) and push permission data,
• associate events to a server-side profile when your app calls identity (optional).

Example flow:

Hood('consent', { analytics: true });
Hood('identity', 'user_12345');
Hood('trackEvent', 'purchase', { value: 25 });

If consent is later withdrawn, the SDK will stop using identifiable data and continue with anonymous session tracking only.

What Data Is Stored

All data is stored under the single key _opc, namespaced by configuration tag. The subkeys below are relative to _opc.<tag>.

How the SDK Handles Consent

The SDK includes a simple consent interface that should be synced with your CMP.

Setting Consent

Pass consent states directly from your CMP, using the SDK’s four category names:

Hood('consent', {
  analytics: true,
  advertising: false,
  functional: true,
  consent: true
});

Passing a boolean sets all four categories at once, which is a convenient shorthand for an accept-all or reject-all button:

Hood('consent', true);

Updating Consent

If the user updates consent:

Hood('consent', newConsentState);

Only categories whose value actually changes trigger a consent event, so re-sending the same state is harmless.

Clearing Data

For “right to be forgotten” or user data removal:

Hood('identity', null);
Hood('consent', { analytics: false, advertising: false, functional: false, consent: false });

Revoking analytics clears the persistent visitor ID and stored campaign parameters from localStorage.

CMP Configuration Guide

In your Consent Management Provider (CMP), define the following categories and map them to the SDK purpose keys:

Best Practices

• Send consent to the SDK immediately after your CMP loads
• Linking events to a person happens server-side via identity and requires consent (no user IDs are stored locally)
• No data passed via identity() / setUserProperties() is saved locally
• Use unique key names if your app also writes to localStorage
• Keep your SDK up to date — privacy rules evolve

Quick Reference

Summary

• All SDK data is stored under a single key _opc in browser storage, namespaced by configuration tag.
• The only cookie is _ocpsh, a constant non-identifying push subscription flag that can be turned off with push_enable_subdomain_subscription.
• Persistent data (the visitor ID and UTM parameters) is stored only with analytics consent.
• The push subscription flag is a functional check — never a user identifier.
• The SDK recognizes four consent categories: analytics, advertising, functional, consent.

Need more technical details?
Check our Integration Guide or contact our support team.