Third-party hosts: who your container lets into the page

A container's third-party hosts are the list of organisations you have delegated execution to. Each one can change what it serves without telling you.

What the list means

The hosts we report are the destinations a container's tags can reach: script sources, pixel endpoints, and collection URLs found in tag configuration. A host appearing here means the container is able to send data there or load code from there — whether it did on a given page load depends on the trigger firing.

That distinction matters and we keep it visible. A tag with no trigger never runs, and a tag gated behind consent runs only for visitors who agreed.

Why each host is a standing decision

Loading a third-party script is not a one-time choice. It is a standing grant of execution to whatever that vendor serves, on every page load, from now on. The code you reviewed in March is not necessarily the code being served today, and nothing notifies you when it changes.

This is the mechanism behind most client-side supply-chain incidents: not a breach of your systems, but a change in someone else's.

Hostnames we cannot resolve

Some tags build their endpoint at runtime from a variable, so the container contains a template rather than a literal hostname. We show those as partial values rather than guessing, because an invented hostname in an audit is worse than an acknowledged gap.

Useful questions

Which of these do you have a contract with, and which arrived with a campaign that ended two years ago?

Which are loaded on every page, and which only on checkout or a thank-you page? The second group usually sees the most sensitive data.

For each one: if this vendor shipped hostile code tomorrow, what would it have access to?