tjt.ee

Context

tjt.ee is the website of AS Tallinna Jäätmete Taaskasutuskeskus, registration code 10450572, Loovälja tee 125, Rebala village, Jõelähtme parish, Harjumaa. The company handles waste collection, recycling, and removal for private and corporate clients; the site runs a WooCommerce store, an auction module, and contact forms. Data-protection contact: andmekaitse@tjt.ee. Platform: WordPress, served via Apache / ZoneOS; the site sets no proprietary Content-Security-Policy header.

Measurement: 82 requests, sixteen hosts. Forty-five requests go to the proprietary domain, 37 go outward to nine external services. The page fully loaded by 434 ms, with the last recorded request at 8391 ms. Captured on July 31, 2026, on the English-language homepage, reached via navigation from the Russian version of the same site.

Processing is described by two documents, in effect since May 1, 2024: the terms of use, where section 1 covers cookies, and the client personal data processing principles.

Who receives data directly

Google (Tag Manager, Ads, Analytics, DoubleClick, reCAPTCHA, Fonts), Meta, Automattic, CookieYes, Websystems.

Declared versus actual

The documents describe a site running on its own cookies. The terms state that TJT’s site server creates and determines the content of cookies, and that cookies transmit information to TJT’s server only to the extent the user has consented. Two categories are named: session cookies — for security and core functions, and persistent cookies — for analyzing visitor counts and average time on site. Management is offered via browser settings. The processing principles, in section 4.3.1, state that TJT does not process personal data for purposes requiring consent, and in section 7, that personal data is not transferred to third countries. The list of data categories collected consists of identification, contact, and contractual data; network identifiers, IP addresses, and device data are absent from it.

The measurement reveals four discrepancies.

First — advertising processing, absent from the documents as a class. The Google Tag Manager container deploys the Google Ads resource, and at +571 and +668 ms, two conversion-measurement calls fire carrying an advertising identifier, the page title, and its address. At +754 ms, a call to DoubleClick follows; at +755 ms, a remarketing-audience pixel at www.google.ee, both carrying the same client identifier used in the analytics. At +577 ms, the Meta Pixel library loads; in the page markup, the PageView event call is unconditional, and the pixel’s configuration enables server-side transmission via the Conversions API. The site’s documents mention neither advertising, nor remarketing, nor Meta.

Second — the composition of recipients. Besides Google and Meta, data is received by Automattic (Jetpack counters and WooCommerce analytics, a call to pixel.wp.com carrying site ID 239155189, page ID 564, the hostname, timezone, and previous page’s address), CookieYes as the consent-data processor, and Websystems when its developer logo loads in the footer. reCAPTCHA v3 deserves separate mention: its configuration specifies the action homepage, meaning the check runs on the homepage itself, not only on form submission, and transmits visitor behavior data to Google. The page’s font loads directly from fonts.gstatic.com. Not one of these recipients is named in the documents.

Third — the nature of the data transmitted, versus the described anonymous statistics. The terms reduce persistent cookies to counting visitors and average time on site. The GA4 request carries a client identifier, a screen resolution of 1920x1080, the Windows platform, system bitness and architecture, a full list of browser versions, interface language, a first-visit indicator, the page address, its title, and the previous page’s address. A second event carries a 90% scroll depth. Screen resolution and the set of browser client hints are parameters used for device fingerprinting.

Fourth — transfer outside the Union, directly denied. Section 7 of the processing principles states that personal data is not transferred to third countries. Requests carrying identifiers go to Google, Meta, and Automattic — companies registered in the USA. No legal mechanism for such a transfer is named in the documents, since the transfer itself is denied in them.

Worth noting separately is an internal contradiction between the documents and the site itself. The cookie table in the banner lists _ga, ga, _fbp, gcl_au, IDE, test_cookie, and tk — meaning the site itself knows about Meta, about Google’s advertising cookies, and about Automattic. The formal documents, in effect since May 1, 2024, know nothing of this.

Consent: what is proven and what is not

Proven: the banner exists, and the moment it appears is recorded by the consent platform itself. At +1038 ms, a log entry with the event type banner_load is sent to CookieYes’s log. Between +1041 and +1275 ms, configuration, translation, the cookie table, and styling load. The banner is in Estonian, with the buttons “Nõustun kõigiga,” “Keeldu kõigist,” and “Kohanda,” and its settings text states directly that third-party cookies are stored in the browser only with the visitor’s prior consent.

