Tracciamento del tempo che gli utenti trascorrono sul mio sito web

Question

Tracciamento del tempo che gli utenti trascorrono sul mio sito web

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Monitoreremo il coinvolgimento degli utenti (ovvero il tempo trascorso sul sito web, la parte / pagina più vista del sistema, ecc.)

Non vedo Google Analytics / MixPanel in grado di fare ciò, poiché dobbiamo analizzare in base a fattori presenti solo nel nostro backend (come utenti che frequentano una scuola specifica, utenti di un tipo specifico, ecc.) - Non le cose generali come Country, Gender, ecc.

Posso pensare ad una soluzione DAVVERO semplice, ma non sono sicuro se sia, serverwise, cattivo. Hai una tabella simile a questa:

CREATE TABLE 'log' (
  'id' int(11) unsigned NOT NULL AUTO_INCREMENT,
  'uri' int(11) DEFAULT NULL,
  'date' timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  'user' int(11) NOT NULL,
  PRIMARY KEY ('id')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

E poi ogni volta che una pagina viene caricata, una riga viene aggiunta alla tabella "log", con il timestamp corrente, l'id utente e l'uri.

Ora ho i dati che voglio, il che è fantastico. Posso capire quando l'utente era online e quanti minuti passano in media.

MA. Questo è male per il server? Aggiungerà una riga per ogni caricamento della pagina, che è un sacco di righe, se hai 500 o 1000 utenti attivi. Ma importa? Quali sono i tuoi pensieri?

sql mysql

posta FooBar 14.05.2014 - 23:43

fonte

3 risposte

Leggi altre domande sui tag sql mysql

Nel sourcing di eventi, è corretto introdurre una dipendenza nella mia classe di messaggi? Come progettare la relazione tra un gioco e un giocatore in un gioco?

score 2 · Answer 1

Non è necessariamente negativo per il server registrare una richiesta di riga per pagina. Tuttavia, ci sono alcune cose da considerare qui. Prima di tutto, vedo che stai usando un AUTO_INCREMENT come chiave. Ciò si tradurrà in una perdita di prestazioni mentre stai scrivendo dei record.

È possibile sostituire l'ID con un campo GUID e generare GUID mentre si scrivono le righe.

Un'altra ottimizzazione che potresti fare è di farlo in modo asincrono. Quindi l'utente richiede una pagina, che viene fornita all'utente, e mentre lo fai, spara una richiesta, un evento o qualsiasi altra cosa è adatta per la tua tecnologia lato server e non blocca l'invio della richiesta, per scrivere effettivamente la tua registrazione .

Un'altra cosa da considerare è, hai davvero bisogno dei dati in un database immediatamente? Potrebbe essere sufficiente scrivere solo su un file di registro e importare i dati in un database in un secondo momento.

score 1 · Answer 2

In una configurazione simile, uno degli sviluppi del dominio registra gli eventi e altri eventi in-page in una tabella di registrazione su un server SQL. Utilizza un int-PK a incremento automatico. Per Google Analytics (GA), abbiamo sicuramente visto oltre 500 "utenti attivi". E noi non abbiamo visto alcun problema nel loggare alla tabella.

La differenza notevole per noi, penso, è che in realtà avvolgiamo la registrazione GA e il browser avvia una richiesta di registrazione separata "a fianco" della richiesta GA. Ciò consente a tutti i colli di bottiglia nel logger di rimanere fuori dalla questione più importante di che effettivamente costruisce la pagina.

Ma non posso dire se questo sia possibile per la tua applicazione , che probabilmente ha carichi di server molto diversi, schemi di traffico, schemi di blocco, ecc. Alla sua superficie, tu stai ovviamente usando un DMBS diverso, e probabilmente un diverso stack lato server ... Non posso dire quale impatto avrà.

Ma il log di base che vuoi può essere fattibile se le risorse del tuo server possono gestirlo, e idealmente se lo tieni "fuori mano" del tuo logica di base dell'applicazione.

score 1 · Answer 3

Se pensi davvero che questo imporrà un pesante carico del server, considera di loggare tutto su un database NoSQL come MongoDB (o magari anche un semplice file di testo / CSV), quindi eseguire un'operazione di carico di massa durante le ore non di punta. Se il processo di caricamento è l'unica cosa che scrive su questa tabella, è possibile eliminare l'ID di incremento automatico e pre-generare tutti gli ID prima di inserirli.

Questo presume che non sia necessario l'accesso in tempo reale a questi dati; se lo fai, allora potresti prendere in considerazione la scrittura di un caricatore di dati che pubblicherebbe i dati in modo controllato (diciamo solo N righe / secondo, configurabile). Ciò impedirebbe allo scrittore di inondare il server del database.

In ogni caso, prova a caricare definitivamente l'opzione per pagina di caricamento. Sembra l'approccio più diretto, non dedicarsi a molto lavoro per risolvere un problema di prestazioni che in realtà non esiste.