Compare your cookie and consent statement with what your tags actually do

Turn the visible statement into a checkable promise

Copy the wording from the live banner, its preference panel, and the linked cookie or privacy statement. Record the page, language, date, and choices actually offered. Identify what each sentence promises to control: storage, analytics collection, advertising activity, or all contact with a third party. Those promises require different observations. A statement about cookies alone does not describe every possible network request.

Keep the state visible alongside the words. A visitor who has not chosen yet, a visitor who refused, and a returning visitor with a saved preference are different cases. A screenshot of the banner after acceptance does not show the default behavior before a choice. If the wording or choices vary between site areas, keep each relevant version in the comparison rather than treating one homepage screenshot as the entire store.

Use this inventory to define the question for the technical and privacy owners. The question is whether the stated choice controls the behavior it claims to control. A preference label or a visible toggle is evidence of the interface; it is not evidence that the relevant tag received that choice.

Connect each choice to the tags it is meant to govern

Inventory the analytics and advertising tags actually installed through the theme, plugins, and any tag-management configuration. Record the service, the configuration location, who owns it, and which consent choice is meant to affect it. Have the technical owner identify the default state and the update applied after each choice. Keep third-party tags separate from Google tags because Google’s consent documentation does not establish how every other vendor behaves.

Google documents consent mode as a way to adjust tag behavior according to consent. That is a mechanism to inspect, not proof that a banner’s button is correctly connected to it. Advanced consent configurations can differ from configurations that block tags until consent. Refusal therefore cannot be translated into a blanket claim that the browser sends no requests. The reviewer must distinguish whether a tag loaded, whether storage was used, and what requests were actually made.

The GA4 ecommerce guide defines events such as begin_checkout, add_payment_info, and purchase that an implementation sends. Installing analytics or displaying a consent banner does not prove that those events are emitted. Conversely, the presence of an event name in a tag configuration does not show that it ran in the observed consent state. List only the implementation’s actual events and preserve unknown behavior as unknown.

Compare configuration with observed behavior in each state

Have an authorized technical owner record the live page and consent state alongside the tag configuration version and the observation time. In the no-choice state, establish that the observation did not inherit an earlier permission. After refusal, confirm what the interface saved and what state the tags received. After an allowed choice or a later preference change, compare the resulting behavior with the exact permission selected. Do not infer the underlying state from the button label alone.

Use the relevant browser network, storage, and tag diagnostics to distinguish a loaded script, a consent-state update, and an analytics or advertising request. Record the destination and type of activity in a sanitized finding. Do not publish raw request payloads, customer identifiers, full URLs containing private parameters, or browser recordings that expose order data. An unclassified request stays unclassified until its owner explains it; its presence alone does not establish what data it collected.

Compare only transitions that were actually observed or for which existing authorized evidence is available. Do not place an order or submit payment details merely to populate a consent worksheet. If purchase-event behavior was not observed, record that limit. A real order record can establish that an order exists, but it cannot establish which browser tags ran or what consent state they used.

A quiet network view in one session is narrow evidence. Record browser conditions and blockers that may have affected it, along with the pages and states examined. No request observed under those conditions is not proof that every visitor, tag, or server-side process behaves the same way.

Assign the change to the promise, the setup, or both

If the intended restriction is approved by the privacy owner but the observed tag behavior does not implement it, the configuration or code needs correction. If the recorded and observed behavior agree with the approved approach but the text describes something else, the wording needs correction. If the business has no agreed approach or cannot explain the behavior, both wording and implementation need a coordinated decision.

Do not resolve a contradiction simply by weakening the banner’s promise to match whatever the tags currently do. The qualified privacy owner determines the applicable obligations and intended treatment; the technical owner implements that decision and records the resulting behavior. Preserve the original finding and tie the correction to the affected wording, tag version, and consent state. Recheck that affected state after the change before recording the contradiction as resolved.

For a Prism website-review consultation, provide the public page, the exact promise, and a non-sensitive summary of the observed conflict. Prism’s published review scope includes store policies and business disclosures. Agree which pages, technical investigation, reporting, and follow-up are included, with scope, responsibilities, fees, and terms confirmed before work. A content review does not supply a universal privacy-law opinion or a provider approval.

Consent-statement and tag comparison

Use this comparison for the real configuration you operate. In the final column record the wording, configuration reference, observed state, finding, and owner as applicable. A missing observation stays unverified. Decide text change, configuration change, both, or no contradiction observed only for the states you actually examined.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.