We need more of the identify() at 3 key points: registration/signup, login. and app open/foreground(if users can re-open the app in a logged in state)
Comments by Rishi Patel from the MixPanel team.
If you already have identify() calls placed in the correct areas of your implementation then there shouldn't be any changes needed. In general we recommend calling identify() at 3 key points: registration/signup, login. and app open/foreground(if users can re-open the app in a logged in state). This also all depends on your identity management set up but ultimately you want to make the call at the point where you want to assign an anonymous user your own internal identifier.
Scenario
No response
Design
No response
Technical Details
No response
Threat Modeling Framework
No response
Acceptance Criteria
No response
Stakeholder review needed before the work gets merged
[ ] Engineering (needed in most cases)
[ ] Design
[ ] Product
[ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
What is this about?
TBD
We need more of the identify() at 3 key points: registration/signup, login. and app open/foreground(if users can re-open the app in a logged in state)
Comments by Rishi Patel from the MixPanel team.
If you already have identify() calls placed in the correct areas of your implementation then there shouldn't be any changes needed. In general we recommend calling identify() at 3 key points: registration/signup, login. and app open/foreground(if users can re-open the app in a logged in state). This also all depends on your identity management set up but ultimately you want to make the call at the point where you want to assign an anonymous user your own internal identifier.
Scenario
No response
Design
No response
Technical Details
No response
Threat Modeling Framework
No response
Acceptance Criteria
No response
Stakeholder review needed before the work gets merged
References
No response