I think your approach can be compliant, but it's going to be a bit tricky.
Personal data has a broad definition
The GUID is almost certainly personal data. Personal data is any information relating to an identifiable person. You should treat all the raw data collected via the survey as personal data. Even if there is no PII-style identifier like a name or telephone number, the GDPR has a very broad concept of identification.
- Even just being able to “single out” one person's records can count as identification. A GUID facilitates such singling out.
- Information can also be personal data if the data subject can only be identified indirectly, by linking your information with other data or with the help of third parties. It doesn't matter whether you will actually perform such linking, only if it's reasonable that you would likely have the means to carry out identification in some scenario.
Any processing needs a legal basis
To collect, store, or otherwise process personal data (such as survey responses, or analytics events), you need a legal basis.
For example, you might have a legitimate interest, where you weighed your interests against the data subject's rights and interests and determined that your interests are more important. However, the GDPR provides some factors that you must consider during this balancing test (such as whether the data subject would reasonably expect this processing to occur). The data subject also has a right to object (opt-out), though the objection can be denied in some scenarios.
A more well-known legal basis is consent (opt-in). Consent can authorize nearly any processing, but you must provide enough information up front so that the data subject can make an informed decision. Consent is never the default, but always involves some statement or affirmative action from the data subject, such as clicking an “I agree” button. Withdrawing consent must be as easy as giving it in the first place.
Consent is needed for accessing or storing information on end user devices, unless strictly necessary
Consent is widely used as a legal basis on the web because the ePrivacy directive mandates consent before setting or accessing information on the end user's device (such as cookies), unless this access/storage is strictly necessary for a service explicitly requested by the user. This consent requirement is completely independent from the question whether the information on the user's device is personal data. For example:
- Storing or accessing cookies for analytics purposes is not strictly necessary from the perspective of the user, and therefore requires consent – regardless of whether personal data is involved.
- Storing or accessing session cookies might be strictly necessary for user-requested functionality to work, for example in order to connect pieces of a form that is split across multiple pages. Such cookies probably do not require consent.
Note that “cookies” are merely the most common technology used for client-side storage of IDs, but ePrivacy is technology-neutral and likely covers all similar technologies, such as LocalStorage, hidden input fields in HTML, URL query parameters, and fingerprinting techniques.
Side note: you consider what happens when “users opt-out of anayltics cookies on the site”. That is not a good mindset towards GDPR/ePrivacy compliance, because analytics cookies require consent. Consent is always opt-in, never the default.
Using the GUID for multiple purposes
Things get more tricky when this access has multiple purposes, for example if a cookie with a GUID is strictly necessary for the site to work, but would also be used for analytics purposes.
I am not entirely sure how to resolve this in general. It could be argued that once the information is on the server, subsequent use of the information for different purposes would not be an additional “access” and would not require consent. If the information is also personal data, then Art 6(4) GDPR allows use of personal data for “compatible” purposes. On the other hand, such an argument would defeat the objective of the ePrivacy Directive.
But in this particular instance, things are easier: the legal basis for collecting information through your survey will almost certainly be consent. Consent must be specific to a processing purpose. Consent to data collection through the survey does not imply a legal basis for analytics, unless such metrics are integral part of the study's design (e.g. in a psychological study that measures reaction times, or in an UX study that must track user behaviour while they complete tasks). Given that consent to data collection for the study is specific to a purpose, it is unlikely that reusing the GUID for analytics purposes would be a compatible purpose.
Here, I think the appropriate approach would be as follows:
- Before subjects can take the survey, they are informed about the processing, in line with the GDPR conditions for consent and your Art 13 information obligations.
- Participants are only admitted to the survey if they consent to this processing.
- Separately, participants are asked if they optionally want to consent to collection of analytics data. Taking into account Art 7(4) GDPR, this is totally optional and participants can proceed regardless of their choice.
Things might be different if you don't generate separate analytics events from the GUID, but just analyze partial survey responses, if such an analysis is compatible with the purpose for which these responses were collected. Mining your existing survey responses stored on your servers would only be subject to GDPR, not to ePrivacy's consent requirements.