feat(analytics): add tools event tracking and shared event constants#664
feat(analytics): add tools event tracking and shared event constants#664kjmitchelljr wants to merge 11 commits intomainfrom
Conversation
Deployment results
Logs #24726480127 |
There was a problem hiding this comment.
Consider creating a map (like object) of event name and its expected custom event data (can be undefined/never).
Then instead of exporting each constant, we just let our frontend analytics lib know the possible events, and when we call trackEvent, it'll be correctly typed (and we get to keep all events info in one place too).
Like:
type Events = {
eventA: undefined,
eventB: { tool: ToolName, walletProvider: string }
}Also instead of shared package, start by adding it in frontend only (where do you expect frontend event map to be used for it to be a shared package?)
Can do. I don't expect frontend event map to be used, but based on the doc I know I'll be soon adding events in CDN and API as well. The thinking was to have it shared across there, however could keep it all separate. |
|
Given CDN & frontend won't be sharing event names (like CDN ones will have a prefix for sure), I don't think they need to be in a shared package. I'm not sure we need Umami events in API - we've different kind of technical instrumentation there from Cloudflare already; and as CDN/embed is calling the API, we'll have user-facing events from embeds, not "API called" events. |
Are you suggesting we shouldn’t use Umami in the API for things like tool_embed_render? If so, that could mean our events are no longer in one place dashboard. |
@sidvishnoi I was basing this off the doc where it mentions Count GET /profile{tool} on /api module per what Darian was saying above. Could you help me understand? |
|
Can we discuss tracking the API when we come to it, and here focus on the frontend? |
| trackEvent('script_generated', { | ||
| tool: toolState.currentToolType, | ||
| }) | ||
| openDialog(<ScriptDialog wallet={wallet} />) | ||
| } else { | ||
| trackEvent('profile_saved', { |
There was a problem hiding this comment.
Do we need two separate events for this? What if we pass an action in event data to tell whether it was save or script?
| const validatedPointer = await validateAndConfirmPointer(pointerInput) | ||
| setParsedLinkTag(htmlEncodePointer(validatedPointer)) | ||
| setShowCodeBox(true) | ||
| trackEvent('generated_tag', { tag_type: 'link_tag' }) |
There was a problem hiding this comment.
Can we use the same save /submit event here from other tools and pass tool: "link_tag" with it?
| if (result.success) { | ||
| actions.commitProfile() | ||
|
|
||
| trackEvent('settings_changed', { |
There was a problem hiding this comment.
Let's remove this event for now - this one here is fired even if settings aren't changed.
3 participants
PR Description
Focuses on
TOOLS_EVENTScoverage for issue#663What's changed
tools_*tracking for:link_tag)Notes
tools_settings_changedcurrently fires on successful save pathssettings_changed- in this PR do we want to track the fields the user changed for the profile?Apart of #625