Regressione della coda. Cause comuni degli utenti che "retrocedono" nella coda.

CrowdHandler si basa sull'equità e nella stragrande maggioranza dei casi la coda viene gestita con una configurazione "first-in, first-out". Per questo motivo prendiamo molto sul serio le segnalazioni di "regressione della coda" (utenti che segnalano che la loro posizione nella coda "va indietro"). Eseguiamo costantemente test funzionali per garantire che le posizioni in coda vadano solo nella giusta direzione. Tuttavia, ci sono alcune circostanze in cui un utente può segnalare che il suo numero sta andando indietro. Questo articolo descrive le ragioni più comuni. Indagheremo sulle singole segnalazioni di regressione della coda, se segnalate con un token, ma in tutti i casi che abbiamo analizzato finora si è trattato di una delle seguenti cause:

Comprendere la rotazione dei token

Gli utenti in coda sono anonimi. Riconosciamo la sessione di un utente nella coda, o sul vostro sito, inviandogli un token generato in modo casuale al momento della prima connessione. L'utente utilizza i cookie e/o la memoria locale per rappresentare il token ogni volta che richiede un aggiornamento della sua posizione nella coda o accede a un URL sul vostro sito. Il funzionamento è analogo a quello di qualsiasi altra sessione web.

Una volta che la coda è attiva, salvo casi particolari come i codici di priorità o la prioritizzazione IP, il token viene emesso con una posizione in fondo alla coda, cioè con un numero alto. Se un utente vede la sua posizione in coda passare da un numero basso a un numero alto, quasi certamente significa che gli è stato rilasciato un nuovo token, ovvero che ha perso il suo token originale. Quindi, se un utente segnala che il suo numero va indietro, la domanda è: come ha fatto l'utente a perdere il suo token originale? Quasi certamente si tratta di una delle seguenti spiegazioni:

Timeout della sessione

Una volta che un token ha esaurito la sua utilità, alla fine viene scartato. Ma come si fa a sapere quando un token non è più necessario? Come tutte le altre applicazioni web, utilizziamo il concetto di timeout di sessione. Ciò significa che manteniamo la sessione per un certo periodo di tempo ogni volta che l'utente si connette con noi. L'impostazione predefinita è di 15 minuti, ma è possibile impostarla nelle impostazioni del dominio. Ogni volta che l'utente controlla la propria posizione nella sala d'attesa (automaticamente, ogni minuto), la durata della sessione viene prolungata per quel periodo di tempo. Quando l'utente accede al vostro sito web e reinserisce gli URL, la durata della sessione viene prolungata. Ma se l'utente smette di connettersi alla sala d'attesa o al vostro sito web dopo il timeout della sessione, il suo token verrà scartato.

Ecco i tempi legittimi in cui una sessione può andare in timeout:

Nella sala d'attesa
Se si è scelto di consentire la scadenza delle sessioni nella sala d'attesa (si tratta di un'impostazione della casella di controllo nella pagina del dominio), un utente può perdere il proprio token se lascia che il suo dispositivo vada a dormire o chiude la scheda del browser per un periodo di tempo superiore a quello specificato per il timeout del dominio. Se l'utente riapre il browser, potrebbe ricevere un nuovo token e potrebbe percepire questo fatto come un arretramento del proprio numero. Per impostazione predefinita, la sala d'attesa avvisa l'utente di questo comportamento e questo messaggio viene aggiornato automaticamente in base alle impostazioni del dominio.

Sta a voi decidere se consentire o meno la scadenza delle sessioni nella sala d'attesa. In caso contrario, un utente può riconnettersi alla sessione anche dopo aver chiuso il browser e averlo riaperto, per un massimo di 24 ore. Perché consentire la scadenza delle sessioni in sala d'attesa? Si ottengono code più brevi, quindi sta a voi decidere il comportamento appropriato per la vostra coda. 

Sul vostro sito
Se l'utente non è attento, può essere fatto passare sul vostro sito, ma non può cliccare su nessuna pagina per più del tempo specificato dal timeout del dominio. Quando clicca su un link, gli viene assegnato un nuovo token e può essere rimandato in coda. È possibile che il visitatore riferisca che la sua posizione nella coda è arretrata, perché ricorda di aver visto una posizione inferiore prima di essere passato al sito.

La rottura delle casse

CrowdHandler ha una funzione che consente di distruggere i token una volta che l'utente ha raggiunto una pagina di obiettivi, di solito una sorta di conferma del checkout. Questa funzione è spesso utilizzata quando la coda è per l'accesso a uno stock limitato. È pensata per impedire agli utenti di approfittare della loro posizione in coda per ordinare più volte.

L'esperienza tipica dell'utente è che la pagina di conferma viene caricata con successo, ma quando si fa clic su altri link che attivano la sala d'attesa, l'utente riceve un nuovo token e viene quindi collocato in fondo alla coda.
Tuttavia, abbiamo visto che gli utenti riportano questo comportamento previsto semplicemente come "andare indietro nella coda".

Problemi di integrazione

Se state scrivendo la vostra integrazione personalizzata, è vostra responsabilità tracciare il token degli utenti che visitano il vostro sito rilasciando un cookie o utilizzando la memorizzazione della sessione. È necessario prestare attenzione a questo aspetto, soprattutto nel primo punto di passaggio. Se impostate il cookie in modo errato o se non riuscite a impostarlo sulla prima pagina visitata dall'utente, quest'ultimo non rappresenterà il proprio token nei clic successivi e riceverà quindi un nuovo token. Potrebbe anche non vedere il caricamento della prima pagina, prima di essere rimandato alla sala d'attesa, e quindi probabilmente lo segnalerà come regressione della coda. Le cause più comuni di questo problema sono:

1. Indirizzare gli utenti a pagine che non eseguono il codice di integrazione di CrowdHandler.
2. Problemi generali nell'impostazione e nell'ottenimento dei cookie

3. Errori generali sulle pagine di destinazione che impediscono l'esecuzione del codice di integrazione di CrowdHandler.
4. Utenti che arrivano sul sito attraverso percorsi inaspettati e non protetti, ad esempio e-mail di reimpostazione della password.

Per saperne di più, consultate i nostri suggerimenti per la risoluzione dei problemi di integrazione personalizzata.