Analytics counted Pay clicks as completed purchases

Read the trigger behind the event name

Google's ecommerce guide describes begin_checkout, add_payment_info and purchase as events the implementation sends. The label purchase is therefore not an independent observation by the payment provider. If the site's tag sends it when Pay is clicked, the event records that click even when payment has not finished.

Inspect the deployed tag rule or integration configuration and any retained event records. Write down the condition literally: button activation, submission of payment information, a page view, or a confirmed payment result. Also identify which checkout path uses that rule. A tag name or a dashboard heading cannot substitute for the triggering condition. If the rule cannot be retrieved, the purchase count's meaning remains unverified.

Find the payment result for the same order

Use an existing affected order and its provider reference to compare the event time with the payment timeline. A Pay click can precede confirmation, required customer action and the eventual outcome. Stripe's lifecycle distinguishes requires_confirmation from requires_action; asynchronous payments can remain processing for days. None of those intermediate states establishes a completed PaymentIntent.

The same lifecycle uses succeeded for both PaymentIntents and SetupIntents, with different meanings. A PaymentIntent completes a payment flow, while a SetupIntent completes credential setup without collecting payment. Record the object type as well as the status. Do not use a saved-method confirmation as the evidence for a paid order.

Then record the store's actual rule for treating that order as paid. If the provider result and the store condition disagree, keep that case unresolved rather than making the analytics tag the deciding record. For another provider or an offline method, obtain that arrangement's own success definition. Stripe terminology does not establish the outcome on another rail.

Correct the definition without rewriting the history

Give the measurement owner a specific change requirement: distinguish the observed start action from the confirmed paid-purchase condition, and document which order and payment references connect them. An earlier action may still be useful funnel information, but it must be named and interpreted as that action. Renaming a chart alone leaves the emitting rule unchanged.

Preserve the old definition and its affected date range. Mark reports that used it so colleagues do not compare clicks from the earlier period with confirmed purchases after the correction as though the measures were identical. Where genuine retained records allow matching, prepare a separate reconciliation of those records. Do not invent outcomes for events that cannot be joined to an order.

After an authorized measurement change, use available real order and event records to establish whether the new trigger follows the documented success condition. Record the release time and any paths still unverified. A corrected event definition does not by itself establish complete analytics coverage, distinct-order counting or accounting revenue.

Take a defined measurement question to a consultation

The useful conclusion is either that the current event represents a verified payment condition, that it represents an earlier action, or that the available records cannot establish its meaning. Assign the tag definition and report annotation to a named owner. Payment status questions stay with the provider and integration owner; they are not resolved by changing a report.

For a Prism checkout-review consultation, describe the website, research-only products, event trigger and mismatch in ordinary language. Ask for the measurement investigation you need; scope, responsibilities, fees and terms are confirmed before work. The public form is not a place for customer records, passwords or payment details. Follow-up is by email, and the request does not purchase implementation or submit a processing application.

Purchase-trigger reconciliation

Complete one sheet for each deployed purchase rule. Keep real order references in your authorized internal records and enter only non-sensitive summaries here. If a payment outcome cannot be matched, leave it unresolved; do not convert the event into a sale by assumption.

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.