Instrument monthly user GitLab Group migration flow
Purpose
We have implemented a new GitLab Group migration and plan to remove the old one.
We already announce the deprecation of the old flow in the product: https://gitlab.com/groups/new#import-group-pane
but we need to plan the removal of this feature.
In order to do so we must understand how many users use the old flow and how many the new flow.
In addition, we should make the old flow less accessible from the UI in order to get our users used to using the new migration.
Current numbers from the DB
490 records in the database of BulkImport and 1260 of GroupImportState for the past 60 days
Structured Snowplow events to track
- Category: The page or backend area of the application. Unless infeasible, please use the Rails page attribute by default in the frontend, and namespace + classname on the backend. If you're not sure what it is, work with your engineering manager to figure it out.
- Action: A string that is used to define the user action. The first word should always describe the action or aspect: clicks should be
click
, activations should beactivate
, creations should becreate
, etc. Use underscores to describe what was acted on; for example, activating a form field would beactivate_form_input
. An interface action like clicking on a dropdown would beclick_dropdown
, while a behavior like creating a project record from the backend would becreate_project
- Label: Optional. The specific element, or object that's being acted on. This is either the label of the element (e.g. a tab labeled 'Create from template' may be
create_from_template
) or a unique identifier if no text is available (e.g. closing the Groups dropdown in the top navbar might begroups_dropdown_close
), or it could be the name or title attribute of a record being created. - Property: Optional. Any additional property of the element, or object being acted on.
- Value: Optional, numeric. Describes a numeric value (decimal) directly related to the event. This could be the value of an input (e.g.
10
when clickinginternal
visibility)
Category | Action | Label | Property | Feature Issue | Additional Information |
---|---|---|---|---|---|
BulkImports::CreateService OR self.class.name
|
create |
bulk_import_group |
- | - | - |
Groups::ImportExport::ImportService OR self.class.name
|
create |
import_group_from_file |
- | - | - |
Snowplow event tracking checklist
-
Engineering complete work and deploy changes to GitLab SaaS -
Verify the new Snowplow events are listed in the Snowplow Event Exploration dashboard -
Create chart(s) to track your event(s) in the relevant dashboard -
Use the Chart Snowplow Actions SQL snippet to quickly visualize usage. See example - this will be done in Create chart for GitLab Migration group migrati... (#378617 - closed)
-
Proposal
Let's implement tracking on the controller level via GitLab::Tracking.event
(see https://docs.gitlab.com/ee/development/snowplow/implementation.html#implement-ruby-backend-tracking). We'd like to implement two tracking events (one for the GitLab migration and one for the file-based import/export). See the Snowplow section above for more details on these events.
Note: We want to track both the internal (private) API and the public API with the same tracking event (i.e., category name)
Additional Note: As we are adding tracking events to the controllers and the api endpoints, I propose using the categories We're going to move the event tracking to the service level as this is used by both controller and api to create the import service. This means adding to the Import::BulkImports
and Import::GitlabGroups
. This will avoid any confusion e.g. when the event is triggered via an API request, but the category says Import::BulkImportsController
, a class that plays no part in creating the import service when the api endpoint is used.app/services//groups/import-export/import_service.rb
& app/services/bulk_imports/create_service.rb