Experiment: continuous onboarding iteration 2 - change destination URLs
Experiment summary
We believe we can increase adoption by directing users directly to the action. To verify this we will change link URLs from going to onboarding issues to the direct action the user needs to complete within the app. To monitor the success of this experiment we will look at the stage adoption, invite, trial signup rates.
Hypothesis
We can increase adoption rates by directing users directly to the action within the app.
Business problem
If we're able to increase stage adoption, invites, or trials it has a direct impact on the conversion rate to being a paid customer which is the ultimate goal of the Growth division.
Supporting data
Expected outcome
Experiment design & implementation
The visual experience within the product will remain the same in the control and experiment. The only variable we will change between the control and experiment will be where the URLs link to
| Display Text (same in both experiment and control | Control URL Path | Experiment URL Path |
|---|---|---|
| Invite your colleagues | learn-gitlab/-/issues/7 | /project_url/members |
| Create a repository | /learn-gitlab/-/issues/2 | /project_url
|
| Set-up CI/CD | /learn-gitlab/-/issues/4 | /pipelines |
| Start a free trial of GitLab Ultimate | /learn-gitlab/-/issues/13 | /trials/new?glm_content=onboarding-start-trial&glm_source=gitlab.com |
| Add code owners | /learn-gitlab/-/issues/2 | /trials/new?glm_content=onboarding-code-owners&glm_source=gitlab.com |
| Enable require merge approvals | /learn-gitlab/-/issues/2 | /trials/new?glm_content=onboarding-require-merge-approvals&glm_source=gitlab.com |
| Create an issue | /learn-gitlab/-/issues/3 | /issues |
| Submit a merge request (MR) | /learn-gitlab/-/issues/5 | /merge_requests |
| Run a Security scan using CI/CD | https://docs.gitlab.com/ee/user/application_security/security_dashboard/#gitlab-security-dashboard-security-center-and-vulnerability-reports | /security/configuration |
Current visual experience should not change:
ICE score
| Impact | Confidence | Ease | Score |
|---|---|---|---|
| value 1 | value 2 | value 3 | Average(1:3) |
Known assumptions
Results, lessons learned, next steps
Checklist
-
Fill in the experiment summary and write more about the details of the experiment in the rest of the issue description. Some of these may be filled in through time (the "Result, learnings, next steps" section for example) but at least the experiment summary should be filled in right from the start. -
Add the label of the group::that will work on this experiment (if known). -
Mention the Product Manager, Engineering Manager, and at least one Product Designer from the group that owns the part of the product that the experiment will affect. -
Fill in the values in the ICE score table ping other team members for the values you aren’t confident about (i.e. engineering should almost always fill out the ease section). Add the ~"ICE Score Needed" label to indicate that the score is incomplete. -
Replace the ~"ICE Score Needed" with an ICE low/medium/high score label once all values in the ICE table have been added. -
Mention the [at]gitlab-core-team team and ask for their feedback.