Kaufprozess messen und verbessern: Analytik je Schritt und A/B-Tests

1Ausgangslage

Unser Kaufprozess (Vertragsverkauf über das Angebots-Widget auf der Website und im Portal) hat heute diese Stationen:

1. Angebotsseite mit Tarifkarten gesehen
2. Tarif gewählt
3. Schritt 1 „Persönliche Daten"
4. Schritt 2 „Kontakt"
5. Schritt 3 „Zahlung" (Zahlungsart, Lastschrift-Daten)
6. Knopf „Kaufen" gedrückt, Bestellung angelegt
7. Zahlungsseite (nur bei Zahlungslink) abgeschlossen
8. Übertragung ins Studiosystem (Magicline, Agilea): übertragen, abgeschlossen oder fehler
9. Aktivierung (Magicline: Vertrag aktiv; Agilea: direkt oder über Freischaltung)

Gemessen wird davon heute nur das Ende: Verkäufe mit Status und der Trichter „Anfragen, Termine, Verträge" im Cockpit. Alles zwischen „Seite gesehen" und „Kaufen gedrückt" ist blind. Wenn 200 Leute die Angebotsseite sehen und 6 kaufen, wissen wir nicht, ob 150 schon bei den Tarifkarten gehen oder 60 im Zahlungsschritt hängen bleiben.

Randbedingungen: Der echte Test braucht die finale Freischaltung durch Magicline (kommt in Kürze). SimGym hat die echte WhatsApp-Nummer. Life X läuft über Agilea auf der Testinstanz, dort lässt sich der komplette Prozess schon heute durchspielen.

2Teil A: Analytik je Schritt (zuerst)

2.1 Was gemessen wird

Jede Sitzung im Kaufprozess erzeugt Ereignisse. Eine Sitzung ist eine zufällige Kennung, die das Widget beim ersten Aufruf erzeugt und im Browser des Nutzers behält (30 Tage). Keine Personendaten, kein Fingerabdruck, keine Drittanbieter, kein Cookie von uns. Erst mit der Bestellung entsteht eine Verbindung zum Verkauf, und die liegt ohnehin in unserer Datenbank.

Die Ereignisse 1 bis 9 schickt das Widget mit sendBeacon an den Hub (eine kleine Route je Angebot, mit Ratenbremse). Die letzten drei schreibt der Hub selbst, wenn sich der Verkauf ändert. So bleibt der Trichter bis zur Aktivierung durchgängig.

2.2 Was wir sehen

Ein Trichter je Angebot und Zeitraum:

Dazu die Aufschlüsselung, die den Unterschied macht:

• Abbruch je Feld: Welches Feld war zuletzt aktiv, welches hat den Fehler erzeugt. Beispiel: „Telefon" ist bei Agilea Pflicht, wenn dort 40 Prozent aussteigen, ist das ein konkreter Befund.
• Zeit je Schritt: Wo verbringen Leute lange, wo klicken sie sofort weg.
• Nach Gerät: Handy gegen Rechner. Ein Zahlungsschritt, der auf dem Handy 70 Prozent verliert und auf dem Rechner 30, ist ein Darstellungsproblem.
• Nach Tarif und nach Herkunft (Google Ads, Meta, Website, WhatsApp-Einstieg, Kampagne).
• Nach Position der Tarifkarte: Kauft jemand die dritte Karte, oder nur die erste.

2.3 Wo es angezeigt wird

• Portal-Cockpit, Reiter Zahlen: neuer Block „Kaufprozess" mit dem Trichter als Balken je Station, Umschalter Angebot, Zeitraum, Gerät. Darunter die drei größten Abbruchstellen als Klartext („45 Prozent brechen bei den persönlichen Daten ab, meist beim Feld Geburtsdatum").
• Zentrale, Cockpit-Karte: dasselbe, plus Rohliste der letzten Sitzungen für die Fehlersuche.
• Kampagnen: Trichter je Kampagnen-Kennung, damit man sieht, ob Werbe-Besucher anders abbrechen als Website-Besucher.
• Copilot: Werkzeug kaufprozess_trichter, damit „Wo brechen die Leute ab?" eine Antwort mit Zahlen bekommt.
• Monatszahlen im Portal: eine Zeile „Kaufprozess: Sichtkontakte, Bestellungen, Quote".

