Consent choices changed analytics counts but not order records
Treat the analytics change as a measurement question until matched order and payment records show a payment problem. Google consent mode changes tag behavior based on consent, and ecommerce events are supplied by the store's implementation. A lower purchase-event count can therefore coexist with successful payments. Compare the same period and checkout paths, record the actual consent configuration, and distinguish verified coverage changes from gaps whose cause is unknown. Neither the missing events nor the successful orders establish complete tracking of buyers.
For: A research-only store owner comparing a decline in measured purchases with continuing successful order and payment records.
Keep three counts separate: recorded store orders, successful payments according to the provider, and measured purchase events. Define the order statuses you included and the provider status you used for payment success. Count distinct records under those definitions rather than treating every order or every payment attempt as a completed sale.
Then name the analytics report, property, event, date range, time zone, filters, and time of retrieval. Google's ecommerce guide describes purchase as an event the implementation sends. It does not make the report a direct copy of the payment ledger. Confirm what event your implementation sends and when it sends it before interpreting its total.
Match orders to provider payments through existing references inside the authorized records system. Keep unmatched records visible. A stable total can hide changes within the list, so total counts alone do not prove that every order has a corresponding successful payment.
Connect the consent change to collection behavior
Record the consent configuration that applied during each comparison period and the date any change took effect. Google's consent-mode guidance says that consent state adjusts Google tag behavior. That supports investigating a collection difference after a consent change; it does not establish what your installation actually did for each visitor.
Use available implementation records to describe the behavior under each configured consent state. Distinguish a documented configuration from behavior actually observed on the relevant checkout path. If the earlier configuration was not retained, say that historical behavior is unknown rather than assuming the current settings were always in force.
A missing event does not reveal an individual's consent choice. Do not label every unmatched paid order as a refusal, infer a hidden buyer journey, or claim that all successful purchases were observed. The evidence may support only a period-level comparison between a configuration change and lower measured coverage.
Interpret matched and unmatched records differently
When a real order and its provider payment agree but no corresponding purchase event is available, the demonstrated gap is in the measurement evidence for that payment. The comparison does not show that this payment failed. If available implementation evidence connects the gap to consent-dependent behavior, record that narrower explanation; otherwise leave its cause unresolved.
When the store and provider disagree, investigate that order-to-payment mismatch separately even if consent settings also changed. Consent documentation cannot establish the payment outcome. Likewise, a purchase event without a corresponding verified payment requires checking what triggered the event, not counting it automatically as money collected.
An apparent drop after a configuration change is a reason to inspect the change, not proof of causation. Keep other known changes to the event implementation or report filters alongside it. If the event list cannot be matched to orders, report the two aggregates and that limitation instead of manufacturing order-level coverage.
Choose the next action without filling the gap by assumption
If the records support a change in measurement coverage, annotate the affected reporting period with the configuration and known limitation. Keep operational decisions about paid orders tied to the order and provider records. Do not alter consent choices just to force the analytics count to equal the ledger.
If the evidence identifies a missing or incorrect event trigger, give the implementation owner the specific path and recorded behavior. If neither consent evidence nor event records explain the gap, the next task is a bounded investigation of that path. A proportional comparison of subsequent genuine records can show whether the corrected measurement behaves as intended; it cannot establish universal buyer tracking.
For a Prism checkout-review consultation, summarize the report change, the period, and whether store and provider records agree. Include the website and research-only product context without sending order exports or customer data. Measurement investigation or implementation responsibilities must be agreed with scope, fees, and terms. An inquiry receives email follow-up and does not book or purchase that work.
Consent-aware measurement comparison
Fill the last column from one defined reporting window, then repeat for the comparison window. Keep counts distinct and use only the consent information your authorized records actually contain. A missing event with a confirmed payment is a measurement gap; consent is its cause only where supporting evidence connects them.
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.
Consent-aware measurement comparison. The last column is for temporary notes.
Comparison element
Evidence to record
Interpretation limit
Your observation
Consent configuration
Evidence to recordDated configuration and change record for the checkout paths included.
Interpretation limitCurrent configuration does not prove the settings in an earlier period.
Analytics collection behavior
Evidence to recordActual event trigger and available observations under the configured consent states.
Interpretation limitA configuration describes intended behavior; missing events do not identify individual choices.
Recorded order count
Evidence to recordDefined order statuses, distinct order count, period, and time zone.
Interpretation limitAn order total alone does not verify successful provider payments.
Payment success count
Evidence to recordDistinct matching provider payments under the provider's stated success status.
Interpretation limitKeep unmatched orders and payments visible; do not count repeated attempts as separate completed orders.
Measured purchases
Evidence to recordExact report or event extract, count, filters, and retrieval time.
Interpretation limitEvent totals need a verified meaning before comparison with distinct paid orders.
Known measurement limitation
Evidence to recordMissing references, unavailable consent observations, or unmatched checkout paths.
Interpretation limitReport the supported scope; do not reconstruct unobserved visitors or assign every gap to consent.
Decision and reporting note
Evidence to recordWhether the evidence supports changed coverage, a payment mismatch, or an unresolved collection issue.
Interpretation limitChoose the next investigation from the observed gap rather than the size of the analytics decrease.
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.
Limits
Google's consent-mode and ecommerce documentation describe Google tags and events, not another analytics product or a merchant's payment result.
This comparison does not certify consent compliance, identify every buyer, or establish complete analytics coverage.
Keep customer records, card details, authentication codes, and credentials out of the worksheet and public inquiry.
Google consent mode — checked 2026-09-21. Consent mode adjusts Google tag behavior based on consent; this supports investigating collection coverage but does not identify the cause of an individual missing event.
Google Analytics ecommerce measurement — checked 2026-09-21. Ecommerce events, including purchase, are sent by the implementation. Event measurement is therefore a separate observation from the merchant's order and payment records.
Prism solutions — checked 2026-09-21. Public support includes storefront review, card-processing preparation, and help with a provider's website questions. Scope, fees, and terms are discussed before work; the provider decides eligibility and account terms.
Prism contact — checked 2026-09-21. The inquiry asks for the website, products, and question, excluding payment card details, passwords, and customer records. Follow-up is by email; a request is not an appointment, purchase, or processing application.