Refactor GA tracking events for module settings

This issue introduces new general GA events around module settings (related: #4004).

---

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

Acceptance criteria

• All of the event categories mentioned below should technically rely on the VIEW_CONTEXT_* constants for their first name segment (i.e. don’t hardcode “dashboard” but use the constant instead).
• The following new GA events should be fired in the Settings > Connected services tab, for all modules (event category: settings_module-list, event label: the respective module slug):
  • view_module_settings whenever the user expands a module’s settings panel.
  • close_module_settings whenever the user collapses a module’s settings panel.
  • edit_module_settings whenever the user clicks on the “Edit” button within a module’s settings panel.
  • update_module_settings whenever a module’s settings have been successfully updated (via the handleConfirm callback within the module’s settings panel’s Footer).
  • cancel_module_settings whenever the user cancels out of the “Edit” mode explicitly via the “Cancel” (or “Close”) button within the module settings panel’s Footer.

Implementation Brief

• In assets/js/components/settings/SettingsActiveModule/Header.js:
  • Add a new callback that calls trackEvent( '${ VIEW_CONTEXT_SETTINGS }_module-list', 'view_module_settings', slug ) if isOpen is false. Otherwise it should call trackEvent( '${ VIEW_CONTEXT_SETTINGS }_module-list', 'close_module_settings', slug ).
  • Add the new callback to the onClick property of the Link element.
• In assets/js/components/settings/SettingsActiveModule/Footer.js:
  • Add a new callback handleEdit that calls trackEvent( '${ VIEW_CONTEXT_SETTINGS }_module-list', 'edit_module_settings', slug ).
  • Add the handleEdit callback to the onClick property of the Edit link.
  • Update the handleConfirm callback to call trackEvent( '${ VIEW_CONTEXT_SETTINGS }_module-list', 'update_module_settings', slug ) when settigns are saved successfully.
  • Update the handleClose callback to call trackEvent( '${ VIEW_CONTEXT_SETTINGS }_module-list', 'cancel_module_settings', slug ).

Test Coverage

• N/A

Visual Regression Changes

• N/A

QA Brief

• Install the Google Analytics Debugger extension for your Google Chrome if you haven’t done it yet.
• Verify that events mentioned in AC are triggered correctly.

Changelog entry

• N/A

[felixarntz]

@wpdarren The cancel_module_settings should indeed happen on either the “Close” or “Cancel” button (which technically do almost the same thing, it’s just that the label is different for modules where there are no settings. So it looks like that indeed needs to be fixed @kuasha420

I couldn’t see it in the AC but should I expect to see events when I disconnect a module within the ‘Connected Services’ tab. When I click to disconnect I see settings_module-list and deactivate_module Is this correct? Just wondering if it should be deactivate_module_settings

This is correct as is. All the *_module_settings events are to compare interactions in the UI, whereas the deactivate_module event is more focused on seeing from where and how often people deactivate modules.

[wpdarren]

QA Update: ✅

Verified:

settings_module-list, event label appears on all: view_module_settings whenever the user expands a module’s settings panel. close_module_settings whenever the user collapses a module’s settings panel. edit_module_settings whenever the user clicks on the “Edit” button within a module’s settings panel. update_module_settings whenever a module’s settings have been successfully updated cancel_module_settings whenever the user cancels out of the “Cancel” and “Close” button.