Open edX Aspects analytics: when a self-hosted team needs it and why it is harder than it looks
A self-hosted Open edX team usually needs Aspects when instructors and administrators can no longer answer basic questions from the LMS alone: which learners are stuck on which units, how far a cohort has progressed, and whether a course is working. Aspects is the analytics layer for that job. The event-routing-backends plugin captures tracking logs from the platform and converts them into xAPI statements. Ralph or Vector then receives those statements and stores them in a ClickHouse database, and Superset presents them as dashboards. The reporting question is therefore not answered by one component. It depends on every link in that chain working and staying in step.
That chain is why the work is harder than it looks. Each piece has its own configuration, its own service to run and its own failure modes: the LMS must emit the events, the routing plugin must map them correctly, the store must accept and retain them, and the dashboards must query them without errors. A change in the LMS can alter the events that the routing plugin expects, and a change in the plugin can alter what ends up in ClickHouse. Teams should plan for Aspects as a set of coupled services rather than as a single add-on, and should ask any partner to name every component and its owner before work begins.
Version coupling is the constraint that most affects planning. Open edX states that the latest named release is the only supported release and that it cannot support more than one release at a time. The current named release is Verawood, published on 30 July 2026. Because the analytics pipeline must be upgraded together with the LMS, a platform upgrade is also a test of the event contract, the plugin version and the dashboard definitions. A team that upgrades the LMS first and the analytics later may find that reports silently stop matching the data. Confirm with the Aspects documentation which plugin and Superset versions are compatible with the Open edX release you run, and treat that compatibility check as part of every upgrade.
Before committing to Aspects, decide who will read the reports and what questions they must answer. Course teams may need progress by unit, administrators may need enrolment and completion trends, and both may need exports for their own records. Each question determines which events must be captured, how long they must be kept and who may see them. Learner data is personal data, so access controls on Superset, retention rules in ClickHouse and the legal basis for processing should be agreed with your data protection owner before the first dashboard is built. Ask the implementation partner to show where each of these controls is configured.
Finally, plan for operations after go-live. The pipeline needs monitoring for dropped or malformed events, capacity planning for ClickHouse storage as enrolments grow, and a tested restore path for analytics data. Ask for the sizing assumptions behind any quote, including expected event volume and retention period, and confirm which of these items are included in fixed scope and which are recurring support. Those answers will show whether Aspects fits your team's operating model or whether it needs more people than you have.
Which components make up the Aspects analytics pipeline
Aspects analytics runs as a chain: the LMS emits tracking logs, a plugin converts them to xAPI statements, an intake layer routes them into storage, and dashboards read from that storage. Each link has a different owner and a different version dependency, so the team should map every component to its owner before any build starts.
LMS tracking logs
The LMS writes learner activity, such as video views, problem attempts and page navigation, to tracking logs. These logs are the raw source for every Aspects report, so their content and volume set the upstream data for the whole pipeline. Your platform team owns the LMS configuration that enables and retains these logs. Confirm in the Aspects documentation which tracking events your Open edX release emits and how they are structured before you design any custom report.
Event-routing-backends xAPI conversion
The event-routing-backends plugin reads tracking logs and converts them into xAPI statements, the format Aspects stores and reports on. This conversion step is where event meaning is set, so mapping errors here appear as wrong or missing numbers on dashboards. Your team owns the plugin version, its settings and any custom event mappings you add. Confirm that the plugin version matches your Open edX release and Tutor version in the Aspects documentation.
Ralph or Vector event intake and routing
Ralph or Vector receives xAPI statements from the conversion step and routes them into ClickHouse. This layer decides throughput, buffering and what happens when storage is slow or unavailable, which makes it the main point of failure for data freshness. Choose one option deliberately, then assign ownership for its configuration and monitoring. Confirm the supported intake option and its version pairing with your release in the Aspects documentation before you select it.
ClickHouse analytics storage
ClickHouse stores the xAPI statements in a database built for large analytical queries over event data. Its sizing, retention settings and backup approach determine how long history stays queryable and how fast dashboards respond. Your infrastructure team usually owns capacity, backups and access control, and the operations plan must cover them from day one. Confirm the ClickHouse version that Aspects supports for your release, and check the sizing guidance in the Aspects documentation.
Superset dashboards
Superset connects to ClickHouse and presents the learner analytics dashboards to course teams and administrators. Dashboard definitions, user roles and data access rules are where most reporting requests end up, so they need clear ownership. Decide early who builds and maintains custom charts and who can view learner-level data. Confirm the Superset version bundled with Aspects for your release, since upgrading Superset separately can break shipped dashboards.
Tutor deployment layer
Tutor deploys the Aspects components alongside the LMS and Studio as Docker-based services, and it is the place where versions are pinned together. Its configuration and plugins decide which component versions run in your environment, and an unplanned Tutor upgrade can change the whole stack. Your platform team owns the Tutor configuration, the deployment pipeline and the upgrade calendar. Confirm the Tutor version that pairs with your Open edX release and Aspects version in the Aspects documentation before installation.
Ralph or Vector, single-node or dedicated analytics hosts, and who owns the dashboards
This table compares the main architecture choices for Aspects analytics: how events are routed, where ClickHouse and Superset run, and how reports are built. Read each row for when the option fits and what it asks your team to operate after go-live. The main takeaway is that the cheapest-to-start option often moves cost into upgrades, on-call and data retention.
| Decision | Option | Operational cost | When it fits |
|---|---|---|---|
| Event intake and routing | Ralph, the Aspects-native event router that stores xAPI statements in ClickHouse | Your team tracks Ralph releases alongside the Aspects release and monitors its queue and storage path | Teams that want the Aspects default path and expect to follow its documented configuration closely |
| Event intake and routing | Vector, a general-purpose log pipeline that Aspects can use for routing | Your team owns Vector configuration, its version upgrades and the transforms that shape each event before storage | Teams with existing Vector or log pipeline skills who want to standardize event handling across services |
| Analytics hosting | Co-locate ClickHouse and Superset on the LMS hosts | Shared CPU, memory and disk make LMS incidents and analytics load affect each other; backups must cover both | Small pilots or low event volumes where a separate host would add more administration than it saves |
| Analytics hosting | Dedicated analytics hosts for ClickHouse and Superset | Separate patching, monitoring, backup jobs and access controls; one more host class for on-call to cover | Production deployments that need learner-facing uptime isolated from reporting load and a clear data-retention boundary |
| Analytics hosting | Managed ClickHouse service with Superset on your own host | Recurring service fees set by the provider; you still own Superset upgrades, access and dashboard backups | Teams that do not want to run ClickHouse storage and replication, and whose data-residency rules allow the chosen provider |
| Report building | Superset dashboards maintained by the analytics owner | Dashboard definitions, datasets and permissions need version control and a named owner for each change | Standard course and administrator views where the dataset model covers the questions asked |
| Report building | Custom SQL or API exports for reports Superset cannot express cleanly | Queries and export jobs become application code that breaks when the xAPI schema or table layout changes | Reports that feed another system, need custom joins to Open edX records, or require a fixed file format |
| Data retention | Retention set in ClickHouse and Superset under a written policy | Retention jobs, storage growth and restore tests recur; confirm the exact retention settings with the Aspects documentation for your release | Deployments with a defined learner-data retention period agreed with privacy and legal owners |
How to build Aspects analytics, step by step
This sequence takes an Open edX installation from no analytics to a working Aspects pipeline, where learner activity is emitted as xAPI statements, routed through Ralph or Vector, stored in ClickHouse and shown in Superset dashboards. Platform engineers usually run the first five steps, and course-team staff check the dashboards at the end. Each step closes with a check you can run before moving on.
Confirm the Open edX release and Tutor version
Platform engineers record the Open edX named release and the Tutor version your installation runs, then confirm that the Aspects components you plan to install support both. Open edX supports only its latest named release, so check the current release notes before choosing versions. This step is done when a written version record exists for the LMS, Tutor and every Aspects component, and a staging instance on the same versions starts cleanly.
Plan hosts and storage for ClickHouse and Superset
Infrastructure engineers decide where ClickHouse, Superset and the Ralph or Vector pipeline will run, and how much disk and memory each needs for your expected event volume. Analytics storage grows with every tracked learner action, so ask your implementer to size it from your enrollment and activity estimates before purchasing hardware. Keep these services inside your own environment, with network paths from the LMS defined. This step is done when a sizing note and network diagram are approved and the hosts pass a basic connectivity test.
Enable event-routing-backends and xAPI output
Platform engineers install the event-routing-backends plugin into the LMS image through Tutor plugin configuration, then enable the xAPI output that converts tracking logs into xAPI statements. Keep these settings in the Tutor configuration under version control and apply them with a redeploy. Confirm the exact settings keys for your release in the Aspects documentation. This step is done when the LMS logs show xAPI statements being emitted for a test action and the target endpoint is reachable from the LMS.
Configure Ralph or Vector to receive and route events
Data engineers configure either Ralph or Vector to receive the xAPI statements from the LMS, validate them and forward them into ClickHouse. Choose the component that the Aspects documentation for your release supports and that matches how your team already operates log pipelines. Set retry and failure handling so that dropped statements are visible in logs and alerts. This step is done when statements sent from a test source arrive at the router, pass through it and are written to the staging store without errors.
Load the ClickHouse schema with Aspects tooling
Data engineers create the ClickHouse database and load its tables with the schema tooling provided for your Aspects release, so table definitions match the dashboards that depend on them. Run the load against staging first and record the schema version it produces. Ask your implementer which command and migration path apply to your release, since these steps are version-specific. This step is done when the expected tables exist and a count query against them returns results without errors.
Connect Superset and load standard dashboards
Analytics engineers connect Superset to the ClickHouse database as a data source, then load the standard Aspects dashboards for learner and course activity. Check that each dashboard's datasets point to the correct database and schema, and note any chart that shows no data so you can trace the gap back through the pipeline. Confirm that the dashboards load against the test data. This step is done when every standard dashboard renders against staging data with no query errors.
Restrict access to dashboards and data
Security and platform engineers limit who can open Superset and query ClickHouse, using role assignments that separate course-team viewers, administrators and database operators. Learner data is personal data, so decide which courses and fields each role can see and set a retention period for stored statements. Disable default accounts and confirm that the ClickHouse and Superset endpoints are not reachable from the public internet. This step is done when a test account for each role sees only its permitted views and the endpoints are closed to outside traffic.
Test a learner event end to end
QA engineers enroll a test learner in a test course, perform a tracked action such as viewing a unit or submitting a problem, and follow that event through the LMS, the router, ClickHouse and into a Superset chart. Compare the timestamp, course identifier and user identifier at each stage. Record the result as the acceptance test for the environment and repeat it after every upgrade. This step is done when the test event appears in the expected Superset chart and its values match at every stage.
How to verify that Aspects analytics records the right events
Verification means proving that the analytics stack records the learner actions you expect before anyone reads the dashboards. Start with a sandbox course on a non-production Open edX instance and write down, in advance, the exact actions to perform: enroll in the course, view one unit, submit a graded problem and complete one section. For each action, note the expected xAPI verb and object and how many statements it should produce. Then run each action once, alone, and watch the intake. The event-routing-backends plugin emits these statements, so the first check is whether each action produces the statement you predicted, with the verb, object and timestamp you recorded. Repeat the run with two or three test accounts so that user-level differences show up early.
Next, confirm that the rows land in ClickHouse with the correct keys. Query the tables for your sandbox test run and check the course, organization and user identifiers against the values in Studio and the LMS for the test accounts. A common failure is a row that exists but carries the wrong course or organization key, which makes the data look plausible while it is attributed to the wrong place. Compare row counts per action against the expected counts from your test sheet. Finally, open the Superset dashboards filtered to the sandbox course and the test time window. Figures should match your test actions exactly. Check the time zone setting, because a mismatch there can move events across a day boundary and make counts appear wrong when the data is correct.
Failure behavior needs its own test, because it determines whether you can trust reporting after an outage. With the sandbox running, stop the intake for a short, defined period, perform a known set of actions, then restore it and check whether those statements appear. Repeat the exercise with ClickHouse stopped instead. Each test shows whether events are queued, retried or dropped. Queueing depends on the chosen pipeline, Ralph or Vector, and on its buffer and retry configuration, so do not assume a behavior from documentation alone. Ask the implementation team to document the buffer and retry settings for your pipeline, then confirm them against your own results. If events are dropped, record the gap and decide with the data owner how it will be reported or backfilled.
The last check covers personal data. Your data protection policy defines which fields may be stored for learner analytics, so compare that list with what the statements and ClickHouse tables actually contain. Look for names, email addresses, IP addresses, free-text answers and any identifier that can be traced back to a person outside your systems. Use a test account with recognizable details, perform actions, then search the stored data for those values. Also review which Superset roles can see individual-level rows and whether aggregated views are available for course teams who do not need them. Confirm each field decision with your configuration owner and the vendor documentation, and keep the signed results with the test plan as evidence for your assessor.
What drives the effort and cost of Aspects analytics
This table lists the main factors that change the build and running effort of Aspects analytics, how each one raises that effort, and what keeps it contained. Read it to see which decisions in your scope move the quote most, and which costs are paid once versus every year. The main takeaway is that a standard dashboard set, one agreed event schema and staging parity do more to control cost than any single hosting choice.
| Driver | How it raises effort or cost | What keeps it down | One-time or recurring |
|---|---|---|---|
| Number of courses and organizations | More courses, organizations and course runs multiply the event context that must be mapped, filtered and checked in every dashboard, and more org-level views need access rules. | Start with standard Superset dashboards filtered by organization. Agree which organizations need separate views before build begins. | One-time for mapping and access design. Recurring only if new organizations are onboarded often. |
| Event volume tied to learner activity | Video, problem and navigation events grow with learner activity, which increases ClickHouse storage, ingestion load and query time. Sizing needs the expected concurrent learner pattern, which the client should supply. | Size the ClickHouse and Ralph or Vector tier from measured or forecast learner activity. Review retention so older raw events are archived or aggregated. | Sizing is one-time. Hosting and storage capacity recur and grow with volume. |
| Number of environments (dev, staging, production) | Each environment needs its own event pipeline, ClickHouse instance, Superset configuration and test data, so setup and verification effort multiplies. | Keep staging close to production in versions, event routing and dashboard configuration. Use the same Tutor configuration with different values for each environment. | Setup is one-time per environment. Keeping environments aligned recurs with each upgrade. |
| Custom reports and data mappings | Each custom report needs a defined question, a query, a dashboard layout, validation against known learner data and sign-off from the course team or administrators. Non-standard xAPI fields from custom XBlocks add mapping work. | Limit the first release to standard dashboards and a short list of agreed reports. Document a single event schema so new reports reuse existing fields. | Initial reports are one-time. Maintaining reports after course or platform changes recurs. |
| Identity and data-protection requirements | Pseudonymization of learner identifiers, access control on dashboards, retention rules and data location requirements add design, testing and evidence work. Single sign-on and role mapping for Superset access must match the platform's identity setup. | Confirm the data classification and retention policy before build. Reuse the identity provider already configured for the LMS and limit dashboard roles to a few named groups. | Design and evidence are one-time. Access reviews and policy changes recur. |
| Release upgrade cadence | Open edX supports only the latest named release, so each upgrade can change event fields, Aspects components and the dependencies that custom reports rely on. Confirm the current release and the upgrade schedule with your platform team before quoting. | Pin the Aspects and Tutor versions in configuration, keep a test environment that mirrors production, and retest the standard dashboards after every upgrade. | Recurring. Each release requires regression testing of the pipeline and dashboards. |
| Hosting model and infrastructure | Running ClickHouse, the event pipeline and Superset alongside the LMS adds servers, backups and monitoring. Hosting choices in your cloud account or data center change the cost of each component. | Right-size the analytics tier separately from the LMS. Ask the provider to quote compute, storage and backup as separate line items. | Infrastructure is recurring. Initial provisioning is one-time. |
| Operations and dashboard maintenance | Someone must watch pipeline health, data gaps, dashboard errors and access requests after go-live. Without an owner, broken dashboards go unnoticed until course teams raise them. | Assign an owner, define which alerts matter, and agree a support window in the written scope. Ask for a fixed monthly maintenance option in the quote. | Recurring for as long as analytics is in use. |
How the analytics setup changes by deployment model
On a single Tutor host, the LMS, Studio, the event routing path, ClickHouse, Superset and their supporting databases share one Docker host. Placement decisions are therefore mostly about resource allocation and disk layout. This is the simplest model to build, and it is the one most likely to be undersized for analytics, because ClickHouse and Superset compete with the learning platform for memory, CPU and disk on the same machine.
- Component placement: All Aspects services run as containers on one machine managed by Tutor, alongside the LMS and Studio containers.
- Storage: Confirm which Docker volumes hold ClickHouse data, where they sit on disk, and whether that disk can grow with the event volume you expect.
- Network path to Superset: Superset is reached through the host's reverse proxy. Confirm which hostname and TLS configuration expose it and which networks may reach it.
- Backups: ClickHouse data needs its own backup schedule, separate from the platform database dumps. Confirm the supported backup method in the Aspects and Tutor documentation.
- Image sourcing: Images are pulled from public registries during the build. Confirm which registries the host must reach outbound and whether you need to mirror them.
Before you choose this model, confirm in the Aspects and Tutor documentation which analytics services a single-host install starts by default and what minimum resources they expect.
Tutor supports Kubernetes deployments, and the analytics services can run as separate workloads so that ClickHouse, Superset and the learning platform scale on their own schedules. The trade-off is that persistent storage, ingress and the event path become cluster design decisions that your platform team must own and operate.
- Component placement: Ralph or Vector, ClickHouse and Superset run as workloads in the cluster. Decide whether ClickHouse runs inside the cluster or on a dedicated external service that the cluster can reach.
- Storage: ClickHouse needs persistent volumes sized and performance-tuned for your event volume and retention period. Confirm the storage class, how volumes are expanded and how they behave during node failure.
- Network path to Superset: Superset is exposed through the ingress controller. Restrict which namespaces and network policies can reach ClickHouse and Superset, and confirm how authentication is enforced at the ingress layer.
- Backups: Use your cluster backup tooling or a ClickHouse-level export for analytics data, and test restores in a separate namespace on a regular schedule.
- Image sourcing: Pull images from a private registry you control. Confirm which image tags the Tutor Kubernetes tooling references for the analytics services and how you update them.
Before you choose this model, confirm with the Tutor Kubernetes documentation and the Aspects documentation which analytics components the deployment provisions and which ones your team must supply, such as storage classes or external databases.
In an air-gapped or restricted network, nothing can be fetched at install time or during routine operation. Every image, package and update must be staged inside the boundary before installation begins. Analytics adds to this work because its ClickHouse and Superset dependencies must be carried in as well, and the versions you stage are the versions you run until you bring in a new set through the approved transfer process.
- Component placement: Decide whether analytics runs in the same enclave as the LMS or in an adjacent zone with a controlled data path. Keep learner event data inside the boundary at all times.
- Storage: Plan storage on enclave hardware with capacity for event data and backups. Use external object storage only if it sits inside the same boundary.
- Network path to Superset: Limit access to Superset to named internal user groups. Confirm whether your identity provider can reach it from inside the enclave, and how sessions are managed.
- Backups: Store backups inside the boundary and test restores in an isolated environment. A backup that has never been restored gives no assurance that it works.
- Image sourcing: Build an internal registry, mirror every image and package the install needs, and record checksums for each transfer. Confirm the approved transfer process with your security team before the first import.
Before you choose this model, confirm with the Tutor and Aspects documentation which images, packages and external calls the install makes, then plan how each one reaches the restricted network.
Access control and data protection for learner analytics
Aspects analytics brings learner event data into ClickHouse and Superset, so access has to be designed across the dashboards, the data stores, the intake path and the configuration that holds credentials. The cards below cover the decisions and checks that connect these layers, and the points where your own assessor should confirm requirements.
Restricting Superset access by role
Superset is the reporting layer that learners' event data reaches, so its role model determines who can see which courses, dashboards and datasets. Map each Superset role to a named job, such as course team, program reporting or platform operations, and remove default roles that grant broader database or SQL access than that job needs. Review who can create or edit datasets, since a dataset can expose raw event fields that dashboards hide.
Separating instructor, course team and administrator views
Instructors, course teams and administrators ask different questions, and they should not all see the same learner-level detail. Decide which dashboards show aggregate results, which show identifiable learner activity, and who may open each. Test the separation with real accounts from each group before go-live, because a dashboard that is hidden in the menu can still be reachable by direct URL.
Network controls and credentials for ClickHouse and intake
ClickHouse and the event intake endpoints receive learner activity, so they should not be reachable from the public internet unless a documented need exists. Restrict network paths between the LMS event routing, Ralph or Vector, ClickHouse and Superset, and give each service its own database user with the minimum write or read rights it needs. Confirm how intake endpoints authenticate senders and how those credentials are rotated.
Managing secrets in Tutor configuration
Tutor stores generated and user-supplied values in its configuration, and some of those values unlock the LMS, databases and analytics services. Keep secrets out of version control, decide where production values are stored, and record who can read and change them. Check that the values used for ClickHouse and Superset credentials are not reused across environments and that rotation can be done without rebuilding the whole deployment.
Reviewing stored learner identifiers and retention
Event records can contain learner identifiers, course identifiers and timestamps, and those fields may persist longer than the reports that use them. List every identifier that reaches ClickHouse and Superset, decide which must be pseudonymized or dropped, and set a retention period for raw events and for aggregated tables separately. Document the answers so that privacy, legal and security reviewers can check them against your policies.
Audit logging of dashboard access
Access controls are only useful if you can see who used them. Enable and retain logs for Superset logins, dashboard views, dataset changes and role assignments, and forward them to the logging system your security team already monitors. Confirm which events Superset records by default in your version and which need configuration. Agree with your own assessor which log fields, retention periods and review cadence are required for your environment.
Building custom reports for course teams and administrators
Design each custom report from the question it answers, not from the data that happens to be available. Before opening Superset, write down who asks the question (for example, a course team lead checking where learners stop progressing, or an administrator reviewing activity across several organizations), what decision the answer informs, and how often that person needs it. The question determines which xAPI verbs you need, which ClickHouse tables hold them, and what level of detail the chart must show. Keep one audience and one question per report where possible. A single chart that tries to serve course teams and administrators usually serves neither well.
Map each question to the event data before you build anything. Aspects captures tracking logs through the event-routing-backends plugin as xAPI statements, and Ralph or Vector loads them into ClickHouse for Superset to read. In your own deployment, confirm which verbs and object types your installed Aspects version emits and which tables the standard dashboards already query. Use the Aspects documentation for that release as the reference, not memory or examples from other versions. If a field the question needs is missing, decide whether you can derive it in a saved query or whether the report should state that the question cannot be answered from current events.
Assign an owner to every custom report before go-live. Custom reports depend on event schemas and table layouts that can change when you upgrade Aspects or move to a new Open edX named release, and a chart that breaks silently is worse than one that was never built. Agree who checks reports after each upgrade, who repairs broken queries, who approves changes to shared dashboards, and who decides whether a schema change in the events means a report must be retired. Ask your implementation partner whether this maintenance is part of the fixed-scope work or an ongoing support arrangement, because the answer changes who is accountable after the first release upgrade.
Test each report against the sandbox dataset before it reaches users, and confirm that the sandbox produces the event types your production environment emits. Choose a small test course where you know the expected learner counts and activity, and check that the figures match what you can verify directly in the LMS. Then document each report with its question, audience, owner, xAPI verbs, ClickHouse tables and fields, filters, refresh behavior and known limitations. This record is what lets a new administrator or an external auditor understand where a number came from, and it is the first thing to update when an event schema changes.
Questions teams ask before building Aspects analytics
How much does it cost to build Aspects analytics?
No single figure applies, because the cost depends on the components you need and who builds them. The main parts are the event pipeline (event-routing-backends, Ralph or Vector), the ClickHouse database, the Superset dashboards, and the Open edX configuration that emits the events. One-time work includes design, installation, mapping events to reports, building dashboards and testing. Recurring work includes hosting the analytics infrastructure, keeping the pipeline working through each Open edX upgrade, and maintaining dashboards as course teams ask for new reports. Costs rise with the number of custom reports, the number of environments, and the data retention you require. Ask any provider for a written scope that separates one-time build work from ongoing hosting and support, and that states which reports are included.
How long does an Aspects analytics setup take?
The timeline depends mainly on scope, not on the Aspects software itself. The main drivers are how many dashboards and custom reports you need, whether ClickHouse and Superset will run in your own infrastructure or a shared environment, how mature your Open edX deployment is, and how quickly your team can confirm report requirements and identity data decisions. Work is usually sequenced as environment preparation, event validation on a test instance, pipeline setup, dashboard build, and review with course teams and administrators. Each stage waits on the one before it, so delays in requirements often hold up everything else. Ask for a schedule in the fixed-scope quote with named milestones and the decisions each milestone depends on.
Can our internal team build Aspects analytics without a partner?
Yes, a capable internal team can build Aspects analytics, but the work spans several skill areas at once. Your team needs experience with Open edX configuration, Tutor or the Kubernetes deployment method you choose, ClickHouse administration, Superset, and xAPI event structures. It also needs someone who can turn course team and administrator questions into report specifications. The maintainers recommend running Open edX in production through a service provider or with Tutor, and bare-metal installs receive limited community support. Assess honestly whether you have these skills on staff, how many people could support the system after go-live, and whether the same people also carry the upgrade workload. A partner can cover gaps in any of these areas, and the division of work should be written into the scope.
What do we need to provide for an Aspects analytics project?
Your side of the project covers environments, data decisions and people. Provide at least one non-production Open edX environment where events can be tested before production, plus access to the infrastructure where ClickHouse and Superset will run, whether that is your cloud account, a data center or an air-gapped network. Decide how learner identities will appear in analytics, including which identifiers are stored, how pseudonymization works, and who may see personal data in dashboards. Name a report owner who can approve metrics and definitions, and make staff available to review dashboards with course teams. Confirm your retention rules and backup expectations early, because they change storage design. Written decisions on these points prevent most rework in later stages.
Does Aspects analytics only work on the latest Open edX release?
Open edX supports only its latest named release, and it cannot support more than one release at a time. Verawood is the current named release, published on 30 July 2026. The next releases, Willow and Xylon, are listed for December 2026 and June 2027. In practice, your Aspects deployment should be built against the release your Open edX platform runs, and you should plan to upgrade the analytics pipeline alongside the platform. Confirm with the Aspects documentation which versions of event-routing-backends, Ralph or Vector, ClickHouse and Superset match each Open edX release before you commit to a version. Include upgrade testing for dashboards and event schemas in your recurring work plan.
How does xAPI data get from Open edX into dashboards?
Open edX emits tracking logs, and the event-routing-backends plugin converts relevant events into xAPI statements. Those statements are sent to Ralph or Vector, which move them into a ClickHouse database. Superset reads from ClickHouse and presents the data as dashboards. For engineers, the points to verify are the event coverage (which learner and course actions produce statements), the routing configuration in the LMS settings, the schema of the statements stored in ClickHouse, and the Superset datasets built on top of them. Test each stage with a known sequence of actions on a test course, and compare the stored statements with what the dashboards show. Check the Aspects overview documentation for the current component list before you configure anything.
What should a fixed-scope quote for Aspects analytics include?
A useful quote lists deliverables, not only hours. Ask for the following in writing: the environments that will be built and where they run, the event coverage and routing configuration, the ClickHouse and Superset setup, the list of dashboards and custom reports with their definitions, the testing approach and acceptance criteria, and the handover materials. Separate one-time build work from recurring hosting, upgrades and support, and state what each recurring item includes. Confirm which decisions the client must make and by when, what happens if requirements change, and how upgrades to a new Open edX release are handled. Ask who holds administrative access after handover. A fixed-scope agreement should make these boundaries clear before work starts.
How DeployOpen works on this
DeployOpen plans, builds and hands over Aspects analytics inside your own infrastructure, so learner event data stays where your governance rules require it. We start from a written scope that names the event sources, the ingestion and storage path, and the dashboards your course teams and administrators will use. The result is a documented pipeline that your own staff or a retainer partner can operate after go-live.
How we scope
- The written scope lists which Open edX sites, courses and event types feed Aspects, agreed in writing before work starts.
- Scope covers the xAPI statements from event-routing-backends, the Ralph or Vector ingestion choice and the ClickHouse storage layout.
- We confirm which Superset dashboards and custom reports course teams and administrators need, with the access each role gets.
How we build
- Install and configure event-routing-backends so tracking logs are emitted as xAPI statements in your Open edX deployment.
- Set up Ralph or Vector to load statements into ClickHouse, then test ingestion against your expected event volume.
- Build Superset dashboards and custom reports, then verify each figure against raw ClickHouse queries before course teams see them.
How we hand over
- Deliver configuration files, a data flow diagram and runbooks for the xAPI, ingestion, storage and Superset layers.
- Document the dashboard definitions, saved queries and the role mapping that decides who can view learner data.
- Walk your administrators and course-team leads through the dashboards and the checks they should run after each release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover analytics changes alongside the platform.
- Pipeline checks after each Open edX upgrade confirm that xAPI statements still reach ClickHouse and Superset renders.
- Changes to sizing or event volume are scoped as written work, and the quote separates one-time from recurring costs.
