Hey @j_lar, just had a quick question – based off of #416584 (comment 1598448198), would we have to create event definitions for each chart type (of which there are quite a few) in Insights to track click events on data items in the charts, or is it enough to create just one event definition and pass the chart type (as well as additional info such as filter label or date range) to either the extra or contextprops?
In order to use Internal Analytics you will have to create an event for each chart type. How many chart types do you have currently?
I would recommend that you take this path if you have less than say 20 chart types. The events are pretty easy to copy-paste after you have the first one.
If the amount of chart types prevents you from using Internal Events, you can use the deprecated Snowplow events, but then your metrics will not be available from self-managed. Does that make sense?
We are considering a solution like you describe where you can add define many metrics on a single event and use a filter to narrow down what is included. But it is not planned yet, so it is not right around the corner.
In order to use Internal Analytics you will have to create an event for each chart type. How many chart types do you have currently? I would recommend that you take this path if you have less than say 20 chart types. The events are pretty easy to copy-paste after you have the first one.
According to the YAML config used to display the charts, there's at least 14; we'll only be tracking click events for 1 or 2 initially, so I think this is a viable path for now.
If the amount of chart types prevents you from using Internal Events, you can use the deprecated Snowplow events, but then your metrics will not be available from self-managed. Does that make sense?
We are considering a solution like you describe where you can add define many metrics on a single event and use a filter to narrow down what is included. But it is not planned yet, so it is not right around the corner.
Sounds good! I was hoping for this solution since it's more scalable given the amounts of charts we have, but given that we'll only be tracking click events for a couple of charts at the start anyway, we'll go with your suggestion above and take it from there.
@rcrespo3@blabuschagne I just want to make sure I am reading/interpreting this correctly, does this mean that this level of detail on metrics will only be available for SaaS?
Open question: Do we want to track chart types i.e. merge_request chart or issue_chart - how will we scale the tracking?
@blabuschagne@mushakov Since #372215 (closed) was completed, I thought I should follow up on this open question, since going this route would allow us to track click events on all charts (including those created by users using a custom YAML file, and would look something like insights_issue_chart_item_clicked), whereas tracking by only the chart titles (i.e., insights_issues_created_per_month_chart_item_clicked) listed in https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/fixtures/insights/default.yml would not. WDYT?
@rcrespo3 I think categorizing like you described above is good. By the type of item (MR and issue) but not by chart title. Chart type would be another interesting dimension to know if they drilled in or not.