...
- Wish list for event tracking from microfrontends:
- All events sent to Segment using (wrapped) Segment calls. Gives additional benefits of resilient JS code (e.g. trackLink and trackForm).
- Note: for Tracking Log events, both the front-end code is not resilient, and it relies on calling LMS which is not the most reliable option.
- Ideally, all events sent to reliable Destination to not lose events (e.g. AWS Bucket).
- Processing could be handled async on server.
- Could handle adding user_id given username (e.g. for Profile API).
- Need a way to indicate stability of event.
- Versioned? Other indicator? Available to GA as well?
- Can/should solution be kept out of the name (e.g. "edx.bi"), or should the version be part of the name?
- Using RAPID, who are all the I's for event design at this point, including potential for refactoring legacy events?
- Need a way to configure to where an event should be sent, including tracking logs and GA.
- Simplified defaults and decision making around this?
- Special considerations for GA? Send from backend processor back to Segment and on to GA? Different GA properties?
- Front-end consistent naming needed. Use Segment names? Tracking log names? Other? See code comment.
- Bill DeRusha (Deactivated) has additional thoughts that require a conversation.
- All events sent to Segment using (wrapped) Segment calls. Gives additional benefits of resilient JS code (e.g. trackLink and trackForm).
QA for Events and Configuration
| Note |
|---|
It would be great to find ways to make this simpler. Here is an example testplan for the Profile microfrontend events. |
- Each new microfrontend requires a new Segment source, and likely a Segment destination for GA and S3.
- GA testing should review real-time events in GA. In Production, this probably needs a Category for the search in order to find the event.
- S3 setup doesn't have a good process defined, since Data Engineering needs to both whitelist and verify. There may need to be a ticketing system for this so one can know that it was properly completed.
- Events sent to the LMS Event API can be tested in one of two ways:
- For whitelisted events that are sent to LMS Segment, you can use the Segment Debugger.
- For events that are not sent to LMS Segment, only Data Engineering or Devops can test by reviewing splunk4tracking. Other engineers are not allowed access.
- One needs to test setup once per microfrontend in every environment to know if all is well (Segment Stage, Prod, possibly Edge).
- For whitelisted events, one needs to test each event for each environment.
- Note: it would be great if the defaults minimized this type of testing.