Come implementare una funzione di "autodistruzione" nella versione di prova gratuita del mio software?

È in corso l'argomento della prova gratuita rispetto a un modello freemium (ovvero una versione gratuita del loro software con funzionalità limitate e / o ridotte) per consentire a potenziali clienti e utenti di testare l'esecuzione del loro prodotto. Sulla base delle mie ricerche, posso concludere che la prova gratuita è la strada da percorrere sia a beneficio dell'esperienza utente dell'individuo che utilizza il software sia a beneficio del venditore in entrambi gli aspetti delle vendite e della massimizzazione dell'utilizzo. Esistono molti fattori per un software di prova gratuito che può massimizzare notevolmente l'utilizzo degli utenti come la durata della prova gratuita.

Una parola chiave che si ripete nella mia ricerca per "freemium" è "frustrante". Molte persone hanno scelto di disinstallare il software invece di dover utilizzare un software in cui alcune funzionalità non erano disponibili per loro. Allo stesso tempo, questi utenti non hanno mai avuto la possibilità di utilizzare le funzionalità "a pagamento". All'insaputa di loro, e nascosti dai venditori stessi che vendono il software, non sanno e non possono sapere quali benefici porteranno le funzionalità Pro. Senza prima doverli usare, un utente non saprà di avere la sensazione di "aver bisogno" di qualcosa. Il che mi porta al prossimo punto di un modello di prova gratuito.

Alcune opinioni di un utente di prova gratuito sono "Non riesco a immaginare di usare questo software senza le funzionalità Pro". Questo risale al punto in cui "l'utente non sa di aver bisogno di qualcosa fino a quando non capisce per primo la sensazione di avere". Coloro che hanno avuto 14 giorni per utilizzare le funzionalità della versione "completa" hanno affermato di non poter immaginare di non avere o utilizzare le funzionalità fornite lì. Quindi, alla fine dei quattordici giorni, erano più propensi a versare denaro rispetto a qualcuno che non ha mai sperimentato le funzionalità complete. La durata della prova gratuita è anche un fattore importante che sta creando un'impressione duratura per gli utenti. In un esperimento condotto da Visual Website Optimizer, hanno notato che per una prova gratuita di 14 giorni contro una prova gratuita di 30 giorni, mentre il numero di registrazioni e installazioni era lo stesso, l'utilizzo per la prova di 14 giorni è aumentato del 102%.

Un altro punto molto importante da ricordare è che "offrire una versione gratuita utile e completamente funzionale del prodotto" è MOLTO IMPORTANTE. Le prove gratuite completamente funzionali sono efficaci per ottenere copertura mediatica e questa pubblicità per i nuovi software e / o venditori di software è abbastanza cruciale.

Un altro aspetto rilevante è l'importanza per gli utenti di fornire feedback. Prendi in considerazione, nella versione di prova gratuita, completamente limitata nel tempo, la possibilità per gli utenti di fornire feedback.

Un'altra caratteristica importante per il nostro software è la necessità di dati telemetrici, ovvero dati quantitativi e completi su come un utente utilizza il nostro software. Alcune statistiche sull'utilizzo potrebbero rientrare in un'area grigia legale, poiché le leggi sono diverse a seconda della posizione negli Stati Uniti e nel mondo. Un modo per combattere questo problema legale è disporre di una funzione di attivazione per la raccolta di statistiche anonime sull'utilizzo. Una funzionalità di opt-in significherebbe dare all'utente la possibilità di disattivare la raccolta di statistiche e allo stesso tempo, l'utente deve essere ben consapevole di ciò che fa la raccolta di informazioni anonime sull'uso. È importante chiarire all'utente quali dati verranno raccolti, cosa "faremo" con esso e rendere più facile la disattivazione in qualsiasi momento, anche consentendo loro di cambiare idea per attivarli o disattivarli. Per statistiche più dettagliate, come il monitoraggio delle singole attività degli utenti, potrebbe portare a problemi legali. L'IDE Eclipse registra statistiche dettagliate sull'utilizzo, ma lo fa con il pieno consenso dell'utente. Potremmo dover potenzialmente preparare un modulo di consenso con il nostro team legale.

