adiconsum.it

Context

Adiconsum is an Italian association for the protection of consumer rights and the environment, headquartered in Rome. The site is built on WordPress with the Elementor builder. The capture shows 125 requests to three domains: the site itself and two external services. And the irony is immediately striking: an organisation whose direct mission is to protect consumer rights, including digital ones, itself handles its visitors’ data not the way it promises on paper.

Was there a consent banner

There is a consent mechanism on the site — a WordPress plugin whose scripts load at +519 ms. But it works only on paper. It does not block the subsequent calls to external services: the calls to Google and LiveChat go out after this plugin has already loaded, and there is no trace in the capture of the user having chosen anything. In other words, the consent banner is formally present in the code but does not actually perform its one and only task — it does not hold back the third-party trackers until the user makes a choice.

What actually happened with the trackers

Precision is needed here, because at first glance one could draw the wrong conclusion in either direction. The facts of the capture are these: at +649 ms the browser reached Google Tag Manager, at +752 ms LiveChat. Both calls came earlier than the visitor could react to the banner in any way. But both responses came back with a 403 error, and the body of the scripts did not arrive. That means that in this particular session the trackers themselves did not run: not a single tag fired, not a single tracking cookie was set. To pretend that tracking was in full swing here would be an overstatement — in this capture it precisely did not fire.

But the container is live — and that changes the conclusion

To understand whether this is chance or the site really does not track, I checked the Google container directly, during the audit itself. The container GTM-WJD9NQ5 turned out to be live: it serves working code. This is an important turn. It means that the 403 error in the capture is a trait of that particular session (something blocked the load on the capture side), and not a sign that the tracker is dead or disabled. For an ordinary visitor, whose load is not blocked by anything, this same container would have loaded and run — with all the tags built into it. That is, the site is configured to track for real; this capture simply caught a session where the load failed. What exactly is embedded inside the container is not visible from here: to find out, the container’s code needs to be executed, and a static capture does not reveal it. So I do not claim which specific tags (analytics, advertising) it launches — only that it is alive and intended to work.

The transfer abroad that the policy denies

The policy, updated in September 2021, explicitly promises: data is not transferred abroad. Reality diverges from this already at the level of the request itself. Even with the 403 error, the request managed to reach Google’s servers in the USA and LiveChat, and with it went the visitor’s IP address — and under that same GDPR the IP counts as personal data. Add to this that neither Google nor LiveChat is named in the policy at all: the document limits itself to the vague wording about «third parties and recipients» without a single specific name.

The policy — outdated and generic

Unlike the tidy government sites, here there is no cookie table, no names, no lifetimes, no purposes — only a general explanation of what a cookie is in principle. The document is dated 2021, whereas the current set of plugins on the site is noticeably newer. That in itself indicates that the policy has long gone unmaintained and unchecked against what is actually installed on the site.

What cannot be claimed from the capture

A few honest caveats. First, I do not know the cause of the 403 error in the capture — it could have been a network block, a regional restriction, or a trait of the capture environment; the cause cannot be determined from the capture itself. Second, I do not see which tags are embedded inside the Google container — for that it needs to be executed. Third, the capture covers only the home page, and this lightweight export does not preserve the servers’ IP addresses, so I take the geography of the calls from the domains’ ownership rather than from the addresses.

Conclusion

The tracking stack here is minimal — only two external services, and in this capture both did not run at all because of an error. It would be tempting to be reassured by that, but it would be half the truth. The site is built so that it reaches out to Google and LiveChat in the very first second, before consent; the consent plugin does not block these calls; the Google container is live at the time of the audit and configured to work; none of the services is named in the policy; and the policy itself promises the very thing that is broken by the mere fact of the request — that data does not leave for abroad. For an organisation that protects consumer rights, the gap between what is written and what is built is the most telling part of the analysis.