Your online store's cookie banner is a business decision

The visible bar is the smallest part of the job. Consent is a state your site has to respect before anything else runs: where consent is required, analytics, advertising pixels, chat widgets, heatmaps and retargeting tags must not load until the visitor has chosen. A very large share of installations display the notice and load everything anyway, because the tags were hardcoded into the theme or fired by a tag manager that never checked the consent state. That is the failure mode with real exposure, and it is invisible from the front end. There are procedural requirements around the choice as well: refusing should be no harder than accepting, nothing except strictly necessary cookies may be pre-selected, the decision has to be recorded, and the visitor has to be able to change it later without hunting for a hidden link.

• Open a private window, ignore the notice, and watch the network tab
• Check that refusing takes one click, exactly like accepting
• Confirm nothing beyond strictly necessary cookies is pre-ticked
• Give visitors a visible way to change their choice afterwards

The two regimes are built on opposite defaults, which is why one configuration rarely satisfies both. European rules generally work on opt-in: non-essential cookies and similar technologies should not be set until the visitor agrees, and the agreement has to be informed, specific and freely given. Most US state privacy laws — California's CCPA as amended by the CPRA, and the newer statutes in states such as Virginia, Colorado and Connecticut — generally work on opt-out: give clear notice of what you collect, offer a route to opt out of sale, sharing or targeted advertising, honour browser-level signals such as Global Privacy Control where required, and answer requests about the data you hold. A US store that also draws European visitors usually ends up applying different behaviour by geography rather than choosing one. This page is general information, not legal advice: thresholds, definitions and exemptions vary by state and by how much data you handle, so have a lawyer confirm what actually applies to you.

When a visitor declines, you lose the identifier — not necessarily the entire signal. Google's consent mode is the mainstream mechanism here: tags still load but run in a restricted mode without writing cookies, sending limited pings that let the platform model the gap. It is imperfect, and it is far better than silence. Block everything by default and your reported conversions collapse, ad platforms optimise against a fraction of reality, and you start cutting campaigns that were fine. Block nothing and you carry the legal risk while browsers and ad blockers erode your data anyway. The workable middle is boring: classify every tag as strictly necessary, analytics or advertising, wire the consent state into the tag manager properly, and reconcile everything against WooCommerce order counts, the one number consent cannot distort. Analytics setup and why ad spend stops working both depend on this being right.

Cookies get the attention, but the heavier obligations usually sit in data you collect deliberately. A typical WooCommerce store holds customer names, addresses, phone numbers and full order history; email addresses captured for abandoned-cart recovery before any purchase happened; support chat transcripts with order details and occasionally card fragments a customer typed in anyway; analytics and advertising identifiers; audience lists uploaded to ad platforms; plugin logs; and database backups that contain all of it, sometimes on a third-party server nobody has thought about in two years. You cannot honour a deletion request, write an accurate policy or answer a regulator's question without knowing this list exists. Building it is unglamorous and takes an afternoon, and every later decision on this page becomes cheap once it is written down.

• List every plugin and third-party tool that receives customer data
• Include backups, staging copies and exported CSVs in that list
• Note where abandoned-cart addresses are captured and how long they live
• Write down who on your side can read support chat history

Both regimes give people a route to ask what you hold and to ask you to delete it, with a deadline attached. The cost of that request is decided long before it arrives: if customer data lives in eight places and you only remember five, the request becomes a week of archaeology. Retention is the other half. Order records generally have to be kept for as long as tax and accounting rules in your jurisdiction require, so a deletion request rarely means erasing an invoice — but analytics identifiers, chat transcripts and abandoned-cart addresses have no such justification and often sit forever because nobody set a window. Configure retention where the data actually lives, name one person who owns incoming requests, and write down the steps once so the second request costs an hour rather than a week. A maintenance arrangement is where this usually gets reviewed on a schedule instead of during an incident.

The most common problem with a privacy policy is not that it is missing but that it is fiction. Generated templates list tools you never installed and omit the three you added last year, name a legal entity that no longer matches your invoices, and promise retention periods nobody configured. That gap is easy for anyone to check: open the network tab, read the policy, compare. Build the document from the inventory instead, and state what categories of data you collect, why, who receives them, how long you keep them, how someone exercises their rights, and a contact route that a person actually reads. Then treat it as part of your release process — when a new script is added to the storefront, the policy changes in the same week rather than at the next audit.

Most consent tools are delivered as a third-party script fetched from someone else's CDN, executed early, and asked to draw a bar over your page. That is three performance problems at once: an extra connection on the critical path, a script that can delay the largest element from painting, and a bar that mounts after first paint and pushes the layout down, which is exactly what Cumulative Layout Shift measures. Interaction to Next Paint suffers too when a heavy SDK is still parsing while a shopper taps. The fixes are structural rather than clever: render the notice with the page instead of injecting it afterwards, position it as a fixed overlay so nothing below moves, keep the SDK off the critical path, and test with the bar visible rather than dismissed. On a storefront we rebuild, the notice is a component in the application and the consent state is available before the first tag is considered — see Core Web Vitals for how that budget is enforced.

• Render the notice with the page, not injected after first paint
• Use a fixed overlay so content below it never moves
• Keep the consent SDK off the critical rendering path
• Measure LCP, CLS and INP with the notice showing, not dismissed

For most stores, a mainstream consent plugin is the correct answer and engineering is not required. The risk is not the plugin — it is assuming that installing it configured anything. Defaults commonly show the notice while every tag still fires, leave geography rules unset so European visitors get the US treatment, map no scripts into categories, and change nothing about your policy. An afternoon spent auditing what actually fires, mapping categories, switching on geographic behaviour and having a lawyer read the resulting policy solves the majority of real exposure for the price of the plugin. Doing nothing is defensible only if you have verified, in analytics, that you have no European traffic and no obligations in your customers' states — verify rather than assume. Bring in engineering when the notice measurably damages Core Web Vitals, or when consent state has to survive across a rebuilt storefront and a native checkout; what that costs is published.