...
Sending events to the (LMS) Tracking Log
| Note |
|---|
See "Consolidating Event Tracking" section first. This section is older. |
Microfrontends (e.g. User Account with Profile):
- Ideally, the frontend could send all events to Segment, and everything else (including the tracking log), would be handled downstream.
- We will probably may need a way to bypass tracking log, which might just be "edx.bi.*" events.
- Events need to go to GA.
- Would any events ever not go to GA?
- How do we determine GA property(ies) to send to? For example, the legacy profile page event went to the LMS GA property. I assume that means we want this same event, "refactored" to the microfrontend, to go to the LMS GA property. Would that mean that all future events from the same microfrontend would also go to this GA property?
- Does it make sense to reuse /segmentio/event, or do we need a 3rd endpoint (see additional questions below)?
- Answer: No.
- The Profile page has a legacy tracking log event which is basically a glorified page view with additional metadata.
- Is there a better way to handle these more generally through page events?
- How would one determine what page events they would or would not want to go to the tracking log? Is there a reason we wouldn't want to send these to the tracking log?
Questions related to /segmentio/event as it might pertain to the microfrontend use case:
- What is prod config of TRACKING_SEGMENTIO_ALLOWED_TYPES. "track" only?
- What is prod config of TRACKING_SEGMENTIO_DISALLOWED_SUBSTRING_NAMES?
- What is prod config of TRACKING_SEGMENTIO_SOURCE_MAP? How could this work for microfrontends?
- Why not use "event" as a backup for "name"?
- A call to analytics.track would set userId as required. Correct?
- The final call to tracker.emit sends this to the event log + optionally segment? Or is the segment call elsewhere?
...
Consolidating Event Tracking
- 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).
- 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?
- 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.