Humind widget: information for legal teams
This page describes the browser storage created by the Humind chat widget and the data sent to PostHog for usage measurement.
It presents the widget's current technical behavior. It is not legal advice and does not assess the compliance of a particular implementation.
At a glance
- The widget uses functional storage to maintain a session, resume a conversation, and prevent certain duplicate actions.
- PostHog sets no cookie and uses neither
localStoragenorsessionStorage. - PostHog events are explicit and pseudonymous. They are not anonymous.
- PostHog is active by default if the merchant does not require consent.
- If the merchant requires consent, PostHog is not initialized before acceptance.
Actions to plan
The merchant's legal team should:
- name Humind as the chat widget provider in the privacy notice;
- add the functional storage below to the cookie policy or appropriate register;
- determine the legal basis for PostHog usage measurement and decide whether it must be subject to consent;
- verify that the Humind setting and the merchant CMP apply that decision;
- name PostHog as a usage measurement processor, using PostHog Cloud EU hosted in Frankfurt;
- document separately the external services enabled by the merchant, including GTM, GA4, and booking tools.
Functional widget storage
These storage items support chat operation. They are not created by PostHog.
| Key | Storage | Data and purpose | Attention level | Current technical duration |
|---|---|---|---|---|
__humind_local_storage_probe__ | localStorage | Temporary value used to check that storage is available | Purely technical | Deleted immediately |
humindVisitorId | localStorage | Pseudonymous identifier used to maintain visitor continuity | Pseudonymous data | No automatic expiry |
humindSessionId | sessionStorage | Pseudonymous widget session identifier | Pseudonymous data | Tab session |
humind.humind-state.<companyId> | localStorage | Conversation identifiers and dates, resume tokens, short titles, and satisfaction flags | Pseudonymous data and access tokens | No automatic expiry |
humind.cookie-consent.<companyId> | localStorage | The value accepted when the visitor accepts usage measurement | Consent choice | No automatic expiry |
lastHumindNotificationTimestamp | localStorage | Date of the latest proactive invitation, used to limit repetition | Purely functional | Useful for 5 minutes, without automatic deletion |
humind:appointment-booking-request | sessionStorage | Technical booking request identifiers, related slots, and update date, with a maximum of 20 entries | Technical data linked to an action | Tab session, deleted when the list becomes empty |
A conversation's short title may reflect its subject. The resumeToken can be used to request that the conversation be resumed. Both should be protected as pseudonymous data and access tokens.
Usage measurement with PostHog
Humind uses PostHog to measure widget display and use, product and cart interactions, advisor requests, appointments, satisfaction, and technical errors.
Events may contain:
- the pseudonymous Humind visitor identifier;
- the Humind company identifier;
- the shop domain, integration type, page template, country, and environment;
- product, store, service, appointment, or conversation identifiers;
- interaction measurements, functional states, and technical diagnostics.
The widget configuration:
- creates no PostHog person profile;
- uses no PostHog cookie,
localStorage, orsessionStorage; - disables session recording, autocapture, automatic pageviews, and campaign parameters;
- excludes the IP address, merchant page URL, and referrer;
- sends only semantic events triggered by the widget.
Traffic goes through ph.thehumind.com and is then forwarded to PostHog Cloud EU, hosted in Frankfurt.
Events are pseudonymous because the Humind visitor identifier may allow them to be linked with data held by Humind. The absence of a PostHog cookie therefore does not make the events anonymous.
Consent behavior
| Configuration | Behavior |
|---|---|
| No consent required in Humind or forwarded by the merchant | PostHog is active by default |
Consent required with a pending status | PostHog is not initialized before acceptance |
Status is accepted | Acceptance is stored and PostHog becomes active |
Status is rejected | Any previous acceptance is deleted, PostHog remains blocked, and the widget closes |
The merchant can require consent in Humind settings or forward the status from its own CMP through the cookie-consent attribute.
Only acceptance is stored in the browser. It has no automatic expiry. Refusal is not stored. After refusal, no PostHog event is sent, the widget closes, and the choice is presented again on a later opening.
When consent is required, events produced before acceptance are not sent later.
Items the merchant must complete
The merchant must complete its inventory with:
- GA4, GTM, or other services triggered from its
dataLayer; - external calendars and booking services displayed in the widget;
- retention periods for conversations, server logs, and other processing performed outside the browser.