Analytics Eventing Hooks
- Renzo Lucioni (Deactivated)
We'd like to gather data on important operations occurring within our e-commerce infrastructure. In order to do so, we need to identify an appropriate set of analytics events to collect, as well as the locations at which these events should be emitted.
Analytics Overview
We emit several different kinds of events from a variety of places in our system. BI events are emitted from the e-commerce front end to track users' progress through and interaction with the payment and verification UI. Tracking log events are emitted by edx-platform when the enrollment API performs enrollment actions. We're now going to want to collect data on products and orders from Oscar.
Oscar's Analytics App
Oscar ships with an Analytics app used to gather data about products and users. It does this by leveraging Django's signal dispatcher, listening for signals from other apps and using these signals as cues to create and update models which aggregate data on product views, user searches, basket additions, and the placing of orders. The Analytics app also includes a reporting module capable of generating CSV and HTML reports on product performance (e.g., views, basket additions, purchases, by product) and user behavior (e.g., product views, basket additions, orders, total spent, date of last order, by user).
Extending Oscar's Analytics with Signals
We can extend Oscar's existing analytics functionality by extending existing receivers or adding new receivers and/or new signals. Oscar includes a variety of signals which, in combination with custom receivers, we can use as hooks to emit analytics events. For example, if we want to send an event to Google Analytics whenever a product is added to a user's basket, we could add a receiver which listens for the `basket_addition` signal and communicates with Google Analytics accordingly.
The following signals could be paired with Segment's e-commerce API to emit events of interest to marketing.
| Signal | Corresponding Segment e-commerce API Event, if any |
|---|---|
| basket_addition | Added Product |
| voucher_addition | None (custom: edx.bi.ecommerce.voucher_applied) |
| start_checkout | Started Order |
| pre_payment | None (custom: edx.bi.ecommerce.to_payment_processor) |
| post_payment | None (custom: edx.bi.ecommerce.payment_completed) |
| order_placed | None (custom: edx.bi.ecommerce.order_created) |
| post_checkout | Completed Order |
| refunded_order (custom signal) | Refunded Order |
This information constitutes business intelligence (BI). As such, it is not researcher-facing and does not need to be included in our tracking logs. However, victorR (Deactivated) thinks we could benefit from including this information in the tracking logs, for debugging purposes.
A few of these events (e.g., edx.bi.ecommerce.to_payment_processor) may duplicate events emitted client-side by the e-commerce frontend. When we implement these events on the backend, we should be pay close attention to the events emitted by the frontend, and in the case of duplicated events, favor the backend version.
Finally, these events could be complemented by a set of new events outside of the ecommerce service. For example, events like "Viewed Product Details" and "Clicked Product" could be emitted when users view course about pages and click course cards. Events like "Viewed Promotion" could be used when marketing uses special means (e.g., a dedicated page) to advertise certain products.
A Note About Enrollments
Orders for enrollments are fulfilled by the enrollment API, not Oscar. As such, it's not appropriate to emit events related specifically to enrollment from within Oscar. These kinds of events (e.g., edx.course.enrollment.enrollment.activated, edx.course.enrollment.enrollment.deactivated, edx.course.enrollment.enrollment.mode_changed, edx.course.enrollment.upgrade.succeeded) are emitted from within edx-platform.