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.
...
Oscar ships with an Analytics app used to gather data on 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).If necessary, we
Extending Oscar's Analytics with Signals
We can extend Oscar's Analytics app existing analytics functionality by extending existing receivers or adding new receivers and/or new signals and receivers. For . 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 new order is placedproduct is added to a user's basket, we could extend the existing order_placed receiver to do this, or create a new receiver which listens to the same signal and communicates with Google Analytics.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 | Refunded Order |
This information constitutes business intelligence (BI). As such, it is not researcher-facing, 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.