Kostenlose Testlizenzen für Desktop-Software: Testphasen, die verkaufen, ohne missbraucht zu werden

Sie fügen Ihrem Desktop-Tool eine 14-tägige Testphase hinzu, und die Downloads steigen. Die Verkäufe nicht. Einen Monat später finden Sie einen Forenbeitrag, der erklärt, dass das Löschen eines einzigen Registry-Schlüssels die Testphase neu startet, dazu ein kleines Skript, das dies bei jedem Systemstart tut. Einige Ihrer aktivsten Nutzer stehen seit dem Frühjahr am ersten Tag ihrer Testphase.

Dieser Leitfaden zeigt, wie Sie eine kostenlose Testphase für Desktop-Software so aufbauen, dass sie standhält: die drei Arten von Tests und wann jede passt, warum Tests, die auf dem Rechner des Kunden erzwungen werden, zurückgesetzt werden, wie serverseitige Testschlüssel funktionieren, die an eine Hardware-ID gebunden sind, und wie Sie einen Testnutzer ohne Reibungsverluste zu einer kostenpflichtigen Lizenz führen. Am Ende steht ein illustratives C++-Beispiel, das Sie an Ihr Lizenzsystem anpassen können.

So fügen Sie Desktop-Software eine kostenlose Testphase hinzu

Die kurze Antwort: Behandeln Sie den Test als Lizenz, nicht als Timer. Startet ein neuer Nutzer die App, fragt sie Ihren Lizenzserver nach einem Test. Der Server prüft, ob dieses Gerät schon einmal einen Test hatte, und wenn nicht, stellt er einen zeitlich begrenzten Lizenzschlüssel aus, der an die Hardware-ID des Geräts gebunden ist. Jeder Start prüft diesen Schlüssel dann auf dem Server, genau wie einen kostenpflichtigen Schlüssel. Nach Ablauf des Tests akzeptiert der Server ihn nicht mehr, und der Nutzer gibt auf demselben Rechner einen Kaufschlüssel ein.

Alles andere in diesem Leitfaden baut auf diesem Modell auf: welche Grenzen Sie setzen, wie Sie ein Gerät identifizieren, was bei fehlender Netzwerkverbindung geschieht und wie Sie die letzten Tage einer Testphase in einen Verkauf verwandeln.

Zeitlich begrenzte, funktionsbegrenzte und nutzungsbegrenzte Tests

Es gibt drei gängige Wege, einen Test zu begrenzen, und viele Produkte kombinieren zwei davon. Welcher passt, hängt davon ab, wie schnell ein neuer Nutzer den Moment erreicht, in dem Ihre Software ihren Wert zeigt.

Ein zeitlich begrenzter Test ist der bekannteste: 7, 14 oder 30 Tage mit allen aktivierten Funktionen. Er schafft eine natürliche Frist, was die Umwandlung unterstützt, ist aber die Art, die am häufigsten zurückgesetzt wird. Ein funktionsbegrenzter Test, manchmal Freemium genannt, läuft nie ab, hält aber die wertvollen Funktionen hinter einem Kaufschlüssel. Er ist nachsichtiger mit Nutzern, die lange für eine Entscheidung brauchen, und seine Schwachstelle ist das Flag, das darüber entscheidet, ob eine Funktion aktiv ist. Ein nutzungsbegrenzter Test zählt Aktionen, etwa zehn Exporte oder drei gerenderte Projekte, und eignet sich für Tools, bei denen jede Aktion offensichtlichen Wert hat.

Welche Sie auch wählen, dieselbe Regel gilt: Die Grenze muss an einem Ort durchgesetzt werden, den der Nutzer nicht bearbeiten kann. Bei einem Zeitlimit heißt das die Uhr des Servers. Bei einem Funktionslimit heißt das, dass die Premium-Logik oder die Daten nur für kostenpflichtige Schlüssel vom Server kommen. Bei einem Nutzungslimit heißt das, dass der Zähler auf dem Server liegt.

Warum lokale Testtimer zurückgesetzt werden

Die meisten Tests, die undicht werden, sind auf dieselbe Weise umgesetzt: Beim ersten Start schreibt die Anwendung irgendwo auf dem PC ein Installationsdatum, und bei jedem späteren Start vergleicht sie dieses Datum mit der Systemuhr. Jeder Teil dieses Entwurfs liegt unter der Kontrolle des Nutzers.

