What data do the third-party services on your website send, and where?

A modern website is assembled from dozens of parts. Analytics comes from one service, the live chat box from another, fonts from a third. The visitor sees one site; their browser may be talking to dozens of different servers in the background.

Each of these services is a data flow: from the visitor's browser to that provider's servers, not yours. And most of these flows are invisible to the site owner; the page works normally and nobody notices anything.

To make that picture visible you first need to know what these services are, what they typically collect, and where the data goes.

What exactly is a third-party service?

Every component loaded from another company's infrastructure rather than your own domain is a third-party service: analytics tools, advertising and conversion pixels, live chat widgets, embedded videos, maps, font and content delivery networks.

They share one trait: when the component loads, the visitor's browser sends a request to that company's server. That request carries at least the visitor's IP address and browser details to the provider; if the service also sets cookies, the flow does not end there and the visitor becomes trackable.

The chain behind a single script

You add one tag manager or one ad script; that script calls further providers in its own chain, and those call others. While you think you allowed one service, five or ten domains can be active on the page at once.

This is why "my site only has analytics" is usually a guess. Nobody builds the chain deliberately; it grows on its own.

The accumulation comes from everyday workflow: marketing adds a conversion pixel for a campaign, a developer forgets to remove a tool they tried. None of it lands in a central list; months later nobody remembers who added what. That is usually where the surprise services in an inventory come from.

Common service categories and typical data collection

It varies by provider, but the typical behaviour per category looks like this:

• Analytics tools: pages visited, session duration, device and browser details, approximate location.
• Advertising and conversion pixels: which pages were browsed and which actions completed; often with the goal of matching the visitor to their profile on the platform.
• Session recording and heatmap tools: mouse movement, scrolling, clicks; in some tools something close to a replay of the session.
• Live chat widgets: the conversation content and part of the visitor's page history.
• Embedded content and CDNs: video, map and font loads; the request details travel to the provider as the content arrives.

What each service precisely collects is written in its own documentation and data processing terms. The provider writes those documents, though; you answer for the data flows on your site, to your visitors and to the regulator.

Where the data goes: the international transfer angle

A large share of popular third-party services run their servers outside your visitors' own country. In practice, adding one script to your site can amount to transferring personal data abroad.

Regulation treats this dimension separately. The GDPR dedicates a chapter to international transfers, with mechanisms such as adequacy decisions and standard contractual clauses; the ICO publishes guidance on when they apply. The details are a matter for legal advice; the practical consequence for a site owner is plain: without knowing which services run where, that assessment cannot even begin.

The first steps require no technical skill: find each service's data processing terms and, where offered, its data processing agreement; check which region its servers run in; note whether it offers EU hosting. Those three facts are also the raw material for the conversation with your legal advisor; they cannot scan your site, you bring them this picture.

Who is responsible?

"I didn't write the script, the provider collects the data" does not hold. As a rule, the controller who put the service on their site answers for the processing that happens there: informing visitors, collecting valid consent where required, and not making that consent a condition for using the site.

Regulators' cookie guidance draws the same frame: consent requests should explain the purpose, the lifetime and whether the cookie is first or third party, and consent should not be buried inside documents like terms of use.

Owning the responsibility also means some internal order: it should be clear who is allowed to add services to the site, every tag an agency installs should be recorded, and tools that were tried and abandoned should be removed. A service added by your agency or developer does not shift the responsibility to them; everything running on the site is still answered for by you.

How to see what runs on your site

You can look manually: open the network tab in the browser's developer tools, browse the site, and note every request that does not go to your own domain. Two difficulties: the request list is crowded and mapping domains to companies takes expertise; and some services load only on specific pages or after specific interactions, so checking the home page is not enough.

To automate this, run a free cookie scan of your site: it lists the cookies in use and the third-party services called in the background, matched against known providers.

Aligning the declaration with reality

Once the inventory exists, two documents must line up with it: the provider list in your cookie and privacy policies, and the categories in your cookie banner. A service running on the site but missing from the policy means your declaration is incomplete; a category collecting data that the banner never asks about means your consent setup is hollow.

DILAYS ties that alignment into one flow: the scan builds the inventory, policy generation feeds on that inventory, and the declaration and the live site agree.

Five frequent mistakes

• Checking only the home page: many services load on subpages or after form interactions.
• Counting the tag manager as one service: the real chain comes in behind it.
• Never reading the provider's documentation: it is the clearest record of what gets collected.
• Ignoring the transfer angle: without knowing where services run, the assessment cannot be made.
• Building the inventory once and stopping: a single newly added pixel changes the picture.

The fifth happens by itself: a clean picture today goes stale with one tool added tomorrow. The durable answer is to set up regular scanning with change monitoring: when an undeclared new service appears, you hear about it.

Checklist

• The whole site was scanned and a third-party service inventory exists.
• For every service, what it does and who added it is known.
• Unused services nobody owns were removed.
• Each service's data processing terms and operating region were reviewed.
• The provider list in the policy matches the inventory exactly.
• Services subject to consent are asked about in the right banner category.
• A monitoring routine catches newly added services.