Ecommerce privacy by design starts before the privacy notice is written. It begins when a store decides what to collect, which services receive it and how a customer can use the site without being pushed through unnecessary data requests. Those decisions belong in the launch plan alongside payments, stock and delivery.
For an EU-facing store, the practical work crosses product, development, marketing and legal responsibilities. A copied policy cannot describe an operation that nobody has mapped. The AEPD's privacy-by-design guidance supports considering privacy throughout the design process; the implementation still needs to reflect the actual business and its applicable obligations.
This is a project-planning guide rather than a determination that a particular store complies with the law. It explains the questions a team should settle with its qualified adviser and then turn into visible, testable behavior.
Follow one customer through the store
Start with an ordinary journey: viewing a product, adding it to a basket, paying, receiving updates and asking for help. At each step, list the information collected and the systems that receive it. Include services loaded through themes, plugins and tag managers.
Then repeat the exercise for a customer who does not create an account, declines optional tracking or returns an item. These paths often reveal assumptions that the happy-path checkout hides. The store should have an intentional response to each choice.
Keep the map understandable to non-developers. A diagram naming the screen, data category, purpose and recipient is often enough to start a useful conversation. The technical details can sit behind it where the implementation team needs them.
Give every field a reason
Ask why each form field exists. Some information is needed to complete an order or respond to a request; other information may be optional or collected for a separate purpose. The responsible adviser should help determine the appropriate treatment.
Challenge inherited fields. A template may ask for a date of birth, company name or phone number because another store once needed it. That is not a reason to make the same field mandatory in your checkout.
Record the decision so it survives future redesigns. Otherwise a well-intentioned developer can reintroduce an unnecessary field when installing a new checkout component. A small field inventory gives the team a reference when the interface changes.
Separate order communication from marketing decisions
A receipt, delivery update and promotional campaign serve different purposes. The system design should reflect those distinctions rather than putting every email address into one undifferentiated audience.
Map what happens when an order is placed, when a customer changes a preference and when someone unsubscribes from a particular communication. Ask the legal owner to define the rules, then give development and marketing a shared specification.
Test the behavior in the actual tools. A preference saved in the storefront is not useful if a separate marketing platform ignores it. The acceptance test should follow the change all the way to the system that sends the message.
Build a vendor list that reflects the real site
The obvious providers are not the only recipients to consider. Customer support, fraud prevention, reviews, analytics, advertising, fulfillment and embedded content can all introduce additional services into the journey.
For each service, record its purpose, the data involved, the relationship to the business and the relevant contractual review. Assign an owner who can answer questions when the service changes or a plugin is replaced.
Do not assume a vendor's general privacy statement settles your store's responsibilities. The actual configuration and agreement matter. The project should identify which questions need specialist review rather than leaving the developer to infer them from a marketing page.
Resolve the checkout questions before the release meeting
A customer enters an email address to receive an order confirmation. The marketing team wants to use the same address in a campaign, and a new support tool will receive a copy of the order. Those are three different uses to put on the launch map, with their purposes and recipients made explicit.
That is a concrete brief for an adviser such as PrivaLex, whose services cover privacy, legal advice and information security. Bring the checkout screens, proposed messages and supplier list together. Ask which decisions need to change the product and who should approve each one within the applicable jurisdiction.
The useful output for the developer is specific: which field changes, what triggers a message, what a supplier receives and what must be tested before launch. Add those decisions to the release checklist so that a later change to the checkout does not quietly undo the agreed setup.
Turn legal decisions into acceptance criteria
A decision that remains in an email is easy to lose during development. Translate it into the behavior expected on a page or in a connected service. The legal owner should confirm the intended requirement; the implementation team should explain how it will be tested.
| Decision area | Example of a useful implementation question |
|---|---|
| Form collection | Which fields are required, optional or removed? |
| Preferences | Where is the choice stored and propagated? |
| Tracking | Which services load under each permitted condition? |
| Customer requests | Who receives, verifies and processes the request? |
| Retention | What action occurs when the agreed period ends? |
The table is a handoff aid, not a universal legal checklist. Its purpose is to make the agreed requirements observable in the finished site.
Plan customer requests as an operational workflow
Decide where requests concerning personal data arrive and who owns the response. The process may need input from several systems, so a single inbox without a routing plan can leave staff improvising.
Have the responsible adviser define the requirements for identity verification, response handling and exceptions. Avoid collecting unnecessary additional information simply because a form makes it easy. The verification step should be designed for the request and its risks.
Document how the outcome is recorded. A completed task should mean the relevant action was taken or the decision explained, not merely that the first support ticket was closed. Train the people who will handle the workflow after the launch team leaves.
Treat retention as a system behavior
Teams often discuss retention in policy language and then discover that every connected tool keeps its own copy. Map where information remains after an order, account or support conversation is no longer active.
The appropriate periods and exceptions require a business and legal decision. Once agreed, identify which systems can implement them automatically and which need a controlled manual process. Include backups and exports in the discussion where relevant.
Give changes an owner. Adding a new reporting tool can create another copy of customer information without changing the visible storefront. A periodic review of the service map helps the team notice that the operation has drifted from the original specification.
Review the site after integrations are switched on
A staging site with integrations disabled cannot prove the final production behavior. Test the agreed customer paths in a controlled way after configuration is complete, using appropriate test data and approved procedures.
Check what actually loads, which requests are sent and whether preferences remain consistent. Include mobile layouts: a choice that is readable on desktop may become confusing when buttons wrap or supporting text is hidden.
Our ecommerce services focus on the whole buying journey. The same end-to-end approach is needed here. A clear product page does not compensate for a checkout or support process that contradicts the decisions made earlier.
Keep a short decision record
Record the requirement, the person who approved it and the release that implemented it. When a later redesign changes the screen, the team can revisit the reason rather than guessing why a field or preference exists. This also makes specialist review more productive: the adviser can inspect a concrete decision and its current implementation instead of rebuilding the history from scattered messages.
Keep ownership after the launch date
Assign responsibility for approving new plugins, updating the service inventory and reviewing changes to collection. Marketing experiments and theme upgrades are ordinary events, so the privacy workflow needs to accommodate them without relying on memory.
Use the conversion-path planning guide to connect each interface decision with the step that follows it. Privacy choices should be part of that design conversation rather than a final layer added after the customer journey is fixed.
Before commissioning the next feature, gather the current data map and unresolved questions. A launch planning discussion can then connect the product work with the specialist review it needs. The result should be a store whose behavior matches the decisions its owners can explain.