Quando installi CrowdHandler e configuri una sala d'attesa, vogliamo che tu riesca a farlo correttamente fin da subito.
Siamo lieti di poter dire che molte persone hanno installato CrowdHandler direttamente nell'ambiente di produzione, nel bel mezzo di un'emergenza legata al carico, e hanno visto come la soluzione abbia risolto la situazione.
Ma, anche con tutta la buona volontà del mondo... gli errori capitano. Ecco quindi un avvertimento. Sette insidie in cui abbiamo visto cadere i clienti, con alcuni consigli su come evitarle per garantire una configurazione più agevole.
Pensi di esserti preparato...?
Supponiamo che tu stia per lanciare un nuovo prodotto, servizio o promozione.
Sai bene che il tuo sito potrebbe avere problemi legati alla domanda o al carico. Forse ti aspetti un picco di domanda perché hai un prodotto estremamente limitato, oppure un problema di carico elevato perché sai che un numero senza precedenti di visitatori accederà al tuo sito contemporaneamente.
Quindi sai già che ti servirà una sala d'attesa. Anzi, la stai progettando fin dall'inizio. Farà parte dell'esperienza utente. Sai esattamente come funzionerà e come la coda verrà integrata nella soluzione che stai realizzando. Sarà testata a fondo. Non c'è alcuna possibilità che qualcosa vada storto.
...C'è?
Per sicurezza, esaminiamo i problemi più comuni relativi all'integrazione personalizzata di CrowdHandler e vediamo come evitarli.
1. Test funzionali limitati
Spesso vediamo clienti che testano la loro integrazione personalizzata, realizzata con grande cura, con un piccolo gruppo di stakeholder interni: cinque o dieci persone che seguono alcuni percorsi utente standard e verificano che gli utenti vengano inseriti in coda e reindirizzati al sito correttamente.
Tuttavia, questo tipo di test non offre un'idea realistica di come il sito funzioni in presenza di una coda attiva. Dopotutto, una volta che quei pochi utenti hanno completato la procedura della sala d'attesa e sono stati ammessi al sito, la coda non esiste più. Ma molti problemi di integrazione tendono a manifestarsi solo quando la coda si attiva su un sito molto trafficato.
Quando esegui i test, devi verificare che gli utenti mantengano lo stato di "promossi" (solitamente indicato da un cookie CrowdHandler) sul sito di destinazione. Anziché limitarti a far passare gli utenti di prova dalla sala d'attesa al sito, dovresti verificare se la sessione CrowdHandler rimane attiva.
Quindi, come minimo, dovresti:
- Imposta il valore su 0: in questo modo la coda entrerà in funzione
- Aumentare temporaneamente la velocità per consentire ad alcuni utenti di collegarsi
- Reimpostare la frequenza a 0 (creando nuovamente una coda attiva)
- Verifica quindi che gli utenti che sono stati trasferiti sul sito siano ancora in grado di completare percorsi utente funzionali.
È fondamentale riportare il limite a 0 dopo aver consentito l'accesso ad alcuni utenti perché, a questo punto, se la sessione CrowdHandler di un utente viene interrotta, questi verrà reindirizzato alla coda. Tuttavia, se si mantiene il limite elevato, tali utenti non verranno reindirizzati alla coda e non ci si accorgerà che l'integrazione presenta un problema.
2. La produzione non rispecchia lo sviluppo
Certo, tutti vorrebbero poter dire che i propri ambienti di staging e di sviluppo rispecchiano fedelmente l'ambiente di produzione... ma, secondo la nostra esperienza, raramente è così.
Uno dei problemi più comuni che abbiamo riscontrato è che un cliente trascorre giorni, o addirittura settimane, a effettuare test sul proprio ambiente di sviluppo o di staging, per poi applicare la stessa configurazione al sito di produzione un’ora prima del lancio, aspettandosi che funzioni esattamente allo stesso modo. Quando si rende conto che non è così, è ormai troppo tardi.
Questo accade perché gli aspetti che tendono a differire tra l'ambiente di produzione e quello di sviluppo sono proprio quelli che potrebbero mettere in difficoltà un sistema di attesa. Molte delle misure di protezione che è necessario implementare nell'ambiente di produzione – ad esempio, l'utilizzo di un CDN, l'attivazione di un firewall o la protezione dai bot – di solito non sono necessarie nell'ambiente di staging, quindi alcune impostazioni di routing o di configurazione della rete potrebbero essere diverse.
Assicurati quindi di prestare attenzione alle differenze relative a:
- Routing di rete (in particolare nelle implementazioni CDN e DNS)
- Protezione dai bot, infrastruttura firewall o configurazioni non corrispondenti all'ambiente di produzione
Per assicurarti di non incorrere in problemi gravi in una fase avanzata, ti consigliamo di effettuare il passaggio all’ambiente di produzione almeno 24 ore prima del momento previsto. Una volta completati i test funzionali in un ambiente di sviluppo o di staging, limita l’ambito a un’area dell’ambiente di produzione che non ti crei problemi – uno specifico modello di URL protetto che difficilmente causerà disagi agli utenti reali – ed esegui alcuni test su piccola scala nell’ambiente di produzione. Potreste anche effettuare un breve test in produzione nel cuore della notte.
Basta che... non lo lasci all'ultimo minuto.
3. Blocco degli indirizzi IP
Le integrazioni personalizzate inviano l'IP dell'utente all'API di CrowdHandler, in modo da poter verificare che non figuri in un elenco di indirizzi bloccati. Tuttavia, non è raro che alcuni siti siano configurati in modo tale da inviarci accidentalmente l'IP di un server proxy anziché quello dell'utente… e questo fa scattare erroneamente il blocco dell'IP da parte di CrowdHandler.
Questo tende a diventare un problema solo se stai configurando manualmente la tua integrazione (se utilizzi una delle nostre integrazioni, ci siamo già occupati noi di tutto), ma è piuttosto facile commettere errori, quindi fai attenzione.
Read more: Troubleshooting Custom API Integrations
4. Impostare un tasso troppo elevato
La maggior parte delle persone pensa che il proprio sito sia in grado di gestire un traffico molto più elevato di quanto non possa effettivamente fare. Ecco perché, in base alla nostra esperienza, i clienti spesso impostano una velocità di ingresso decisamente troppo alta.
Se è la prima volta che metti online il sito, non sai quanto traffico aspettarti e – onestamente – non sai ancora quanto traffico sei in grado di gestire. Non farti ingannare dalla capacità del tuo sito di gestire migliaia di richieste al secondo; questo dato non si traduce nel numero effettivo di persone che puoi far passare dalla tua coda.
I siti in grado di gestire facilmente più di 60 utenti al minuto (ovvero una nuova sessione al secondo) sono piuttosto rari, quindi è consigliabile partire da 30 o meno, a meno che non si conosca davvero il profilo di carico del proprio sito.
In breve: è meglio partire da un livello basso. Poi, se la sorpresa è positiva, è facile aumentare il tasso. Recuperare un’applicazione inattiva può essere più complicato.
See also: Why don't load tests work?
5. Esclusioni di URL
Se stai utilizzando l'integrazione DNS, l'integrazione CDN o la tua integrazione lato server con un front controller, verrà controllato ogni singolo URL per indirizzare gli utenti alla coda.
Tuttavia, è probabile che alcuni URL vengano richiamati da applicazioni di terze parti che non dovrebbero essere inseriti in una coda; pertanto, tali URL devono essere esclusi.
Un esempio lampante è quello di un gateway di pagamento. Un utente completa una transazione, ad esempio con PayPal o Stripe, e il gateway di pagamento invia una ricevuta di conferma dell’ordine, accedendo a un URL sul tuo server. Se non hai escluso quell’URL, l’integrazione con CrowdHandler (che, come ricorderai, controlla ogni singolo URL) interviene e indica che il gateway di pagamento deve essere inserito in una coda. L’ordine non verrà mai completato e l’utente non potrà procedere al checkout.
Questo è un altro motivo per eseguire test funzionali completi con largo anticipo. Imposta la frequenza a 0 per assicurarti che la coda sia attiva e verifica i percorsi utente completi, compresi quelli delle app di terze parti che potrebbero fare affidamento sul tuo dominio protetto.
Read more: Troubleshooting Custom API Integrations
6. Semplificare eccessivamente il modello
Uno dei motivi principali per cui gli utenti apprezzano CrowdHandler è la presenza di modelli personalizzati, e abbiamo visto persone realizzare progetti davvero creativi e entusiasmanti grazie alla libertà offerta da questi modelli.
Il modello predefinito, o “iniziale”, include diversi messaggi e stati per vari scenari, alcuni dei quali più evidenti di altri. Tra questi figurano: la sala non è ancora aperta, la sala è al completo, l’utente è stato bloccato a causa di un comportamento sospetto e all’utente non è stata ancora assegnata una posizione nella coda.
Tuttavia, quando gli utenti personalizzano il modello, capita spesso che prendano in considerazione solo lo “scenario ideale” e ignorino – o, peggio ancora, eliminino del tutto – alcuni dei messaggi di errore e degli stati meno evidenti. Di conseguenza, quando un utente si trova in una di queste situazioni, si trova di fronte a un’interfaccia utente che risulta in gran parte inutile.
È importante comprendere che gli utenti hanno bisogno di ricevere un feedback, anche se tale feedback comunica loro qualcosa che non ritieni positivo, come la loro posizione attuale, la barra di avanzamento o il tempo di attesa stimato. Secondo la nostra esperienza, nascondere questi elementi è controproducente. Senza di essi, gli utenti potrebbero iniziare a comportarsi in modo imprevedibile o reagire negativamente alla mancanza di informazioni. Potresti perdere vendite o addirittura danneggiare la tua reputazione.
7. Impostazione di timeout di sessione estremi
Ogni applicazione web utilizza il concetto di timeout della sessione, e CrowdHandler non fa eccezione.
L'impostazione predefinita di CrowdHandler è di 15 minuti, una durata della sessione relativamente standard per un'applicazione web. Ciò significa semplicemente che, una volta che un utente ha cliccato su qualcosa, per i successivi 15 minuti CrowdHandler presumerà che sia ancora presente.
L'utente mantiene attiva la propria sessione cliccando sulle pagine, ma un timeout di 15 minuti gli consente di allontanarsi per 15 minuti, magari per prepararsi una tazza di caffè, e tornare senza ritrovarsi in coda. Quando effettua un altro clic, la sessione viene ripristinata, quindi ha ancora tutto il tempo per navigare.
Vale la pena ricordare che il numero di sessioni è solo un indicatore molto semplificato del carico sulla tua app. Quando gli utenti sono assenti, ad esempio mentre preparano il caffè, non generano alcun carico sull'applicazione.
Tuttavia, abbiamo notato che alcuni clienti impostano la durata della sessione in modo eccessivamente breve o eccessivamente lunga.
In entrambi i casi, è controproducente. Se il valore è troppo basso, potresti finire per rimandare gli utenti in coda nel bel mezzo della loro visita. Se invece è troppo alto, potresti ritrovarti a gestire una coda molto lunga, perché le sessioni degli utenti rimangono attive per molto tempo dopo che se ne sono andati.
Read more: One in one out
Sei pronto a fare le cose per bene fin da subito?
Prevedete un carico di lavoro elevato o una forte domanda e siete pronti ad allestire una sala d’attesa?