...
There are two new optional experiment-specific kwargs, though:
num_buckets: defaults to 2, specify how many buckets you want users to be broken into.
experiment_id: defaults to None, specify a unique int for your experiment on your installation of Open edX – this is only necessary to define if you want to use the
enrollment_start
feature below.use_course_aware_bucketing: defaults to True. If True, then a given user can hash into different buckets for different courses. If False, then any given user will hash to the same default bucket across all course-runs.
Usage
Code Block | ||
---|---|---|
| ||
bucket = EXAMPLE_FLAG.get_bucket(course_key) if bucket == 1: # variant 1 path elif bucket == 2: # variant 2 path else: # control path |
...
If you pass the optional course_key
to either get_bucket
or is_enabled
, you will potentially get a different bucket per course for the same user. And will emit an analytics event then:
Any applicable
WaffleFlagCourseOverrideModels
you create on the experiment flag or sub-flags will take effect, andAn analytics event will be emitted per-course-per-session (rather than just per-session), and
If use_course_aware_bucketing is True, then you will potentially get a different bucket per course for the same user.
Conversely, if you omit the course_key
argument, none of the above will be true.
When to Check
In general, check whether the flag is enabled as late as possible. This is purely for analytics reasons, because we’ll send a segment event once the flag is checked (if a user is actually bucketed). So, for example:
...
And lastly, you can optionally set up a threshold date for course enrollments. What that means is that if you are slicing users into buckets based off which course they are in (i.e. passing pass a course key to get_bucket
or is_enabled
above), they users will only actually be bucketed and analyzed if their course enrollment started after your threshold date. This is a way to avoid suddenly changing the course experience for users in the middle of an enrollment.
...