In einem Funnel mit kostenloser Testphase zählt der Beleg, dass Leute wie der Besucher eine Testphase gestartet und sich später fürs Bezahlen entschieden haben. Verifizierte Käufe kommen über Stripe am Ende dieses Funnels an, das stärkste Signal ist also genau dort verfügbar, wo die schwierigste Entscheidung fällt. Dieser Beitrag geht den Funnel Schritt für Schritt durch und sagt, was du zeigen solltest, was du weglassen kannst und wie es ehrlich bleibt.
Der Trial-Funnel und wo Social Proof hineinpasst
Ein typischer Self-Service-Funnel für SaaS hat vier Schritte:
- Landingpage oder Marketingseite. Der Besucher entscheidet, ob er es ausprobieren will.
- Registrierung. Er entscheidet, ob sich das Ausfüllen des Formulars lohnt.
- Onboarding und Aktivierung. Er entscheidet, ob das Produkt für ihn funktioniert.
- Umstieg auf den bezahlten Plan. Er entscheidet, ob es Geld wert ist.
Social Proof senkt das wahrgenommene Risiko, und das Risiko ändert sich mit jedem Schritt. Oben heißt es „verschwendet das meine Zeit?“. Unten heißt es „verschwendet das mein Geld?“. Den Beleg auf das Risiko abzustimmen, darum geht es.
Schritt 1 und 2: Marketingseite und Registrierung
Die Marketingseite.
Hier will der Besucher wissen, dass das Produkt echt ist, dass andere es nutzen und dass Ausprobieren wenig kostet. Passender Social Proof:
- Toasts zu verifizierten Käufen auf Preis- und Feature-Seiten, die zeigen, dass Leute auf bezahlte Pläne umsteigen. Weil die Datensätze aus signierten Stripe-Webhooks stammen, trägt jeder das Kennzeichen Verifizierter Kauf mit Link zu deiner Verifizierungsseite. Richte sie mit „only these pages“ und einem niedrigen Session-Limit aus, wie in /blog/social-proof-on-pricing-page beschrieben.
- Ein Live-Besucherzähler auf der Preisseite, wenn dort genug los ist, um das Minimum regelmäßig zu überschreiten. Der Zähler misst die Besucher der letzten 90 Sekunden und blendet sich sonst aus.
- Statischer Social Proof auf der Seite: Logos mit Erlaubnis, eine datierte Kundenzahl, ein Link zu /trust oder deiner eigenen Vertrauensseite.
Lass Toasts auf Blog und Docs weg. Leser dort lernen, sie entscheiden nicht.
Das Registrierungsformular.
Halte das Widget von der Registrierungsseite selbst fern oder erlaube höchstens einen einzelnen frühen Toast. Ein Formular ist eine Aufgabe, und Overlays während einer Aufgabe kosten Abschlüsse. Wenn du auf der Registrierungsseite Sicherheit vermitteln willst, schreib es in den Seitentext neben dem Formular: Ein Satz dazu, wie viele Leute sich diesen Monat angemeldet haben, mit Datum, ist nützlicher als eine einfliegende Benachrichtigung und unterbricht das Tippen nicht.
Schritt 3 und 4: Onboarding und Conversion
Onboarding.
Im Produkt sollte sich die Aufmerksamkeit des Besuchers während der ersten Session darauf richten, den Moment zu erreichen, in dem das Produkt sich beweist. Kauf-Toasts sind hier meist Lärm, und wir empfehlen, sie auszulassen.
Die Ausnahme ist ein echtes, durchgesetztes Willkommensangebot. Wenn neue Konten für einen festen Zeitraum nach der Registrierung einen reduzierten Preis bekommen, ist eine Evergreen-Leiste pro Besucher auf der Abrechnungsseite ehrlich und nützlich: Sie zählt dasselbe Fenster, das dein Stripe-Gutschein durchsetzt, bleibt über Besuche hinweg bestehen und verschwindet, wenn das Fenster schließt. Die Bedingungen, damit das kein Dark Pattern wird, stehen in /blog/evergreen-timers-without-dark-patterns. Zeig die Leiste nicht, wenn das Angebot nicht tatsächlich durchgesetzt wird.
Umstieg auf den bezahlten Plan.
Hier zahlt sich verifizierter Social Proof aus. Auf der Abrechnungs- oder Upgrade-Seite in der App:
- Toasts zu verifizierten Plankäufen, niedriges Limit, großer Abstand. Ein Testnutzer, der über das Upgrade nachdenkt, sieht, dass andere kürzlich für den Plan bezahlt haben, den er in Betracht zieht, und kann sich per Klick ansehen, woher diese Daten stammen.
- Die Evergreen-Leiste, wenn es ein Willkommensangebot gibt und es in seinem Zeitfenster ist.
- Keine falsche Dringlichkeit. Ein Testnutzer hat das Produkt benutzt und sich eine Meinung gebildet; ein Countdown, der sich zurücksetzt, ändert daran nichts und kann sie sogar ins Gegenteil kehren.
Wie „verifiziert“ in einem Abo-Geschäft aussieht
Bei einem SaaS mit Stripe ist das verifizierte Ereignis das, was Stripe sendet, wenn ein Abo startet oder eine Zahlung erfolgreich ist. Der Start einer Testphase ist kein Kauf und bekommt kein Verifizierungszeichen; das Zeichen ist signierten Webhooks vorbehalten, die beschreiben, dass Geld den Besitzer gewechselt hat. Das ist ein Feature. „Jemand hat eine kostenlose Testphase gestartet“ ist ein schwaches Signal, und es als Kauf aufzuhübschen wäre irreführend. Wenn du Trial-Anmeldungen zeigen willst, kennzeichne sie klar und halte sie getrennt.
| Ereignis | Quelle | Label |
|---|---|---|
| Testphase gestartet | Deine App | Kein Kauf; wenn überhaupt, als statischer Text zeigen |
| Abo erstellt, Zahlung erfolgreich | Signierter Stripe-Webhook | Verifizierter Kauf |
| Bestandskunden per CSV importiert | Upload | Imported |
Wie die Kette funktioniert, steht in /blog/how-verified-purchase-notifications-work.
Messen, ohne dich selbst zu täuschen
Trial-Funnels sind lang, und bei der Zuordnung neigen SaaS-Dashboards zum Übertreiben. Provedlys Zählung proof-unterstützter Bestellungen ordnet eine verifizierte Bestellung einer Besucher-ID zu, die in den 30 Tagen davor eine Benachrichtigung gesehen hat, und sonst nichts. Sie ist eine Obergrenze für Einfluss, keine Umsatzbehauptung. Lies sie in einem Trial-Funnel als „von den Testphasen, die konvertiert haben, hat dieser Anteil zuerst Social Proof gesehen“, und leg gelegentlich eine Phase mit und ohne Widget ein, um zu sehen, ob sich die Conversion-Rate ändert, wenn du es entfernst. Details und Grenzen stehen in /blog/measuring-proof-assisted-orders.
Ein Hinweis zum 30-Tage-Fenster: Wenn deine Testphase länger als 30 Tage dauert, fallen manche Conversions heraus und werden als nicht unterstützt gezählt. Die Zählung ist in diesem Fall zu niedrig, was die sicherere Richtung ist.
Eine Startkonfiguration
- Toasts auf
/pricingund/features*, Limit 3, Abstand 30 Sekunden, Standards auf dem Desktop, reduziert auf Mobilgeräten. - Live-Besucherzähler nur auf
/pricing, nur auf dem Desktop und nur, wenn der Traffic es hergibt. - Nichts auf Registrierung, Docs, Blog oder während des Onboardings.
- Toasts und, falls zutreffend, eine Evergreen-Willkommensleiste auf der Abrechnungsseite in der App.
- Stripe verbunden, damit jeder Toast ein verifizierter Kauf ist; Sample-Datensätze archiviert, sobald echte eintreffen.
Der Free-Plan von Provedly enthält verifizierte Käufe, eine Website, ein Widget und eine Leiste mit 2.000 Impressionen pro Monat, was einen kleinen Trial-Funnel abdeckt. Die Pläne findest du unter /pricing.
Häufige Fragen
Sollte ich Toasts wie „X Personen haben heute eine Testphase gestartet“ zeigen?
Nur wenn die Zahl echt ist und als Testphase gekennzeichnet ist, nicht als Kauf. Provedly verifiziert keine Trial-Starts, ein solcher Toast würde also das Label Imported oder Sample tragen, nie das Verifizierungszeichen. Statischer Text mit Datum ist meist das bessere Format.
Wo helfen Toasts in einem Trial-Funnel am meisten?
Auf der Preisseite vor der Registrierung und auf der Abrechnungsseite vor dem Upgrade. Beides sind Momente, in denen der Besucher Geld gegen Nutzen abwägt, und genau diese Frage beantworten verifizierte Käufe.
Kann ich Social Proof in der App und auf der Marketingseite mit einem Konto betreiben?
Der Free-Plan deckt eine Website und ein Widget ab. Starter für $9 deckt zwei Websites und fünf Widgets ab, was für eine Marketingseite plus eine App auf getrennten Domains passt.
Leg ein kostenloses Provedly-Konto an und verbinde Stripe: /register.