Open baltpeter opened 10 months ago
Adapter for singular.net:
singular_install_id
(https://github.com/tweaselORG/TrackHAR/issues/16#issuecomment-1682664775)branch-io/v1
has a whole bunch of third-party IDs in otherIdentifiers
. For now, I'll just link to the documentation that e.g. $marketing_cloud_visitor_id
is "the Marketing Cloud Visitor ID or Experience Cloud ID" (surprise, surprise), but we probably need some separate documentation for IDs that explains why we consider them personal data.
Probably helpful for documenting the Marketing Cloud ID: https://blog.adobe.com/en/publish/2015/10/20/why-new-adobe-marketing-cloud-id-service-should-be-on-your-radar
For the infonline
adapters:
client.uuids.installationId
, client.uuids.androidId
(maybe the ANDROID_ID
?), client.uuids.vendorIdentifier
(maybe the IDFV?)
For onesignal/players
:
ad_id
: "Based on the Google Advertising Id for Android, identifierForVendor for iOS. OptedOut means user turned off Advertising tracking on the device." (source). Ugh.How do we argue that ID-like data are IDs?
What we need to argue:
To argue why installation-specific IDs are also personal: With the first (wlog) ID, a whole series of very unique (fingerprint-like) attributes were linked. The same are then also linked with the new, second ID and thus allow re-identification (can certainly also be well proven with marketing material).
We haven't discussed how to handle things that are pretty obviously vendor-specific IDs but that we can't find any documentation on.
For the time being, I won't work on these but document them here so we can come back later.