Client-side tracking is the collection of user activity from code running in the browser or app on the user's device. It usually uses scripts, pixels, SDKs or local storage to observe page views, clicks or sessions and can be blocked or limited by browser controls, consent settings and content restrictions.
What client-side tracking is used for
Client-side tracking is usually deployed to measure page performance, understand product usage, attribute campaigns, or personalise experiences. Because the code runs in the browser or app, it can observe what the user’s device loads, clicks, submits, or stores during the session.
This placement makes client-side tracking convenient, but it also means the tracking logic inherits the browser’s limits, the user’s privacy settings, and any content controls or script blocking in the environment. The same mechanism that enables analytics can also create visibility gaps when scripts do not load or when browser protections suppress them.
How client-side tracking works
Most client-side tracking relies on JavaScript tags, pixels, software development kits, or browser storage. These components send events to a collector when the page renders, the user interacts, or the app reaches a defined state.
In practice, the tracking code acts as an observer embedded in the user experience. It may record coarse events such as a page view, or finer-grained signals such as click paths, scroll depth, form abandonment, or session continuity. The more data the client sees, the more dependent the organisation becomes on the integrity and availability of the user-side runtime.
Why client-side tracking is constrained
Client-side tracking does not execute in a neutral environment. Users can block scripts, disable certain cookies, tighten consent settings, or run privacy extensions that prevent measurement. Browsers and mobile platforms also change their rules over time, which can reduce identifier persistence and shorten the useful lifetime of tracking data.
That fragility is not just an analytics problem. When organisations treat client-side telemetry as authoritative, blocked scripts or altered browser behaviour can distort product metrics, weaken fraud or abuse signals, and create false confidence in what was actually observed.
Security and privacy implications of browser-based collection
Because the collection point is the user’s device, client-side tracking often touches privacy, consent, and data minimisation concerns. It can also expand the attack surface if third-party scripts are compromised, over-permissioned, or allowed to load more data than they need.
Where tracking depends on script delivery from external vendors, the trust boundary extends beyond the organisation’s own application. That makes tag integrity, consent enforcement, and data flow review part of the security posture, not just marketing operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and OWASP ASVS set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Security of processing | Client-side tracking processes personal data in the browser and must protect it during collection. |
| A.5.34 — Privacy by design and by default | Tracking scripts, pixels, and storage choices directly shape data minimisation and default privacy settings. | |
| Recommendation — Limit browser-side data collection to what is necessary and verify that processing remains lawful and secure. Design tracking so the least data is collected by default and user privacy settings take effect cleanly. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Client-side storage may retain identifiers or session data on the user device. |
| PR.DS-10 — Confidentiality, integrity, and availability are managed for information | The integrity and availability of tracking data depend on scripts, pixels, and browser controls. | |
| DE.CM-09 — Computing hardware and software platforms are monitored | Browser-based collection depends on monitoring the platform where the tracking code runs. | |
| Recommendation — Protect locally stored tracking data and minimize what the browser retains. Validate the integrity of telemetry collection and account for blocked or altered client-side signals. Monitor client-side telemetry failures and changes in browser behaviour that affect visibility. | ||
| OWASP ASVS | V14 — Data Protection | Client-side tracking often handles personal and session data in web and app contexts. |
| Recommendation — Apply data-protection requirements to browser-side identifiers, events, and storage. | ||
Practitioner Guidance
What to watch for: Treat client-side tracking as a control that needs governance, not a passive convenience feature. The main operational question is whether each event, cookie, pixel, or SDK is still justified under the current privacy model and browser landscape.
Practitioner note: Use the browser as an unreliable measurement surface. Validate critical analytics with server-side signals where possible, and review third-party scripts, consent behaviour, and storage usage whenever tracking accuracy or privacy expectations change.
Related resources from NHI Mgmt Group
- How should healthcare security teams reduce client-side data leakage from third-party scripts and tracking tags?
- When does client-side obfuscation stop being useful for fraud prevention?
- How should security teams decide whether client-side obfuscation is enough?
- What do teams get wrong about protecting client-side security logic?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org