Dovremmo riutilizzare i registri delle app Web per l'analisi del comportamento degli utenti?

Non pensare al logging come "Voglio registrare questi dati" pensarlo come "Ho un evento che potrebbe essere interessante per qualcuno."

Il fatto che il 99% delle volte in cui la parte interessata è un oggetto che prende gli eventi di registrazione e quindi scriva su un registro basato su disco è irrilevante per quella mentalità.

La registrazione è essenzialmente un produttore-consumatore framework di eventi

Quello che dovresti fare è definire una caratteristica di questi eventi "speciali". Forse è una categoria o argomento diverso. Quindi definire un consumatore, o appender, che li registra in un modo che il software di terze parti può consumare. Forse questo è un file di registro separato basato su disco, o forse una tabella separata in un database. Forse li canalizza attraverso un servizio web. L'implementazione è irrilevante, la parte importante è che usano lo stesso framework di registrazione e il codice che esegue la registrazione non ha bisogno di saperlo .

Di solito prendo tre importanti preoccupazioni quando costruisco sistemi di analisi.

1. Quanto può essere dannoso l'insieme di eventi di analisi? Ad esempio, i blocchi degli annunci tendono a bloccare la maggior parte delle analisi di terze parti nel browser. A seconda del pubblico che può essere più del 20% dei visitatori del tuo sito. D'altra parte eventi più affidabili possono imporre reali costi di performance sui tuoi sistemi.
2. Quanto deve essere stabile lo schema degli eventi di analisi? L'insieme di registri o eventi segnalati tenderà a cambiare nel tempo. Ciò può invalidare o almeno complicare gli sforzi per confrontare il comportamento degli utenti. In generale, più facile è segnalare gli eventi più difficile diventerà ricostruire il contesto intorno a loro per l'analisi successiva (ad esempio, si sposta un pulsante e gli utenti interagiscono in modo diverso ma riporta lo stesso evento). Dovrai scegliere dove sei disposto a pagare quel tipo di costo.
3. Quanto sono sensibili i dati che stai raccogliendo? È sempre permesso condividere con una terza parte, è necessaria una certa sanificazione?

I prodotti su cui ho lavorato scoprono che hanno bisogno di almeno una, ma spesso due categorie di dati analitici e che i requisiti per loro sono abbastanza diversi da pensare che sia spesso ragionevole disporre di sistemi diversi per segnalarli.

Alcuni eventi sono abbastanza effimeri. Si desidera confrontare i comportamenti di split test o le azioni degli utenti tra versioni consecutive di un'app. Gli sviluppatori di solito vogliono che questi siano automatici o molto facili da raccogliere e le query o i rapporti che li utilizzano sono spesso scritti dopo che i dati sono stati raccolti. È preferibile sfruttare il lato della raccolta di molti dati piuttosto che rendere la raccolta dei dati costosa e incentivare il team a evitarlo. Generalmente i risultati possono essere relativi (% di utenti che hanno completato una canalizzazione) in modo che una perdita di eventi distribuita uniformemente sia tollerabile. Gli ETL di registro funzionano bene così come fanno le librerie JavaScript di terze parti a seconda esattamente dell'attività a cui si desidera dare visibilità. Anche la segnalazione degli errori e la diagnostica rientrano spesso in questa categoria; non sei sicuro di quali dati avrai bisogno per identificare un problema ma sarai triste se non lo hai.

Altri eventi diventano una parte fondamentale dell'attività o del servizio. Si spera che i numeri dei guadagni vengano catturati da qualche parte nel vostro back-end, ma spesso è necessario correlarli con gli eventi che normalmente si trovano solo in quelli meno definiti. Quando è necessario rispondere a domande come "quale caratteristica ha generato queste entrate" o "quali campagne di riferimento portano a queste vendite", queste possono diventare problemi aziendali critici. Se il team di sviluppo le vede come misure "belle da avere", "best effort" in cui un flusso di eventi con perdita è accettabile o dove le modifiche dello schema possono verificarsi frequentemente senza preavviso (e senza la migrazione di dati storici) si verifica una dolorosa divisione nell'organizzazione . Questo tipo di set di dati probabilmente merita il proprio meccanismo di raccolta in cui è possibile introdurre uno schema più affidabile e aggiungere controlli di convalida se necessario. Potrebbe anche essere parte di un registro di controllo, un caso in cui le informazioni sull'utilizzo dovrebbero essere esaustive.

tl; dr tutto dipende dalle tue esigenze e devi capirle in dettaglio

Suggerisco di consultare aggregatori di dati di eventi come Segmento che possono inviare dati sia al tuo back-end che a diversi servizi di analisi allo stesso tempo. Ciò fornirebbe una soluzione per entrambi i tuoi scopi senza la duplicazione della registrazione degli eventi nel tuo codice.