An ecommerce privacy policy fails in a particular way. The order data is described correctly, because somebody thought about the checkout. Everything else the store collects, which is most of what it collects, is not described at all, because it arrived as a tag somebody added to improve conversion and nobody wrote down. The policy is then true about the part the reader already understood and silent about the part they would have wanted to know.
What a store collects besides the order
Browsing and product views tied to a visitor identifier. Abandoned cart data, which is by definition collected from people who did not buy. Email and device identifiers passed to advertising platforms so that audiences can be built. Reviews and the photographs in them. Support conversations and returns correspondence. Loyalty and referral records. Shipping addresses belonging to other people when an order is a gift. Each of those is personal data, most of it is disclosed to somebody, and almost none of it is in the default policy.
Why the platform's default policy is usually untrue
A hosted store comes with a policy describing the platform's own standard processing. It cannot know which apps you installed, which pixels you added, which mailing tool you connected or which country your fulfillment partner is in. So the document is accurate about the base platform and wrong about your store, and the gap widens with every app you add. Treat it as a skeleton: keep the structure, replace the recipient list and the retention statement with yours.
The notice at collection is a separate duty
California requires a notice at or before the point of collection setting out the categories collected, the purposes, whether they are sold or shared, and the retention period. On a store that means the checkout and the newsletter box, not only the footer. It does not have to be long. A line beside the field, linking to the policy, saying what the address is used for and how long the order record is kept, discharges it and reads better than a paragraph of statute.
Keep it true when the stack changes
The event that makes an ecommerce privacy policy wrong is almost always an app installation. Put the policy on the same checklist as the install: which personal data does this app receive, does it act only on our instructions, is there an agreement, does the recipient list in the policy need a new line. It takes minutes at install and is close to impossible to reconstruct a year later, when nobody remembers which of forty tools started reading customer emails.
Questions people ask about privacy policy ecommerce
Does a small store really need its own policy?
The duty does not scale with size. What scales is how much bespoke work it takes, and for a store with a handful of apps the honest version is an afternoon.
What about the payment processor?
Name the category of recipient and the purpose. If the processor takes the card details on its own page, say that you never receive them, because it is true and it is the thing the reader most wants to know.
Do reviews count?
Yes. A review with a name, a photograph or a purchase history attached is personal data you are publishing, and the policy should say that publication is what happens to it.
Do we need a cookie policy as well?
If you set cookies beyond the strictly necessary ones, a separate cookie document listing them is much easier to keep true than a table buried in the privacy policy, and it is the one a reader actually checks.