> With the code here, I don't think we would ever emit an event if a user created an enrollment but never purchased -- which is probably useful to know. It's also unclear to me in that scenario when the "enroll" actually happened.

I see this as semantically different from the concept of "enrollment."  I would make the act of starting the purchase process a separate event.  I was hoping to make the enrollment event represent the moment at which the student is able to access the courseware (assuming it's published).

I'm a bit wary of exposing too many of our internal implementation details to the researcher / analyst when we emit very explicit events like this.  I like the idea of having "explicit" events (like this one) that have a very well defined meaning that we will work hard to keep constant over time, and "implicit" events that are very implementation specific and may change at any time (like our catch-all request logging middleware).  We have kicked around the idea of also adding a catch-all "model changed" post_save signal handler that would emit an event any time any model was updated in the database.

To be consistent, though, I should probably make an explicit "edx.course.enrollment.mode.changed" event that represents a mode change instead of overloading "edx.course.enrollment."