01 Background
The client
The Ranis of Panjab is a women’s clothing brand based in Punjab, selling directly to customers through its own online store rather than through a marketplace.
Selling direct means holding the relationship, and holding the data that comes with it: names, phone numbers, delivery addresses, order history, and everything the tracking tools on the site quietly collect alongside it.
- Sector
- Ecommerce, apparel
- Platform
- WordPress and WooCommerce
- Market
- India, direct to consumer
- Engagement
- 30 days
02 Diagnosis
The problem
Their lawyers raised it first. India’s Digital Personal Data Protection Act applies to any business handling the personal data of people in India, and the brand’s store had been built the way almost every WooCommerce store is built: get it selling, add the tools that help it sell, deal with the rest later.
That is a ceiling rather than a standard fine, but for a growing direct-to-consumer brand even a fraction of it is existential. Three things were true of the store, and they are true of most stores running this stack:
-
Data was leaving the site before anyone agreed to anything
The Meta Pixel and Google Analytics loaded on every page view, the moment a visitor arrived. Both collect and transmit personal data by design. Under the Act, consent has to come first, and be a positive action rather than an assumption.
-
Nobody knew where the data actually went
Four outside services touched customer data: Razorpay for payments, the Meta Pixel and Google Analytics for tracking, and WhatsApp for order updates and marketing. Each was added at a different time for a good reason. No single record existed of what each one received, or on what basis.
-
A customer had no way to exercise their rights
The Act gives people the right to see what a business holds on them, correct it, and have it erased. There was no route to do any of that, and no named person responsible for answering when someone asked.
Publishing a privacy policy is the cheap version of this, and it is what most stores do. A policy describes what you do with data. It does not stop a pixel firing before consent, it does not tell you where the data went, and it does not give a customer a way to be forgotten. So we treated it as a data-flow problem, not a document problem.
03 Execution
Our solution
We started from where the data actually goes, then made the store behave that way, then wrote the documents to match.
-
Mapped every flow before changing anything
We traced each place personal data enters the store and every service it reaches afterwards, recording what each one receives and why. This comes first because every later decision depends on it. You cannot write an honest privacy notice, or set a retention rule, for data you have not located.
-
Stopped the trackers firing before consent
The Meta Pixel and Google Analytics now load only after a visitor has actively agreed. Consent is recorded, refusal is respected, and neither is the default. This is the single change that moves a store from stated intent to actual compliance, because it is the one an auditor can verify by opening the site.
-
Separated what needs consent from what does not
Processing an order and taking payment through Razorpay are necessary to deliver what the customer asked for. Marketing them on WhatsApp is not. We split the two, so consent is asked for where it is genuinely needed and the checkout is not cluttered with permissions that do not apply.
-
Built the rights process, then tested it
A customer can now request access to their data, a correction, or deletion, with a defined route for handling it inside the timelines the Act expects, and a named grievance contact. A right that exists only on paper fails the moment someone uses it.
-
Set retention rules
WooCommerce keeps order data indefinitely unless told otherwise. We set how long each category is kept and what happens at the end of it, so the store stops accumulating personal data it no longer has a reason to hold.
-
Rewrote the notice to match reality
Only at this point did the privacy notice get written, naming what is collected, who receives it, and what a customer can do about it. Written last, deliberately, so it describes the store as it now behaves rather than as we would like it to.
04 Duration
Timeline
05 Stack
Tech stack
- WordPress
- WooCommerce
- Razorpay
- Meta Pixel
- Google Analytics 4
- Consent management
06 Outcome
The outcome
| Criteria |
// After
BPDoxS
|
// Before As we found it |
|---|---|---|
| Trackers before consent | None, consent required first |
Meta Pixel and GA4 on every page view |
| Record of where data goes | Every flow mapped and documented |
None, four services with no inventory |
| Marketing consent | Asked for, recorded and revocable |
Assumed from having placed an order |
| Access, correction, erasure | Defined process, tested end to end |
No route for a customer to ask |
| Grievance contact | Named and published on the site |
Nobody responsible for answering |
| Data retention | Defined per category and enforced |
Indefinite, the WooCommerce default |
| Privacy notice | Matches how the store actually behaves |
Generic template, unrelated to the real flows |
A store that behaves the way its privacy notice says it does, 30 days after the first legal review.