Online tracking: the key concepts first

Online tracking refers to mechanisms that observe and record digital activity, then use identifiers to connect that activity to a person, device, browser, or account. In practice, tracking is usually less about “spying” in one single method and more about a set of cooperating signals—some created by the browser, some by the website, and some by third parties embedded on pages.

For remote professionals and small-business teams, it helps to separate three ideas:

  • What is being tracked: actions (page views, clicks, searches), technical events (page loads, errors), and sometimes interaction patterns.
  • What ties events together: identifiers such as cookies, local storage, browser fingerprinting signals, or account login state.
  • What the data is used for: analytics (measurement), advertising (targeting/attribution), fraud prevention, and personalization.

Because online ecosystems change quickly, treat specific numbers (“how many sites track”) and specific vendor statements (“we do X on all devices”) as uncertain unless you can verify them in your own environment.

How tracking typically operates (and in which conditions)

Most online tracking involves collecting signals and persisting identifiers so that future visits can be linked.

A common operating flow looks like this:

  1. A page loads and includes scripts or tags (from the site itself and often from third parties).
  2. Those scripts interact with the browser to store or read identifiers (for example, cookies or similar client-side storage).
  3. Events are sent to collection endpoints (analytics, advertising, or measurement services).
  4. Later, those same identifiers are presented again, allowing cross-session or cross-page linkage.

In remote-work and international team settings, the observed behavior depends on operating conditions, such as:

  • Consent and settings: cookie consent banners, browser privacy settings, and enterprise policies can reduce or block storage.
  • Logged-in vs. not logged-in: when users are signed into accounts, tracking can rely on server-side identity that persists beyond browser storage.
  • Cross-site embedding: tracking is more likely when third-party services are embedded across multiple websites.
  • Network environment: public vs. corporate networks, DNS filtering, ad blockers, and endpoint security tools can change which requests are made.

Important limitation

A VPN changes network-level visibility (what network traffic appears to come from), but it generally does not stop tracking performed by websites, mobile apps, or account systems through client-side identifiers and server-side records. For practical expectations, avoid assuming that any single tool will remove all forms of tracking.

Differences per situation: remote teams and device hygiene

Tracking practices vary widely across sites, geographies, and technology stacks. For a remote professional or small team, the most useful approach is to think in “situations” rather than looking for one universal solution.

1) Single user, mostly logged out

  • Tracking may be more dependent on browser storage and embedded scripts.
  • Clearing cookies or using different browser profiles can change the observed behavior.

2) Team member using work accounts

  • If users repeatedly log into the same services, identifiers may be tied to accounts.
  • Even with privacy-friendly browser settings, tracking can persist because the service can recognize the account.

3) Shared devices or kiosks

  • Multiple people using the same device can cause identifier confusion.
  • Endpoint policies and user profile management become part of “tracking hygiene.”

4) International collaboration

  • Consent experiences, cookie choices, and policy enforcement can differ by region and service provider.
  • Assume that “what worked in one country” may not behave the same elsewhere.

A practical takeaway: treat online tracking controls as context-dependent. Decide where you want to reduce tracking (analytics measurement, ads, cross-site linking, or account-based profiling) and then measure whether the controls actually affect that specific goal.

Practical verification: how to check what’s really happening

Because claims change and setups differ, verification should be based on controlled tests in the environment you care about.

What to verify

  • Whether identifiers persist across visits (for example, do cookies reappear after closing the browser?).
  • Whether third-party requests continue when you change settings (privacy mode, ad/tracker blockers, cookie settings, browser profiles).
  • Whether behavior changes when logged in vs. logged out for the same service.
  • Whether network-layer tools affect only network visibility rather than site/app identifiers.

Simple verification steps

  1. Use separate browser profiles for testing (one “normal,” one with stricter privacy settings).
  2. Test the same site or service twice—one time logged out, one time logged in.
  3. After actions you can repeat (e.g., search for a product, visit a specific page), check what storage exists and whether requests appear to be made to known tracking/measurement services.
  4. If you change a variable (browser settings, extensions, endpoint policies, VPN on/off), repeat the test and compare results.

Keep expectations realistic: results can be inconsistent due to A/B testing, timing, and caching. When you see a difference, confirm it by repeating the scenario.

How to evaluate product or service claims (without over-trusting them)

If someone claims “reduced tracking” or “privacy improvements,” ask:

  • What exactly changes (client-side storage, cross-site requests, account-based recognition)?
  • Under what conditions (logged in/out, specific browsers, specific regions)?
  • How would you verify it locally?

When there is no clear, verifiable basis, treat the claim as uncertain.

Limitations to keep in mind

  • No single setting guarantees no tracking. Different trackers use different methods (storage, embedded scripts, account identity).
  • Performance and availability vary. Browser behavior depends on device, network, and third-party responsiveness.
  • Empirical claims require verification. If a provider states that a feature blocks or reduces tracking, confirm in your own setup.

For remote teams, the safest operational mindset is: use privacy controls as measured tools for specific goals, not as blanket promises.

Internal next step (for remote professionals)

If you need an actionable starting point for your team, focus on the highest-impact checks: compare logged-in vs. logged-out behavior, test with a separate browser profile, and document what changes when you adjust cookie/privacy settings and network tools. Then base follow-up decisions on what your own tests show.