Background: Community Needs Driving the Project

There are already multiple ways to group learners on the platform: cohorts, teams, and track groups. These grouping mechanisms allow course delivery teams to randomly assign users to a group, group users based on enrollment track, username, or email address. The Teams feature even allows users to assign themselves to a team.

We’ve heard a number of use cases that demonstrate the need for expanding user grouping capabilities on from the options that are currently available to include grouping users based on their characteristics, their performance, and/or the things that they do (or don’t do) on the platform.

The primary reason that users want to be able to segment users based on their characteristics, performance, and platform engagement is to power targeted interventions to users that feel relevant and tailored in the hopes that these interventions improve learner outcomes.

The three major strategic goals of this project are to:

1. Allow platform users to group users at the course, organization, and platform level based on their characteristics, performance, and/or the things that they do (or don’t do) on the platform. Instance operators should be able to easily add their own grouping criteria to their instance’s group creation interface.

2. Allow platform users to send tailored communications to a user group

3. Simplify user grouping on the platform so that all user grouping mechanisms are created and managed in one central place. Users can continue to create groups randomly or by allowing learners to assign themselves to a group (like they can do in teams); or by username, user email, enrollment track. User groups can to be utilized the ways that they are currently utilized on the platform.

Value and Impact

Not all users are the same. Because of this, there is tremendous opportunity in allowing course delivery teams and administrators to segment users in a course, in an organization, and across the platform based on a broader array of characteristics and events data. 

With a centralized and powerful user grouping feature, the Open edX platform will equip course delivery teams and administrators to deliver tailored communications to learners and to provide targeted support to learners based on their engagement or performance.

With simplified, more robust user grouping capabilities, we expect that user grouping will be easier to do and understand for users and will encourage platform administrators and course delivery teams to use these powerful segmentation capabilities more often.

Use Cases

As a course delivery team member, I want to be able easily to create and manage user groups all in one place, so that I can use them a variety of different ways.

Groups

As a course delivery team member, I want to be able to create the following user groups at the course level:

• Coursewide Enrollment-related groups:

  • Learners enrolled in the course in X enrollment track ← Note: This is type of group currently exists on the platform by way of course/track groups.

• Coursewide Engagement-related groups:

  • Learners enrolled in the course, but haven’t logged into the course

  • Learners enrolled in the course, but haven’t logged into the course in N or more days

  • Learners enrolled in the course who have engaged with at least one page in the course, but have not engaged with course material in N or more days (this group where N is 7 is used to generate the Aspects At-Risk Learner Group dashboard)

  • Learners enrolled in the course on X enrollment track who have engaged with course material within the past N days

• Assignment-related groups:

  • Learners enrolled in the course who haven’t completed an (specific) assignment

  • Learners enrolled in the course who have started an (specific) assignment, but have not yet completed it

  • Learners enrolled in the course who have N grade or lower (or higher) on a specific assignment

• Coursewide Performance-related groups:

  • Learners enrolled in the course who have N grade or higher (or lower) in the course

  • Learners enrolled in the course who have N grade or higher and are active in the forums

  • Learners enrolled in the course who have earned a certificate

• Component engagement-related groups:

  • Learners enrolled in the course who watched a (specific) video (s)

  • Learners enrolled in the course who attempted (specific) problem(s)

  • Learners enrolled in the course who attempted specific problem(s) and their final attempt was correct (incorrect)

  • Learners enrolled in the course who answered X on a specific problem or survey

  • Learners enrolled in the course who submitted an ORA response

• Use cases for creating a group made up of a list of learners:

  • I have a list of learners that my organization considers “at risk”

  • I have a list of learners that have certain accessibility needs

  • Specific course staff members

• Use cases for excluding users from a group:

  • I want to exclude residential learners from this group (same domain name)

  • I want to exclude course staff from this group

• Other:

  • Course staff

Utilizing Groups

… so that I can:

• Communicate with a subset of learners (via email or notification depending on the use case and learner notification preferences). See Targeted Interventions: Event-triggered notifications and notifying user groups for example use cases that came up in discovery. 

• Easily compile and download a list of learners that meet certain criteria based on their characteristics, their course engagement, and/or their course performance.

• View course enrollment, engagement, and performance data for a list of learners that meet certain criteria based on their characteristics, their course engagement, and/or their course performance.

