By platform

Cookie Policy Generator for BigCommerce

Written for BigCommerce checkout, its app marketplace, headless storefronts and multi-storefront setups.

Generate your cookie policy Read the cookie policy guide

On BigCommerce the cookie policy is largely a readout of Script Manager, which is the one place every third-party tag is registered - and on a multi-storefront account, the same script list may need different consent treatment per market.

BigCommerce is used disproportionately by larger and more complex stores, which changes the compliance picture. Multi-storefront setups sell the same catalogue into several countries from one backend, headless builds move the storefront onto a separate front end entirely, and B2B features add company accounts with multiple buyers under one customer record.

Each of those raises a question a single-storefront policy does not answer. Multi-storefront means one backend covering several jurisdictions with different consent rules. Headless means the tracking lives in your own front end rather than in a theme BigCommerce controls. B2B means personal data about named individuals inside a business account.

BigCommerce provides a consent-management integration and its own script manager, which is where third-party tags are registered. That script manager is the single most useful inventory for building an accurate cookie and recipients disclosure.

What a cookie policy for a BigCommerce store has to cover

BigCommerce platform and session cookies, split by whether the store can function without them
Every Script Manager entry, with its provider and consent category
Per-storefront differences where one backend serves several jurisdictions
Headless front-end tags, which the platform banner does not reach
How consent is enforced and what a visitor sees after refusing

How a BigCommerce store actually moves personal data

Checkout and customer accounts

Billing and shipping data, order history and saved addresses, held per storefront but in a shared backend.

Script Manager tags

Analytics, advertising and support scripts registered centrally and injected into the storefront.

Headless front-end tracking

On a custom front end, tags live in your own code and are outside anything the platform gates by default.

B2B company accounts

Named buyers, approval hierarchies and purchase limits - personal data attached to a business relationship.

Multi-storefront customer segmentation

The same customer may exist under several storefronts with different applicable law.

Payment gateway hand-off

Stripe, PayPal, Braintree or an enterprise gateway, each seeing different fields depending on integration mode.

Third parties the draft will ask you about

BigCommerce · Stripe · PayPal · Braintree · Klaviyo · Google Analytics 4 · Avalara · ShipperHQ

The rules that apply

BigCommerce Terms of Service and DPA

BigCommerce processes store data on your behalf, with a published data processing addendum and sub-processor list.

Script Manager and consent

Third-party scripts are registered centrally and can be gated by consent category, but only if each script is categorised.

Multi-storefront jurisdiction split

One backend serving several markets means several sets of consent, cancellation and disclosure rules.

Headless storefront responsibility

With a custom front end, the tracking, the banner and the consent enforcement are yours rather than the platform’s.

B2B customer accounts

Company accounts contain personal data about named buyers, which is personal data even in a business context.

What the generated cookie policy contains

What the technologies actually are
Cookies, local storage, session storage, pixels, SDKs and server-side tags - the law covers storage and access on a device, not the word "cookie".
A per-cookie table
Name, provider, purpose, category and duration for each cookie, which is the format UK and EU regulators expect to see.
Category definitions
Strictly necessary, functional, analytics and advertising, with an honest explanation of why only the first runs without consent.
How consent was obtained and how to change it
The banner, the granular choices, and a permanent link to reopen preferences - the withdrawal route has to be as easy as the acceptance route.
Third-party cookies and onward use
Which providers set cookies through your site and what they do with the data once it is theirs.
Browser and device controls
Practical instructions, plus a note that blocking strictly necessary cookies will break parts of the service.

Publishing the document on BigCommerce

Add each document as a web page and link it in the footer
BigCommerce also has a dedicated privacy policy setting that surfaces the link at checkout.
Audit Script Manager and categorise every entry
It is the authoritative list of what runs on the storefront.
Produce per-storefront variants where markets differ
One backend does not mean one legal position.
For headless builds, implement consent in the front end
And confirm nothing non-essential loads before it.
Document the B2B account model
Who can see what, and what happens when a named buyer leaves the company.

Where this usually goes wrong

One policy across every storefront

Different markets have different consent, cancellation and disclosure rules. A single policy is wrong somewhere.

Headless builds with no consent enforcement

The platform banner does not reach a front end it does not control.

Uncategorised scripts in Script Manager

Anything not assigned a consent category loads regardless of the banner.

B2B data treated as out of scope

A named buyer at a company is still a person with rights.

Tax and shipping services undisclosed

Automated tax calculation and rate shopping transmit address data on every quote.

Frequently asked questions

Does BigCommerce provide a privacy policy?

No. It provides hosting, a privacy policy setting that surfaces your link at checkout, a data processing addendum for its own role, and consent tooling. The content is yours.

How do I handle multiple storefronts in different countries?

Produce a variant per market rather than one document that hedges. Consent rules, cancellation rights and disclosure duties genuinely differ, and a single hedged policy is inaccurate in most of them.

What changes with a headless storefront?

Everything on the front end becomes yours: the tags, the banner, and the enforcement. Platform-level consent tooling does not reach a front end it does not render.

Do I need a cookie policy as well as a privacy policy?

In the UK and EU, yes in practice. PECR and the ePrivacy Directive regulate storing and reading information on a device separately from GDPR’s rules on processing, and the per-cookie disclosure is too detailed to bury in a privacy policy.

Do analytics cookies need consent?

In the UK and EU, yes - the ICO has said repeatedly that analytics is not "strictly necessary". Some EU regulators allow a narrow exemption for first-party, non-shared audience measurement, but the default answer is consent first.

Does a cookie policy need updating when I add a tool?

Yes, and this is the clause that goes stale fastest. Every new tag, pixel or embedded widget adds cookies your table does not list. Scanning your own site on a schedule is the only reliable way to keep it honest.

What about cookies set by embedded video and maps?

They count. An embedded YouTube player or Google Map sets third-party cookies as soon as it loads, so either it loads only after consent, or you use a privacy-preserving embed mode and say so.