Privacy

What a Tracking Script Actually Sends — A Network Walkthrough

Open your browser's network panel and you can see exactly what an analytics or session replay script transmits. This walkthrough explains each request, what the payloads contain, and how to audit any tracking script yourself.

Purushottam Kumar Suman
Purushottam Kumar SumanSeptember 29, 20269 min read
Founder & CEO, DeepSync
Browser network panel showing tracking script requests

Short answer: a behavior analytics script makes a small number of request types: one to load itself, one to start a session, and then periodic batches of events. You can read all of them in your browser's network panel. Doing so is the most reliable way to check what a vendor collects, whether masking works, and whether anything is sent before consent.

Table of Contents

  1. Why Look
  2. How to Watch the Requests
  3. Request 1: The Loader
  4. Request 2: The SDK Bundle
  5. Request 3: Session Start
  6. Request 4: Event Batches
  7. Request 5: The Final Beacon
  8. An Audit Checklist
  9. Key Takeaways

Why Look

Documentation tells you what a script is designed to do. The network panel shows what it does on your site, with your configuration. That is what a privacy review, a security questionnaire, and your own peace of mind actually need.

It also settles practical questions: is the script loading at all, is consent wired correctly, and why are there no sessions?

How to Watch the Requests

  1. Open your site in a normal browser window.
  2. Open developer tools and select the Network panel.
  3. Tick Preserve log so requests survive navigation.
  4. Reload the page.
  5. Filter by the vendor's domain.
  6. Click a request and read its Headers and Payload tabs.

Use a normal window. Privacy modes and extensions may block the script and show you nothing.

Request 1: The Loader

The first request fetches a small script. For DeepSync, every web install is the same one-line tag, and the loader lives at a path containing your public project ID (SDK docs).

The loader's job is configuration. It resolves your organisation, the ingestion address, and the SDK settings on the server, then requests the real SDK. Because of that design, the only thing in your page is a project ID, and SDK upgrades reach your site without you changing the tag.

What to check: the tag has the async attribute, so it does not block rendering. The project ID is public by nature. It identifies where data goes and grants no access to it.

Request 2: The SDK Bundle

The loader pulls a versioned bundle containing the recorder. Versioned files can be cached for a long time, since a given version never changes. A new release ships under a new version, and the short-lived loader points to it.

What to check: it is served compressed and from cache on repeat visits.

Request 3: Session Start

Before sending events, the SDK registers a session. This request carries context about the visit.

Typically included:

  • Project ID
  • An anonymous visitor ID, kept across visits
  • Page URL and referrer
  • Campaign parameters and ad click IDs from the URL
  • Screen and viewport size
  • Browser, operating system, and device type
  • Language and timezone

The server adds what only it can see: the IP address the request came from, used for approximate location.

One thing worth knowing if you are auditing third-party calls: the DeepSync SDK resolves visitor geolocation with a client-side fallback lookup if your server does not supply it. The docs mention this specifically for people reviewing outbound requests from their site.

What to check: look at the page URL in the payload. If your URLs contain personal data, it is in this request, whatever your masking settings (PII in URLs).

The consent test: in consent-required mode, which is DeepSync's default, nothing is collected until a consent signal arrives. Load the page without accepting your banner and confirm that no session start and no event requests are made (consent modes).

Request 4: Event Batches

This is the bulk of the traffic. Events are queued and sent in batches. In DeepSync a batch is flushed every 500 milliseconds or once 10 events are queued, whichever comes first. A full DOM snapshot forces an immediate flush. Flushing pauses while the tab is idle.

A batch contains recording events of a few kinds:

EventContents
Full snapshotThe serialised document: elements, attributes, text, styles
MutationNodes added or removed, attribute and text changes, by node ID
MouseCoordinates and target node
ScrollPosition and target
InputThe changed field, with its value masked
CustomEvents your code sent with a track call

The first batch on a page is the largest because it holds the snapshot. Later batches are small.

What to check, and this is the important one: type a recognisable test value into a form field, such as TESTVALUE123, then search the request payloads for that string. With masking working, it will not be there. In DeepSync, text inputs, passwords, and payment fields are masked in the browser at capture time, so the real characters never leave the device (PII masking).

Then do the same for text your page displays: a name on an account page, a balance, an address. If you can find it in the snapshot, it is being recorded, and that element needs a masking class.

A successful request returns status 200. The DeepSync docs suggest exactly this as an installation check: interact with the page for a few seconds and look for POST requests to the ingest endpoint returning 200 (verifying your installation).

Request 5: The Final Beacon

When a visitor closes the tab or navigates away, an ordinary request might be cancelled. So the last batch is sent with navigator.sendBeacon, a browser feature that queues a small request to be delivered even as the page unloads, without delaying navigation.

In the network panel it appears as a request of type "ping" or "beacon" at the moment you leave.

An Audit Checklist

  • [ ] The tag loads asynchronously
  • [ ] No session or event requests before consent, when consent is required
  • [ ] Recording stops when consent is withdrawn
  • [ ] A typed test value does not appear in any payload
  • [ ] Displayed personal data does not appear, or is masked
  • [ ] Page URLs in payloads contain no personal data
  • [ ] Custom event names and properties contain no personal data
  • [ ] Attributes passed when identifying users are limited to what is needed
  • [ ] Requests go only to domains you expect
  • [ ] Batches are reasonably sized and not sent on every keystroke
  • [ ] The script is absent on pages you intended to exclude
  • [ ] The script is absent for internal users, if you exclude them

Repeat on a logged-in page and on a checkout or account page, where the sensitive content is.

Search the payload for your own name

Log in with an account in your own name, browse the account pages, and search every request body for it. It is the fastest masking audit there is.

Key Takeaways

  • A tracking script makes a few request types, all visible in the network panel.
  • The session start request carries URL and device context; batches carry recording events.
  • Search payloads for a typed test value and for displayed personal data.
  • Confirm nothing is sent before consent.

Conclusion

You do not have to take a vendor's word for what a script does. The browser shows you every byte. Spend twenty minutes looking, once, on the pages that matter.

Read how the DeepSync SDK works.

Frequently Asked Questions

Was this article helpful?

Ready to understand
users like never before?

Join thousands of teams who use DeepSync to uncover insights,improve experiences, and build better products—faster.

Quick & easy onboarding
See results in real time
Enterprise-grade security