• –Registry- und Dateimarkierungen. Das Installationsdatum liegt in einem Registry-Schlüssel, einer Datei im AppData-Ordner oder einer versteckten Datei. Hat jemand sie mit einem Datei- oder Registry-Monitor gefunden, startet das Löschen einen neuen Test. Den Namen zu verschleiern verzögert das nur.
• –Neuinstallation. Ein Deinstallationsprogramm, das Ihre Markierungen entfernt, entfernt auch den Testverlauf. Eines, das sie zurücklässt, verursacht Beschwerden über Dateireste, und die Markierungen lassen sich trotzdem finden und entfernen.
• –Uhrzeitänderungen. Vergleicht der Test mit der Systemuhr, verlängert das Zurückstellen des Datums ihn. Die Erkennung von Sprüngen rückwärts hilft ein wenig, doch der Nutzer kontrolliert die Uhr schon, bevor Ihre App überhaupt läuft.
• –Virtuelle Maschinen und Snapshots. Installieren Sie die App in einer VM, erstellen Sie einen Snapshot und stellen Sie ihn wieder her, wenn der Test endet. Jede Wiederherstellung ist ein frischer Erststart, und auf dem Rechner erinnert sich nichts daran.
• –Die Prüfung patchen. Selbst mit einer perfekten Markierung läuft der Vergleich in Ihrer Binärdatei. Ein Cracker ändert einen bedingten Sprung, und der Test endet nie.

Das heißt nicht, dass lokale Markierungen nutzlos sind. Sie sind ein brauchbarer erster Hinweis und erlauben der App, eine sinnvolle Meldung anzuzeigen, bevor sie das Netzwerk erreicht. Sie dürfen nur nicht darüber entscheiden, ob der Test noch gültig ist. Dasselbe Argument gilt für Lizenzierung im Allgemeinen, und clientseitiger Schutz im Vergleich zu serverseitigen Geheimnissen behandelt es ausführlicher.

Serverseitige Testschlüssel, gebunden an eine Hardware-ID

Ein serverseitiger Test ersetzt den lokalen Timer durch einen echten Lizenzschlüssel, der zufällig kurzlebig ist. Der Schlüssel wird von Ihrem Server erstellt, sein Ablauf wird auf Ihrem Server gespeichert, und er ist an den Hardware-Fingerabdruck des Geräts gebunden, das ihn angefordert hat. Es ist derselbe Mechanismus, der in was HWID-Locking ist und wie es funktioniert beschrieben wird, angewendet auf einen Schlüssel, der Tage statt Jahre gilt.

1. 01

   Gerät fingerprinten

   Beim ersten Start berechnet die App einen Hash aus stabilen Hardware-Komponenten, etwa Mainboard- und Prozessorkennungen. Senden Sie nur den Hash, niemals die Rohwerte.

2. 02

   Test anfordern

   Die App sendet den Fingerabdruck über einen verschlüsselten, signierten Kanal an Ihren Lizenzserver und fragt nach einem Test.

3. 03

   Testverlauf prüfen

   Der Server sucht den Fingerabdruck nach. Hatte dieses Gerät nie einen Test, erstellt er einen Testschlüssel mit fester Laufzeit und bindet ihn an den Fingerabdruck. Hatte es bereits einen, lehnt er ab.

4. 04

   Bei jedem Start prüfen

   Die App sendet Testschlüssel und Fingerabdruck bei jedem Start. Der Server vergleicht den Ablauf mit seiner eigenen Uhr, daher hat eine Änderung des Datums auf dem PC keine Wirkung.

5. 05

   Nur freigeben, was die App braucht

   Nur eine gültige Sitzung erhält Konfiguration, Strings oder Dateien, von denen die App abhängt. Eine gepatchte Prüfung lässt ein Programm dann ohne etwas zum Ausführen zurück.

Da der Verlauf dem Gerät zugeordnet ist und nicht etwas, das auf ihm gespeichert wird, führen eine Neuinstallation, das Leeren von AppData oder das Löschen von Registry-Einträgen alle zur gleichen Antwort des Servers. Der letzte Schritt verhindert den gepatchten Sprung: Hängt der Testaufbau von Daten ab, die nur eine authentifizierte Sitzung erhält, entfernt das Entfernen der Prüfung auch die Daten.

Ein Test pro Gerät: die Grenzfälle behandeln

„Ein Test pro Gerät“ klingt einfach, bis echte Nutzer kommen. Einige Fälle tauchen in fast jedem Produkt auf, und jeder braucht vor dem Start eine Entscheidung und nicht erst ein Support-Ticket danach.

