Hallo, ich bin Renzo Lucioni, ein Senior an der Harvard University. Ich hatte diesen Sommer eine tolle Zeit als Praktikant bei edX. Ich arbeite daran, einen objektiven Ansatz für das Produktmanagement zu ermöglichen und zu fördern. Mein Sommerprojekt bestand aus mehreren diskreten Verbesserungen, die sich über das LMS und das neu gebildete Analytics-Team erstreckten. Bei meinem Projekt ging es sowohl darum, den „Prozess“ richtig hinzubekommen, als auch darum, die Art und Weise zu verbessern, wie das LMS den Schülern ihre Fortschritte zeigt. Mit „Prozess“ meine ich: Änderungen identifizieren und validieren, sie umsetzen und dann ihre Auswirkungen quantifizieren. Diesen „Prozess“ zu ermöglichen und zu fördern, ist das Dach meiner Arbeit im Sommer.
Hier ist ein Überblick über den Prozess, den wir hier bei edX zu verfolgen versuchen. Wir beginnen mit der konkreten Identifizierung eines Problems und der Wirkung, die wir von der Behebung erwarten. Wir identifizieren Probleme, die behoben werden müssen, indem wir Analysedaten verwenden, die wir sammeln. Anschließend überlegen wir mögliche Lösungen. Der nächste Schritt ist die Validierung. Bevor wir Änderungen vollständig implementieren, wollen wir sie validieren. Änderungen können durch eine Reihe von Dingen motiviert sein, aber wir möchten sicherstellen, dass die vorgeschlagenen Änderungen das Problem beheben. Es gibt viele Möglichkeiten zur Validierung. Dies kann bedeuten, dass die Änderung intern einer Handvoll Personen gezeigt wird, dass sie von einer Gruppe von Benutzern ausgeführt wird, die wir hinzuziehen, um die Änderung zu testen, oder dass Split-Tests durchgeführt werden. Wenn wir sehen, dass die Änderung hilft, setzen wir sie um. Ist dies nicht der Fall, geht es zurück zu Schritt eins. Nachdem wir die Änderung vorgenommen haben, möchten wir ihre tatsächlichen Auswirkungen in der Produktion messen, um sicherzustellen, dass wir die Rendite erhalten, die wir aus dem Validierungsschritt erwartet haben.
Um bei den Identifizierungs- und Quantifizierungsschritten zu helfen, konzentrierte sich meine Arbeit auf Analytik und Datenqualität. Segment.io ist ein Dienst eines Drittanbieters, der es uns ermöglicht, unsere Analysedaten an jeden beliebigen Analysedienst zu senden, ohne dass wir ihn einzeln in jeden Dienst integrieren müssen. Ich habe Segment.io in die edX-Plattform integriert und die von uns protokollierten Ereignisse bereinigt. Wir verwenden jetzt Segment.io, um zu verfolgen, was Benutzer tun, während sie mit der Kurssoftware interagieren, und leiten diese Informationen an weiter Google Analytics, Mixpanel und Chartbeat.
Um den Validierungsschritt unseres Prozesses zu verbessern, habe ich einen flexiblen und leichtgewichtigen Ansatz für Split-Tests entwickelt. Split-Tests werden auch als A/B-Tests bezeichnet und bestehen darin, unsere Benutzer in Gruppen einzuteilen, zu kontrollieren, was diese Gruppen sehen (wir möchten jeder Gruppe etwas anderes zeigen), und das Verhalten jeder Gruppe überwachen und vergleichen. Wir wollten, dass unser Split-Testing-Ansatz flexibel ist und es uns ermöglicht, ihn auf der gesamten edX-Plattform auf Änderungen anzuwenden, die von kosmetischen Änderungen bis hin zu völlig neuen Funktionen reichen. Das Split-Testing-Framework, das ich implementiert habe, basiert auf Waffel Jersey, ein Django-Feature-Flipper. Ich habe mich entschieden, keines der verschiedenen Open-Source-A/B-Test-Frameworks zu verwenden, die für Django verfügbar sind, da die meisten nicht mit Django 1.4 kompatibel sind, nicht mehr gepflegt werden und entweder schlecht oder gar nicht dokumentiert sind. Darüber hinaus stellte ich bei dem Versuch, den Prozess des Split-Testing zu abstrahieren, fest, dass diese Frameworks für unsere typischen Anwendungsfälle zu starr sind. Die meisten wurden mit dem ausdrücklichen Zweck entwickelt, Anmeldungen oder Käufe von Benutzern zu verfolgen. Die Verwendung von Waffle in Verbindung mit Mixpanel stellt einen flexibleren und leichteren Ansatz dar.
Waffle bietet drei Tools zum Steuern dessen, was Benutzer sehen: Flags, Switches und Samples. Mein Framework verwendet die sitzungsbasierten Flags von Waffle, um Funktionen in Django-Ansichten und Mako-Vorlagen umzuschalten. Flaggen passen gut zum Split-Testing-Gesetz. Sie können allen Benutzern, einer Gruppe von Benutzern oder einem beliebigen Prozentsatz von Benutzern zugewiesen werden. Mit entsprechenden Berechtigungen für das „Flags“-Modell in der Datenbank können Flags mithilfe der Django-Admin-Site erstellt, umgeschaltet und gelöscht werden, ohne DevOps einzubeziehen. Darüber hinaus werden an Flags vorgenommene Änderungen sofort wirksam, ohne dass Code gepusht werden muss. Mein Framework verfolgt, welche Flags für einen bestimmten Benutzer aktiv sind, indem es Segment.io-API-Aufrufen eine Eigenschaft hinzufügt, die eine Zeichenfolge enthält, die aktive Flags auflistet; Diese spezielle Änderung wurde in vorgenommen segment-io.html. Segment.io leitet diese Informationen an Mixpanel weiter, wo wir die Daten untersuchen können, sodass wir das Verhalten verschiedener Benutzergruppen vergleichen können.
Hier ist ein Beispiel für den Prozess in Aktion. In Gesprächen mit Gruppen von edX-Benutzern erfuhren wir, dass ein starker Wunsch nach einer kontextbezogenen Anzeige des Fortschritts besteht. Studenten hatten in der Vergangenheit Schwierigkeiten, ihre Fortschritte in einem Kurs zu visualisieren. Sie hatten auch nur minimale Hilfe beim Navigieren durch die Kursunterlagen. Derzeit teilt die Kursunterlagen-Zielseite einem Schüler mit, wo er oder sie zuletzt war, und verlinkt auf diese Komponente. Das Kursakkordeon zeigt jedoch nicht an, was der Student abgeschlossen hat, woran der Student gerade arbeitet oder womit der Student noch nicht begonnen hat. Um die Sache noch schlimmer zu machen, ist die Fortschrittsregisterkarte von der Kursunterlage getrennt und auch zu ausführlich, was bedeutet, dass die Seite für einen Schüler nicht sofort nützlich ist. Die Schüler haben keine Möglichkeit, ihren Fortschritt im Kontext der Kursunterlagen zuverlässig zu messen.
Ich habe versucht, dieses Problem anzugehen, indem ich die Ergebnisse der Schüler direkt neben den Titeln der Probleme, an denen sie arbeiten, live anzeigte. Um diese Änderung vorzunehmen, habe ich modifiziert capa_module.py und display.kaffee. Wir versuchen, Split-Tests großen, riskanten Änderungen vorzubehalten, nicht klaren Gewinnen wie dieser Änderung; wir wollen auf der richtigen Ebene validieren. Daher bestand die Validierung dieser Änderung darin, die Änderung intern anzuzeigen. Nach der Implementierung dieser Funktion folgt nun die Quantifizierung. Wir haben einen Rückgang des Datenverkehrs von der Kursunterlage zur Fortschrittsseite um 8 % beobachtet und werden diese Daten verwenden, um zukünftige Änderungen zu informieren.
Obwohl wir gerade erst begonnen haben, Analysedaten zu verwenden, um unsere Entscheidungen und dieses neue Framework für Split-Tests neuer Arbeiten zu untermauern, bin ich zuversichtlich, dass diese Tools es uns ermöglichen werden, bessere Entscheidungen zu treffen. Eines der Ziele von edX ist es herauszufinden, was Menschen beim Online-Lernen hilft. Ein eher quantitativer Ansatz in Kombination mit Split-Tests wird uns dabei helfen, dieses Ziel zu erreichen.
