Cookie consent

ConnectWiz can hold your website's cookie consent in the same code that runs the chat widget and captures where visitors come from. When it is on:

• every consent signal starts denied, on every page, before any tag runs;
• the visitor's choice is kept in a first-party cookie and re-applied on every page;
• the tags already on your page — Google (Consent Mode), Meta Pixel, Microsoft Clarity, Microsoft UET (Bing Ads) and the OpenAI pixel — are told the choice in their own words;
• visitors see the ConnectWiz cookie banner — Accept all, Reject all and Preferences, in their language — until they choose, and a small cookie button afterwards to change or withdraw the choice;
• every choice is recorded as proof (who, when, which categories, which version), separately from the person's marketing consent.

Who can set it up

Cookie consent is part of every plan. Setting it up — the switch and the Cookie consent tab — needs the Manage integrations permission (integrations.manage). Reading and exporting the Consent records also needs Manage consent registry (İYS) settings (consent.manage); deleting a browser's records needs Delete or anonymise a person's data (contacts.erase).

Switch it on

1. Go to Settings → Integrations → Website and open your site.
2. Make sure Capture with the chat widget code is on: the consent runs inside the chat widget code. (See Connect your website.)
3. Under What the site script does, switch on ConnectWiz cookie consent.
4. Open the Cookie consent tab to word and style the banner (see Set up the banner), then copy the install block from the Setup tab.

Install

With cookie consent on, the Install card gives you one block of code:

1. a short inline script (under 1 KB) that sets the consent defaults, and
2. the chat widget line you already know.

Paste the block into every page, at the very top of <head> — above Google Tag Manager and every other tag — and keep the two parts together, in this order. Google requires the consent default to be set before any of its tags runs; it cannot be set later by a script that loads in the background, which is why the first part is inline.

With cookie consent off, the Install card shows only the widget line, as before.

Tags in Google Tag Manager?

Choose B — Google Tag Manager + ConnectWiz consent in the Setup tab: then the ConnectWiz Consent template in Tag Manager sets the defaults instead of the inline script, and the install code is the widget line alone. See Use with Google Tag Manager.

On a WordPress site

You do not need to paste anything. Under Install, choose Download the WordPress plugin, then in WordPress go to Plugins → Add New → Upload Plugin, upload the .zip and activate it. Your copy already carries the widget key.

The plugin puts the chat on every page and, with cookie consent on, the first part of the block at the very top of <head> — before Google Tag Manager and every tag other plugins print. It asks ConnectWiz for that part when you save its settings and then every hour, so a change you make here (a region rule, for example) reaches the site without pasting the block again. Its settings page, Settings → ConnectWiz Chat, has a Cookie consent box that says what ConnectWiz knows about the site, and a Check now button.

• The WordPress address must be one of this site's domains, and the site must be linked to the chat widget. Otherwise the box says ConnectWiz does not know the site, and the plugin adds the chat only.
• With mode B, the plugin adds no inline code: the template in Tag Manager sets the defaults.
• If ConnectWiz cannot be reached on a check, the plugin keeps the last code it had. A passing outage does not take the consent defaults off the site.
• A page cache (WP Rocket, LiteSpeed Cache and the like) keeps serving the old page until you purge it. The plugin marks its scripts so that "delay" and "defer JavaScript" options leave them alone.
• With the WP Consent API plugin active, the visitor's choice is passed on to it (statistics, marketing, preferences). Plugins that follow that API, WooCommerce and Site Kit among them, then respect the ConnectWiz banner too.
• Remove any other cookie banner plugin, and do not paste the block into the theme as well.

What the first part does

• gtag('consent', 'default', …) with every signal denied (ad_storage, ad_user_data, ad_personalization, analytics_storage, functionality_storage, personalization_storage), security_storage granted, and a 500 ms wait for the update;
• ads_data_redaction on, so Google ad requests carry no click identifiers while ads storage is denied;
• the same denied default for Microsoft UET;
• if the visitor already chose on an earlier page, their choice is applied straight away, before any tag reads a cookie.

The banner

The banner appears on every page of your site until the visitor chooses. It does not cover the page or block it (no cookie wall) and never moves your content: it floats at the position you pick, in the system font, in the visitor's language (every panel language; Arabic, Hebrew, Persian and Urdu right-to-left).

