Add analytics
Closed this issue · 5 comments
The CLI should fire analytics when
- The CLI launches (maybe record OS information here as well)
- The CLI finishes (selection, error/success etc)
- When the CLI exits because of an error
- When the user force kills the CLI process
The frontend boilerplate applications should also fire an analytics event when the user logs in (views the home page)
If there is a way to get a unique identifier for the device do that, or we generate a random UUID on launch
To take one step back, the purpose of the analytics is for us to see:
- How many people are trying the CLI tool (CLI Launch)
- How many of those successfully download an example - i.e. pick a recipe and tech stack (CLI finishes)
- How many of those that download an example, run the app (open signup page) and create accounts (home page)
1 minus 2 = people that were unsuccessful (failure). Some of those that failed will be because this wasnt what they expected / they dont want to do this. Some of the failure will be because the CLI exits because of an error (which is why that is good to measure to know how much of failure is error driven vs human driven)
Why do we need " When the user force kills the CLI process"? What does that tell us.
Why do we need " When the user force kills the CLI process"? What does that tell us.
The thought process here was to know if people used the CLI but did not complete it (either by errors or exiting early)
So if
- How many people are trying the CLI tool (CLI Launch)
- How many of those successfully download an example - i.e. pick a recipe and tech stack (CLI finishes)
- How many of those that download an example, run the app (open signup page) and create accounts (home page)
- When the CLI exits because of an error
- When the user force kills the CLI process
Then:
1 minus 2 = 4 + 5 ?
What all will 5 be able to measure? For eg; if you close the terminal, this event wont fire right? or like if you control+C, will this event still fire?
There is a way to run some code when the script is killed with control + c, that information probably wont be super important but if the number is high it could mean people use the tool but dont finish it because
- They decided to do it later (less likely if they already went ahead and ran the command)
- They didnt find their tech stack in the list
If the number is high enough it could imply we need to add more boilerplates to the CLI.
Events added
When the CLI starts
{
eventName: "cli_started";
}
When the CLI finishes without errors
{
eventName: "cli_completed";
frontend: string; // react, angular etc
backend: string; // node, python etc
}
When the CLI finishes with errors
{
eventName: "cli_failed";
frontend: string; // react, angular etc
backend: string; // node, python etc
error: string; // The message of the error (useful to fixing issues or identifying points of failures)
}
NOTE: We did not add an event for manually aborting (ctr + c), after thinking about it the event does not actually add much value