A recent-purchase popup needs a real event and a defensible public display

Read the assertion the notification makes

A recent-purchase popup is a claim, repeated for every visitor who sees it. Write down exactly what yours asserts: that someone bought a specific product, how long ago, and often where they are or who they are. Each element is separately checkable, and each needs its own evidence. 'Someone purchased X' is a different assertion from 'someone added X to a cart', and the feed must not blur them.

Also record where the messages come from in configuration: which system supplies events, what filter selects them, and what template fills in the name, location and time. Many feeds can display manually entered or demonstration messages. If your configuration allows entries that did not originate from store events, that capability is itself a finding, because nothing then distinguishes a real sale from a typed one.

Trace the message to a real event of that type

Pick a sample of displayed messages and trace each to the underlying store event. The event behind a purchase message must be a completed order under the store's own paid-order condition, joined by an order reference. An analytics event labelled 'purchase' is not proof on its own — such events fire from whatever trigger the implementation sends, and a button click, an abandoned checkout or a failed payment can carry a purchase-sounding label.

Exclude what the message would misdescribe. Test orders placed by staff, cancelled or refunded orders, and draft or pending records that never completed should be filtered out by rule, not by hope. Record the filter that removes each category and verify it against real examples. If the feed counts events the store would not call sales, the honest options are to fix the source or to stop calling the messages recent purchases.

Check the timing and the repetition

The 'two hours ago' element is a claim about elapsed time. Compare the displayed delay with the event timestamp for traced messages. A feed that recycles old orders with fresh-looking relative times is asserting something false about when purchases happen, even though every order shown is real. The same applies to a feed that displays the same small set of orders on rotation: the repetition implies a purchase frequency the records do not support.

Set the display rules from the records rather than the other way round: the maximum age of an eligible order, whether relative times are shown, and what the feed shows when no qualifying order exists. An empty state or a paused feed is a defensible answer to a quiet week; backfilling with stale or invented messages is not.

Limit the customer detail on display

A completed order establishes that a purchase happened. It does not establish that the buyer agreed to appear in your marketing. Treat publication permission as a separate question from transaction records, and document the basis for every customer-derived field the template shows. Assess each retained field for identifiability in context: a first initial combined with a region can still single out a person in a small town or a niche customer base, so coarse detail is not automatically anonymous and is not a substitute for a documented basis. Where the basis for any customer-derived field is unresolved, omit customer detail from the message or hold the display until the question is resolved.

The ICO's data-minimisation guidance, a UK principle, holds that personal information should be adequate, relevant and limited to what the purpose requires. Whatever your jurisdiction, the discipline transfers: decide what the message needs to convey, then strip fields that add exposure without adding meaning. Full names, exact locations and profile photos are rarely necessary to say that a product was bought. Keep customer-level records inside the store system; the worksheet records the rule, not the customers.

Keep, correct or remove — and assign the owner

The FTC's substantiation policy requires an objective claim's evidentiary basis to exist before publication, and a notification feed publishes claims continuously. That makes the feed a standing obligation rather than a set-up task: name the owner who can change its source, filters and fields, and the condition under which it comes down — a broken event join, an integration change, or any period in which the displayed messages can no longer be traced.

Record what you verified and when: the sampled messages, the filter rules observed, the timing comparison and the field basis. A feed that passes today can fail after a platform update or a checkout change, so the verification belongs with the store's change records. For a Prism website-review consultation, describe the feed's placement, its message template and the evidence gap you have found; scope, responsibilities, fees and terms are agreed before work, and a review of the public presentation does not audit your order system or settle privacy questions, which belong with qualified advisers.

Sales-notification evidence sheet

Complete one sheet per feed configuration, tracing a sample of real displayed messages. Record rules and references, never customer identities. A message that fails any row must not display until the row passes.

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.