Closed samajammin closed 4 years ago
@samajammin https://github.com/SuperblocksHQ/ethereum-studio/pull/266 there is a new PR for this!
Seems to be working just fine, but I have one question for you:
Do we really want a template
prop for OUTBOUND_LINK_CLICK
event? I dont really understand the point of having it there as we only care about what link was clicked, not from which template the click came from, would love to hear your insight!
@lovrobiljeskovic excellent!
Do we really want a template prop for OUTBOUND_LINK_CLICK event? I dont really understand the point of having it there as we only care about what link was clicked, not from which template the click came from
Yes I do believe the template
prop on OUTBOUND_LINK_CLICK
would be useful. The reasoning is that I actually do care which template the click came from for the cases where we link to the same resource from multiple templates. For example, at the bottom of every README, we link to a resource on how to set up a local development environment. It'd be useful to know at which point (i.e. which template) the user is taking that step. Are they doing that straight from the Hello World template? Or are they first moving on to the subsequent templates before making that jump? Knowing the data on this may influence how we guide users through the product.
Summary
Currently we track the following events:
APP_START
NEW_PROJECT_SELECT_TEMPLATE
CREATE_PROJECT_FROM_TEMPLATE
w/template
propCONTRACT_DEPLOYED
w/environment
propSAVE_PREFERENCES
Let's add the following:
template
prop to the existingCONTRACT_DEPLOYED
eventSEND_TRANSACTION
eventtemplate
prop &status
prop (to indicatesuccess
/fail
of tx)OUTBOUND_LINK_CLICK
template
prop &URL
prop (URL that the user clicked)Motivation
This will help give us more complete insight into the user funnel. An ideal user "happy path" being a session where the user:
CREATE_PROJECT_FROM_TEMPLATE
)CONTRACT_DEPLOYED
)SEND_TRANSACTION
)OUTBOUND_LINK_CLICK
of a README's "next steps")Tracking the
template
prop across each funnel will allow us to compare engagement across templates & to make improvements accordingly.Tracking the
status
prop of transactions may allow us to debug issues that users have (if many of their txs fail).Describe alternatives you've considered
None
Additional context
How we plan to think about product KPIs moving forward:
Count of unique visitors
Count of unique projects created
Count of contracts deployed
Count of transactions w/ deployed contract
Count of transitions to more advanced tooling (currently unknown)
Average session length
The hope is that establishing these metrics will help guide decisions around product features & prioritization.