dhlexpress.ee

Context

dhlexpress.ee is the Estonian site of DHL Express, an international logistics operator. The processing is described by a privacy notice (v1.2c, Estonian and English) and a detailed cookie declaration running on the OneTrust engine. Consent is managed by the OneTrust platform; part of the static is served from express-resource.dhl.com (behind Cloudflare and F5 BIG-IP, per the cookie declaration).

The capture is a single recording of the English-language homepage (dhlexpress.ee/en/): 66 requests, 6 nodes. The page contains a shipping calculator (the generate_lead event with route parameters).

Who receives data directly

Analytics — Google Analytics 4 and Google Ads (both under denial, gcs=G100, cookieless). Consent management — OneTrust. Facebook loads only the SDK, without events. Everything else is DHL first party. LinkedIn and YouTube are also named in the cookie declaration, but did not fire in this capture.

Declared versus actual

Here almost everything is done right, and the problem lies in a single broken detail.

Google’s consent mode is respected. The GA4 events (G-ZXH7E3H54N) — page_view, generate_lead — and Google Ads (ccm/collect) carry status gcs=G100: both storages denied, pings cookieless, and Google Ads has dma=1 (EEA mode) and ads_data_redaction set. The generate_lead event is a shipping calculation in the calculator; it carries route parameters (country of departure and destination) in dl, but without a cookie binding. This is correct behaviour when consent has not been given.

Facebook is present only as an SDK. connect.facebook.net/fbevents.js loads at +986 ms, but there are no pixel /tr events in the capture — that is, the Facebook pixel is initialised but transferred no data.

Recipients are disclosed. The OneTrust cookie declaration names OneTrust, Google, Facebook, YouTube, LinkedIn — with categories, hosts and retention periods. The «Privacy settings centre» banner is symmetrical, with a real choice and an honest warning about data transfer to countries with an inadequate level of protection (USA).

But the tag auto-blocking mechanism is broken. The OtAutoBlock.js script — the part of OneTrust that should prevent third-party tags from loading before consent — returned status 404: it did not load. Because of its absence, the marketing components manage to initialise within the first second: the GTM container (GTM-MNMS78R) at +494 ms — earlier than the consent platform itself (+654 ms), the Facebook SDK at +986 ms, Google Ads at +1023 ms. An important caveat: no actual transfer of marketing data was recorded — Google’s consent mode held analytics and conversions under denial, and the Facebook SDK sent no events. That is, the data is held at the consent-mode level, but the second line of defence — auto-blocking the loading — did not work. This is a gating defect, even if in this capture without a data leak.

Consent: what is proven and what is not

Proven: the auto-block did not load. OtAutoBlock.js returned 404 — confirmed by the status in the HAR and by the Network panel in the screenshots.

Proven: Google’s consent mode is respected. All GA4 and Google Ads requests carry gcs=G100, cookielessly; Google Ads has ads_data_redaction and dma=1.

Proven: Facebook is only the SDK, without events. In the capture there is only fbevents.js, no /tr requests.

Proven: the tags initialise before the consent platform. GTM — +494 ms, OneTrust — +654 ms; Facebook and Google Ads — +986…+1023 ms.

Proven: the recipients are named. The cookie declaration lists Google, Facebook, YouTube, LinkedIn, OneTrust.

Not established: the consent decision in detail. Which choice was made in the banner cannot be read unambiguously from the capture; the gcs=G100 status indicates a denied state of the storages (by default or by refusal).

Not established unambiguously: the per-field breakdown of gcd. A gcd signal is present, but the exact field breakdown is not decoded; the conclusion rests on gcs=G100 and on the 404 status of the auto-block.

Observation boundaries

The capture covers a single page — the homepage — and records browser behaviour, not server-side processing: why OtAutoBlock.js returns 404 (a configuration error, expiry, regional delivery) and what the parties do with the received signals is not determined by a browser capture. The fact of the 404 status and the fact of the tags initialising are established; the conclusion of an auto-block defect rests on these, not on a transfer of marketing data, which is absent in this capture. The recipients named in the declaration but not surfacing (LinkedIn, YouTube) are placed under «declared».

The file is published cleaned of personal data (61 redactions, self-check clean); the 404 status of OtAutoBlock.js, the load order, the gcs=G100 of the Google requests and the absence of Facebook /tr events can be verified directly against the published file. The banner UI and the 404 status in the Network panel are confirmed by the screenshots — a separate type of evidence.

The legal assessment is made by the competent authority — Andmekaitse Inspektsioon.

Conclusion

The international logistics operator’s site is built to a corporate standard: the OneTrust consent platform with a symmetrical banner, a detailed cookie declaration with individual disclosure of recipients, an honest warning about cross-border transfer, and — importantly — Google’s consent mode is respected: analytics and conversion measurement run under denial, gcs=G100, cookielessly, with redaction of advertising data; Facebook is limited to loading the SDK without events.

One detail lets it down, but a significant one: the OtAutoBlock.js auto-blocking script returns 404 and does not load. This is the OneTrust component that should hold back the very loading of third-party tags until consent. Without it, the GTM container, the Facebook SDK and Google Ads manage to initialise within the first second — this time without a data leak, because Google’s consent mode backed them up. But relying on a single line of defence when the second is broken is a risk: consent mode covers the Google stack, whereas auto-blocking is needed precisely for those tags that consent mode does not govern.

Remediation: restore the loading of OtAutoBlock.js (fix the cause of the 404), so that OneTrust’s auto-blocking prevents third-party tags from loading before consent; load the GTM container after the consent platform is initialised; preserve the correct Google consent mode, extending the gating principle to all marketing tags, not only those governed by consent mode.