• First layer: a short text, your cookie policy link, and three buttons — Accept all, Reject all, Preferences — drawn exactly alike. The law asks for equal weight, so the panel offers one button style for all three.
• Preferences: one row per category. Strictly necessary is always on and is not a choice; every other box starts empty. Each category says what it is for, which providers it covers, the countries their data may go to, and its cookies (name, provider, duration, first or third party). Choose and press Save my choices, or Accept all / Reject all here too.
• Your consent ID appears in the preferences once a choice exists. A visitor can quote it to ask what was recorded or to have it deleted — see The Consent records tab.
• The cookie button stays in a bottom corner on every page after the choice. It reopens the preferences; Reject all there withdraws an earlier yes, as easily as it was given. Your own link can do the same: window.cwz.consent.open().

The banner code is downloaded only when it must show: a returning visitor whose choice still holds downloads only the cookie button (under 1 KB).

Set up the banner

Settings → Integrations → Website → your site → Cookie consent. The preview on the right shows your unsaved change, both layers; Publish makes it live.

• Texts: pick a language and type your own wording; an empty field keeps the default text of that language. Plain text only. Add the address of your cookie policy — it is shown as its own link, apart from the buttons.
• Look: the banner wears an appearance template — layout, button style, colours, the cookie button and more. Change the look opens the studio. Accept all, Reject all and Preferences always look the same, text stays readable (4.5:1) and the cookie button cannot be switched off, whatever the template.
• Categories asked for: analytics, marketing and functional; strictly necessary is always listed.
• Providers on this site: tick the tags your site uses (Google Analytics, Google Ads, Meta Pixel, Microsoft Clarity, Microsoft Advertising, OpenAI Ads). The banner lists them with their cookies and their country; a tag it finds on the page is listed even if you did not tick it. Add your own cookies (name, provider, category, days or session, party, purpose) for the cookie table.
• Ask again after: how long a choice is kept before the banner asks again — after a yes 1–12 months (default 12), after Reject all 6–12 months (default 6; never sooner, so a refusal is not asked away).

Data transferred abroad

The banner names the country each provider's data goes to (for the providers above: the United States). It informs; it does not replace the legal step for transfers abroad — under KVKK usually a standard contract with the provider and a notice to the Board.

ConnectWiz's own entries (the consent cookie, the chat's storage, the attribution cookie) show the United States too: ConnectWiz processes what they carry on servers there. ConnectWiz is your processor for this data; name it in your privacy notice like your other processors.

Region defaults

Before a visitor chooses, everything is denied, everywhere — that is the default. You may add up to five rules that open other regions (for example analytics granted by default in the United States). Türkiye, the EU/EEA, the United Kingdom and Switzerland are always denied and cannot be named in a rule. The banner still shows in an opened region, so visitors there can refuse.

Region rules are written into the inline part of the install block. After changing them, copy the install block again from the Setup tab; the block must stay under 1 KB, which is why the number of rules is limited.

Publishing and versions

Every choice is recorded under the banner version. Changing the texts, the policy link, the categories, the providers or your cookie list publishes a new version, and every visitor is asked again — their earlier choice no longer counts until they answer (their consent ID stays the same). Colours, positions, the re-ask periods and region rules do not change the version.

The categories

Category	Consent Mode signals	What it covers
Necessary	security_storage	Always on; needs no consent. The consent cookie itself is here.
Analytics	analytics_storage	Statistics tags (Google Analytics, Clarity).
Marketing	ad_storage, ad_user_data, ad_personalization	Ad tags and click ids (Google Ads, Meta, UET, OpenAI), ConnectWiz's _cw_at attribution cookie.
Functional	functionality_storage, personalization_storage	Preferences such as a remembered language.

Boxes start empty: a category left out of a choice is refused.

Set the choice from your site

// Everything accepted / refused
window.cwz.consent.acceptAll();
window.cwz.consent.rejectAll();

// A mix: categories left out are refused
window.cwz.consent.set({ analytics: true, marketing: false, functional: true });

// Take everything back (as easy as giving it)
window.cwz.consent.withdraw();

// Open the banner's preferences (e.g. from a "Cookie settings" link in your footer)
window.cwz.consent.open();

