„Dürfen wir Ihnen jemanden vorstellen?“, lautete die Frage, mit der wir in unserem Experiment „Deutschland spricht“ mehr als 12.000 Nutzer von ZEIT ONLINE überzeugt haben, sich auf einer kleinen Dating-Plattform für politische Gespräche anzumelden. Das Besondere dabei: Die Gespräche fanden nicht online statt, sondern vergangenen Sonntag, eins zu eins in Bars, Cafés und auf öffentlichen Plätzen in ganz Deutschland. Wie wir das technisch organisiert haben, beschreibt dieser Blogpost.
Build-Measure-Learn
Bei „Deutschland spricht“ war klar, dass wir schnell und ohne großes Entwicklerteam arbeiten mussten. Oder wie Chefredakteur Jochen Wegner schreibt: Das Flugzeug bauen, während es abhebt. Die Kernfrage: Was ist das einfachste Vorgehen, das unsere Anforderungen erfüllt und gleichzeitig vor Missbrauch schützt? Wir haben uns zweier Methoden aus dem Lean Startup Framework von Eric Ries bedient: ein eng gefasstes Minimal Viable Product bauen und mit dem Build-Measure-Learn-Kreislauf das Ergebnis verbessern. Das Minimal Viable Product (MVP), ist laut Eric Ries, „die Version eines neuen Produktes, die einem Team erlaubt, mit dem geringst möglichen Einsatz das Meiste über Kunden zu lernen“. Der Build-Measure-Learn-Kreislauf besagt: Bau sofort funktionierende Software, miss die Nutzung und lerne daraus.
Das haben wir getan. Während wir auf unserer Website Teilnehmer für das Projekt gewannen, bauten wir einen ersten Proof-of-Concept. Nach weniger als einer Woche funktionierten die wesentlichen Komponenten, um die Teilnehmer zu bestätigen und Gesprächspartner zu matchen, die unterschiedlicher Meinung waren.
Zunächst haben wir ein Formular auf unsere Website gestellt, in dem fünf politische Grundfragen mit Ja oder Nein beantwortet werden konnten. Außerdem haben wir um Name, E-Mail und Postleitzahl gebeten. Die Daten haben wir SSL-verschlüsselt übertragen und zunächst in einer Tabelle, in einem Google-Apps-Doc (der Apps Dienst von Google garantiert bestmögliche Datensicherheit, eine Nutzung der Daten durch Google ist ausgeschlossen), gesammelt. Nach einem ersten Säubern der Daten haben wir mit Mailchimp einen Newsletter versandt. Rückläufer und Abmeldungen haben wir verwendet, um die Qualität des Datensatzes zu erhöhen. Um die Telefonnumern der Teilnehmer zu verifizieren, haben wir die API von Nexmo verwendet. Twilio, Plivo oder jeder andere ähnliche Dienst wäre hier genauso in Frage gekommen. Die SMS-Komponente besteht aus zwei Python-Skripten. Ein Skript, welches eine SMS an eine Liste von Telefonnummern sendet, und einem Dienst, der an einem API-Endpunkt die Antworten entgegen nimmt und speichert. Insgesamt 150 Zeilen Code, der in wenigen Stunden geschrieben und getestet werden konnte. Mit den bestätigten Nutzern fütterten wir den Matching-Algorithmus.
Der Augmentierende-Pfade-Algorithmus
Für jedes mögliche Paar wurde nun – wieder per Python-Skript – geprüft, wie viele der fünf Fragen die beiden Partner unterschiedlich beantwortet hatten. Das Ergebnis: eine Abstandstabelle mit Werten von null bis fünf: Null bedeutete völlige Übereinstimmung, fünf hitzige Diskussionen. Damit ließ sich ein Graph konstruieren. Ein Graph ist eine abstrakte Struktur, die Objekte (Knoten) und ihre Verbindungen (Kanten) repräsentiert. Die Kanten des Graphen enthielten alle Paare von Menschen, die näher als 20 Kilometer voneinander entfernt wohnen, gewichtet mit der Antwortdistanz. Der Graph enthielt am Ende mehr als eine halbe Million Kanten. Das Problem bestand darin, genau so viele Kanten zu wählen, so dass möglichst jeder Knoten, also die Daten des Teilnehmers, abgedeckt wurde, und dabei ein möglichst großes Gewicht zu sammeln – ein größtmögliches Matching also. Das kann man mit Hilfe des Augmentierenden-Pfade-Algorithmus des amerikanischen Mathematikers Jack Edmonds berechnen.
Wir nutzten die Python-Library networkX von Benjamin Edwards et al., in der eine Variante dieses Algorithmus implementiert ist. Der Algorithmus gehört zu den Standards der Graphentheorie und ist in den meisten graphentheoretischen Bibliotheken verfügbar. Eine Alternative wäre die Python-Library networKIT gewesen, die am Karlsruhe Institute für Technologie entwickelt wird. Die Implementierung in networkx findet ein optimales Matching in Graphen dieser Größe in weniger als einer halben Stunde Rechenzeit.
Mit den Matches und der Mandrill-API von Mailchimp haben wir den Teilnehmern ihren möglichen Gesprächspartner angeboten – zunächst ohne E-Mail-Adresse. Auch hier: Sendgrid oder Amazon SES wären gute Alternativen für den E-Mail-Versand gewesen. Erst nach nochmaliger Bestätigung haben wir beide Teilnehmer einander vorgestellt und ihnen ihre jeweiligen E-Mail-Adressen mitgeteilt. Auch hier das Mittel der Wahl: eine Handvoll Skripte, die man direkt in der Konsole ausführt.
Unsere zentralen Metriken waren im wesentlichen die Öffnungs- und Klickrate der E-Mails, die Antwortrate auf die SMS sowie die erzielten Bestätigungen. Außerdem haben wir in dem mehrwöchigen Anmeldeprozess fast täglich ein Testmatching berechnet, um herauszufinden, wie viele Paare wir bilden können und um die Qualität der Matches zu überprüfen.
Was wir das nächste Mal verbessern würden
1) Die Qualität der Daten ist entscheidend. Je besser die Validierung im Formular, desto so weniger Daten muss man bereinigen.
2) E-Mail ist kein zuverlässiger Kommunikationsweg. Egal wie genau man sich an Anti-Spam-Vorgaben hält, es werden E-Mails in Spamordnern verschwinden.
3) Als Nutzer wünscht man sich genaues Feedback, in welcher Phase des Matchings man sich gerade befindet. Wir mussten viel Zeit investieren, um Nutzeranfragen zu beantworten.
4) Relevanz ist der wichtigste Faktor für gute Öffnungsraten von E-Mails. Überrascht haben uns die enorm hohen Öffnungsraten der E-Mails – mehr als 73 Prozent.
5) Die Antworten der Nutzer waren nicht unterschiedlich genug. Es gab Abweichungen häufig nur bei einer oder zwei Antworten. Eine mögliche Lösung: Beta-Test für die Fragen.
Uns ist bewusst, dass unsere Skripte keine vollständige Software im Sinne eines Produktes sind, dass sie weder skalieren, noch den Ansprüchen eines Dauerbetriebs genügen. Aber sie sind genau richtig, um die Hypothesen des Experiments „Deutschland spricht“ zu überprüfen, Menschen zum Nachdenken über Diskussionskultur anzuregen und 600 Eins-zu-eins-Gespräche in ganz Deutschland zu vermitteln. Und nun: repeat.
Dr. Andreas Loos, Data Scientist, und Michael Schultheiß, Leiter Entwicklungsredaktion
Read the English version of this blogpost here
In einer früheren Version schrieben wir „[…] in einem Google-Doc […]“. Wir haben nun detailliertere Informationen zu Google Apps ergänzt.