• –Virtuelle Maschinen. Eine frische VM erzeugt einen frischen Fingerabdruck, und genau so funktioniert der Missbrauch durch VM-Snapshots. Virtualisierte Umgebungen zu erkennen und dort Tests abzulehnen oder eine E-Mail zu verlangen, schließt den größten Teil der Lücke. Beachten Sie, dass manche seriösen Nutzer in VMs arbeiten. Entscheiden Sie daher, ob Sie ablehnen oder nur mehr verlangen.
• –Hardwarewechsel. Ein Nutzer, der mitten im Test eine Systemfestplatte austauscht, erzeugt womöglich einen neuen Fingerabdruck. Wenn Sie den Fingerabdruck aus mehreren stabilen Komponenten bilden und eine teilweise Übereinstimmung zulassen, bleibt er beim selben Test.
• –Geteilte Rechner und Labore. Ein Klassenraum-PC hatte möglicherweise einen Test von einem früheren Schüler. Geben Sie Ihrem Support-Team eine Möglichkeit, manuell einen zweiten Test zu gewähren.
• –Zweite Bewertungen. Wer Version 2 getestet hat, verdient vielleicht einen neuen Blick auf Version 4. Eine Testrichtlinie pro Hauptversion oder eine manuelle Verlängerung löst das, ohne eine Lücke zu öffnen.
• –Konten zusätzlich zu Geräten. Eine E-Mail-Abfrage beim Teststart fügt eine zweite Identität zur Prüfung hinzu und gibt Ihnen eine Möglichkeit, den Nutzer zu erreichen. Sie erhöht aber auch die Hürden. Testen Sie, ob sie mehr Anmeldungen kostet, als sie einbringt.

Ein Testablauf in C++, Schritt für Schritt

Das Beispiel unten zeigt, wo die Testlogik in einer C++-Anwendung sitzt. Es verwendet Platzhalternamen für einen allgemeinen Lizenz-Client, damit die Struktur klar ist, ohne sie an ein bestimmtes SDK zu binden. Das Muster ist in C# dasselbe: Schlüssel anfordern oder laden, auf dem Server prüfen und bei fehlgeschlagener Prüfung den Zugriff verweigern.

// Nur zur Veranschaulichung. Licensing::*, LoadStoredKey, SaveKey und die
// UI-Funktionen sind Platzhalter für Ihr Lizenz-SDK und Ihren eigenen Code,
// keine API-Namen von qPapel Auth.

int main()
{
    Licensing::Client lic;                      // verschlüsselter, signierter Kanal
    std::string fingerprint = lic.HardwareId(); // auf dem Gerät gehasht

    std::string key = LoadStoredKey();          // Kauf- oder Testschlüssel, falls vorhanden
    if (key.empty())
    {
        auto trial = lic.RequestTrial(fingerprint);
        if (!trial.granted)
        {
            ShowBuyScreen("A trial was already used on this device.");
            return 0;
        }
        key = trial.key;                        // kurzlebig, an HWID gebunden
        SaveKey(key);                           // ein Hinweis, nicht die maßgebliche Quelle
    }

    auto session = lic.Validate(key, fingerprint); // Ablauf auf dem Server geprüft
    if (!session.valid)
    {
        ShowBuyScreen(session.reason);          // abgelaufen, gesperrt, falsches Gerät
        return 0;                               // im Fehlerfall verweigern
    }

    if (session.isTrial && session.daysLeft <= 3)
        ShowUpgradeBanner(session.daysLeft);    // Hinweis vor Ablauf

    auto config = session.FetchConfig();        // nur für gültige Sitzungen
    RunApp(config, session.isTrial);
}

Drei Details wiegen schwerer als alle anderen. Der auf der Festplatte gespeicherte Schlüssel ist nur eine Komfortfunktion, daher führt sein Löschen zu einer neuen Testanfrage, die der Server für ein bekanntes Gerät ablehnt. Der Ablauf wird auf dem Server verglichen, die Uhr des PCs ist also unerheblich. Und die Konfiguration, die die App braucht, kommt nur mit einer gültigen Sitzung, und genau das macht das Patchen von session.valid sinnlos. Der C++-Authentifizierungsleitfaden und sein C#-Pendant behandeln die Sitzung selbst ausführlicher.

Einen Test in eine kostenpflichtige Lizenz umwandeln

Missbrauch zu stoppen schützt Umsatz, den Sie sonst verlieren würden. Die Umwandlung ist die Stelle, an der der Umsatz entsteht. Die Mechanik ist einfach: Der Nutzer kauft einen Kaufschlüssel, gibt ihn auf demselben Rechner ein, und die App prüft ihn anstelle des Testschlüssels. Die Details entscheiden, wie viele Nutzer es tatsächlich tun.