// Read the current state, and follow changes
window.cwz.consent.get(); // { analytics, marketing, functional, source, id, version, at }
window.cwz.consent.on((state) => { /* … */ });
window.addEventListener('cwz:consent', (e) => console.log(e.detail));

window.cwz exists once the widget code has loaded; call it from your own buttons or links, not from the very top of the page. With the ConnectWiz banner you do not need these calls; they are there for a site that builds its own buttons.

Where the choice is kept

• Cookie cwz_consent on your own domain: the consent id, the version, the categories and the time. Kept as long as your Ask again after periods say (by default 12 months when anything was accepted, 6 months when everything was refused); after that, or after a new banner version, the visitor counts as not having chosen and sees the banner again. A copy is kept in the browser's local storage in case the browser drops the cookie early.
• The cookie is the consent tool's own preference cookie: it needs no consent of its own. List it in your cookie policy as necessary.

What happens to the tags

Tag on your page	When the visitor accepts the category	When they refuse or withdraw
Google tag / Google Tag Manager	gtag('consent', 'update', …) granted	Updated to denied
Meta Pixel	fbq('consent', 'grant')	fbq('consent', 'revoke')
Microsoft Clarity	clarity('consentv2', …) granted	denied; Clarity removes its cookies
Microsoft UET	uetq consent update, ad_storage granted	denied
OpenAI pixel	oaiq('consent', true)	oaiq('consent', false)

When a category is withdrawn, the cookies of these tags for that category (_ga, _gid, _gcl_*, _fbp, _fbc, _clck, _clsk, _uetsid, _uetvid, __oppref, __obref) are deleted from your domain, and ConnectWiz's own _cw_at cookie goes too.

In these modes ConnectWiz only tells the tags you already have. To have ConnectWiz load them — only after consent, with the events and one event id — use the tag manager (mode A). Meta and OpenAI start "granted" by default if your page loads them before the widget code — see the next section.

Pixels that start before consent

The Meta pixel does not read Google Consent Mode, and the OpenAI pixel starts with consent given. Both must be told "revoked" before their init line — which the widget code, loading in the background, cannot guarantee for a pixel your page starts itself. When ConnectWiz sees such a pixel already started with no revoke in front of it, the Cookie consent tab shows "The Meta pixel starts before consent on this site" (or the OpenAI one), with the last time it was seen. To fix it:

1. move the pixel's code below the ConnectWiz install block, or load it from Google Tag Manager with Require additional consent on ad_storage;
2. if the pixel stays in the page, call fbq('consent', 'revoke') — for OpenAI oaiq('consent', false) — before its init line;
3. check again after a day: the warning disappears 30 days after the last sighting.

A pixel whose library has already started and emptied its queue cannot be read this way, so no warning does not prove the order is right. The lasting fix is the tag manager: ConnectWiz loads these tags itself and tells them the choice before their init.

Your own consent tool instead

If your site already has a consent banner, leave ConnectWiz cookie consent off. ConnectWiz still reads your tool's answer — it never sets it:

1. window.cwConsent ({ ads, analytics }), if your site sets it;
2. an IAB TCF consent tool (__tcfapi): analytics needs purposes 1 and 8 or 9, marketing purposes 1, 3, 4 and 7;
3. Google Consent Mode calls in your dataLayer.

No signal at all counts as no consent. See Consent for what attribution keeps with and without it.

One visitor id

The consent id in cwz_consent is also the visitor's id on your site — only while analytics or marketing is accepted. The visits, the page journey, the chat and the forms of one browser then land on one visitor, across days. A visitor who refused keeps a new id for each browser tab, as before. A visitor who already had a _cw_at cookie keeps that id.

The consent records

Every choice made through ConnectWiz is stored as its own row, never edited: the consent id, the version, the categories, accept / reject / mixed / withdrawn, the page (without its query string), the language, the country, the visitor's IP address cut to its network (203.0.113.0/24) with a keyed hash of the full address, and the browser, system and device type. The full IP address and browser string are never stored.

