[Suggestion] Combine + structure `copy` events

[ambergristle]

tracking copy features as 1) named/categorized parameters, 2) in a single event, seems more ergonomic from an analytics perspective.

1. by categorizing feature flags, we make it easier to directly compare feature choices, and to do more complex analytics (e.g., "how often is ui framework X paired with data fetcher Y?")
2. tracking as a single event makes it easier to use the events for conversion metrics (e.g., how often do page views or feature choices lead to copy events?)

parameter-level reporting is automatic with both umami and google analytics, so we don't lose any resolution on which features are most popular.

we also limit the number of network calls to 1.

proposal

instead of generating an id and iteratively calling track, the track helper would group feature flags by category, and call globalThis.zaraz?.track once (with most params optional).

i think it's also worth using a more-specific event name, as there may be other copy events to track in the future (e.g., starter code snippets).

globalThis.zaraz?.track('copy_cmd', {
  package_manager,
  is_preset, // could be interesting, but maybe tracking button clicks as part of a funnel is better
  ui_framework,
  css,
  components,
  auth,
  fetching,
  server,
  database,
  hosting,
  linter,
  analytics,
  errorTracking,
  tooling,
});

considerations

this is effectively a breaking schema change. however,

• copy is being tracked in a bati-specific analytics account, and migrating that data to the vike analytics is non-trivial
  • so from a vike analytics perspective, we're starting from scratch anyways
  • if/when we do migrate historical data, we could theoretically recombine into single events using interactionid

i don't think there will be a better time to make this change, and i expect that it will be impactful in clarifying vike conversion rates.

in the long term, there's also an argument to be made for switching the vike site to umami. it's much easier to access/view the same data in umami, and the data ownership/export situation looks better. in a week or two, i think we'll have enough telefunc data in umami to get a feel for whether it will work for telefunc (or vike).

• it's not clear whether we can use umami with zaraz. there is an option for a custom http proxy, and managed components may be a solution, but there's no preconfigured integration.
• if vike is going to keep using google analytics, setting up consent + data retention is required