Update top pages panel under the behavior dashboard to show path fragments

Overview

See Next Steps for current status. tl;dr this needs some research to ensure we're solving a real customer problem by changing the default view OR if we build more visualizations OR filters OR something else.

Problem

The existing Top pages panel shows a list of paths and how many page views are associated with that path. The problem is that when a page path is broken down further by path fragments (example/example-page#path-fragment), the visualization breaks down the page views by the path fragments but doesn't render them in the visualization. So it just looks like a lot of duplicate page paths.

Proposal

A few ideas discussed to resolve this issue have been:

Add page_urlfragment to the Cube schemas and add as an additional column to the table.
Update the Cube schemas to combine both the page_urlpath and page_urlfragment into one unified dimension and use that instead.
Look at providing a drill down UI which shows the path with a total count, followed by a subsection breaking down the count per path fragment.
Rely on the pageUrlhosts dimension for creating clickable links, as this will be the same value in most cases and will prevent pages being segmented. We would then need to manually construct the link href from host + path. This was proposed in a duplicate issue.

Option details

Option 1

Page URLPath	Page location	Views
`content/voice-and-tone`	`#location1`	100
`content/voice-and-tone`	`#location2`	80
`other-page/`	`N/A`	75

Option 2

Page URLPath	Views
`content/voice-and-tone#location1`	100
`content/voice-and-tone#location2`	80
`other-page/`	75

Option 3

Page URLPath	Views
`content/voice-and-tone`	180
`other-page/`	75

(TBD - needs some UX for drilldown behavior)

Next Steps

Current as of 2023-11-21

We will revert the top_pages behaviour in #432491 (closed) to completely exclude fragments, which was how it originally worked. See: #420898 (comment 1659543901)

This issue remains to discuss solutions for viewing data about path fragments.

Status on 2023-11-08

In discussion on the UX/PM Weekly call we talked about what was feasible to build (these options OR an option to group/sum all page views with paths/query parameters into the page itself to avoid duplicates). We also determined the right next step is some research by UX/PD/PM to figure out what is valuable for users in more scenarios then web apps so we can make the default still valuable and hint at ways to customize if another view provides more value.

Status on 2023-09-06

Determine feasibility/effort of each proposal
- Option 1 and 2: Same feasibility/effort
- Option 3: Without a dedicated UX designer, it's difficult to determine the feasibility of this option, so will leave for a future issue.
Create implementation steps

Chosen MVC solution: Option 1

Known potential UX concern:

We might need a follow-up to work on Option 3 if the breakdown gets confusing for users. If a user visits /my-page and then visits /my-page#subsection you will get:

Page URLPath	Page Urlfragment	Page Views Count
`my-page`	N/A	1
`my-page`	`subsection`	1

The root page does not get given a page view when you visit a fragmented part of the page. We may find users expect something more like:

Page URLPath	Page Urlfragment	Page Views Count
`my-page`	N/A	2
`my-page`	`subsection`	1

Implementation plan

DevKit/Analytics stack - infrastructure 1️⃣

Update cube/schema/snowplow/SnowplowTrackedEvents.js in the DevKit to reveal the pageUrlfragment:

Index: cube/schema/snowplow/SnowplowTrackedEvents.js
===================================================================
diff --git a/cube/schema/snowplow/SnowplowTrackedEvents.js b/cube/schema/snowplow/SnowplowTrackedEvents.js
--- a/cube/schema/snowplow/SnowplowTrackedEvents.js	(revision Staged)
+++ b/cube/schema/snowplow/SnowplowTrackedEvents.js	(date 1694010362409)
@@ -44,6 +44,10 @@
       sql: `page_urlpath`,
       type: `string`
     },
+    pageUrlfragment: {
+      sql: `page_urlfragment`,
+      type: `string`
+    },
     event: {
       sql: `event`,
       type: `string`

Copy schema change to the analytics stack and deploy it to the different environments.

GitLab - frontend 2️⃣

Update ee/app/validators/json_schemas/analytics_visualization.json to allow the new fragment field.

Update ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml to render the new fragment field.

Index: ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml
===================================================================
diff --git a/ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml
b/ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml
--- a/ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml	(revision Staged)
+++ b/ee/lib/gitlab/analytics/product_analytics/visualizations/top_pages.yaml	(date 1694010368623)
@@ -9,6 +9,7 @@
     dimensions:
       - SnowplowTrackedEvents.pageUrlpath
       - SnowplowTrackedEvents.pageUrl
+      - SnowplowTrackedEvents.pageUrlfragment
     limit: 100
     timezone: UTC
     filters: []
@@ -17,3 +18,4 @@
   links:
     - text: SnowplowTrackedEvents.pageUrlpath
       href: SnowplowTrackedEvents.pageUrl
+      fragment: SnowplowTrackedEvents.pageUrlfragment
Index: ee/app/validators/json_schemas/analytics_visualization.json
===================================================================
diff --git a/ee/app/validators/json_schemas/analytics_visualization.json b/ee/app/validators/json_schemas/analytics_visualization.json
--- a/ee/app/validators/json_schemas/analytics_visualization.json	(revision Staged)
+++ b/ee/app/validators/json_schemas/analytics_visualization.json	(date 1694010319017)
@@ -142,6 +142,9 @@
         },
         "href": {
           "type": "string"
+        },
+        "fragment": {
+          "type": "string"
         }
       },
       "required": [

Update any specs.

Edited Nov 20, 2023 by Elwyn Benson