Regressione nella coda. Cause comuni per cui gli utenti "tornano indietro" nella coda.
CrowdHandler punta tutto sull'equità e, nella stragrande maggioranza dei casi, gestirai una coda con un sistema "first-in, first-out" (primo ad entrare, primo ad uscire). Per questo motivo prendiamo molto sul serio le segnalazioni di "regressione della coda" (utenti che segnalano che la loro posizione nella coda "sta andando indietro"). Eseguiamo costantemente test funzionali per garantire che le posizioni in coda procedano solo nella direzione corretta. Tuttavia, esistono alcune circostanze in cui un utente potrebbe segnalare che il proprio numero sta regredendo. Questo articolo descrive le cause più comuni. Esamineremo le singole segnalazioni di regressione della coda accompagnate da un token, ma in tutti i casi che abbiamo analizzato finora la causa è stata una delle seguenti:
Understanding token rotation
Users in the queue are anonymous. We recognize a user's session in the queue, or on your site, by sending them a randomly generated token when they first connect. The user uses cookies and/or local storage to represent the token each time they request an update on their queue position, or access a URL on your site. This works much as any other web session.
Una volta che una coda è attiva, salvo casi particolari quali i codici di priorità o la prioritizzazione IP, al token viene assegnata una posizione in fondo alla coda, ovvero con un numero elevato. Se un utente vede la propria posizione in coda passare da un numero basso a uno alto, ciò significa quasi certamente che gli è stato assegnato un nuovo token, il che implica che ha perso il token originale. Quindi, se un utente segnala che il proprio numero sta andando all’indietro, la domanda è: come ha fatto a perdere il token originale? Quasi certamente si tratterà di una delle seguenti spiegazioni:
Session Timeouts
Once a token has served its useful purpose, it is ultimately discarded. But how do we know when a token is no longer required? Like all other web applications, we use the concept of a session timeout. That means that we hold the session for a length of time each time the user connects with us. The default is 20 minutes, but you can set this in your domain settings. Each time the user checks their position in the waiting room (which is automatic, every minute) the life of the session is extended for that period of time. When the user gets onto your website and requests URLs, the length of the session is extended. But if the user stops connecting with the waiting room, or your website, after the session timeout, their token will be discarded.
Ecco i casi legittimi in cui una sessione può scadere:
In the waiting room If you have opted to allow sessions to expire in the waiting room (this is a checkbox setting on the domain page) then a user may lose their token if they allow their device to go to sleep, or close their browser tab for more than the period of time specified for the domain timeout. If the user re-opens their browser they may be issued a new token, and they may perceive this as their number going backwards. By default, the waiting room warns the user about this behavior, and this messaging is updated automatically based upon your domain settings.
Sta a te decidere se consentire o meno la scadenza delle sessioni nella sala d'attesa. Se non lo fai, un utente potrà ricollegarsi alla propria sessione anche dopo aver chiuso e riaperto il browser, per un massimo di 24 ore. Perché mai dovresti consentire la scadenza delle sessioni nella sala d'attesa? Ciò comporta code più brevi, quindi sta a te stabilire il comportamento più appropriato per la tua coda.
Sul tuo sito Se l'utente non è attento, potrebbe essere reindirizzato al tuo sito, ma potrebbe non cliccare effettivamente su alcuna pagina per un tempo superiore a quello specificato dal timeout del dominio. A quel punto, quando cliccherà su un link, gli verrà assegnato un nuovo token e potrebbe essere rimandato in coda. Potrebbe segnalare questo fenomeno come un arretramento della propria posizione in coda, poiché ricorda di aver visto una posizione inferiore prima di essere reindirizzato al sito.
Checkout Busting
CrowdHandler dispone di una funzionalità che consente di annullare i token una volta che l'utente ha raggiunto la pagina di destinazione, solitamente una sorta di conferma dell'ordine. Questa funzione viene spesso utilizzata quando la coda è finalizzata all'accesso a scorte limitate. È stata progettata per impedire agli utenti di approfittare della propria posizione in coda per effettuare più ordini.
L'esperienza utente tipica e prevista è che la pagina di conferma venga caricata correttamente, ma quando si clicca su altri link che attivano la sala d'attesa, all'utente viene assegnato un nuovo token e quindi viene reinserito in fondo alla coda.
Tuttavia, abbiamo notato che gli utenti descrivono questo comportamento previsto semplicemente come “andare indietro nella coda”.
Integration Issues
Se stai sviluppando una tua integrazione personalizzata, è tua responsabilità tracciare il token degli utenti che accedono al tuo sito tramite l’emissione di un cookie o l’utilizzo della memoria di sessione. È necessario prestare particolare attenzione a questo aspetto, specialmente nel primo punto di passaggio di consegne. Se imposti il cookie in modo errato, o se non riesci a impostarlo correttamente sulla prima pagina visitata dall’utente, quest’ultimo non presenterà il proprio token nei clic successivi e gli verrà quindi assegnato un nuovo token. Potrebbe persino non vedere il caricamento della tua prima pagina prima di essere reindirizzato alla sala d’attesa e, di conseguenza, segnalerà probabilmente questo problema come un regresso della coda. Le cause più comuni di questo problema sono:
- Reindirizzamento degli utenti verso pagine che non eseguono il codice di integrazione di CrowdHandler.
- Aspetti generali relativi all'impostazione e al recupero dei cookie
- Errori generali nelle pagine di destinazione che impediscono l'esecuzione del codice di integrazione di CrowdHandler.
- Utenti che accedono al sito tramite percorsi di navigazione imprevisti e non protetti, ad esempio tramite e-mail di reimpostazione della password.
Per ulteriori informazioni, consulta i nostri consigli per la risoluzione dei problemi relativi alle integrazioni personalizzate.