• –Kauf direkt in der App ermöglichen. Ein Button „Jetzt kaufen“, der Ihren Checkout mit dem richtigen Produkt öffnet, entfernt einen Suchschritt. Liefern Sie den Schlüssel sofort nach der Zahlung, damit der Nutzer ihn einfügen kann, während die App noch offen ist.
• –Die Arbeit behalten. Was der Nutzer während des Tests erstellt hat, sollte nach dem Upgrade noch da sein. Ein verlorenes Projekt im Moment des Kaufs ist eine Rückerstattung, die nur darauf wartet, zu passieren.
• –Den Kaufschlüssel an dasselbe Gerät binden. Der Test hat bereits bewiesen, welchen Rechner der Nutzer verwendet, daher kann der Kaufschlüssel bei der ersten Prüfung ohne zusätzlichen Schritt gebunden werden.
• –Einen Grund geben, sich jetzt zu entscheiden. Ein Gutschein, der in den letzten Tagen des Tests oder eine Woche danach gilt, gibt der Frist einen konkreten Vorteil.
• –Abgelaufene Tests sauber behandeln. Wenn der Test endet, zeigen Sie, was der Nutzer durch den Kauf behält, und einen klaren Weg dorthin, statt einer nackten Fehlermeldung.

Wenn Sie Abonnements statt unbefristeter Lizenzen verkaufen, wird der Test zur ersten Periode des Tarifs statt zu einem separaten Schlüssel. Abonnement-Lizenzierung für Software erklärt, wie Verlängerungen und Ablauf mit der Schlüsselprüfung zusammenspielen.

E-Mails und In-App-Hinweise, die umwandeln

Die meisten Testnutzer entscheiden sich nicht gegen Ihr Produkt. Sie vergessen es. Eine kleine Zahl gut getimter Erinnerungen, in der App und per E-Mail, falls Sie eine Adresse erhoben haben, holt einen Teil von ihnen zurück.

Richten Sie die Nachrichten danach aus, was der Nutzer getan hat, nicht nur nach dem Kalender. Wer fünf Projekte exportiert hat, braucht einen Preis und einen Kaufbutton. Wer die Einrichtung nie abgeschlossen hat, braucht Hilfe, keinen Countdown. Da der Server jede Prüfung sieht, wissen Sie bereits, wer aktiv ist, was nützlicher ist als jede Öffnungsrate. Halten Sie die Zahl der E-Mails klein und bieten Sie immer eine Möglichkeit zur Abmeldung.

Tests mit PapelShip betreiben

qPapel Auth bietet die serverseitigen Bausteine, auf die sich dieser Leitfaden stützt, für Software in C, C++ und C#: Lizenzschlüssel, die auf dem Server geprüft werden, HWID-Sperre mit Reset-Sperrzeiten, verschlüsselte und signierte Sitzungen sowie serverseitige Strings und Dateien, die erst nach einer gültigen Prüfung ausgeliefert werden. Der Schutz gegen virtuelle Maschinen hilft beim Snapshot-Problem, und Remote-Einstellungen erlauben es, das Verhalten anzupassen, ohne einen neuen Build auszuliefern, wie in Schutz aus der Ferne aktualisieren ohne neuen Build beschrieben.

Auf der Verkaufsseite liefert der PapelShip-Shop Lizenzschlüssel nach der Zahlung sofort aus, unterstützt Gutscheine für Angebote zum Testende und akzeptiert Karten- und Kryptozahlungen in einem einzigen Checkout. Tarife starten kostenlos; die Gebühren finden Sie unter Preise, oder unter der Übersicht zur Software-Lizenzierung, wie die Teile zusammenpassen. Wenn Sie noch überlegen, wie Sie Schlüssel überhaupt verkaufen, ist Software-Lizenzen online verkaufen ein guter Einstieg.

Tests, die enden, wenn sie enden sollen

Ein Test ist ein Versprechen an den Nutzer und an Sie selbst: voller Zugriff für eine Weile, dann eine Entscheidung. Wenn Sie ihn auf dem Server durchsetzen, an das Gerät binden und das Upgrade zu einem einzigen Schritt machen, halten Sie dieses Versprechen in beide Richtungen. Ehrliche Nutzer erhalten eine faire Bewertung, und wer ein Reset-Skript sucht, stellt fest, dass auf seinem Rechner nichts zum Zurücksetzen liegt.