Analytics additions: tracking login step successes/fails

[g-opzt]

ACs

Add the following events.

• [ ] vama_user_call: Return the response code of the API call to the user endpoint in a param outcome

  • [ ] status_code: status code from the API return

• [ ] vama_login_token_get: Returns the response code of the request for access and refresh tokens on /token endpoint

  • [ ] status_code: status code returned from the /token endpoint

• [ ] vama_login_token_store: Return whether or not the app's attempt to store tokens in app storage succeeded

  • [ ] success: true if tokens stored (should be in the try statement), false if not (in the catch statement)

• [ ] vama_login_token_retrieve (check length): Return whether or not the the app's attempt to retrieve tokens in app storage

  • [ ] success: true if token retrieved, false if not

• [ ] vama_login_token_refresh: Return the response code of the call to the /refresh endpoint

  • [ ] status_code: status code returned from the /refresh endpoint

[g-opzt]

Moving this ticket back to me to redefine after discussion with FE made clear that we should use event logging instead of Crashlytics for this due to limitations of/appropriate use cases for Crashlytics.

[g-opzt]

Updates complete and moved back to handoff pipline. Question out to Narin on Slack to confirm some details.

[g-opzt]

This comment is just a reminder for me when it comes time to document these:

• We'll monitor the error of "SIS cannot authenticate the user" via datadog.
• We can't capture, "Device does not accept input biometrics to access secure storage."

[dumathane]

https://adhoc.slack.com/archives/C0212B872MT/p1688674703134599 'Greta Opzt narin Could you take a look at this revamped ticket for analytics on log-in fails that we discussed on handoff? My main uncertainty right now is not being sure what all can be returned in some of these situations. For example, the first event I've got listed is to "Return the results of the API call to the user endpoint in a param outcome." I think that would include capturing the case of a users's access and refresh tokens both being expired, but looking at the API endpiont docs, I can't tell that we would be able to differentiate that case. (edited) '

[narin]

@dumathane Greta and I chatted about this and decided we'll only be returning the response code for the API calls and whether or not the AsyncStorage calls were successful. Reworded the ticket to better reflect that.

[TKDickson]

@g-opzt @ajsarkar28 what's the relative timeline for this work? Super roughly, like "this quarter" or "not yet prioritized/dunno"

[g-opzt]

@TKDickson This is primarily a blocker to refining our retention understanding but there's no specific work planned, that I know of, to actually dig in on login issues from our team's side currently. It is blocking the dashboard for Login which was the top of Rachel's priority list for dashboards--but we also don't have any points planned for dashboard work this quarter. @ajsarkar28 this would be a good thing to surface with PMs/leadership for planning.

[TKDickson]

@g-opzt thank you for the clarification!

I know I'm preaching to the choir here, and want to have this on the ticket somewhere -- we still see login-related bug reports coming in from users that we can't replicate internally, so having more clear analytics (events firing to better track what's going on, how often this is occurring, etc) we're hoping could give us better insight on when and why those are happening (are the biometrics problems mostly because they're logging in less frequently than every 45 days, or something else?? etc)

[TKDickson]

Removing my autoassignment from this ticket; as an analytics event ticket, there's currently no way to test this before release.

[theodur]

The vama_login_token_retrieve event name is 1 character over the 24-character limit, so I had to shuffle some things around with the event names. I ended up renaming vama_login_token_retrieve to vama_login_token_get and renaming the original vama_login_token_get event to vama_login_token_fetch.

Appending fetch to the event name responsible for tracking the status codes from the /token should help signify that it's tracking fetching from the API rather than getting the token from async storage. Likewise with the vama_login_token_get event and async storage.

[theodur]

Also, it was mentioned in the ticket description, but the changes in my PR will only track status codes from failed API calls, since our API client doesn't return the status code for successful API calls.

[theodur]

The PR has been merged into develop. Since there's nothing for QA to test, this should be good to close