• A choice is not a marketing or commercial-message (İYS) consent: those are recorded separately and are not changed by it.
• Contact card → Marketing consent → Cookie choices downloads the records of that person's browsers (JSON) — for an access request. A browser that refused everything never shared its id, so its records are linked to no one.
• Deleting or anonymising a contact deletes their cookie consent records.
• A choice that refuses every optional category (Reject all, a withdrawal, or Save with every box empty) keeps no IP information at all — neither the network nor its hash; the consent id, version, choice, time, country and device type remain as proof that the refusal was honoured. Records written before this rule keep what they had.
• Records are kept 13 months by default; see below.
• When a visitor withdraws marketing consent, ConnectWiz stops sending their ad conversions to Meta and Google Ads (click ids included).

The Consent records tab

Settings → Integrations → Website → your site → Consent records.

• List and filter by site, date range and action (accepted all, rejected all, own choice, withdrew), newest first.
• Search by consent ID — the ID a visitor quotes from the banner's preferences. This is the only way to find a visitor who refused everything: they never shared a visitor id, so no contact is linked to them.
• Export the filtered records as CSV or JSON (up to 50,000 rows); every export is written to the audit log.
• Delete one browser's records: search its consent ID, then Delete this browser's records and confirm. Use it for a visitor's erasure request. It cannot be undone; the audit log keeps that a deletion happened and how many records went, but not the ID itself.
• How long records are kept: one value for every site of the workspace, 13 months by default, at least 12 — the longest a choice is valid, so the proof of a choice is never gone while the choice still counts — and at most 120. Older records are deleted every night.

The same records can be read (not changed) from your own AI agent over MCP — list_consent_records — and the banner settings read and changed with get_cookie_banner / update_cookie_banner (a key with mcp:write).

Consent rates

Above the list, How visitors answered shows the last 7, 30 or 90 days: the share of browsers that accepted all, rejected all, made their own choice or withdrew; how many granted analytics, marketing and functional; the share without marketing consent; and the same by country and by device. Each browser counts once, with its latest choice in the period.