La raccolta di informazioni sull'utilizzo di Eclipse raccoglie queste informazioni: 1. Plug-in avviati dal sistema. 2. Comandi accessibili tramite le scorciatoie da tastiera e le azioni invocate tramite menu o barre degli strumenti. 3. Quando la "vista" dell'editor viene messa a fuoco. 4. Informazioni di sistema come la versione del software in uso, il sistema operativo in uso. 5. Descrizione degli errori interni.

Kill Switch

Un kill switch per il nostro software può essere gestito registrando i dati iniziali, crittografandoli con un salt e ogni volta che si tratta di una data non valida, cioè l'utente tenta di modificarlo, disabiliterebbe il software. Un'altra opzione è disporre dell'autenticazione Internet all'installazione, registrare tale data su un database Web centrale e controllare la data ogni volta che si apre l'applicazione.

Disabilitando il software, possiamo eliminare le DLL vitali. L'opzione di dover pagare per generare un rapporto non può essere considerata.

Sono interessato a implementare una versione di prova gratuita per il mio software esistente. Ho intenzione di avere il processo negli ultimi 14 giorni. Al 14 ° giorno, il mio software richiederebbe all'utente di pagare per la versione a pagamento o di avere la conseguenza di non poterlo utilizzare. La versione di prova gratuita è completamente sbloccata, il che significa che ci sono tutte le funzionalità a pagamento.

Tuttavia, il mio dilemma riguarda il modo "migliore" di implementare cosa fare per una soluzione di fine prova. Posso eliminare le DLL vitali? Hai un sistema di autenticazione utente al momento dell'installazione o dell'utilizzo? Crittografa l'ora e la data iniziali di utilizzo con un valore salt e, se si tratta di una data non valida (AKA tentano di modificare la data iniziale), disabilitare il software?

Sono interessato a sapere quali sono alcune misure efficaci per disabilitare il software.

Ci sono due problemi qui: uno è un problema di programmazione e uno è un problema aziendale. Per il secondo, chiedere ai programmatori le analisi di business è un buon consiglio che puoi ottenere dal tuo autista di autobus locale; vale a dire che può essere buono o terribile, ma non stai chiedendo agli esperti, quindi non assegnare alcun peso intrinseco a nessuno di essi. (Per inciso, uno dei miei autisti di autobus mi dà spesso buone idee.)

Ma per quanto riguarda un problema di programmazione, il rovescio della medaglia è che sembra che alla maggior parte delle persone non piaccia l'idea di iniziare. Ci sono molte buone ragioni per questo, ma non sono molto importanti qui. Purtroppo, in qualche modo siamo anche un terribile gruppo di persone da chiedere, perché in virtù della nostra posizione e conoscenza la maggior parte di noi è dannatamente brava nel software di pirateria al punto che riteniamo inutile cercare di implementare misure di prova !

Il fatto è che il tuo problema principale è un problema di analisi commerciale e di esperimenti di vendita, e non c'è nessuna risposta se non quella di conoscere i tuoi clienti e la sperimentazione. Non sembra che tu abbia già un grande pool di clienti con cui parlare della loro pipeline di vendita dei prodotti e di come puoi implementare un software di prova per migliorarlo, quindi bisogna capire che ora siamo in grado di accoltellare ciecamente al buio . Il primo passo per lavorare in una stanza buia è sapere che sei in uno!

Quindi, inizia da qualche parte. L'obiettivo non è la risposta giusta, perché posso garantire solo una cosa al 100%: non inizierai con la risposta giusta. Ma inizia dobbiamo.

Dai ai tuoi clienti un BACIO

Inoltre, "mantienilo semplice, stupido". Oppure, da una metodologia di programmazione, "prova la cosa più semplice che potrebbe funzionare". Quindi vai da lì.

Quindi, durante l'installazione ottieni una data. Conservalo. Ottieni i tuoi dati su installazioni e utilizzo e goditi il ​​calore che può portare l'analisi dei dati. Disabilita qualsiasi parte del software che desideri alla scadenza del periodo di prova if (trial_expired()). Quindi regolare.

Prima di tutto, ottieni buoni dati. Ti aspetti di fornire aggiornamenti in futuro per il tuo software? Quindi se qualcuno prova a battere v1.0, non preoccuparti.