2.4 Datenschutz

• Sitzungskennung zufällig, im Browser-Speicher des Nutzers, 30 Tage, kein Cookie, keine IP-Speicherung, keine Drittanbieter. Damit ist es keine Reichweitenmessung Dritter, sondern eine technisch notwendige Eigenmessung ohne Personenbezug bis zur Bestellung. Der Datenschutztext der Website bekommt trotzdem einen Absatz (Vorlage liefern wir mit).
• Feldwerte werden nie gespeichert, nur Feldnamen und Fehlergründe.
• Aufbewahrung 13 Monate, danach Verdichtung auf Tageswerte.

3Teil B: A/B-Tests

3.1 Was ein A/B-Test hier bedeutet

Zwei Fassungen desselben Kaufprozesses laufen gleichzeitig. Jede neue Sitzung bekommt zufällig Fassung A oder B zugeteilt und bleibt dabei (die Zuteilung hängt an der Sitzungskennung). Nach genug Sitzungen vergleichen wir: Welche Fassung führt öfter zur Bestellung. Die bessere wird für alle geschaltet.

Wichtig für die Vorstellung: Es geht nicht um zwei verschiedene Websites, sondern um einen Schalter im Widget, der eine Sache anders macht.

3.2 Was wir testen würden, und was nicht

Sinnvolle Tests, in dieser Reihenfolge:

1. Drei Schritte gegen eine Seite: Sind die Abbrüche zwischen den Schritten das Problem, oder das lange Formular.
2. Reihenfolge der Schritte: Kontakt zuerst (nur Name, E-Mail, Telefon), dann persönliche Daten. Wer Kontakt eingegeben hat, ist als Lead da, auch wenn er später abbricht.
3. Reihenfolge und Hervorhebung der Tarifkarten: empfohlene Karte in der Mitte gegen links, „beliebt"-Etikett ja oder nein.
4. Preisdarstellung: Monatsbeitrag groß mit Laufzeit klein, gegen Gesamtpreis. Der Preis selbst bleibt gleich.
5. Wortlaut des Knopfs: „Jetzt Mitglied werden" gegen „Kostenlos starten" (bei Probetraining-Angeboten).
6. Vertrauenselemente: Bewertungen und „Widerruf 14 Tage" neben dem Zahlungsschritt, ja oder nein.
7. Reihenfolge der Zahlungsarten.

Nicht getestet werden Preise, Laufzeiten, Vertragsinhalte, Pflichtangaben aus dem Recht. Alle Nutzer bekommen denselben Vertrag zu denselben Bedingungen. Das ist die Regel, die den Test rechtlich sauber hält, und sie steht als Sperre im Code: Eine Variante darf nur Darstellungsparameter ändern.

3.3 Mechanik

• Je Angebot höchstens ein laufender Test mit zwei Fassungen (A = heutiger Stand, B = eine Änderung). Mehr Fassungen gleichzeitig verwässern die Zahlen bei unseren Mengen.
• Ein Test ist ein Datensatz: Angebot, Name, Änderung (aus einer festen Liste von Schaltern, siehe 3.2), Start, Mindestumfang, Ziel (primär Bestellung, sekundär Aktivierung), Status (läuft, entschieden, abgebrochen).
• Das Widget bekommt beim Laden die Zuteilung und den Änderungssatz. Kein Flackern, keine zweite Seite.
• Alle Ereignisse aus Teil A tragen die Fassung. Damit haben wir nicht nur „B kauft öfter", sondern „B kauft öfter, weil im Zahlungsschritt weniger abbrechen".

