π Day 97 β Privacy-First Website Analytics
π Topic
Understanding website analytics from a privacy-first and security-aware perspective.
π― Goal
Learn how a website can collect useful visitor statistics without unnecessarily tracking individual users.
π What I Did
Today I looked at website analytics for a small public business website.
The main question was:
Can we see who visits the website, when they visit, and how many people access it?
The better version of that question is:
Can we collect useful aggregate analytics without turning the website into a tracking system?
I compared the idea of using:
- Vercel Web Analytics
- Plausible
- Matomo
- Google Analytics 4
The important difference is between:
- basic aggregate analytics
- cookie-based tracking
- marketing pixels
- user profiling
- session recording
- advertising attribution
For a small farm or local business website, the goal is not to identify individual people.
The goal is to understand general visitor behavior.
Useful analytics questions include:
- How many people visited the site?
- Which pages were viewed most?
- Did people visit from mobile or desktop?
- Did traffic come from Google, direct visits, or social links?
- Which product or service pages attracted attention?
- Did people visit the contact page?
- Did SEO changes improve traffic?
That is enough for a small website.
Trying to identify exact individuals would create unnecessary privacy and compliance risk.
π Key Cybersecurity Connections
Analytics is not just a marketing feature.
It is a telemetry system.
A normal website analytics setup may process information such as:
- page path
- visit time
- referrer
- device type
- browser
- approximate country or region
- operating system
- traffic source
- session-like activity
- sometimes IP-derived information
From a cybersecurity point of view, this matters because every telemetry system creates questions:
- What data is collected?
- Where is it stored?
- Who controls it?
- Is a third party involved?
- Is the data anonymized?
- Are cookies used?
- Is profiling happening?
- Is the privacy policy accurate?
- Does the analytics script create a supply-chain dependency?
The useful mental model is:
Website visit
β
Browser request
β
Hosting platform
β
Analytics script or server-side event
β
Aggregated dashboard
β
Business decision or security review
Analytics can be helpful.
But unnecessary tracking becomes risk.
π Investigation Questions
If I were reviewing analytics on a website, I would ask:
- What analytics tool is installed?
- Is the analytics script first-party or third-party?
- Does it set cookies?
- Does it track users across websites?
- Does it create persistent identifiers?
- Does it collect IP addresses?
- Are IP addresses anonymized or shortened?
- Does analytics run before consent?
- Is Google Analytics present?
- Is Meta Pixel present?
- Are advertising or remarketing tags present?
- Is the privacy policy updated?
- Is the cookie policy accurate?
- Is the website owner collecting more data than they actually need?
Useful technical checks:
- browser DevTools Network tab
- browser DevTools Application tab
- cookies and local storage
- page source
- script tags
- hosting dashboard
- analytics provider dashboard
- privacy policy text
π¨ Detection Opportunities
Analytics can also help reveal suspicious website behavior.
Useful patterns include:
- sudden traffic spikes
- repeated visits to non-existent pages
- many requests to admin paths
- traffic from unexpected countries
- bot-like user agents
- repeated 404 errors
- scraping behavior
- repeated contact form submissions
- suspicious referrers
- abnormal traffic after publishing a new page
Example suspicious web activity:
time=2026-05-08 14:21:04
source_ip=198.51.100.44
method=GET
path=/wp-admin
status=404
user_agent=python-requests/2.31
For a website that is not WordPress, repeated requests to /wp-admin may suggest automated scanning.
Another example:
time=2026-05-08 15:02:11
path=/.env
status=404
user_agent=curl/8.0
A request to /.env may indicate a bot looking for exposed environment files.
The defender should not panic from one request.
But repeated patterns matter.
π§ MITRE ATT&CK Techniques
Relevant ATT&CK ideas may include:
- T1595 β Active Scanning
- T1592 β Gather Victim Host Information
- T1190 β Exploit Public-Facing Application
- T1105 β Ingress Tool Transfer
Analytics itself is not an attack.
But analytics and web logs can help identify reconnaissance, scanning, exploitation attempts, and suspicious automation.
πΊ Visual Investigation Diagram
Visitor or Bot
β
Website Request
β
Hosting Logs
β
Analytics Tool
β
Aggregate Dashboard
β
Security Review
β
Privacy Policy Update
β Challenges
The main challenge is that the word βanalyticsβ is too broad.
It can mean:
- simple page view counts
- privacy-friendly aggregate metrics
- cookie-based visitor tracking
- advertising attribution
- remarketing
- cross-site profiling
- heatmaps
- session replay
These are not the same thing.
For a small business website, heavy tracking is usually unnecessary.
The practical mistake would be adding Google Analytics, Meta Pixel, and several marketing scripts before knowing whether they are actually needed.
That creates more legal, technical, and security complexity.
π What I Learned
I learned that privacy-first analytics is usually the better starting point for a simple website.
The best approach is:
- collect only useful aggregate data
- avoid individual visitor identification
- avoid marketing pixels unless needed
- avoid unnecessary cookies
- avoid bloated third-party scripts
- keep the privacy policy accurate
- review what the website actually loads
Analytics should answer business questions without creating unnecessary tracking risk.
A good small-site analytics setup should help answer:
Is the site being visited?
Which pages matter?
Are people finding us from search?
Is mobile traffic important?
Are visitors reaching the contact page?
That is enough for a first stage.
β‘ Next Steps
- Inspect the website with browser DevTools
- Check which scripts are loaded
- Check whether cookies are created
- Decide whether analytics should be Vercel, Plausible, Matomo, or something else
- Avoid Google Analytics unless there is a real marketing reason
- Update the privacy policy to describe analytics honestly
- Monitor traffic for basic scanning and abuse patterns
π§ Reflection
Today helped me connect web analytics with security thinking.
Before, analytics sounded like a simple website feature.
Now I see it as a telemetry and data-processing decision.
That means it needs the same questions I would ask in cybersecurity:
- What data is collected?
- What system receives it?
- What risk does it create?
- What value does it provide?
- Is it necessary?
The best security decision is often not adding more tools.
Sometimes it is choosing the smallest tool that solves the actual problem.
π§© Lessons Learned
What worked
Thinking of analytics as telemetry instead of just marketing.
What broke
At first, βseeing who visits the websiteβ sounded like a normal request.
Why it broke
The phrase can imply individual tracking, which is usually unnecessary and risky for a simple public site.
Fix / takeaway
Use aggregate analytics first.
Measure useful website behavior without trying to identify individual people.
π Skill Progression Context
This supports my cybersecurity progression because real-world security is not only about attacks.
It is also about responsible monitoring, data minimization, third-party risk, and accurate documentation.
For SOC and detection work, this reinforces important habits:
- understand telemetry sources
- inspect what data is collected
- separate useful evidence from unnecessary collection
- identify suspicious web activity
- think about logs, scripts, and privacy together
This is practical web security thinking.
π TL;DR
Analytics is useful.
Tracking everyone like a spy agency is not.
