Nov 01 2010

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti semaforo giallo - articolo avanzato semaforo rosso - articolo per esperti

Sito nuovo? pensa a Google Analytics

autore: categoria: web analytics

Una delle frasi che mi ritrovo più spesso a digrignare tra i denti quando mi fanno domande su Google Analytics è “mapporc… ma possibile che ci siano sempre questi grossi casini?”. Non scherzo. Io sono un programmatore, sono cresciuto con la logica del “keep it simple” e non disdegno di rifare pezzi di lavoro se le soluzioni attuate mi permetteranno di risparmiare tempo in futuro. La web analytics ormai è in giro da un pezzo, e sebbene sia cosciente che i clienti sono a volte impossibili, le richieste assurde e le soluzioni tecniche proposte spesso “fantasiose”, non posso fare a meno a volte di domandarmi “ma perché?”

Qualche tempo fa Robbin Steif di Lunametrics ha scritto un post che mi è piaciuto molto: “designing a Google Analytics friendly site“; se i suoi suggerimenti fossero sempre tenuti in considerazione nel rifacimento di un sito, il lavoro di chi fa le analisi sarebbe più semplice, e questo si tradurrebbe in meno tempo per il debug e più tempo per le analisi. Visto e considerato che la web analytics dovrebbe essere parte integrante di un più vasto processo aziendale, e visto e considerato che il design di un sito non è fine a sè stesso, perché non provare in fase di redesign ad agevolare il lavoro futuro dei web analyst?

Ecco le sue considerazioni:

  • Pagina obiettivo: provate ad avere una pagina obiettivo per ogni goal che andrete a misurare. E se possibile raggruppatele anche logicamente a livello di cartelle (per esempio col prefisso /thank/), in modo da poterle tracciare singolarmente o raggruppate. O anche singolarmente E raggruppate!
  • cerca sul sito: meglio se la ricerca avviene in GET e c’è un parametro univoco davanti alla parola cercata
  • tracciare sezioni del sito: fate in modo che le sezioni del vostro sito da tracciare separatamente siano tutte sotto la stessa directory, così potrete usare il report “dettaglio contenuto” sneza dover ricorrere a complessi filtri. Al massimo userete dei profili-copia con il filtro predefinito “includi solo il traffico verso una sottocartella”
  • Il problema dei domini: cercate di usare un solo dominio. Il passaggio da dominio a dominio mantenedo la congruenza del tracciamento è possibile, ma si introducono potenziali e multiple falle nel “sistema”. Se userete altri domini (servizi terzi) almeno assicuratevi di poter inserire il vostro codice di tracciamento!
  • Sottodomini: Gestire il tracciamento per un sottodominio non è complicatissimo (è una riga di codice in più), ma se non proprio necessario perché non puntare su una sottodirectory? (Robbin punta sul discorso SEO, questo punto io lo trovo piuttosto debole, dato che è sempre consigliato usare _setDomainName in un nuovo tracciamento, per prevenire la congruenza dei cookie nel caso di aggiungesse dopo un sottodominio)
  • Frame e iframe: E’ difficilissimo gestirli. Non è impossibile, ma è dannatamente faticoso. Se proprio dovete usarli, dovreste rispondere alla domanda “è più importante il frame o il tracciamento con Google Analytics?”
  • Redirect: Assicuratevi che siano server-side e che passino correttamente tutta la querystring
  • Piccole cose: ad esempio evitare di avere /percorso e /percorso/ come finale degli URL. Per Analytics sono due indirizzi distinti, se potete prevenire è meglio che risolvere con dei filtri, specie in siti di grandi dimensioni…

Siete d’accordo?

Condividi l'articolo:

4 Commenti

  1. Ciao Marco,

    Sono daccordo con te su tutto, nei sito che sviluppo, ultimemente cerco di ragionare nell’ottica dei GA soprattutto per creare delle pagine di risposta (a form contatti, iscrizione newsletter, o qualunque interazione con l’utente) che siano facilmente tracciabili come obiettivi.

  2. Ottimi spunti come al solito 🙂 , un post back to basics è sempre utile per aiutare anche chi la WA la vede solo dal punto di vista dello sviluppo di applicazioni.

    Senza questi presupposti tecnici si rischia la deriva, peraltro non solo nell’ambito di progetti WA ma più in generale quando parliamo di web marketing, passando dal SEO (redirect, URL canonization, frame…) alla più astratta web credibility (sottodomini…).

    Non è solo Google Analytics a necessitare questo tipo di attenzioni, praticamente ogni soluzione di web analytics sul mercato (da Omniture fino ai log analyzer) per poter processare informazioni che diano luogo a report sensati necessitano che l’oggetto misurato abbia alcune caratteristiche specifiche, pena una raccolta dati non corretta e in grado perfino di portare a decisioni errate.

    Un altro punto che aggiungerei alla lista è la necessità di disporre fin da subito di un’architettura informativa solida, scalabile e comprensibile anche da chi non l’ha progettata in modo da poter disporre di informazioni aggregate in maniera trasparente all’interno dei report.

    Requisito opzionale ma sicuramente auspicabile è quello di disporre di URL parlanti e generate in maniera coerente rispetto all’AI in uso. Penso che si tratti di un requisito ahinoi opzionale in quanto mi capita ancora spesso di imbattermi in CMS che non prevedono questo livello di personalizzazione.

    Che ne pensi?

    Alla prossima!
    Daniela.

  3. Dal mero punto di vista di Google Analytics, più che URL parlanti sarebbe sensato parlare di strutture di “cartelle” sensate, per poter usare in modo proficuo il report “dettaglio contenuto”, ma in generale hai – come sempre – ragione 🙂

  4. Si si, intendevo proprio URL strutturate interamente in maniera parlante e aderente al labelling utilizzato nell’architettura informativa.
    Sapere dove si trova l’utente con un semplice sguardo alla URL o più in genere al path, rende decisamente più facile per tutti, e non solo per chi segue l’implementazione degli strumeni, riuscire ad utilizzare le informazioni a disposizione.

Scrivi un Commento