• Automatically reset attempts for (specific) problem(s) for a subset of learners who are not performing well on an assignment or those that got their final problem attempt(s) wrong for (specific) problem(s) in order to keep them engaged with coursework.

• Tailor the course content for learners in a particular group and/or deliver the same course plus supplemental content and problems to a subset of learners in my course based on what the learner does in the course, learner characteristics, etc.

  • Specific examples:

    • For learners who answered the survey at the beginning of my course with X as their primary area of interest, I want to tailor the problems and examples given throughout the course course to their interests to help keep them engaged.

    • For learners who did not get a problem correct (on their final attempt) or scored N or less on the initial/preliminary assessment, I want to deliver supplemental content to those learners about the topic they struggled with and re-test these concepts later on in the course.

What We Propose to Build

Our goal is to create a single user grouping mechanism that allows administrators and course delivery teams to create and manage subsets of users in a course, in an organization, or across the platform. In addition to being able to randomly assign users to a group, group users based on enrollment track, username, or email address, or to allow users to assign themselves to a team, we want to introduce a way to group users by their characteristics or their platform activity.

The idea would be that once user groups are created, administrators and course delivery teams would be able to utilize these groups in a number of different ways. In addition to the ways in which users can use cohorts, track groups, and teams today, users would be able to send targeted communications to a user group, download a list of users in a user group, and filter an Aspects dashboard by a user group.

Key Capabilities

• Define, name, save, and edit user group at the course, organization, and platform level

  • Manual/Static user group: Include/exclude a list of learner(s) manually or by uploading a CSV file

  • Dynamic user group: Include/exclude learners that share criteria (attributes and/or events)

  • Randomly assign users to a group

  • Allow users to join a group

• User group membership should be kept up to date

  • For dynamic user groups, the refresh would occur via either an automatic cadence or the refresh would be triggered by the usage of the user group (depending on the criteria used to create the user group)

  • Users would also be able to manually refresh user groups

• Disable user group

  • Stops automatic refreshing of dynamic groups

  • Stops any interventions associated with the group

• View… for user group

  • Metadata (including group name, grouping criteria, number of users in group, date last modified)

  • Data (such as the list of users in the group, enrollment, engagement, performance data)

    • For instances running Aspects, this will be possible by allowing users to filter existing dashboards by a user group.

• Export list of users in group

• Utilize user group

  • Notify/communicate with user group(s)

  • Notify/communicate with user group(s) when a triggering event or date/datetime occurs

  • Assign content groups to a user group (formerly cohorts and track/course groups)

  • Link user groups/user group sets to discussions and projects (formerly teams)

  • Custom usage of user groups:

    • Examples:

      • I want to be able to re-set the number of attempts for X problem for users in a group

      • I want to be able to grant an extension to all users in a group

Key Concepts

See Key Concepts

How We Propose to Build It

A few different ADRs will be up for review by June 27th that will delve into the unified user group model architecture, proposed migration paths and refresh mechanisms. Will be linked here once available. In the meantime:

• See https://openedx.atlassian.net/wiki/x/BIAdJQE for the thinking that has been done around the model

• See https://openedx.atlassian.net/wiki/x/A4DeKgE for more information about the migration path

• See https://openedx.atlassian.net/wiki/x/BQBMKgE for more information about the refresh framework.

How will we manage transition?

1. Ulmo (User Groups BETA release; defaulted to off): Add the ability to create and manage a Static User group at the course level; user can download a CSV file that lists the users in the group and can filter Aspects dashboards by user group (Requirements)

2. Verawood (User Groups BETA release; defaulted to off): Add the ability to create and manage a Dynamic User group at the course level (Requirements draft)

Beyond

1. Start to integrate communication mechanisms with user groups; provide users with a small number of out-of-the-box pre-made user groups based on those we expect to be commonly used (No longer in BETA; defaulted to on)

2. Slowly start migrating legacy groups over to user group creation and management model and interface in the following order:

   1. Track groups

   2. Cohorts

   3. Teams ← Outstanding: how many instances are using teams - does it make sense to keep teams separate from the rest of user grouping for the long term?

3. Start to expand the scope of user grouping beyond the course level (user groups created at the org level and then platform level)