La cosa più semplice è disinstallare il software, quindi reinstallarlo. Nuovo periodo di prova (perché il tuo software ha eliminato quella vecchia data). Ti importa? Se la v1.0 sarà presto aggiornata, allora ti consiglio vivamente di trovare un modo per scoprire se questo accade, ma non provare a fermarli (ancora). È come le persone che prendono 2 zecche invece di 1 - è solo una zecca, lascia perdere. Probabilmente non ti avrebbero pagato (ancora) per questo, comunque.

Come? Bene, in Windows questo di solito veniva fatto inserendo chiavi casuali orfane nel registro e file con nomi strani in varie directory di installazione comuni. Il tuo installatore farebbe finta esplicitamente che non esistessero e li lascerebbe lì. Il livello di sofisticazione del computer che questo richiede per sconfiggere è molto più della disinstallazione.

Ma se non provi a impedire a qualcuno di reinstallare, otterrai i dati che ti serviranno. Non stanno derubando il tuo negozio, qui - ti stanno dando una preziosa opportunità di studiare un potenziale cliente. Usalo per personalizzare il tuo marketing, i suggerimenti di aiuto software, le campagne e-mail, le "offerte speciali". Proverei a rilevare l'evento e poi, il giorno dopo, inviando loro una chiave che potrebbero inserire nel programma per prolungare la loro prova fino al mese prossimo. Potresti trovare un metodo che li trasforma in clienti paganti o no; nessun modo di sapere in anticipo!

Sembra banale, ma ammettiamolo: hai davvero bisogno di qualcosa di più? Se stai raccogliendo dati, questo vale per te. Probabilmente vorrai trascorrere del tempo assicurandoti che le e-mail siano buone, progettando messaggi nel software che puoi aggiornare per guidare i nuovi utenti (piazzole di vendita invisibili, in realtà), riscrivere il blurb della tua app, eliminare i bug che impedirebbero a qualsiasi persona sana di mente dall'acquisto del software in primo luogo, ecc.

Ma la chiave qui è che stai comunicando onestamente e chiaramente a tutti i potenziali clienti - se vuoi questo, dovresti pagarci. Solo perché sei (invisibilmente) magnanimo non significa che questo è freeware - sarai solo intelligente e non allontanerai i clienti perché non hanno siglato l'affare nelle prime due settimane.

Se ci pensate, queste persone stanno arrivando nel vostro negozio per guardare davvero al vostro prodotto. Stanno facendo un giro di prova, ma non ti costa (quasi) nulla. Nessun negozio di successo è riuscito a cacciare i clienti che non erano ancora pronti ad acquistare! Eppure sappiamo tutti se puoi ottenere qualcosa gratis, per sempre, perché pagare? Quindi usa il meglio dei due mondi.

Ad ogni passo che farai funzionerai un filtro, e se il tuo software è buono farai conversioni ad ogni passo. Il mio semplice suggerimento:

1) prova gratuita di 14 giorni

2) Estendi la prova gratuita, senza fare domande

3) Offri di estendere nuovamente la prova gratuita, se fossero così gentili da compilare un breve modulo che ti comunica le loro opinioni sul tuo software finora.

4) Sei sicuro che queste persone che stanno ancora utilizzando il tuo software non prenderanno in considerazione l'acquisto? Trova un modo per attirarli - o almeno prova a spremere più informazioni da loro su cosa potresti fare per convincere gli altri a comprare. Forse consentire loro di "richiedere" un'estensione attraverso un modulo, che il personale di vendita concederà gentilmente a prescindere e quindi utilizzare le informazioni per vedere se sono in grado di affrontare eventuali obiezioni che potrebbero dover acquistare il software.

Che cosa succede se questo utente lo sta valutando per l'uso in tutto il suo reparto? Se la riunione del budget è il mese prossimo, vuoi davvero che non siano in grado di utilizzare il software fino ad allora?

5) Forse li interrompi ora ... e forse li inviti per un'offerta speciale una settimana dopo con uno sconto. Forse no. Forse ti offri di estendere per dare un'estensione finale.

Queste persone non ti devono denaro, quindi trattali come potenziali futuri clienti, non ladri, freeloader o persone che devono pagare il conto o disattivare il servizio. Tutti odiano gli esattori, quindi non comportarti come tale.