• A country or device with fewer than ten browsers is not shown on its own (it goes into "Other", which is hidden too when it is that small). A period with fewer than ten browsers in total shows only the counts. Small groups say more about a few people than about your site.
• No consent id, IP or page is in these numbers.
• The country is looked up from the visitor's address on ConnectWiz's own servers (DB-IP's free country database, refreshed monthly; the address is sent nowhere for it). An address it cannot place — a private network, some mobile carriers and VPNs — has no country, and the breakdown shows Unknown for it. The totals and rates are still right. Records made before 27 October 2026 have no country.
• Reports → Conversions shows the same "without marketing consent" share as Consent loss: those visitors' conversions reach Meta and Google Ads only through what consent allows on the server side.
• Over MCP: get_consent_report (needs the same permission as the records).

Scan your site

Settings → Integrations → Website → your site → Scan.

The scanner opens your site in a fresh browser — no cookies, nothing stored — three times, and lists what each visit sets and sends:

Visit	What must be true
Before a choice	Only strictly necessary cookies and storage. No tag sends data, except Google tags in Consent Mode with every signal denied.
After "Reject all"	The same: the refusal stops every optional tag.
After "Accept all"	Everything the visitor allowed may run, and Google tags report consent granted.

It opens the home page and up to four links on it (the same pages in every visit), waits a few seconds on each for late tags, and reads cookie names, domains, first or third party and lifetimes — never their values — the names of localStorage / sessionStorage keys, and every request to a known tracking host (Google, Meta, Microsoft, TikTok, LinkedIn, Yandex, Hotjar, Pinterest, Snap, X, OpenAI). For Google requests it decodes the Consent Mode parameters (gcs, gcd, npa, dma). A site with ConnectWiz consent off is visited only before a choice — that is the question it can answer.

• Scan now runs a scan in the background (one to three minutes). At most three scans per site per hour and twenty per workspace per day; one at a time per site.
• Scan again every week — off by default. Turn it on and a new tag that starts before consent shows up within a week.
• The "Accept all" visit loads your tags like a visitor does, so your own analytics may count a few page views from it (its browser identifies itself as ConnectWizConsentScan).
• The scan runs from the server's country (United States). If you set a region default that allows tags there, what that rule allows is not counted as a leak before a choice.
• It does not read your robots.txt: you are looking at your own site, a handful of pages, on request. Pages behind a login, forms and checkout are not visited.
• If the panel says "The scanner is not available yet", this installation has no headless browser installed; nothing is scanned until it is.
• Over MCP: get_consent_scan reads the latest scan, run_consent_scan starts one (mcp:write).

Each finding has a severity — High (something runs without consent), Medium (consent is not applied the way it should be), Low (the banner's information is incomplete), Note — and what to do about it.

The consent script is missing or the banner does not appear

ConnectWiz consent is on, but the page does not load widget.js, or a first-time visitor saw no banner, or a returning visitor's choice was not read back. Paste the install code into the <head> of every page (with the consent part above Google Tag Manager), and check that no other script removes the banner or deletes the cwz_consent cookie.

Cookies before consent or after "Reject all"

An analytics or marketing cookie (or storage key) was written before the visitor chose, or after they refused. Something loads that tag without waiting:

• In Google Tag Manager: open the tag → Advanced settings → Consent settings → Require additional consent for analytics_storage or ad_storage. Google's own tags already wait in Consent Mode.

• On the page: load the tag only after the choice allows it:

  window.addEventListener('cwz:consent', (e) => {
    if (e.detail.marketing) { /* load the tag here */ }
  });

Preference (functional) cookies are reported as Low.

ConnectWiz's own copies for the current tab are not reported. Without consent, ConnectWiz keeps the campaign of the visit (_cw_at, without any click id) and the tab's page journey (_cw_ps) in the browser's session storage. They carry a random id that is never joined to a person, and they are gone when the tab closes. The same _cw_at written as a cookie or into local storage before a choice is reported.

Tags that send or load before consent

• Sends data (a hit, a pixel, a collect call) before a choice or after a refusal: High. Block the tag until its category is allowed, as above. For the Meta and OpenAI pixels see Pixels that start before consent.
• Loads a tag that has no consent switch of its own — TikTok, LinkedIn, Yandex, Hotjar, Pinterest, Snap, X: Medium. These must not load at all until consent; move them behind consent.
• Microsoft Clarity without its cookies and Microsoft UET marked denied work in a cookieless mode; they are reported as Medium and as a Note.

Google Consent Mode

• Google tags run without Consent Mode — requests carry no consent state, so they behave as if consent were given. Add the ConnectWiz consent block at the very top of <head> (or, with Tag Manager, the ConnectWiz Consent template on Consent Initialization – All Pages) before any Google tag.
• Granted before a choice / after "Reject all" — another consent default or an early gtag('consent', 'update', …) grants consent. Remove the other consent code so only the ConnectWiz choice speaks.
• The default comes too late — the tag read consent only after it started (or the default came after the tag's config). The default must run before the Google tag loads, never asynchronously.
• Consent Mode v2 signals missing — ad_user_data and ad_personalization are not set. The ConnectWiz block and template set them; remove an older snippet that sets only ad_storage and analytics_storage.
• "Accept all" does not reach Google tags — after acceptance requests still say denied: you lose measurement you are allowed to have. Check that widget.js runs on the page.
• Cookieless pings (a Note) — with every signal denied, Google tags send a signal without cookies or identifiers that Google uses for modelling (advanced Consent Mode). Google allows it; whether it is acceptable for your visitors is a legal choice. To send nothing before consent, block the Google tag until consent.

The scanner reads the consent state from the request's address and, for Google beacons that send it in the request body (GA4's /g/s/collect), from the body. A beacon whose body it could not read is not judged either way.

Cookies nobody recognises

The scanner names cookies from ConnectWiz's own list, the tags it knows and the Open Cookie Database (Apache-2.0). A cookie in none of them is listed as unknown: find out which script sets it and describe it yourself under Cookie consent → Your own cookies (category, provider, lifetime).

Cookies missing from the banner

Every cookie on your site must be described in the banner — strictly necessary ones too. Under Add to the banner's cookie table the scan proposes the known tags and the database's entries for the cookies it saw: tick the ones that are right and Add selected. Nothing is added on its own. Adding changes the banner version, so every visitor is asked again. The database's description is in English — edit it in the Cookie consent tab if your banner speaks another language.

What the scanner cannot see

It visits a few public pages from one country with a desktop browser. It does not log in, fill forms or open your checkout; it does not open private or local addresses (a tag loaded from one is listed as refused); and a tag that fires only on a click or a scroll may not show. A clean scan is good evidence, not a proof — scan again after you change your tags.