Data and Privacy Agreement for GitLab users
Summary
We need to provide a way for GitLab to be very clear and transparent about what data we're collecting, why we're collecting it and what we intend to do with it, giving them the chance to stop using the service if they do not agree. In addition, users will be able to individually opt-in to PII tracking if that is what they prefer.
There are multiple reasons why we need to start collecting a unique user ID for each user, including but not limited to:
- 1. Experiments The primary responsibility of the new growth team is to run experiments that help our users get more value out of GitLab. If we don't have user id tracking on our frontend events, we won't be able to analyze the data from any of these experiments. For example, we have a new onboarding flow ready to be A/B tested soon, but without tracking user_id we'll have no idea if our conversion funnel is actually improving or not (relying on backend data only is not a viable option.) Additionally, making snowplow tracking opt-in will cause every experiment to take much longer (assuming a 5% opt-in rate, every A/B test will take 20x as long to run).
- 2. MAU/SMAU Product Managers want to know how many active users we have within each product stage. We need frontend data to do this, since many activities don't create any backend data. As it currently stands, we don't know how many active users we have on gitlab.com, how often they return, etc.
In addition, tracking the user ID allows us to more specifically locate user information and remove it if requested as per our privacy policy.
Task list from original MR:
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14182
Once policy is approved and Tech Stack is updated:
Ensure that new customers accept this - mechanism for this to be determined by product and engineering Notify current customers who have requested we email them upon update of privacy policy Put a banner or notification on site to alert customers to new policy - mechanism for this to be determined by product, engineering, and/or UX Update the employee privacy policy - DIR @cciresi
Proposal
-
Update https://gitlab.com/gitlab-org/gitlab-ce/issues/44798 with new Privacy Policy so that new users accept it. -
Add an in-product notification Alert Component (Tip variant) CTA (so we can include a link) letting current users know that the Privacy Policy has been updated.
Copy:
Our Privacy Policy has changed, please visit [link] to review these changes.
Privacy Policy: https://about.gitlab.com/privacy/
Original proposal
Introduce a modal component for our data and privacy policy.
- Upon the first login for new users, asks the user to agree to our data and privacy policy to make the message disappear.
- For existing users, the modal should appear for anyone who hasn't clicked on it yet.
- For self-managed users, we will email them the updated privacy policy.
The modal and email should be consistent with one another.
The modal should be included in the next release of GitLab CE/EE as well as GitLab.com, and we should ensure that the banner does not show up for instances that have telemetry data turned off.
Considerations
### Considerations
This makes a lot of sense for new users, but not for existing. Some questions:
-
How should we handle existing users? -
Is notifying them via email enough or do we require them to hard-agree to it before continuing to use the product? Updated proposal to answer this
-
Should we simply provide instructions via email explaining what steps they need to take if they don't agree to the policy? Included in privacy policy itself under the contact section.
-
-
Should we somehow force folks to agree by logging them out after a set period of inactivity and upon re-login we tell them our terms have changed, please agree to continue
? This is probably a no, but could spur other ideas...no
-
How would this work for self-managed users? If the admin turns off telemetry data for the instance, we would need to ensure this doesn't pop up for people, right? updated proposal
@timnoah @jackib Do we want users to go through the entire sign up process before reaching the agreement? If they choose not to agree then we may have to delete their data, which could be avoided by somehow introducing the modal earlier.
Tagging @jeremy @matejlatin since this applies to users logging in and you may want to have input here.
Also cc @bmarnane & @ebrinkman just for visibility