A livello di programmazione, ammettiamolo: in realtà non è difficile. Usa file orfani per tenere traccia delle date. Se devi avere un account valido come tramite iTunes, questo monitoraggio è molto più semplice. Se non è necessario, in genere suggerirei di non richiederlo per una prima installazione - non allontanare mai le persone dalla prima versione perché non vogliono compilare un modulo stupido. Le persone odiano le forme! E non conoscono il tuo software, quindi perché 'pagare' per compilare un modulo se non sanno nemmeno se la tua app funziona?

Al passaggio 2, riceverò un'iscrizione / e-mail da estendere. Ancora una volta, programmarlo è banale.

3) Dopo 30 giorni probabilmente avrei bisogno di un qualche tipo di comportamento da "telefono a casa". Se le persone lo spezzeranno - come fanno loro - congratu-friggin-lations! Stai diventando molto popolare. Ma non preoccuparti, se questo non è un videogioco la gente probabilmente non si preoccupa abbastanza di preoccuparsi, quindi cambia il codice nella prossima versione e riportali al tavolo da disegno.

TL; DR;

# 1 Non risolvere un problema che non hai realmente (non sei ancora Adobe - DRM può essere semplice ed efficace se non lo pensi troppo). # 2 Non chiedere a un programmatore quando è necessario rivolgersi a un operatore di marketing, un analista aziendale o un venditore. # 3 Tratta i tuoi clienti come persone che potrebbero darti da vivere, non come persone che ti devono denaro, e soprattutto non come ladri. # 4 DRM è davvero molto semplice. Non pensare che impedirai alle persone di usare il tuo software che quasi certamente non ti daranno mai, mai e poi mai ... almeno non oggi.

• Ho comprato software che ho piratato, anni dopo. Quindi non fare incazzare inutilmente i futuri clienti.

Stai cercando qualcosa che sia essenzialmente impossibile. Alcune delle aziende più grandi e meglio finanziate nel settore del software hanno trascorso anni e milioni e milioni di dollari, alla ricerca di un modo per realizzare ciò che si sta tentando di fare e non ha mai prodotto risultati di successo.

Prima di tutto, puoi dimenticare tutto di rovinare un'installazione locale. Finché esiste ancora il programma di installazione originale (o può essere eseguito il backup o riscaricato), questo non è altro che un dosso. Anche posizionare qualcosa da qualche parte nelle impostazioni di sistema significa molto poco quando l'utente può installare su una VM e quindi eseguire il backup e il ripristino dell'intera immagine della VM.

Il prossimo ovvio passo è l'autenticazione online: configurare un server e fare in modo che il programma "chiama home" ogni volta che viene avviato per controllare le credenziali. Neanche questo funziona. Innanzitutto, si riscontra un problema evidente (e altamente frustrante) di falsi negativi quando il server è inattivo o irraggiungibile per qualsiasi motivo o presenta qualche problema tecnico nel suo software. E non puoi fare in modo che il software convalidi automaticamente l'utente se non riesce a raggiungere il server, o è banale aggirare l'autenticazione con alcuni trucchi di rete, o semplicemente utilizzandolo su una macchina con il wi-fi attivato off. (E ovviamente, questo significa che le persone che cercano di usarlo legittimamente con una buona ragione per non avere una connessione wi-fi, come portare il loro laptop con loro sul bus, saranno bloccate. Ciò non farà sì che nessuno come il tuo programma.)

L'altro problema con l'autenticazione online è che alla fine si riduce a un valore booleano da qualche parte nel codice. Da qualche parte chiama AuthenticateUser()e se ritorna True, l'utente è dentro e, se ritorna False, sono bloccati. E non importa quello che fai per crittografare, offuscare o nascondere il codice, alla fine si riduce al semplice fatto che se un computer può leggerlo ad un certo punto, così può fare un programmatore. Qualcuno, da qualche parte, produrrà una crepa in cui AuthenticateUserritorna sempre True, e lo metteranno sul Web.

Il problema fondamentale della crittografia può essere descritto come "Alice vuole inviare una lettera a Bob, senza che Charlie sia in grado di leggerlo anche se dovesse cadere nelle sue mani". Il problema con quello che vuoi è che Bob e Charlie siano la stessa persona, il che rende impossibile il tuo obiettivo.

