Privacy policy for ecommerce: what yours has to cover

Open your own store in a private browser window and watch what loads before you have clicked anything. An analytics script. Probably an ad platform's tag. A chat widget. A font from somewhere. Each of those is a third party learning that a particular person, on a particular device, in a particular city, just looked at a kettle.

That is the gap this post is about. A privacy policy for ecommerce is not a legal ornament you paste at the bottom of the site. It is a factual description of what your store does with information about people — and the reason copied ones are dangerous is that they describe someone else's store, which makes your policy a false statement rather than a missing one.

Step 1: inventory what you actually collect

Before you write a word, list the data. Almost every store collects more than its owner would say from memory. Walk the store and the dashboard, and write down what arrives at each point.

• Checkout: name, email, delivery and billing address, phone, order contents, the order value, sometimes a note to the courier or a date of birth for age-restricted items.
• Payment: you almost certainly do not hold the card number, but you do hold the last four digits, the card type, a transaction ID and often the billing name and country.
• Accounts: a password hash, an order history, saved addresses, a wishlist.
• Marketing: newsletter subscribers, who opened which email, who clicked, abandoned-cart records — which means you are storing an email address for a sale that never happened.
• Analytics and ads: cookies, device and browser details, IP address, referring page, a journey through your site, and advertising identifiers that let a platform match the visitor to a profile it already holds.
• Support: chat transcripts, emails, social DMs, and if you take phone support, call records or recordings.
• Reviews and user content: names, photos, whatever people typed.
• Staff: admin accounts, who logged in, who changed what.
• Server logs: IP addresses and request records, usually kept automatically for some period you have never chosen.

Two entries on that list surprise people every time: abandoned-cart data and support transcripts. Both are personal data about identifiable people, both accumulate silently, and neither usually appears in a policy that was copied from somewhere else.

Step 2: list everyone else who gets it

Your store is not one system, it is a dozen vendors in a trench coat. Write each one down with what it receives: platform, payment gateway, carriers, email marketing tool, analytics, ad platforms and their pixels, review tool, chat or helpdesk, accounting software, any AI features, and anyone on your team or at an agency with a login. Note roughly where each company operates — international transfers are a category privacy regimes treat specifically.

If you use AI features for support or marketing, say so plainly. On mAutomate the AI Customer Support answers customers on your site, which means customer messages are processed by an automated system; the AI Marketing Suite drafts content from your catalogue. The human-in-the-loop design means nothing publishes until you approve it, but approval is not the same as not processing, and your policy should describe the processing honestly.

Step 3: write down why, for each item

Policies that only say what they collect read as evasive. For each item, state the purpose in a sentence a customer would accept: to deliver your order, to answer your question, to stop fraud, to send offers you asked for, to see which pages work.

If a purpose makes you uncomfortable to write down, that is information about the purpose, not the writing. The classic case is sharing shopper behaviour with an ad platform for retargeting — real, common, and conspicuously vague in most policies.

Some regimes also require a legal basis for each purpose, and distinguish what needs consent from what needs only disclosure. Which apply to you is a question for a professional; the inventory underneath is the same either way, and it is yours to build.

Step 4: decide how long you keep things

"Indefinitely, because nobody ever deleted anything" is the honest answer for most small stores and it is not a good one. Decide a period for each category — orders and invoices usually have to be kept for accounting reasons, which is a different clock from marketing lists and support transcripts.

Then check whether your tools actually do what you decided. A retention sentence nobody enforces is one more thing in the policy that is not true.

Step 5: cover the standard sections

A policy that a reasonable customer can use generally needs all of these, in plain language.

The "how to exercise them" row is the one that fails most often in practice. If the policy names a contact address, someone has to be reading it, and someone has to know what to do when a request arrives. Decide that before you publish, not when the first email lands.

Step 6: publish it where it is actually usable

Link it in the footer on every page, beside your terms and returns policy, and again at checkout and at the newsletter signup — next to the field where data is handed over, which is the moment a person might care. If you run a cookie banner, the policy behind it must describe the cookies you really set.

Why a copied policy is worse than none

A missing policy is a gap. A borrowed policy is a claim, and three things go wrong with it.

It describes the wrong store. It may promise you do not use tracking cookies while your ad pixel fires on every page, or omit the chat transcripts and call records you genuinely hold. Anyone can check the first part in a minute with a browser's developer tools. You have published something checkably false about your own business.

It creates promises you cannot keep. Copied policies name contact addresses, response times and rights processes that belong to another company. When a customer uses them, nothing happens, and now you have a complaint about the handling of a complaint.

It is often written for a jurisdiction that is not yours. It will name regimes that do not apply to your customers and miss the ones that do, while sounding authoritative throughout.

Starting from a template is reasonable. Publishing a template unread is not. The practical test: read your policy line by line with your step-1 inventory beside it and strike every sentence that is not true of your store. If a sentence needs to stay but is not true yet, the fix is to change the store, not the sentence.

What this post deliberately does not tell you

Which laws apply to you, what your retention periods should be, whether consent is needed before a cookie fires, or whether a named regime covers your customers. Those depend on where you and your buyers are, and they change. Your own data protection authority usually publishes free small-business guidance, and reading it for your jurisdiction beats nine articles that each assume a different one. Broader picture: our legal basics orientation. The inventory above is the part you can start today.