feat: migrate from mixpanel to segment #1005
Conversation
utils/eventtracking.js
Outdated
| const id = getMixpanelID(shellSettings); | ||
| await mixpanel.people.increment(id, 'deployed_contracts'); | ||
| const id = getSegmentID(shellSettings); | ||
| // TODO: find a way to increment a Segment analytic property |
There was a problem hiding this comment.
It seems like there is no persistent analytic properties in segment (or at least a direct replacement). Not sure how much we care about the total amount of deployed contracts as a stored number vs aggregating them by deployed events.
| @@ -48,19 +50,20 @@ const track = async (eventType, eventProperties, options) => { | |||
| return; | |||
| } | |||
|
|
|||
| if (shouldTrackID(shellSettings)) { | |||
| if (options.accountId && shouldTrackID(shellSettings)) { | |||
There was a problem hiding this comment.
@itegulov is this change intended?
I think users can avoid tracking even if they do not pass any accountId in command.
There was a problem hiding this comment.
Yes, previousId is a non-optional field in Segment, so it was throwing runtime errors without this check
utils/eventtracking.js
Outdated
| const id = getMixpanelID(shellSettings); | ||
| await mixpanel.people.increment(id, 'deployed_contracts'); | ||
| const id = getSegmentID(shellSettings); | ||
| // TODO: find a way to increment a Segment analytic property |
There was a problem hiding this comment.
@itegulov are you planning to work on it now?
Deployed contracts are the most important part of analytics IMO.
There was a problem hiding this comment.
I have spent some time looking for alternatives to no avail, so I think it would make sense to hear @TiffanyGYJ's opinion first before spending even more time on this
There was a problem hiding this comment.
Deployed contracts are the most important part of analytics IMO.
Curious to hear your reasoning. Wouldn't aggregating deployed events achieve the same goal? Do we need to store/cache this as a definite number for something?
There was a problem hiding this comment.
Deployed events might happen multiple times with different contracts, so that might not be an accurate estimate on how many unique contracts each dev deployed.
Is there a way we can track that somewhere else or finding a way from Segment/Mixpanel is the best option?
There was a problem hiding this comment.
Deployed events might happen multiple times with different contracts, so that might not be an accurate estimate on how many unique contracts each dev deployed.
Looking through the code, the current logic does not track unique deployed contracts either, just the number of times when devDeploy/deploy were executed successfully.
There was a problem hiding this comment.
I think that the total number of deploys per week is the most important metric since we are tracking developer activity.
The number of active contracts (contracts that have been deployed or redeployed in the past week) is also important.
Tracking a particular user and his deploys is not that important IMO, and a bit shady.
There was a problem hiding this comment.
I think that the total number of deploys per week is the most important metric since we are tracking developer activity. The number of active contracts (contracts that have been deployed or redeployed in the past week) is also important.
I agree with this, but a per-user counter does not really help with that, no? Increments do not have a timestamp, so you would have to track how much a counter has changed each week which kind of beats its point. I think we can deduce all that information just from tracking events (by writing a small custom event consumer or building something in Segment itself, not sure if it provides any processing logic).
Tracking a particular user and his deploys is not that important IMO, and a bit shady.
👍
|
I have deleted the deployed contract tracking, so I think this PR is ready for a review CC @volovyk-s @TiffanyGYJ |
No description provided.