What online tracking means (and why it happens)
Online tracking is the collection of information about your browsing or app use so services can recognize a device or user, remember preferences, show relevant content, and measure performance. It typically involves multiple parties: the site you visit, embedded third-party services (such as analytics or ads), and the technologies running in your browser or app.
A helpful mental model is: identify → store/associate → observe → act.
- Identify: The system tries to link activity to a recognizable “fingerprint” or identifier.
- Store/associate: It keeps that identifier using mechanisms like cookies or similar storage.
- Observe: It collects events such as page views, clicks, and conversions.
- Act: It uses the data to personalize, optimize, or report metrics.
This is not limited to advertising. Analytics, fraud prevention, login sessions, and site performance monitoring can all involve tracking.
How it works in practice
Online tracking is usually not one single thing. It’s the combined effect of several layers.
1) Identifiers in browsers and apps
Common examples of identifiers include:
- Cookies (small pieces of data stored by a site or third party)
- Local storage / session storage (client-side storage)
- Device or browser signals (a mix of characteristics that can help distinguish devices)
- Account identifiers (when you log in)
- Request-level details (such as what IP address is used for the network connection)
Even when an identifier is “not a cookie,” other signals may still link activity.
2) Third parties inside pages
Many pages load external scripts or resources that run in your browser while you view the page. Those third parties can set or read their own identifiers, measure interactions, and report events back to their services.
That means two users visiting the same site may see different tracking behavior depending on which third-party components load, what those components do, and what storage access is allowed.
3) Network visibility versus tracking purpose
A VPN changes how your network traffic is routed, which can alter which IP address websites observe. However, online tracking may still work through client-side storage and identifiers that remain available inside your browser session.
So, it’s common to see outcomes like:
- Some “network-based” observations change (your visible IP/network path)
- Other tracking continues (persistent identifiers, device signals, logged-in account data)
4) Operating conditions and why results vary
Tracking behavior can differ based on:
- Browser settings (cookie permissions, tracking protection modes)
- Consent choices (where applicable)
- Logged-in state and synchronization
- How frequently storage is cleared
- Device configuration and updates
- The specific sites and embedded services you use
Because of these variables, you may get partial improvements rather than a single consistent “on/off” result.
Practical context: applying the concepts to VPN setup, diagnostics, and troubleshooting
If you’re configuring a VPN connection and trying to understand what it changes about online tracking, focus on what the VPN can affect versus what it usually cannot.
What a VPN can realistically change
- The network origin (IP address and routing path) used for connections.
- Which network-level blocks or region-dependent content you encounter.
What a VPN does not automatically stop
- Tracking that relies on cookies or client-side storage.
- Tracking tied to an account you’re logged into.
- Tracking that uses device-level signals.
This is why troubleshooting works best as a verification exercise, not as a one-time assumption.
If you’re diagnosing issues like “tracking still happens with the VPN enabled,” think in terms of: What identifier is being used now? The answer is often “something other than the IP address.”
A simple test workflow
Use a repeatable workflow so you can compare outcomes:
- Use the same browser profile or a controlled profile.
- Decide what “before” and “after” mean (VPN on/off, location changes, and so on).
- Perform a small set of actions on the same pages (e.g., load a page with embedded content).
- Check which identifiers and requests change.
- Keep notes about the sequence and timing.
Limitations to keep in mind
- A VPN does not guarantee anonymity, safety, or access.
- Performance and availability vary by network, device, location, provider, and time.
- Tracking mechanisms can be designed to work even when network origin changes, so you may need multiple controls (browser settings, consent choices, and storage management).
Also, avoid “winner-takes-all” conclusions from a single test. Many tracking systems optimize over time and may behave differently across sessions.
What to check to verify tracking changes (step-by-step)
These checks are practical because they observe measurable client-side effects.
1) Check cookie and storage behavior
- View which cookies are set while you load the test page.
- Look for third-party cookies or storage associated with embedded services.
- Note whether those values persist across sessions.
If you see the same identifiers returning after enabling the VPN, it suggests the main linkage is not purely IP-based.
2) Inspect network requests and third parties
- Open your browser’s developer tools.
- Filter network requests by “third-party” or by domain (as supported by your tool).
- Compare the request list with VPN on versus off.
You’re looking for patterns such as: same third-party domains executing the same logic; or changed network origin for the requests.
3) Confirm the IP change you expect
- Visit a simple “what is my IP” page with VPN on and off.
- Verify the displayed IP/network attributes change as expected.
This is not a tracking test by itself, but it confirms the VPN routing part of your setup.
4) Keep the test conditions consistent
Results can change due to caching, account login, consent, and timing. If your “after” test uses a different logged-in state or a different profile, your comparison may be misleading.
5) Interpret results carefully
If tracking appears unchanged:
- It may be because the client-side identifiers still exist.
- Or it may be because third-party scripts still run and keep using their own storage.
If tracking decreases:
- That may indicate your current settings reduce identifier persistence or third-party storage access.
In either case, treat the outcome as specific to your tested conditions.
