Jul 07 2010
SemaforoQuesto semaforo indica il livello difficoltà del post
Migrazioni obbligatorie di codici
Come abbiamo già avuto modo di notare in passato, Google Analytics non ha mai costretto nessuno a effettuare migrazioni del codice di monitoraggio; esse sono semplicemente consigliate. Se anche non usate il nuovo codice asincrono non cambia nulla. Se addirittura avete ancora il vecchio urchin.js, i vostri dati vengono raccolti ugualmente. In questo ultimo caso non potete avvantaggiarvi di alcune delle ultime funzionalità , tipo il tracciamento degli eventi o molte funzioni che esistono solo per ga.js, ma i vostri dati di base ci sono, vengono analizzati.
Mi è venuta in mente questa cosa perché ho letto che da fine luglio la versione v.4 del codice di tracciamento di Yahoo Web Analytics smetterà di funzionare, in favore della v.5. Da un alto trovo giusto che ogni sistema agisca come vuole – ed in Yahoo avranno sicuramente le loro ragioni ed esigenze – dall’altro mi stavo domandando quale dei due metodi sia preferibile. In Google effettivamente fanno fatica a star dietro ai tre metodi con la documentazione, ed ogni situazione andrebbe descritta tre volte, ma così facendo nessuno ha mai perso un dato. Esisteranno clienti di YWA che non hanno letto, in questi anni, o che non si ricordano della deadline? qualcuno perderà dei dati?
quale pensate che sia la soluzione migliore?
[a margine, già che ci siamo: le richieste HTTP alla gif fatte da codice asincrono (leggi questo post se non sai di cosa sto parlando) contengono un parametro aggiuntivo &gaq=1, che non produce nessun dato in Google Analytics, ma che immagino consenta a Google di conoscere puntualmente il numero di installazioni che usano l’ultimissima versione del GATC]
Sono più dalla parte di Google…
Non completamente perchè, fosse per me, lascerei “morire” urchin.js 🙂
A mio modo di vedere il monitoraggio eventi sta avendo, e avrà sempre più, un ruolo importante nelle statistiche di un sito internet, così come saranno sempre più incisivi i piccoli-grandi accorgimenti apportati in tema velocità, usabilità.
Navigando e curiosando il codice sorgente di vari siti si nota che urchin è ancora largamente utilizzato e la non-forzatura di Google è condivisibile. Credo che obbligare la migrazione porti sicuramente alla perdita di dati per qualcuno anche se si avvisa con largo anticipo e a caratteri cubitali.
Ma da operatore del settore mi infastidisce l’utilizzo di urchin 😀
E’ vecchio, non si sfruttano tutti i vantaggi che Google Analytics è in grado di offrire e nel mondo della Web Analytics, che quotidianamente sforna novità, rimanere indietro ha il suo prezzo…
No Marco?
Ciao Marco,
dal punto di vista della consulente, anche io come Luca condivido la posizione di Google e ne apprezzo gli sforzi per mantenere la funzionalità di codici obsoleti, comprendo però che questo tipo di effort non sia riproducibile/sostenibile da tutti i vendor che operano sul mercato.
In questo caso Yahoo a mio parere ha dato modo ai propri clienti di pianificare per tempo tutti gli interventi (almeno per chi era al corrente della novità), ribaltando su di loro però dei notevoli costi indiretti di re-implementazione che possono spaventare anche il più integerrimo tra i web manager.
Lato “cliente”, avendo a che fare con processi molto elaborati e strutturati, essere costretti ad implementare anche solo una piccola mutazione del codice che non era stata prevista nel disegno di implementazione e manteinance inziale, può comportare, oltre ad un costo notevole, anche una perdita di dati per un periodo più o meno lungo a seconda della clemenza del proprio IT.
però se il sistema è progettato bene, non dovrebbe costare nulla al vendor mantenere un codice vecchio (non svilupparlo, ovviamente): il codice produce dei dati, e quelli verranno analizzati. Se il cambio di codice produce mutazioni nei dati raccolti, e c’è bisogno di infrastrutture separate, non si può nemmeno avere la certezza che la cosa non abbia ripercussioni sui dati “buoni”.