3.4 Wann ein Gewinner feststeht

Klassische Statistik braucht große Zahlen. Ehrliche Rechnung: Bei 3 Prozent Bestellquote und einer erhofften Verbesserung um ein Drittel braucht man rund 2.500 Sitzungen je Fassung, um sicher zu sein. Ein Einzelstudio mit 300 Angebots-Besuchern im Monat wäre damit ein halbes Jahr beschäftigt. Das ist der Grund, warum A/B-Tests bei Einzelstudios selten funktionieren.

Deshalb zwei Dinge:

1. Auswertung nach dem Bayes-Verfahren statt Signifikanztest. Ergebnis ist ein Satz, den ein Studiobetreiber versteht: „Fassung B ist mit 92 Prozent Wahrscheinlichkeit besser, erwarteter Unterschied plus 1,1 Punkte Bestellquote." Der automatische Gewinner wird ausgerufen, wenn die Wahrscheinlichkeit 95 Prozent erreicht und beide Fassungen einen Mindestumfang haben (Vorschlag 150 Sitzungen und 10 Bestellungen je Fassung), oder wenn nach 60 Tagen kein Unterschied erkennbar ist (dann bleibt A, Test wird archiviert).
2. Flotten-Tests: Dieselbe Änderung läuft bei mehreren Kunden gleichzeitig, die Ergebnisse werden zusammengerechnet. Zehn Studios mit je 300 Besuchern sind 3.000 Besucher im Monat. So lernen wir als Agentur, was funktioniert, und der einzelne Kunde profitiert vom Ergebnis der Flotte. Das kann TRINITY mit 675 Studios, wir mit unserer Flotte in kleinem Maßstab. Voraussetzung: Die Änderung ist bei allen Teilnehmern dieselbe (z. B. „Kontakt zuerst"), und jeder Kunde kann in der Akte aussteigen.

3.5 Wo es bedient wird

• Zentrale, Cockpit-Karte, Reiter „Tests": Test anlegen (Angebot, Änderung aus der Liste, Mindestumfang), Verlauf mit beiden Fassungen, Wahrscheinlichkeit, Knopf „Gewinner übernehmen" oder automatisch.
• Zentrale, Flotte: Flotten-Test anlegen, Teilnehmer wählen, Gesamtergebnis und je Kunde.
• Portal: Der Kunde sieht laufende Tests und Ergebnisse im Reiter Zahlen unter dem Kaufprozess, kann Tests aber nicht anlegen (das machen wir), und kann aus Flotten-Tests aussteigen.
• Copilot: „Läuft gerade ein Test, und wer führt?"

4Etappen und Aufwand

Gesamt rund 10 AT. E1 und E2 zuerst, dann liefern die Zahlen zwei bis vier Wochen lang Befunde, und erst danach wissen wir, welcher Test als erster lohnt. E3 bis E5 danach.

Pilot: SimGym (Sandbox) für die Technik, Life X auf der Testinstanz für einen echten Durchlauf mit Agilea, dann der erste Magicline-Club nach der Freischaltung.

5Entscheidungen

1. Sitzungskennung im Browser-Speicher ohne Einwilligungsabfrage (unsere Einschätzung: technisch notwendig, kein Personenbezug), oder lieber hinter das Cookie-Banner hängen und damit weniger Daten.
2. Mindestumfang für den automatischen Gewinner: 150 Sitzungen und 10 Bestellungen je Fassung, oder strenger.
3. Flotten-Tests: grundsätzlich ja, und ob Kunden standardmäßig dabei sind (mit Ausstieg) oder standardmäßig draußen (mit Einstieg).
4. Erste Testkandidaten: „Kontakt zuerst" und „Drei Schritte gegen eine Seite" als Vorschlag.
5. E1 und E2 jetzt bauen, E3 bis E5 nach den ersten Befunden.