DM4: Privacy, consent and the law for marketers
Personal data in marketing
🎯You'll be able to
Spot personal data in forms, URLs, events and ad audiences, and apply data minimisation to a marketing plan.
🏠The everyday picture
A shopkeeper who remembers that you like strong tea is being helpful. One who writes down your phone number, address and every purchase, and sells the notebook to a stranger, is doing something else, even if each fact seems small.
📘What it really is
- Personal data is data about an identifiable person. In marketing that includes:
- names, email addresses, phone numbers, postal addresses;
- device and cookie IDs, advertising IDs and IP addresses, which can identify someone when combined with other data;
-
order histories, locations and browsing behaviour linked to an ID.
-
It leaks in quiet places: a form that uses
GETputs the email in the address bar, which then goes into analytics, server logs and the referrer sent to other sites; a "user_email" parameter in a purchase event; an uploaded customer list for ad matching. -
Data minimisation: collect only what the purpose needs. A newsletter needs an email address, not a date of birth. Analytics needs counts and steps, not names.
-
Purpose limitation: data collected for delivery shouldn't quietly become an ad audience.
- Retention: keep data only as long as the purpose needs it, then delete it.
- Sensitive situations: health, finance, children and religion call for extra care, even where the law doesn't single them out.
📝A worked example
Input: MittiMart's starter newsletter form is <form action="index.html" method="get"> with a field named email.
Steps:
- Submit it with
asha.rao@example.comand look at the address bar:index.html?email=asha.rao%40example.com. - Look at the terminal running
npm run serve: the page view sent to/collectincludes that address aspage_location. - Note the fix: handle the form on the page (no
GET), and send only the event name and the form's name.
Expected output: one leak found in the address and one in the generate_lead event (which also sends the email). Project 1's test 6 fails
on the starter for exactly these leaks.
🌍Where it's used
- Analytics teams check events and page addresses for email addresses and phone numbers.
- CRM teams decide which fields each form really needs.
- Ad operations check what customer data, if any, is shared with ad platforms, and on what basis.
📝Case scenario
A bank's password reset page put the customer's mobile number in its address. The number ended up in the bank's analytics and in a
third-party chat tool's logs. Nobody had meant to collect it. The fix was a POST form and a filter that strips query values from every
address sent to analytics.
🖱️Try it
Fill in a newsletter or contact form on any site with a made-up address you control, and watch the address bar and the browser's Network tab. Success: you can say whether the address appears in any request other than the form submission.
⚠️Common mistakes
- Thinking an ID isn't personal data. Sign: "It's just a cookie number." Fix: treat IDs linked to behaviour as personal data.
- Collecting "just in case". Sign: date of birth on a newsletter form. Fix: one field per real purpose.
- Personal data in addresses. Sign:
?email=or?phone=in a URL. Fix:POSTforms, and strip query values before analytics.
🛠️For your project
Project 1's test 6 fills in the newsletter and checkout with invented details and fails if any of them reaches /collect.
✅Quick check
Can a cookie ID be personal data?
Show the answer
Yes, when it can be linked to a person, for example through their behaviour or account.
What does data minimisation mean for a newsletter form?
Show the answer
Ask only for what the newsletter needs: usually just an email address.