At a bare minimum, we should be able to get the following metrics for our projects for users that haven't opted-in to collecting the full set of metrics supported by Countly

1. Weekly/daily/monthly active users
   • see Discussion: Metrics normalization  #128
2. web-vitals (where appropriate) - https://www.npmjs.com/package/web-vitals
3. download counts (where appropriate)
4. pageviews
5. session time

Disclaimer

Note that until this, #130, and https://discuss.ipfs.tech/t/ipfs-gui-metrics-changes-in-progress/15695 have been available to the community for feedback for enough time( see ipfs-shipyard/ignite-metrics#2), we will continue with the implementation we currently have in public-gateway-checker:

• metrics implementation was already merged (feat: add countly metrics public-gateway-checker#309), but it's not opt-out yet. I.e. until you accept/decline, no metrics are sent. see feat: switch to opt-out metrics ipfs-shipyard/ignite-metrics#2

Current problems with metrics

See https://pl-strflt.notion.site/Telemetry-b005d4f217f44db3986902c67d922cf4

Current planned solution

https://www.notion.so/pl-strflt/Telemetry-b005d4f217f44db3986902c67d922cf4#0833d8c86b4f4ffc99337305159d27b0

Metrics distinctions

minimal metrics will be 'sessions' and 'views' as categorized by countly (i.e. const minimalFeatures = ['sessions', 'views']). See #130 for more information

Minimal Metrics (opt-out)

We will allow the disabling of minimal features once we switch to opt-out metrics. See ipfs-shipyard/ignite-metrics#2

• sessions - tracks when, how often, and how long users use your website
• views - allows for the views/pages accessed by a user to be tracked
  • Note that these view metrics are "App views" and not page URL (i.e. public/private gateway access views that include CID)

All Metrics (opt-in)

Note that while these are opt-in, when presented with our cookie banner/modal for the first time (see ipfs/public-gateway-checker#340 (comment)), the checkbox will be enabled for "all" metrics. Closing the banner without other actions will update your consent from "minimal" to "all".

• events - allows your events to be sent to the server
• scrolls - allows a user’s scrolls to be tracked on the heatmap
• clicks - allows a user’s clicks and link clicks to be tracked on the heatmap
• forms - allows a user’s form submissions to be tracked
• crashes - allows JavaScript errors to be tracked
• attribution - allows the campaign from which a user came to be tracked
• users - allows user information, including custom properties, to be collected/provided
• star-rating - allows user rating and feedback tracking through rating widgets
• feedback - allows survey, nps rating and feedback tracking through feedback widgets
• apm - allows performance tracking of application by recording traces
• location - allows a user’s location (country, city area) to be recorded

Current planned solution

Describe alternatives you've considered

General

1. Not collecting metrics
   • Not viable due to the need to prioritize efforts to satisfy customer needs.
2. Opt-in only metrics (i.e. only send metrics when users consent)
   • Having opt-in-only metrics is not giving us the full picture. See Current problems with metrics above.

IPFS-companion

1. Using only firefox & chrome store metrics
   • This is no longer viable, as we have no way to normalize these metrics with our other projects' metrics.

Child tasks

• Create post on discuss.ipfs.tech to let the community know and give a chance for community feedback
• Provide example snippet of data sent to our countly.ipfs.io endpoint for necessary features #130
• consolidate metrics plan and all discussions in a single public notion document #131

I'm proposing the following settings for countly metrics for our projects:

  /**
   * @see https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript-#features-for-consent
   */
  const minimalFeatures = ['sessions', 'views']
  const marketingFeatures = ['attribution', 'users', 'location']
  const performanceFeatures = ['events', 'crashes', 'apm']
  const trackingFeatures = ['scrolls', 'clicks', 'forms', 'star-rating', 'feedback']

  Countly.group_features({
    all: [...minimalFeatures, ...marketingFeatures, ...performanceFeatures, ...trackingFeatures],
    minimal: minimalFeatures,
    marketing: marketingFeatures,
    tracking: trackingFeatures,
    performance: performanceFeatures
  })

Note that from the above list, 2(web-vitals) is not provided by default from countly, and without events in the performanceFeatures group from the above code snippet, we cannot submit custom events/metrics/analytics. However, if we enable events for "minimal" metrics, it's possible that at some point in the future, a custom metric could be sent that does not adhere to our groupings and opt-in ethics. Therefore, 2(web-vitals) above will be considered an opt-in metric only to keep our minimal metrics light.

However, we can use countly's trackView event in order to track page views without exposing the full blown "events" functionality to limit user risk.