`view_notification` GA event being sent for Banner Notifications that are dismissed or hidden

Bug Description

As discussed here, the view_notification GA event that is sent for the main authentication notification is being sent even when the notification has been dismissed, and the view_notification event is being sent for various components that use BannerNotification even when the notification is hidden due to multiple notifications being present.

Steps to reproduce

1. Set up Site Kit with tracking enabled and use the Google Analytics Debugger extension to log GA events in the JS console.
2. Ensure that multiple notifications are present, this could include: ~ Use a pre-5.2 version of WordPress to show the WPVersionBumpNotification. ~ Use a site in the zero or gathering data state, or use the Tester plugin to force these states, to show ZeroDataNotification or GatheringDataNotification.
3. Navigate to /wp-admin/admin.php?page=googlesitekit-dashboard&notification=authentication_success&slug=analytics to show the main authentication notification, SetupSuccessBannerNotification.
4. Check the JS console, where view_notification events will be logged for the hidden notifications.
5. Dismiss the main authentication notification and reload the page with the path & query string above.
6. The view_notification event will be logged for the dismissed notification.

Screenshots

Event for main authentication notification sent although the notification has been previously dismissed:

Event for gathering data notification sent although the notification is hidden:

Additional Context

• PHP Version: any
• OS: any
• Browser: any
• Plugin Version: checked in 1.86.0 & 1.87.0
• Device: any

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• All of the view_notification events for BannerNotification components should be reviewed.
• All cases where the event is sent for a dismissed or hidden notification should be addressed, so the event does not fire in these cases.

Implementation Brief

Note for IB author: This should probably be done in a centralised manner for example by adding an onView prop to BannerNotification, which a callback can be passed into to call trackEvent, and potentially using IntersectionObserver as a mechanism for determining when the notification is viewed.

• In assets/js/components/notifications/BannerNotification/index.js:
  • Add a new prop, say onView to the BannerNotification component which should be a callable function.
  • Check if the BannerNotification is actually visible using IntersectionObserver, similar to the implementation in WidgetAreaRenderer.
    • Add a new ref (using the useRef hook from @wordpress/element) and apply it to the root <section> element returned by the component.
    • Use the same ref to create an IntersectionObserver using the useIntersection ref from react-use.
  • Add a useEffect hook which will check if onView exists and if there is a valid “intersection” using the intersection observer. If yes, then call the onView function.
  • Use a local component state variable to check if the onView function has already been called and ensure it is called only once per page load (i.e. the function should not fire every time the component comes into view).
• Move all trackEvent() calls within a useMount()/useEffect() for the view_notification event and pass it as the onView prop when rendering that component’s BannerNotification component:
  • CoreSiteBannerNotification
  • SetupSuccessBannerNotification
  • GatheringDataNotification
  • ZeroDataNotification
  • UserInputSuccessBannerNotification

Test Coverage

• No new tests required.

QA Brief

Changelog entry

[techanvil]

Thanks @jimmymadon.

This should be pretty self-evident, but it might be worth mentioning that onView should only be called once, for the sake of clarity.

I know we have used local component state to track if the event was fired already. However, if for some reason, a notification is actually displayed twice (because the user refreshed the page before dismissing, etc), shouldn’t trackEvent fire twice?

Sorry, I should have been a bit clearer. What I mean is, onView should only be called once for a given banner instance, rather than say being called every time the banner comes into view.

Also, I think UserInputSuccessBannerNotification should be added to the list as it looks like the same problem could occur…

Thanks - the reason I didn’t spend time on checking the 2 user input notifications is because they will probably be removed as part of the Key Metrics Widget flow. But no harm in refactoring it together now for consistency.

Ah, right I didn’t know that. It’s probably worth doing now anyway, as you say for consistency, and just to be on the safe side.

On a separate note, all GA4 Banner and a few other notifications individually check if the trackEvent is fired and implement other hacks like checking ahead for dismissals. Maybe if this issue is implemented fully, another issue can be created to copy the pattern from this one to all other view_notification event calls?

Sounds good to me!

[techanvil]

Thanks @eugene-manuilov, good idea. I have moved the 3rd point to a note for the IB author as suggested 👍