Not a vulnerabilityNothing is exploited. The identifier is passed on because a setting says so, and the objection is to the setting.
What it is
Before sign-in a third party recognises the browser or the device by an identifier of its own. At the moment of authentication the operator hands that same party its own account identifier: a user number, a customer number, a hashed address, sometimes the address itself. From then on the profile that was pseudonymous has a name attached. Everything recorded before the sign-in and everything recorded after it, on any device where the person signs in, belongs to one identified person.
Why it is a separate entry
The step is invisible and it cannot be undone. A profile built from browsing can be argued about as long as it is pseudonymous; once joined to an account it is a dossier about a named person. Clearing cookies no longer separates the two, because the next sign-in joins them again.
How it arises
a user identifier configured as a custom dimension or user property in a measurement tag
an advertising tag firing on the login event with the account identifier as a parameter
an identity feature of the measurement product, enabled as soon as a user identifier is available
the same identifier used in the application and in the tag, because it was the value at hand
Not to be confused with
Two third parties exchanging identifiers so their profiles can be matched is Identifier synchronisation between parties. Here the value comes from the operator itself and names the account. An operator writing its own user identifier into its own store is not this entry either: the value has to reach a party that also holds an identifier of its own for that browser.
How to establish it
Differential over accounts. Sign in twice in the same browser profile with two accounts you control: a request to a host under a different registrable domain carries a value that changes with the account while that host's own identifier stays the same. The reverse check confirms it, in that the same account in a fresh profile yields the same account-dependent value against a new host identifier.
method differentialQoD 95
Requirements on the measurement
two accounts you control on the same service, plus a clean profile for the reverse check
capture the authentication step and the first screen after it; the join is often made once per session
record the consent state, because the join may be gated and the gate is part of the finding
compare on values, not on parameter names: every product names its user identifier differently
sign in twice with the same account, so a session token can be told apart from an account identifier
What would refute it
automatedThe account-dependent value changes on every sign-in of the same account, so it identifies a session rather than an account.finding falls
automatedThe receiving host is under the operator's own registrable domain.finding falls
automatedThe receiving party holds no identifier of its own for this browser, so there is nothing to join to.Then the account identifier is being disclosed, which is a transfer question, without the joining that makes this entry what it is.weakens
not from the captureThe recipient acts on the operator's instruction only and is barred from using the value for its own purposes.weakens
Where this plugs into existing processes
The one question that surfaces itWhat leaves the browser at the moment someone signs in, and does anything in it change with the account?
In a DPIA, verify this
Verify with two test accounts what leaves the browser at the moment of sign-in, rather than accepting that measurement is pseudonymous.
As a procurement clause
No account identifier, hashed or not, reaches a measurement or advertising party at authentication; demonstrated with two test accounts on delivery.
With a complaint, hand over
Two captures of the sign-in step with different accounts, the value that changes with the account marked, and the third party's own identifier shown to be constant.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-1-b
eu-gdpr-6-1-a
eu-gdpr-13
eu-gdpr-26
Objections, and the answer
“We only send an internal number, not a name.”
The number is the join. The recipient does not need the name to know that this browser and that account are one person, and the operator can resolve the number to a name whenever it likes.
“It improves measurement across devices.”
That is the purpose stated plainly, and it is exactly the processing nobody was asked about. A benefit to the operator is not a ground.
“The person is logged in, so they know we know them.”
They know the operator knows them. This is about a third party, and the sign-in screen says nothing about it.
“The identifier is hashed before it is sent.”
A hash that is stable per account works as an account identifier. What matters is that the value is the same on every visit and different per person.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0032: Account identity joined to a tracking profile. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0032
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0032, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.