Ensure that page-feedback events are usable with Google Analytics 4

[chalin]

This can be viewed as a subtask of #35299 or a followup task, which is why I'm creating a separate issue. I'd vote for the latter.

While the website's custom layouts/partials/feedback.html is already using the gtag.js library, the custom event name (click) conflicts with GA4's use of the same name to measure outbound clicks.

It isn't clear to me yet if we can still (relatively easily) extract the page-feedback data or, for example, write custom GA4 i/f code to rectify this name clash, but IMHO, it would be easier to choose an event name that doesn't clash.

This is also an issue for Docsy, see google/docsy#1302. I'll likely be exploring solutions for Docsy, and can port the required changes here.

/cc @a-mccarthy @nate-double-u

[a-mccarthy]

Thanks for filing this @chalin. I also noticed that the data we are currently getting from the feedback form is not reliable. I opened a bug here: #37201. I've done a bit of investigating to try and remove the bot data, but its looking like this is not as straight forward as i was hoping. I dont have a solution yet, but wanted to make sure to note the issue here to remind ourselves about it :)

[sftim]

/triage accepted
/area web-development

[chalin]

Progress: I've defined an Event Modification rule through the analytics console interface. It changes the event name of Docsy page-feedback events to page_helpful from click:

So far it is working in realtime in the debugger. It also is appearing in the Realtime overview events panel:

Here's an example of the parameters of one of these modified events:

I'm not sure how we can conveniently see page_helpful stats per page path. We might have to create a custom report for that. I'll check that tomorrow.

[chalin]

Here is an example of the kind of page-feedback report that we can create. This is for Nov 2 (the only day we have data for since I added the event-modification rule):

[a-mccarthy]

Thanks for working on this @chalin! Just so i understand the numbers, does the 3 for /release/notes mean three clicks? Is it possible to determine if the click is yes or no?

Previously, the clicks value was calculated as yes is 1 and no is 0, and then GA would calculated an average value of the clicks. So the feedback is this page helpful? would show up as a percentage between 0-1, where the closer to 1 the number was, the more helpful the page. I'm not saying this was better, just describing how it worked previously.

I'm not sure if GA4 tracks values in the same way or if we are passing the value correctly for GA4. We may need to define a metric/dimension to be able to use this data in a report 🤔

[chalin]

Oh, you're right, I'm missing a data (missing a column). I've updated the screenshot, adding an "Event count" column. PTAL. I've found it challenging to create reports in GA4. Maybe it's just a steep learning curve, or maybe the i/f needs improvements (or both) 😄

[chalin]

There might be a better way to visualize that data. If there is, I haven' t found it yet. 🤷‍♂️ ... But I'll keep looking!

[a-mccarthy]

I was just poking around a bit in GA4 just now, and it seems a lot like creating graphs in Google Data Studio. Which is NOT easy either. I used a pre made Data studio template when i put together the analytics dashboard for the Kubernetes site, which is the only reason we have the pretty graphs.

So i understand, the /release/notes/ 3 here in both columns mean 3 yes clicks. But for a page like /zh-cn/docs/setup/learning-environment there were 3 page_helpful clicks, but on 1 was yes?

[chalin]

I'm glad that you found that GDS template then! (Thanks for sharing your experience with GDS and validating that you found that challenging too.

My understanding of the data matches yours.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale

[chalin]

Page-feedback events are currently being processed thanks to a workaround so I'll close this issue now. Once Docsy is fixed to address this issue, and it is updated here, things will fall into place.

[chalin]

FYI, the following is targeted for the next release of Docsy (0.8.0):

• Page feedback: support for Google Analytics 4 (GA4) google/docsy#1302