Try it on your own data
Every report in this article is in the free plan. One snippet for web and apps, up to 10 sites.
Start freePrivacy by design is easy to agree with and hard to apply. This guide translates the seven principles into what product and analytics teams actually do, summarizes GDPR Article 25, and walks through a tracking-plan review where six personal-data properties became one pseudonymous id while every report kept working.
What you will learn
- Decide what data you need at design time, not after launch
- Defaults must protect users without any action from them
- Pseudonymize identifiers and truncate IPs at collection
- Most analytics reports need no names or emails
- Set and enforce retention; include logs and exports
What is privacy by design?
Privacy by design is the practice of building privacy into products, systems and processes from the start, rather than adding it after launch or after a complaint. The idea was set out by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, in the 1990s, and is now law in the EU and UK: Article 25 of the GDPR requires data protection by design and by default.
In practice, privacy by design means asking at every design decision: do we need this data at all? If so, how little, for how long, who can see it, and how do we protect it?
The seven foundational principles
| # | Principle | What it means in a product team |
|---|---|---|
| 1 | Proactive, not reactive; preventative, not remedial | Review privacy in design docs, before code is written |
| 2 | Privacy as the default setting | Users are protected without changing settings; opt-in for anything extra |
| 3 | Privacy embedded into design | Built into architecture (hashing, minimization), not bolted on as a policy page |
| 4 | Full functionality: positive-sum, not zero-sum | Find designs that deliver the feature and privacy, such as aggregate analytics instead of individual tracking |
| 5 | End-to-end security | Protect data across its whole life: collection, storage, use, deletion |
| 6 | Visibility and transparency | Document what you collect and why; make it verifiable |
| 7 | Respect for user privacy | Keep the user's interests central: clear choices, easy access and deletion |
| Principle | In practice |
|---|---|
| Proactive | Review in design docs |
| Privacy by default | Protected without settings |
| Embedded | Hashing, minimization in code |
| Positive-sum | Aggregate instead of individual |
| End-to-end security | Protect until deletion |
| Transparency | Document and verify |
| User-centric | Easy access and deletion |
GDPR Article 25 turns these into legal duties in the EU and UK.
What GDPR Article 25 requires
- By design: implement appropriate technical and organizational measures, such as pseudonymization and data minimization, both when deciding how to process data and during processing, taking into account the state of the art, cost, and the risks to individuals.
- By default: by default, process only the personal data necessary for each specific purpose: the amount collected, the extent of processing, the storage period and accessibility.
For high-risk processing, a data protection impact assessment (DPIA) under Article 35 is the formal version of privacy by design. Related techniques: pseudonymization, hashing and cookieless measurement.
Worked example: applying privacy by design to an analytics tracking plan
A SaaS company reviewed its product analytics tracking plan before a relaunch. It had 42 event properties across 18 events (sample data).
Step 1: inventory. Six properties contained personal data or could: email, full_name, phone, full page URLs (some carried ?email= from email links), ip_address, and a free-text feedback field.
Step 2: ask "do we need it?" for each.
| Property | Purpose claimed | Decision |
|---|---|---|
email | Join with CRM | Replace with internal user id; hash if a join key is unavoidable |
full_name | None found | Remove |
phone | None found | Remove |
| Page URL | Page reports | Keep path; strip query parameters except UTM and an allowlist |
ip_address | Country reports | Truncate at collection; derive country, discard the rest |
feedback text | Product research | Move to the survey tool with its own consent and retention |
Step 3: set defaults. Analytics runs in cookieless mode until a user consents to more; identified tracking only after login and only for product features; raw events kept 13 months instead of indefinitely.
Result: personal-data properties fell from 6 to 1 (a pseudonymous user id). Every report the teams used still worked: page, funnel and retention analysis do not need names or emails. The DPIA for the analytics system went from "high risk, mitigation needed" to "low residual risk", and a later data subject request took minutes instead of a day.
This is principle 4 in action: full functionality, with far less data.
Personal-data properties
6 → 1
▼
Reports still working
All
Raw event retention
13 months
Tracking plan review · personal data
42 properties, 18 events| Property | Decision |
|---|---|
| Replace with user id | |
| full_name | Remove |
| phone | Remove |
| page URL | Strip query except allowlist |
| ip_address | Truncate at collection |
| feedback text | Move to survey tool |
Sample data.
A privacy by design checklist for product and analytics
- [ ] Every new data field has a stated purpose and owner
- [ ] Personal data is not sent to analytics, logs or third parties unless required; see keep personal data out
- [ ] Identifiers are pseudonymized; IP addresses truncated
- [ ] Defaults are privacy-protective; extra tracking is opt-in
- [ ] Retention periods are defined and enforced automatically
- [ ] Access is limited by role; access to personal data is logged
- [ ] Data subject requests (access, deletion, export) can be fulfilled quickly
- [ ] A DPIA is done for high-risk processing
- [ ] Vendors are assessed and bound by data processing agreements
Common mistakes
- Treating the privacy policy as the design. Text does not minimize data; architecture does.
- Collecting now, deciding later. "We might need it" is not a purpose under GDPR.
- Privacy as a launch gate only. Reviews must happen at design time, when changes are cheap.
- Over-relying on consent. Consent does not fix collecting more than necessary.
- Forgetting logs and backups. Personal data in debug logs, error trackers and exports is still personal data.
How TapCub is built for privacy by design
TapCub's defaults follow the same principles: cookieless counting with a salted visitor hash, IP truncation and retention limits, and collection tiers so identified tracking only happens when you turn it on, with consent where required. Login emails sent for identification are lowercased and hashed before storage. You can set privacy rules by region, honor Do Not Track and handle data subject requests from the compliance center. See also GDPR-compliant analytics.
See also: Data residency.
See also: What is data minimization? Meaning, GDPR rules and examples.
Sources
- European Union. GDPR Article 25: data protection by design and by default.
- Cavoukian, A. (2011). Privacy by Design: The 7 Foundational Principles. Information and Privacy Commissioner of Ontario.
- European Data Protection Board (2020). Guidelines 4/2019 on Article 25 data protection by design and by default.
Was this article helpful?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Solutions Engineer
Covers SDKs, API integrations, and data implementation, with an emphasis on validation, system interoperability, and troubleshooting.
