Complete Phase 1 of Mixpanel integration

[yaelberger-commits]

Complete Phase 1 of Mixpanel integration

Description

Proposed events to track:

• [X] Login
• [ ] Add a new service
• [ ] After clicking on a service name..
• [ ] Create a template
• [ ] Choose a template
• [ ] Send email

WHY are we building? Experiment with Mixpanel. Implement event tracking for approximately 5 events to see what is possible.

Context: Mixpanel implementation notes Draft Notify Metrics planning Original Issue

WHAT are we building? Mixpanel integration with GC Notify to track 5 events to collect metrics and web analytics inside our product once a user is authenticated

VALUE created by our solution So we can make more data informed decisions about our Product Backlog based on user needs and impact. For example, when we have needed to prioritize tasks like accessibility issues, it would be very helpful to have metrics for what the top tasks are in the GUI.

Acceptance Criteria** (Definition of done)

To be refined through discussion with the team

Given a GC Notify team member wants data on how Senders us the platform product, when they're logged in to Mixpanel, then they can see dashboards and reports of Sender usage of GC Notify, and they do not see any PII of non-federal public servants and GC Notify admin usage does not get included to skew the data.

Given that we have Mixpanel integrated and 5 events sent, when an event is triggered, then the event is recorded within the Mixpanel dashboard.

• [ ] Mixpanel API key and URL are kept as secrets within the .env encrypted files for both staging and production environments within the notification-manifests repository.
• [ ] Mixpanel is initialized within the Notify admin back-end, but only if the environment variable URL was defined in the environment.
• [ ] Mixpanel can send 5 events from the Notify admin and display those events in its dashboard.
• [ ] There are unit tests to make sure that the Mixpanel is called where it should be called.
• [ ] Suggestion: Mixpanel related events sending should be in its own module so we can easily manage these. For example, a login event might be triggered from the login code but would refer to a mixpanel.py module where potentially a send_login event would be reported.
• [ ] No collection of PII from non-federal public servants. No collection of Personally Identifiable Information, so we need to mask IDs for any non federal government employee email addresses https://docs.google.com/document/d/1EBUYJ3i0l0oQ-2NMXYe-fB3Ny_CcoAPdm88pLux2xlU/edit#heading=h.8gh1bt5pc4y0
• [ ] No tracking events for GC Notify Admin
• [ ] Privacy considerations
• [ ] Security controls in place

[yaelberger-commits]

Decided to icebox until we have the resources to further integrate Mixpanel