Da CrowdHandler è spesso la prima domanda che ci viene posta: “Supportate il principio ‘One In, One Out’?”. E la risposta è: “Sì, lo supportiamo... ma, per la maggior parte degli utenti, non lo consigliamo”.
Sappiamo per esperienza che impostare semplicemente la giusta velocità di ingresso è un modo più efficiente di gestire il traffico rispetto al principio “uno entra, uno esce” e rappresenta la soluzione migliore per la stragrande maggioranza dei nostri clienti.
Purtroppo, molti proprietari di siti web sentono dire “sì, supportiamo il principio ‘One In, One Out’”, ma non ascoltano la seconda parte del nostro consiglio. Per loro, il concetto di “One In, One Out” sembra talmente logico che fanno fatica a immaginare che il traffico possa essere gestito in altro modo. Così procedono, attivano l’impostazione “One In, One Out” e mettono online il sito… solo per scoprire che si formano code e che gli utenti si lamentano dei tempi di attesa.
Allora, cosa c'è che non va nel principio "uno entra, uno esce"?
Il problema è che la semplicità della formula “One In, One Out”, così come la intendiamo la maggior parte di noi, non corrisponde alla realtà del traffico sui siti web e dei percorsi degli utenti. La soglia “One In, One Out” può risultare sia irrilevante che problematica.
Irrilevante? Beh, supponiamo che tu abbia un sito web con una capacità di 1000 utenti e che ne accetti 100 al minuto. Sai che il percorso medio di un utente dura dieci minuti, quindi, partendo da zero (0 utenti), ti aspetteresti di raggiungere la capacità massima in dieci minuti. Dopodiché, se il principio “One In, One Out” funzionasse come molti credono, l’equazione sarebbe semplicemente 1000/10. Ci si aspetterebbe che il primo gruppo di 100 utenti completasse la procedura di check-out al decimo minuto, a quel punto si consentirebbe l’accesso ai successivi 100 utenti, e così via.
Chi ha prestato attenzione durante le lezioni di algebra avrà forse notato che, a questo punto, la variabile con capacità pari a 1000 si è annullata. Basterebbe semplicemente impostare il tasso di ingresso a 100 per ottenere esattamente lo stesso effetto.
Tuttavia, il principio “One In, One Out” non è solo irrilevante in questo scenario, ma è addirittura problematico. Questo perché la semplice equazione “One In, One Out” trascura anche due fattori cruciali: i timeout delle sessioni e la capacità di elaborazione dei pagamenti.
Problema n. 1: timeout delle sessioni
OK, quindi il percorso medio di un utente potrebbe durare dieci minuti. Ma non sono pochi gli utenti che non arriveranno mai alla fase di checkout – e se lo facessero, potresti non saperlo (a meno che tu non abbia configurato il monitoraggio degli abbandoni durante il checkout). Quindi, piuttosto che lasciare che le sessioni degli utenti rimangano attive e possano influire potenzialmente sulla capacità in modo permanente, le chiudiamo automaticamente.
Il timeout predefinito della sessione in CrowdHandler è di 15 minuti, il che significa che il posto di ogni utente verrà mantenuto per 15 minuti dopo la sua ultima attività. Ciò consente agli utenti di fare una pausa, rispondere a un’e-mail urgente o effettuare un rapido confronto dei prezzi su un altro sito durante la loro visita, per poi tornare in coda senza dover ricominciare da capo.
Quindi, tenendo conto di quei 15 minuti, la durata media effettiva della sessione utente è di 25 minuti. Tornando alla nostra equazione, 1000/25 significa che la velocità effettiva è di soli 40 accessi e uscite al minuto se applichiamo la regola “One In, One Out” con 1000 utenti. Utilizzando il nostro calcolo originale, ci aspetteremmo che una coda di 3000 persone si svuotasse dopo 30 minuti con un’attesa mediana di 15 minuti. Ma tenendo conto del timeout della sessione, i primi 1000 utenti lasceranno la coda nei primi 10 minuti, e poi i restanti 2000 utenti si esauriranno a una velocità di 40 al minuto, impiegando 50 minuti. Quindi l’intera coda impiegherà effettivamente un’ora per svuotarsi, con un’attesa mediana di 30 minuti. Il doppio del tempo.
“Ah!” penserai. “Ma non farò entrare i primi 1000 utenti al ritmo di 100 al minuto; massimizzerò la velocità e mi affiderò esclusivamente all’algoritmo ‘One In, One Out’ per far entrare i primi 1000 utenti nel primo minuto, massimizzando così la mia capacità”. Beh, questa è una pessima idea per due motivi, ma il primo è questo: con il principio “One In, One Out”, nel nostro scenario di esempio, i restanti 2.000 utenti in coda non si muoveranno affatto per 25 minuti quando le prime sessioni registrate inizieranno a scadere. Quegli utenti vedranno una posizione in coda che non si muove e una stima del tempo di attesa terribile. Proprio il tipo di esperienza utente che stai cercando di evitare. Inoltre, a meno che tu non tenga attentamente conto del timeout delle sessioni nella tua soglia “One In, One Out”, a lungo termine avrai effettivamente un numero inferiore di sessioni completate, oltre a una coda ostinata.
Problema n. 2: Capacità delle casse
Questo problema deriva da un altro malinteso: basare le impostazioni "One In, One Out" sui dati dei test di carico.
I test di carico tendono ad aumentare il traffico in modo graduale (proprio come quando si imposta una frequenza in CrowdHandler!) e spesso riproducono il traffico quotidiano, che presuppone che il numero di visitatori che navigano sul sito sia superiore a quello di chi effettua un acquisto. Tuttavia, durante il lancio di un prodotto o in uno scenario di "drop", la percentuale di acquisti sarà molto più alta rispetto al traffico normale. È opportuno presumere che la maggior parte degli utenti inseriti all’inizio del percorso di navigazione effettuerà l’acquisto alla prima occasione utile.
Per molti versi, non ha importanza quanti utenti simultanei si ritiene che il sito sia in grado di gestire. Il punto è quanti checkout o transazioni è in grado di gestire al minuto. Sebbene molti siti possano gestire 1000 utenti simultanei, pochissimi sono in grado di elaborare 1000 checkout al minuto. Basare le impostazioni “One In, One Out” sulle metriche relative agli utenti simultanei non terrà conto del picco di transazioni effettive che si verifica durante un lancio o un’offerta speciale, e il sito rischia maggiormente di andare in crash sotto l’ondata di transazioni che si verificherà al decimo minuto del nostro scenario di esempio, se si consentono l’accesso a 1.000 utenti già dal primo minuto.
Un’analogia utile è quella di un negozio fisico con una capienza di 1000 persone ma solo 10 casse. Sebbene il negozio possa ospitare comodamente 1000 clienti, è in grado di evadere in modo efficiente solo 10 ordini al minuto. Far entrare 1000 clienti contemporaneamente creerà solo lunghe code di persone frustrate, senza alcun progresso a causa dell’accumularsi delle transazioni. Lo stesso vale online, con la differenza che il rischio non è solo quello di lunghe code, ma anche di un crash dei server.
Come farlo nel modo giusto
Un modo per mitigare i problemi legati al principio “One In, One Out” sarebbe quello di effettuare alcuni calcoli complessi durante la configurazione. Questi potrebbero includere operazioni quali l’aumento della capacità “One In, One Out”, la riduzione delle impostazioni di timeout delle sessioni, il calcolo dei rapporti tra sessioni e checkout, la verifica che l’opzione “Elimina sessione al checkout” sia attivata e il calcolo dei tempi effettivi del percorso dell’utente.
In effetti, ci ha rattristato così tanto vedere i clienti compromettere le loro vendite con impostazioni errate di “One In, One Out” che abbiamo aggiunto uno strumento di controllo che esegue questi calcoli e mostra loro dei suggerimenti:
Per alcuni clienti – quelli per i quali il numero di sessioni simultanee rappresenta davvero un parametro critico dell’applicazione; che sono certi di comprendere appieno i risultati dei propri test di carico e hanno una chiara comprensione delle impostazioni ottimali per i timeout delle sessioni e del loro impatto sulla soglia “One In, One Out” – questi calcoli potrebbero avere senso. Se siete tra questi, vi rendiamo omaggio.
Ma, per la maggior parte dei clienti, la risposta è molto più semplice: basta con i calcoli complicati basati su limiti teorici e test di carico inaffidabili, e concentriamoci sugli indicatori che incidono realmente sull’esperienza utente. Il successo deriva dalla comprensione della propria larghezza di banda di picco comprovata, non da un numero ipotetico di utenti simultanei.
Per la maggior parte dei siti, ciò significa regolare il tasso di afflusso su un valore leggermente superiore al tasso massimo sostenibile di completamento degli ordini. (Un buon punto di partenza è dividere per 60 il numero massimo di ordini evasi in un’ora di attività positiva, quindi impostare il tasso a un valore appena superiore a quello ottenuto.) Ciò consentirà un buon flusso di visitatori sul vostro sito.
Inizia con un approccio prudente, poi monitora attentamente le prestazioni. Se la coda si allunga ma il sito continua a funzionare correttamente, puoi sempre aumentare la frequenza; la funzione Autotune di CrowdHandler può aiutarti in questo senso.
In sintesi: puntare su prestazioni comprovate
Come strategia di gestione delle code può sembrare logica, ma una visione semplicistica del principio “One In, One Out” non tiene conto dei fattori reali che influenzano l’esecuzione. Spesso ciò comporta problemi quali lunghi tempi di attesa, clienti insoddisfatti e operazioni di pagamento non andate a buon fine, poiché i calcoli si basano su ipotesi: metriche inaffidabili o irrealistiche.
Pertanto, sebbene siamo favorevoli a questa pratica, il nostro consiglio è: non impostate una soglia “One In, One Out” senza averne compreso appieno il significato e concentratevi sui tassi di completamento degli acquisti piuttosto che sulle metriche relative agli utenti simultanei. Concentrandovi sulle prestazioni comprovate e sui limiti effettivi del vostro sito, migliorerete l’esperienza utente per tutti.