What becomes visible during a purchase
A shopping flow naturally produces context: the product viewed, quantity, cart changes, delivery region, account or loyalty state, referral source, coupon, time, and final payment step. Analytics, advertising, fraud, experimentation, and session-replay tools may observe different parts of that flow when their browser requests or first-party integrations are present.
Not every observation is an abuse. A merchant needs some information to calculate tax, show inventory, prevent fraud, and complete an order. The privacy question is whether additional collection is necessary, disclosed, proportionate, and kept separate from unrelated profiling.
What surveillance-pricing research found
The FTC reported that pricing intermediaries can have access to location, browsing and shopping history, channel information, cart activity, and even interaction data such as mouse movements. Those systems may help retailers tailor a price, promotion, or ranking for an audience or individual.
The same FTC publication is careful about its evidence: the public staff perspective aggregates confidential study material and uses hypothetical examples. It shows that a market and technical capability exist; it does not prove that every retailer or delivery app changes each person's price from those signals.
Why two totals can differ for ordinary reasons
Inventory, time, location, taxes, fees, delivery distance, membership, currency, coupon eligibility, app-only promotions, and experiments can all change what appears. Two sessions may also refresh at different moments or compare different variants without making the difference obvious.
A useful comparison holds the ordinary variables steady: same item, quantity, location, account state, currency, fees, and time. Even then, the result is an observation rather than a backend audit. It can justify a support question or complaint, but it should not be presented as proof of a particular profiling system.
Reduce what the browser contributes
Limit unnecessary sign-ins and permissions, review third-party-cookie controls, and remove common campaign tags from links. A tracker blocker can interrupt selected analytics, replay, pixel, and ad-tech requests before they complete. First-party collection and server-side records may remain.
Cloak 2.0 applies those browser-side layers in desktop Chrome, blocks a defined set of exchange and OpenRTB requests, normalizes selected battery and device clues, and rate-limits covered high-frequency movement and visibility telemetry. It cannot protect activity inside a native mobile app or state why a merchant showed a particular price.
On supported retailer pages, Cloak can keep a purchase observation in Chrome local extension storage for up to 30 days and compare it with a later visible price. A local alert can make a drop easier to notice; it does not file a return, secure a price match, or guarantee that variants, fees, and changing page structures were equivalent.
Primary sources