Proven: eight data-carrying requests fired before the banner. The Automattic pixel — at +375 ms, reCAPTCHA — at +483 ms, the container and advertising tags — between +491 and +553 ms, Google Ads conversion measurement — at +571 and +668 ms, the Meta Pixel library — at +577 ms, GA4 analytics, DoubleClick, and the remarketing-audience pixel — at +753, +754, and +755 ms. The gap between the last of these transfers and the banner’s appearance is roughly three-tenths of a second.

Proven: the consent platform is configured to declare consent granted by default. In the page markup, CookieYes’s integration with Google’s consent mode carries explicit values: analytics — granted, advertising — granted, ad user data — granted, ad personalization — granted, functional and necessary — granted, applicable region — All. This is not a consequence of load order, but a stored setting: even under normal integration operation, Google’s tags would be told “permitted” before the visitor makes any choice.

Proven: at the time of the first wave, no consent state had been set at all. Neither the conversion-measurement requests nor the first GA4 request carries a consent-state parameter. The script integrating with consent mode is loaded with deferred execution on the page and had not yet run by the time the tags fired.

Proven: the rejection only registers at the eighth second. The scroll event at +8391 ms carries a consent-state update flag and the value gcs=G100 — both storage categories denied. The client identifier in this request is new, different from the one used in the first wave: the tag regenerated it, since storage is no longer permitted. In other words, the rejection is applied and does work — but it applies to what happens afterward, and has no effect on what was already sent.

Not proven, and not required for the finding: what exactly the visitor clicked. The record shows the outcome — a “denied” state — but not the action that led to it. This is immaterial to the finding: the gap between the transfers and the banner’s appearance, along with the default granted values, is established independently of whether a button was clicked.

Boundaries of this observation

The measurement covers a single page — the homepage. The observation records browser behavior, not the internal workings of the services: server-side processing, contractual relationships with recipients, and settings on the recipients’ own side are not verified by a browser-based measurement. Legal assessment falls to the competent authority — the Andmekaitse Inspektsioon.

The published file has been cleaned of personal data: Cookie headers in requests have been removed. Response bodies and page markup are preserved, so the consent-mode configuration, the Meta Pixel event call, and the reCAPTCHA settings can be verified directly from the published file, rather than inferred from indirect evidence. The composition of cookies on the device cannot be reconstructed from HTTP headers, and no finding rests on them: the fact that identifiers were recorded rests on those identifiers being transmitted to Google within the requests themselves.

The Meta Pixel event was not observed in the capture — only the loading of the library is recorded. Meanwhile, the PageView call is present unconditionally in the markup, and the pixel’s configuration includes transmission via the Conversions API — directly from the site’s server to Meta; such a transfer is not visible in a browser-based measurement by definition, and falls outside the scope of this observation.

Service identification rests on domains, URL schemes, and markup contents: Google — via googletagmanager.com, google.com/ccm, analytics.google.com, doubleclick.net, google.ee/ads, recaptcha, and fonts.gstatic.com; Meta — via connect.facebook.net and the pixel identifier in the markup; Automattic — via stats.wp.com and pixel.wp.com; CookieYes — via cdn-cookieyes.com and log.cookieyes.com. Three requests to the site’s own addresses at the six-second mark are link preloading, not navigation to other pages.

Conclusion

The site has everything it should: a consent-management platform, an Estonian-language banner with a reject button, a detailed cookie table. It operates in reverse order. Advertising and analytics requests — Google Ads conversion measurement carrying an advertising identifier, a GA4 event carrying a client identifier and device parameters, a DoubleClick call, a remarketing-audience pixel, an Automattic counter — fire between the 375th and 755th millisecond, while the banner appears at the 1038th, as recorded by the platform’s own log. On top of that, the Google consent-mode integration is stored with “granted” values across all categories, including advertising and its personalization, for all regions: before the visitor makes any choice, the tags are told consent exists. A rejection in this session is genuinely recorded and genuinely applied — at the eighth second, by which point the data has already been sent.

The site’s documents describe a different platform: cookies whose content is determined by TJT’s own server, two categories with no advertising whatsoever, no processing requiring consent, and a direct denial of any transfer of data to third countries. Neither Google, Meta, Automattic, nor CookieYes is named in them, even though the cookie table in the banner, on that very same site, lists their identifiers.

Remedy: remove the default “granted” values from the consent-mode configuration; move the loading of advertising and analytics tags under the banner’s actual control, rather than firing them directly from the page markup; rewrite the cookies section to list all recipients and the advertising purpose; remove the claims in the processing principles about the absence of consent-based processing and third-country transfer, or bring practice into line with them; host the fonts on proprietary infrastructure; and restrict reCAPTCHA to pages with forms.