BUG - Sev 3 - All - Rx refill analytics not working

[g-opzt]

What happened?

Ticket #5700 was to add analytics to log events around refill actions and was released in version 2.5. Upon checking what's coming in from analytics that version and forward, I see that:

• The parameter rx_ids isn't showing up on these events that I've checked so far: 'vama_rx_request_start','vama_rx_refill_fail','vama_rx_refill_success'.
• I am also getting a greater count of successes than I am starts. I'm thinking this is due to use of the global refill option (where 1 click would be several API calls -- one for each Rx id) but I can't confirm that with out the ids piece mentioned above.

Specs:

Steps to Reproduce

Ideally we would work #6363 to be able to test this.

Desired behavior

See original ticket #5700

Acceptance Criteria

Analytics operate as described in original ticket #5700

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See [Bug Tracking](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/QA#issue-severity) for details on severity levels

• Impact: Low
• Frequency: Low

• 3 - Low

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

• [ ] Steps to reproduce are defined
• [ ] Desired behavior is added
• [ ] Labels added (front-end, back-end, relevant feature, accessibility, etc)
• [ ] Estimate of 1 added (for front-end tickets)
• [ ] Added either to the relevant feature epic (if found during new feature implementation), or the bug epic

[Sparowhawk]

@g-opzt Luckily when in terminal I can see what is being called until we work the other ticket. I just went to demo mode and clicked a couple of prescriptions and went through the process:

logging analytics event vama_rx_request_start {"rx_ids": ["21142579", "21142592"]} logging analytics event vama_rx_request_confirm {"rx_ids": ["21142579", "21142592"]} logging analytics event vama_rx_refill_success {"rx_ids": ["21142579", "21142592"]}

So this should be working properly according to the documentation that the array is being passed correctly.

As for why you see more successes than starts that shouldn't happen because we only call the api once per array of strings. This might be occurring because I think this was updated to an array after the analytic was in place. So for people using old versions of the app with prescriptions it would call the api multiple times and result in multiple successes.

[g-opzt]

Thanks, @Sparowhawk. Assigning to myself to review. I will reach out if the array change you described doesn't clear this all up but it makes sense to me.

[g-opzt]

Noting this was moved to Blocked due to BigQuery access problems.

[g-opzt]

Per conversation with team leadership I will continue to not run any additional queries beyond what the existing dashboard queries are pulling so that we can monitor the impact of the dashboards alone more easily. I will be OOO until Oct. 17-22 so we will revisit the status of this blocker on Monday, Oct. 23.

[g-opzt]

No longer blocked, moving to backlog as this is not a priority at the moment.

[bischoffa]

@g-opzt is this okay to pull in next sprint for bug work?

[alexandec]

Based on local console output, the rx_ids parameter is being passed correctly:

logging analytics event vama_rx_request_start {"rx_ids": ["21142579", "21142592", "21142625", "21142586", "21142588", "21142590", "21142589", "21142591", "21142594", "21142627"]}
logging analytics event vama_rx_request_confirm {"rx_ids": ["21142579", "21142592", "21142625", "21142586", "21142588", "21142590", "21142589", "21142591", "21142594", "21142627"]}
logging analytics event vama_rx_refill_success {"rx_ids": ["21142579", "21142592", "21142625", "21142586", "21142588", "21142590", "21142589", "21142591", "21142594", "21142627"]}

The local analytics console logging has proven very reliable in the past as an indication that events are being sent correctly. If the rx_ids aren't showing up in the analytics data, my guess is the issue is happening somewhere on the analytics side, not in the app.

This is the only event where we send a list of data. I checked the React Native Firebase docs and it looks like we are sending the list in the correct format: https://rnfirebase.io/analytics/usage#custom-events. Maybe there's some kind of configuration on the other end that needs to be modified?

One thing an analytics person could check is whether the vama_rx_details event is appearing correctly. It looks like:

vama_rx_details  {"rx_id": "21142610"}

If sending a single ID works but not a list of IDs, that could be a starting point to investigate the analytics configuration. I don't think there's any further investigation to do on the app side of things.

[alexandec]

I'll increase the estimate and move this back to the backlog.

[Sparowhawk]

@ala-yna I am not sure who handles analytics now for the app, as it looks like a dashboard issue on firebase, not an app issue

[Sparowhawk]

@bischoffa is this workable/still an issue?

[bischoffa]

@Sparowhawk I would ask the Health & Benefits team if this is still an issue. From what I have heard from QA there are issues with analytics not working. Given its specifically RX I would not be the one to answer that. Looks like @ala-yna was asked last month.

[Sparowhawk]

@OVezeamama I believe you handle analytics. cc: @ala-yna @bischoffa

Taking a look further we log the analytics correctly according to the documentation from firebase. I do show that it says that the arrays are logged in the analytics console. So it might be in the analytics dashboard > view more in google analytics button. I don't have access to that portion of firebase so I cannot confirm. The "Events" dashboard likely doesn't support arrays of data, but I suspect the path mentioned before does.

[timwright12]

@OVezeamama ping on @Sparowhawk's comment from May. Looks like this is blocking some other work.

[OVezeamama]

@Sparowhawk I'll take a look again to see if the problem still exist and if it doesn't I'll close the ticket.