Add tracking to better understand how people arrive at the 'New merge request' page
Creating your first MR is one of our activation actions. To better understand 'how' people are creating their first MR we need to fill in gaps in our tracking to be able to understand how people are arriving at the 'new merge request page'.
In general though, there's really only one path which is through the new merge request page... there's a few ways to get there (Issue button, Link after you push, button MR list, etc...) but it's all the same path after that.
We want to ensure we collect namespace identifier in the following events:
Known gaps (flows where someone does not end up on the New MR page):
- There's one other path for creating by sending an email, but I'd suspect it's uncommon.
- Folks who work exclusively from their local environments to create their first MR locally. I'd suspect it's a very small percentage of users who create an MR exclusively from their local command line via push options.
- Push Options documentation
- GitLab CLI
Tracking details:
activity | action | |
---|---|---|
Create merge request on Issues |
click_create_mr_issues_list |
|
Create confidential merge request on Issues |
click_create_confidential_mr_issues_list |
|
Link after you push or click Create merge request inside banner | visit_after_push_link_or_create_mr_banner |
Potentially could be triggered somewhere else |
New Merge request Button MR list |
click_new_merge_request_list |
|
New Merge Request CTA on MR empty state |
click_new_merge_request_empty_list |
|
Create MR button in Web IDE |
create_mr_web_ide |
Edited by Serhii Yarynovskyi