- Added the ``user_api_usercoursetag`` table to the :ref:`Student_Info` chapter and the ``assigned_user_to_partition`` and ``child_render`` event types to the :ref:`Tracking Logs` chapter.
* - 19 Mar 2014
- Provided alternative formatting for the examples in the :ref:`Discussion Forums Data` chapter.
* - 13 Mar 2014
- Updated the :ref:`Student_Info` chapter.
* - 24 Feb 14
* - 24 Feb 2014
- Added descriptions of new fields to the :ref:`Wiki_Data` chapter.
* - 21 Feb 14
* - 21 Feb 2014
- Added descriptions of new fields to the :ref:`Discussion Forums Data` chapter.
* - 14 Feb 14
* - 14 Feb 2014
- Added the ``seek_video`` and ``speed_change_video`` event types to the :ref:`Tracking Logs` chapter.
@@ -100,6 +100,7 @@ The following tables store data gathered during site registration and course enr
* :ref:`auth_user`
* :ref:`auth_userprofile`
* :ref:`student_courseenrollment`
* :ref:`user_api_usercoursetag`
* :ref:`user_id_map`
.. _auth_user:
...
...
@@ -602,6 +603,71 @@ mode
**History**: All enrollments prior to 20 Aug 2013 are "honor".
.. _user_api_usercoursetag:
============================================
Columns in the user_api_usercoursetag Table
============================================
This table uses key-value pairs to store metadata about a specific student's involvement in a specific course. For example, for a course that assigns students to groups randomly for A/B testing, a row in this table identifies the student's assignment to a partition and group.
**History**: Added 7 Mar 2014.
.. need a sample header and row from a data package when available
The ``user_api_usercoursetag`` table has the following columns:
.. list-table::
:widths: 15 15 15 15
:header-rows: 1
* - Column
- Type
- Null
- Key
* - user_id
- int(11)
- NO
- PRI
* - course_id
- varchar(255)
- NO
-
* - key
- varchar(255)
- NO
-
* - value
- textfield
- NO
-
.. need type, null, key for each one
---------
user_id
---------
The student's ID in ``auth_user.id``.
-----------
course_id
-----------
The course identifier, in the format {org}/{course}/{run} (for example, ``MITx/6.002x/2012_Fall``).
----
key
----
Identifies an attribute of the course.
For example, for a course that includes modules that are set up to perform A/B testing, the value in this column identifies a partition, or type of experiment. The key for the partition is in the format ``xblock.partition_service.partition_ID``, where ID is an integer.
------
value
------
The content for the key that is set for a student.
For example, for a course that includes modules that are set up to perform A/B testing, this column stores the group ID of the particular group the student is assigned to within the partition.
.. _user_id_map:
==================================
...
...
@@ -883,7 +949,7 @@ done
-----------
course_id
-----------
The course that this row applies to, represented in the format org/course/run (for example, ``MITx/6.002x/2012_Fall``). The same course content (same ``module_id``) can be used in different courses, and a student's state needs to be tracked separately for each course.
The course that this row applies to, represented in the format {org}/{course}/{run} (for example, ``MITx/6.002x/2012_Fall``). The same course content (same ``module_id``) can be used in different courses, and a student's state needs to be tracked separately for each course.
This chapter provides reference information about the event data that is delivered in data packages. Events are initiated by interactions with the courseware and the Instructor Dashboard in the LMS, and are stored in JSON documents. In the data package, event data is delivered in a log file.
The sections in this chapter provide:
The sections in this chapter describe:
* A :ref:`sample_events`.
* :ref:`common` that are included in the JSON document of every event type.
...
...
@@ -20,7 +19,7 @@ The sections in this chapter provide:
Sample Event
*************************
A sample event from an edX.log file follows. The JSON documents that include the event data are compressed before they are added to the log file, so they appear in this compact format.
A sample event from an edX.log file follows. The JSON documents that include the event data are included in the log file as raw data, so they appear in this compact format.
.. code-block:: json
...
...
@@ -132,7 +131,6 @@ If you use a JSON formatter to "pretty print" this event, a version that is more
"username": "AAAAAAAAAA"
}
.. _common:
********************
...
...
@@ -149,11 +147,17 @@ This section contains a table of the JSON fields that are common to the schema d
| ``context`` | For all event types, identifies the course that generated | string/JSON | Contains these common member |
| | the event, the organization that lists the course, and the | | fields: |
| | individual who is performing the action. | | ``course_id`` |
| | Also contains member fields that apply to specific event | | ``org_id`` |
| | types only: see the descriptions for each event type. | | ``user_id`` |
| | | | ``org_id`` |
| | ``course_user_tags`` contains a dictionary with the key(s) | | ``user_id`` |
| | and value(s) from the ``user_api_usercoursetag`` table | | ``course_user_tags`` |
| | for the user. See :ref:`user_api_usercoursetag`. | | |
| | | | These fields are blank if values |
| | Also contains member fields that apply to specific event | | cannot be determined. |
| | types only: see the description for each event type. | | |
| | | | |
| | **History**: Added 23 Oct 2013; ``user_id`` added | | These fields are blank if values |
| | 6 Nov 2013. Other fields may duplicate this data. | | cannot be determined. |
| ``ip`` | IP address of the user who triggered the event. | string | |
...
...
@@ -195,7 +199,9 @@ The Student Event Type table lists the event types that are logged for interacti
* :ref:`ora`
A description follows for each event type that includes what each event type represents, which component it originates from, and what ``event`` fields it contains. The ``event_source`` field from the "Common Fields" table above distinguishes between events that originated in the browser (in javascript) and events that originated on the server (during the processing of a request).
* :ref:`AB_Event_Types`
The descriptions that follow include what each event type represents, which component it originates from, and what ``event`` fields it contains. The ``event_source`` field from the "Common Fields" table above distinguishes between events that originate in the browser (in javascript) and events that originate on the server (during the processing of a request).
.. _navigational:
...
...
@@ -217,7 +223,7 @@ These event types are fired when a user selects a navigational control.
**Event Source**: Browser
``event`` **Fields**: All of the navigational event types have the same fields.
``event`` **Fields**: These navigational event types all have the same fields.
Course authors can configure course content to present modules that contain other modules. For example, a parent module can include two child modules with content that differs in some way for comparison testing. When a student navigates to a module that is set up for A/B testing in this way, the student is randomly assigned to a group and shown only one of the child modules.
* Internally, a *partition* defines the type of experiment: between video and text, for example. A course can include any number of modules with the same partition, or experiment type.
* For each partition, students are randomly assigned to a *group*. The group determines which content, either video or text in this example, is shown by every module with that partitioning.
The event types that follow apply to modules that are set up to randomly assign students to groups so that different content can be shown to the different groups.
**History**: These event types were added on 12 Mar 2014.
----------------------------------
``assigned_user_to_partition``
----------------------------------
When a student views a module that is set up to test different child modules, the server checks the ``user_api_usercoursetag`` table for the student's assignment to the relevant partition, and to a group for that partition. The partition ID is the ``user_api_usercoursetag.key`` and the group ID is the ``user_api_usercoursetag.value``. If the student does not yet have an assignment, the server fires an ``assigned_user_to_partition`` event and adds a row to the ``user_api_usercoursetag`` table for the student. See :ref:`user_api_usercoursetag`.
.. note:: After this event fires, the common ``context`` field in all subsequent events includes a ``course_user_tags`` member field with the student's assigned partition and group.
When a student views a module that is set up to test different content using child modules, a ``child_render`` event fires to identify the child module that is shown to the student.
