Rewards

Bei wissenschaftlichen Studien, Marktforschungsprojekten oder Kundenbefragungen werden Teilnehmer häufig für ihre Teilnahme incentiviert. Ein typisches Modell ist einfach: Wer eine Befragung vollständig abschließt, erhält anschließend einen Gutscheincode.

Auf den ersten Blick scheint dafür nicht viel notwendig zu sein. Es gibt einen Bestand an Gutscheincodes, eine abgeschlossene Teilnahme und eine Adresse, an die die Prämie verschickt werden soll.

Bei genauerem Hinsehen entstehen jedoch einige fachliche Fragen:

• Wann genau entsteht der Anspruch auf eine Prämie?
• Wie wird sichergestellt, dass eine Teilnahme nur einmal belohnt wird?
• Woher stammt die Kontaktadresse des Empfängers?
• Wie werden Gutscheincodes verwaltet und einzelnen Teilnahmen zugeordnet?
• Was passiert, wenn die Zustellung fehlschlägt?
• Und wie lässt sich das alles so integrieren, dass LimeSurvey weiterhin das tut, was es gut kann: Befragungen durchführen?

Der interessante Teil ist dabei nicht der Versand einer Prämie. Der entscheidende Punkt ist die Verbindung zwischen einer abgeschlossenen Befragung und dem daraus entstehenden Anspruch.

Was wird eigentlich belohnt?

Die naheliegende Antwort wäre zunächst: der Teilnehmer.

Für eine saubere Modellierung ist das jedoch zu ungenau. Eine Kontaktadresse kann an mehreren Befragungen teilnehmen. Ein Teilnehmer kann mehrfach zur Teilnahme eingeladen worden sein. Bei anonymen Befragungen existiert möglicherweise überhaupt keine Teilnehmeridentität.

Was eindeutig feststeht, ist eine abgeschlossene Teilnahme.

Damit lässt sich die fachliche Regel präziser formulieren:

Eine erfolgreich abgeschlossene Teilnahme kann einen Anspruch auf eine Prämie erzeugen.

Die Teilnahme ist damit der Ausgangspunkt der Zuweisung. Die Empfängeradresse wird erst anschließend benötigt, um die Prämie zuzustellen.

Diese Unterscheidung ist wichtig:

Teilnahme abgeschlossen
        ↓
Prämie zuweisen
        ↓
Empfänger bestimmen
        ↓
Prämie zustellen

Zuweisung und Zustellung sind zwei unterschiedliche Vorgänge – und genau diese Trennung wird interessant, sobald etwas schiefgeht.

Woher kommt die Empfängeradresse?

Nicht jede Befragung verwaltet Teilnehmer auf dieselbe Weise.

Bei einer nicht anonymisierten Befragung mit Einladungsverwaltung kann eine Kontaktadresse bereits vorliegen. Bei anderen Befragungen wird sie stattdessen innerhalb des Fragebogens selbst erhoben.

Eine tragfähige Lösung darf deshalb nicht vorschreiben, wie eine Befragung aufgebaut sein muss. Sie benötigt lediglich eine Strategie, mit der sich für eine abgeschlossene Teilnahme ein Empfänger ermitteln lässt – wahlweise aus der Teilnehmerverwaltung oder aus einer Antwort im Fragebogen.

Damit entstehen zwei getrennte fachliche Konzepte:

Anspruchsprüfung – bestimmt, ob und welche Prämie aufgrund einer abgeschlossenen Teilnahme vergeben wird.

Empfängerermittlung – bestimmt, wohin diese Prämie zugestellt wird.

Diese Trennung wird insbesondere bei anonymen Befragungen relevant, bei denen die Zustellung einer Prämie die Anonymität der eigentlichen Befragungsdaten nicht aufheben darf.

Prämien als Bestand, nicht als Einzelfall

Gutscheincodes werden üblicherweise nicht einzeln gepflegt. Ein Betreiber erhält beispielsweise eine größere Menge an Codes eines bestimmten Anbieters und möchte diese über eine oder mehrere Befragungen hinweg einsetzen.

Daraus ergibt sich ein weiteres fachliches Objekt: ein Bestand an verfügbaren Prämien, aus dem bei jeder Zuweisung ein einzelner Code entnommen wird. Eine Befragung kann einem solchen Bestand zugeordnet werden, statt einzelne Prämien direkt zu hinterlegen.

Die Verwaltung dieses Bestands ist bewusst schlank gehalten: Es wird kein monetärer Wert erzeugt, sondern lediglich ein bereits vorhandener Bestand verwaltet und einzelnen abgeschlossenen Teilnahmen zugeordnet.

Zuweisung und Zustellung sind nicht dasselbe

Dieser Unterschied wird wichtig, sobald Fehler auftreten.

Angenommen, einer abgeschlossenen Teilnahme wurde bereits ein konkreter Gutscheincode zugewiesen. Beim anschließenden Versand tritt jedoch ein technisches Problem auf – der Versanddienst ist gerade nicht erreichbar.

Beim nächsten Versuch darf nicht einfach ein weiterer Code aus dem Bestand entnommen werden. Der fachliche Zustand lautet bereits: Diese Teilnahme hat eine Prämie zugewiesen bekommen, deren Zustellung fehlgeschlagen ist. Nicht: Diese Teilnahme hat noch keine Prämie.

Die Zuweisung muss deshalb dauerhaft festgehalten werden, bevor die Zustellung überhaupt versucht wird. Entscheidend ist, dass für denselben Anspruch nicht versehentlich mehrere Prämien vergeben werden. Damit wird die Verarbeitung wiederholbar: Auch wenn ein Zustellversuch erneut angestoßen wird, entsteht kein zweiter Gutschein für dieselbe Teilnahme.

LimeSurvey bleibt Survey Engine

Auch hier gilt dasselbe Prinzip, das sich bei komplexeren LimeSurvey-Anwendungsfällen immer wieder zeigt: Die Befragungslogik gehört zu LimeSurvey. Die Incentivierung ist eine eigenständige Fachlichkeit. Sie entsteht unmittelbar aus dem Ablauf einer Befragung, gehört aber nicht zur eigentlichen Befragungslogik.

Survey, Teilnahme und gegebenenfalls Teilnehmerdaten bleiben dort, wo diese Informationen bereits vorhanden sind. Ergänzt wird lediglich eine klar abgegrenzte Beziehung: Diese abgeschlossene Teilnahme hat diese Prämie erhalten.

Gerade diese Beziehung – nicht der eigentliche Versand des Gutscheincodes – ist für eine zuverlässige Incentivierung der entscheidende Teil.

Ein Konzept, keine fertige Software

Die technische Aufgabe „nach einer Umfrage eine Prämie verschicken" wirkt klein. Das dahinterliegende fachliche Problem ist interessanter: Eine abgeschlossene Teilnahme kann einen Prämienanspruch erzeugen. Dieser Anspruch muss genau einmal erfüllt, einer konkreten Prämie zugeordnet und anschließend an einen bestimmbaren Empfänger zugestellt werden – zuverlässig auch dann, wenn einzelne Schritte fehlschlagen.

Für dieses Problem habe ich ein Architekturkonzept ausgearbeitet, das diese Trennung von Anspruch, Zuweisung und Zustellung konsequent durchhält und LimeSurvey dabei unverändert als Survey Engine belässt. Das Konzept ist bewusst noch keine fertige Software: Ob und wie daraus eine konkrete Anwendung entsteht, hängt vom tatsächlichen Bedarf eines konkreten Projekts ab. Bei konkretem Bedarf lässt sich auf dieser Grundlage sehr gezielt über Anforderungen und Umsetzung sprechen.