Se vuoi guadagnare con il tuo software, girare le braccia degli utenti non è la risposta. Ciò che funzionerà, l' unica cosa che funziona in modo coerente in questi giorni, è la teoria di mercato di base: offrire un prodotto che l'utente percepisce come avere un valore maggiore per lui rispetto al prezzo che lo stai chiedendo, e sarà disposto a pagare . Qualsiasi altra cosa sarà solo una perdita di tempo e fatica da parte tua.

Solo il mio 2 ¢.

L'autodistruzione affidabile al 100% è impossibile. Ci sarà sempre un modo sofisticato per decifrare la tua protezione.

Quello che puoi fare è rendere più seccante l'utilizzo o il crack di una versione di prova scaduta rispetto all'acquisto di una versione completa per il tuo mercato di riferimento .

Se fossi nei tuoi panni, proverei a garantire che il mio software sia: (1) popolare, quindi tutti gli interessati almeno lo hanno provato e (2) a prezzi ragionevoli, quindi chi è disposto a pagare può acquistarlo e tu ti giri un profitto. Il resto degli utenti può giocare con prove scadute sul contenuto dei loro cuori: non lo comprerebbero comunque, ma aiutano la popolarità e forniscono più potenziali assunzioni per le aziende che acquistano effettivamente il tuo software.

Suppongo che il mercato target di un plug-in Revit sia costituito da architetti, imprenditori edili, progettisti, tutte le persone che gestiscono quantità relativamente elevate di denaro per contratto e nessun eccesso di tempo libero o competenze informatiche di basso livello.

Quindi, assicurarsi che la versione di prova scaduta infastidisce sufficientemente loro senza rompere nulla in realtà (o ti odiano voi). Le persone che hanno bisogno di lavoro finiranno per frugare e pagare il prezzo [ragionevole].

Alcune idee:

• Crea una versione di prova in modo rapido (e pulito) disinstallalo alla scadenza. La reinstallazione dovrebbe essere possibile, in modo che gli utenti vedano intatto il proprio lavoro, seguito da un'altra disinstallazione automatica poco dopo.
• Consenti all'output di una versione scaduta di includere un segno o un testo che dice "Realizzato con una versione di PROVA SCADUTA del [tuo software]". Un utente serio non mostrerebbe tale output a un cliente. (E se lo fa, di nuovo, è troppo economico per pagare il tuo software comunque).
• Fai in modo che una versione di prova scaduta mostri caselle di messaggio in momenti casuali, avvisando che la versione di prova è scaduta e fornendo un collegamento alla versione completa. Queste cose interrompono il flusso di lavoro abbastanza da rendere utile un aggiornamento per un utente serio.

È possibile applicare qualsiasi combinazione di trucchi consueti per contrassegnare un computer con una versione di prova scaduta: chiavi di registro criptiche, file criptici in posizioni casuali (non dimenticare di ripristinare il timestamp se li modifichi), nascondendo i timestamp in file grafici non correlati o altro forme di steganografia, ecc.

Naturalmente se l'utente, ad esempio, reinstalla il sistema operativo, riceverà di nuovo un periodo di prova gratuito. Non importa: un cliente serio difficilmente potrà ricorrere a questo. Certamente questo schema alla fine sarà rotto; assicurati che il tuo software sia abbastanza popolare da allora che puoi offrire un aggiornamento con funzionalità interessanti e un diverso schema di protezione.

Come esempio di "inconveniente" di successo, sceglierei i modelli di Balsamiq. Puoi usare il loro software gratuitamente (sul web), con alcune funzionalità limitate, incluso il salvataggio del tuo lavoro. Il lavoro può essere "esportato" e "importato" con qualche seccatura. Cioè, qualsiasi studente delle scuole superiori che vuole giocare con la versione gratuita quasi completamente funzionale può farlo, e può anche fare un po 'di lavoro. Lo studente non lo acquisterà comunque. Ma un designer serio che apprezza il loro tempo e convenienza lo comprerà.

Come altro esempio di grande successo, ovviamente prenderei MS Windows.

Non è difficile da fare. Dipende davvero da quanti sforzi vuoi fare.

Ricorda, lo scopo di una versione di prova è aumentare le vendite. Tutti gli schemi di versione di prova per software installabili possono teoricamente essere aggirati in qualche modo, anche se comporta uno sforzo enorme, poiché il codice viene eseguito localmente e può quindi essere modificato con un editor esadecimale. Questa risposta funziona dal presupposto che il poster originale chieda soluzioni pratiche a questo problema aziendale, non teorici.

