- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Mon, 6 Jul 2020 15:54:47 +0100
- To: Georg Philip Krog <georg@signatu.com>
- Cc: Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
Hello - adding some more comments to the thread. On 01/07/2020 17:51, Georg Philip Krog wrote: > 3) Analytics > > Several of the vendors in Signatu 3rd party registry offer analytic > tools that are integrated into sites (e.g. Matomo, Google Analytics, > Hotjar etc). > > Several of these tools offer analytics/insights into end user behaviour > without combining these tools with other tools. Hence, the “output” of > such tools is “analytics” alone, e.g. events on URLs. It is up to the > website owner to use this insight to achieve another purpose, e.g. > personalisation. In my view, that is a new purpose. Agreed with the argument put forth here. However, the wording still isn't quite transparent IMHO. For example, analytics is actually two separate purposes when done for: a) understanding website visitors/usage -> (assuming to) Improve existing products and services in DPV b) personalise content provided -> user interface personalisation and service personalisation in DPV Within this, the quoted comment says "the output of such tools is analytics alone ... upto the website owner to use this insight to achieve another purpose" -> and my understanding of GDPR says that purposes need specific legal basis on their own. So analytics for Purpose A does not automatically qualify the same analytics to also be used for Purpose B (in case of consent, and where A and B are mutually exclusive). Therefore, I am not in favour of putting a blanket purpose called 'Analytics' as it does not distinguish between purposes it is used for and therefore cannot be called a Purpose on its own - but of course everyone can vote to contrary to this : ) Another option suggested (at some point) is to provide clusters of purposes and ask declaration via multiple sub-classing (as one possible implementation). E.g. DPV will provide purposes: ImproveProducts..., ImproveService, PersonaliseContent, and also Analytics An implementer will declare a purpose somewhat like this: MyPurpose is a (rdfs:subClassOf or rdf:type) of all the following: Analytics, ImproveProducts This indicates a Purpose that has Analytics being used for Improving Products -> which is okay, but then Analytics can never be an independent purpose. So, if this is to be interpreted as saying 'Analytics is not suggested to be used on its own' - why define it as a purpose at all? It is more akin to be a collection of processing activities - collect data + store data + analyse data + derive data etc. So wouldn't it be better to provide Analytics as either an implementation detail or a Technical measure to implement another purpose? (fun fact of the day: IAB TCF v2 framework does not list analytics as a purpose either - https://vendorlist.consensu.org/v2/vendor-list.json) > > > 4) Advertising > > Advertising is a “big bucket” if one includes all the technologies that > are used to programmatically serve an ad to an end user. However, if one > looks at the end result for the end user, it is the end user that sees > an ad on a site/app, and that ad was served based on different > parameters which may or may not include the end user profile. If the > latter was the case, then one could say it was a personalised ad. Yes. So we need to add an "Advertising" purpose in DPV? (I think a better wording would be 'deliver advertising'?) And this is given that advertising may be different from Marketing, Recommendations - hence a separate purpose? > > > “Marketing” is often used for direct marketing towards an end user, e.g. > communication of marketing info via e-mail, sms etc. A topic of > discussion in the e-Privacy Reg. is whether ad serving based on > profiling is direct marketing. Regardless, we need to add Marketing and its subclass Direct Marketing as purposes. Now, a lot of domain-specific articles consider Advertising a subset of Marketing - which I agree with. > 7) Document consent are the words used in the GDPR (Article 7.1). > > I am fine with record consent. > > However, some contend that “record” is not a requirement. In this case, we should go with document consent. > > > 8) Content Management > > Agree that it falls under Service Provision. So does “Cloud > infrastructure and traffic distribution”. > > Our customers wanted to be more specific, and thus wanted “Content > Management” to enable end users to understand that one technology allows > a site owner to create, design and store content while another > technology would distribute the content. The nice thing about DPV is that one can create specific instances of purpose as they wish - so in this case, Service Provision can be 'personalised' into 'Content Management' or 'Content Media Management' or whatever anyone wants to call it. The core of it is that all of these are grouped under 'Service Provision' type of purposes. It is impossible to capture or represent every purpose and its variation into DPV. Therefore we have chosen to instead provide an upper-level taxonomy with the expectation that adopters will 'personalise' it to their use-case. > > > 9) Customer Management is about managing the lifecycle of a customer > (who are prospective customers? Who are existing customers one can > “upsale” to? Who are terminated customers? etc) and is not about > customer support. Agreed - we should have a general CRM purpose given that we have "improve internal CRM processes" as a purpose. > > > 11) Marketing should be added. It is defined in the ePD and in the > upcoming ePR and also in many national marketing laws. Yes - comment in (4) > > > 13) Payment and fraud detection should be separate classes/categories. Agreed. However, in this case - wouldn't payment be part of Service Provision or not necessarily so? For e.g. if I buy something, then in order to complete the sale to me as part of service - I am expected to provide my card details. Regardless, I think we should add Payment to the list of Purposes. > > > 14) Personalisation depends on/is enabled by profiling, so are these two > different purposes or one? Personalisation is a purpose Profiling is not a purpose - it is a processing activity. DPV represents these as above. > > > 15) Survey and Reviews - agree that it is what is being done with the > survey data that is the purpose. This is similar to 'Analytics' - secondary purposes which are subsumed within 'higher-order' purpose descriptions. IMHO this is another implementation detail - how to represent these? > > > 16) Search can be search within or outside a site, so not necessarily > Service Provision. This is too abstract for me. Search has to be fine-tuned to a more relevant purpose. > > > 19) Social Media - Isn't this part of Marketing? Yes. One can integrate > social media on a site to lead end users to the site´s social media > accounts, or one can embed social sharing buttons etc to enable end > users to share content from the site. In this case, we should add specifics of Marketing - e.g. social media, newspaper, etc. - based on common occurrences. > > > 20) Tag management is a technology that allows a site to determine which > tags that should fire where and when etc. > This is a domain-specific term and I don't think this would constitute as a purpose. To the best of my (limited) understanding, 'tags' are a type of technological implementation agnostic of purposes. (my understanding is that tags are similar to or the same as pixels or beacons) -- --- Harshvardhan Pandit, Ph.D Researcher at ADAPT Centre, Trinity College Dublin https://harshp.com/research/
Received on Monday, 6 July 2020 14:55:05 UTC