Come menzionato in uno degli altri poster, il punto è assicurarsi che lo sforzo necessario per aggirare lo schema della versione di prova superi il costo in termini di tempo e impegno rispetto al costo di acquisto del software. "Pirati" dedicati scaricheranno semplicemente versioni pre-crackate del tuo software usando BitTorrent . Non preoccuparti per loro, poiché non sarebbero comunque clienti. Gli approcci sottostanti sono stati adottati da innumerevoli società di software per decenni e finché non sarai paralizzato dall'idea che tali sistemi debbano essere teoricamente perfetti, scoprirai che funzionano abbastanza bene nel mondo reale.

Al livello più semplice, è possibile semplicemente mantenere una 'finestra' della data di inizio / data di fine nel registro (crittografata). Ogni volta che il programma viene eseguito, si controlla che l'ora di sistema sia compresa tra queste due date e si aggiorna il componente "start" di quella data. Ciò impedisce all'utente casuale di ripristinare semplicemente l'orologio per consentire l'accesso alla versione di prova.

Puoi estenderlo tenendo traccia della finestra temporale in diverse posizioni (sia nel registro che nella cartella dei dati dell'applicazione) e assicurandoti che corrispondano ad ogni avvio. Ciò impedisce alle persone di spostarsi con le voci: devono sapere esattamente dove si trovano e come decodificare / crittografare i dati.

Esistono anche altri modi per restringere le cose, che sono sicuro che incontreresti quando inizi a sviluppare la funzionalità di prova.

Se non vuoi fare tutto da solo, ci sono alcune librerie di terze parti che offrono questo tipo di funzionalità.

Nota relativa all'eliminazione effettiva dei file: se l'applicazione tenta di eliminare i file, potrebbe essere contrassegnata come malware dal software antivirus dell'utente. Oggigiorno il software antivirus è molto aggressivo. E molti utenti finali saranno convinti che c'è un virus nel tuo software se il loro programma antivirus fa apparire un avviso.

Dipende da quanto vuoi rendere difficile per i tuoi potenziali clienti eludere quelle funzionalità di auto-disabilitazione (suona meglio di "autodistruggersi"). Supponendo che i tuoi potenziali clienti non proveranno a manipolare il codice del programma stesso (che alcuni tenteranno, fidati di me), hai le seguenti opzioni:

• memorizzare l'ora della data iniziale da qualche parte (nascosta) sul computer in cui è installato il software: questo ha lo svantaggio che i tuoi clienti possono facilmente aggirarlo, ad esempio installando il programma in una macchina virtuale e disinstallandolo dopo il periodo di prova reimpostazione della VM al suo stato originale

• assicurati che ogni copia scaricata del tuo programma abbia un tempo di download codificato individualmente da qualche parte nascosto nel codice binario del programma. Ciò richiederà molto più impegno amministrativo da parte tua e non puoi ancora essere sicuro che la stessa persona non scarichi una nuova copia del programma dal tuo server dopo il periodo di prova (forse, usando un'identità diversa)

• consegnare la versione di prova solo con un "dongle" in cui è memorizzata la fine del periodo di prova. Questo sarà possibile solo per programmi con una manciata di potenziali clienti e un prezzo molto più alto del prezzo del dongle.

• rendi la cosa un'app Web, o parti di essa, o semplicemente un'app connessa al Web. In questo caso, è possibile memorizzare la data iniziale sul server, ma sarà necessario identificare e distinguere le persone che utilizzano il software (ad esempio, impostando i cookie o creando un accesso). Ma ancora una volta, non puoi essere sicuro al 100% che le persone non cambino la loro identità.

Qualunque cosa tu faccia, assicurati di testare molto attentamente ciò che accade oltre la data di scadenza. Una volta ho lavorato per un'azienda che distribuiva software con uno schema di prova molto simile a quello che descrivi. La differenza era che la scadenza era una data fissa in futuro.

Abbiamo abbandonato lo schema immediatamente dopo aver ricevuto un sacco di chiamate da clienti arrabbiati quando anche le loro versioni legittimamente acquistate hanno smesso di funzionare in quella data.