Questa volta vi ritrovate un lungo articolo (in due parti), che affronta il tema dello studio dei fenomeni inerenti alle visite del sito da parte dei navigatori.
Inizio con una precisazione. Vi sono situazioni in cui uno studio è conveniente si faccia in laboratorio per avere la certezza di poter controllare separatamente ogni fenomeno e studiarlo come fatto a sé. Altre volte, invece, al laboratorio si preferisce un contesto reale, perché i singoli fenomeni si influenzano uno con l'altro ed uno studio asettico non produrrebbe dati vicini a quelli reali.
Quando si hanno tempo e soldi a disposizione, si affrontano i singoli fenomeni in laboratorio, per averne una comprensione specifica, per poi passare ad una situazione reale in cui si studiano relazioni, interferenze reciproche e risultati d'insieme.
In questo articolo affronto l'attività di laboratorio che consente di isolare e comprendere ogni fenomeno. In successivi articoli potremo esplorare la seconda fase, quella del contesto reale.
Definizione di landing page
La landing page è una pagina di arrivo (planata) di un visitatore proveniente solitamente da un motore di ricerca (ma non è obbligatorio).
La landing può essere una pagina del sito appositamente realizzata o essere parte di un dominio registrato per lo scopo. Quest'ultima soluzione è preferita quando la URL stessa è parte in causa, per qualche motivo.
Tecnicamente una landing non ha necessariamente differenze rispetto alle pagine usuali di un sito. Solitamente, invece, sono i suoi contenuti, le parti attive ed il layout generale a renderla differente.
Landing, in sostanza, è una definizione dell'uso previsto dal progettista, non uno schema tecnico definibile ed individuabile. Un progettista, per esempio, potrebbe creare una landing in nessun modo differente da una pagina normale. Il perché lo comprenderete nel seguito dell'articolo.
Studiare i fenomeni mediante le landing page
A voi che leggete, vorrei ricordare che il titolo di questo articolo è "Usare una landing per studiare le chiavi". Non parliamo, quindi, di landing con obiettivi quali il vendere un prodotto o girare i visitatori ad un sito. Ovviamente i risultati dello studio poi si applicheranno proprio a questi obiettivi, ma qui trattiamo della fase precedente.
Per meglio comprendere i fenomeni che incidono sulla conversione visitatore/cliente, occorre studiare le visite in un ambiente controllato e modificabile senza i vincoli che normalmente un sito ha. Parliamo di comprensione, ovviamente. Questo non significa che poi il sito dovrà essere modificato.
Un webmaster, in definitiva, può anche decidere di mantenere un layout che non sia ottimizzato al massimo, l'importante è che abbia capito quali sono i fenomeni negativi, quale la loro influenza ed i rischi corsi.
La landing di studio è diversa da quella "di produzione" (espressione con la quale indico qualcosa che è effettivamente usato a regime). A volte nella landing di studio, infatti, si impostano parametri poi non ripetibili sul sito, al solo fine di comprendere certi aspetti. In questo consiste la definizione di laboratorio. Un contesto che consenta la registrazione, l'identificazione, la ripetizione di ciò che si fa.
Per iniziare, come immaginiamo una landing? Salvo precisazioni successive, la landing di studio è una pagina realizzata mediante un linguaggio server-side quale PHP o ASP, posta su un dominio specifico diverso da quello del sito (per evitare interferenze o penalizzazioni al sito), con grafica solitamente minimale.
Definire il fenomeno da studiare
Primo passo, definire il fenomeno da studiare. Un errore spesso fatto, nello studio delle visite, è il voler osservare molti fenomeni con lo stesso esperimento.
Importante, invece, è:
- fare una lista dei fenomeni che si ritiene si possano verificare;
- dare una definizione corretta per ognuno di loro;
- definire quali sono le possibili influenze sul raggiungimento dell'obiettivo finale;
- identificare uno o più parametri che li misurino;
- studiare un contesto di prova per ogni fenomeno.
Il risultato finale quasi sempre sarà che per ogni fenomeno occorre realizzare una specifica landing. Ciò potrà sembrare eccessivo, ma in realtà è pratica comune di ogni laboratorio. Perché un esperimento possa essere considerato scientifico, infatti, occorre che ogni test sia relativo ad una sola variabile. Con l'aumentare delle variabili, il test diventa meno scientifico e più empirico in quanto si trasforma in una osservazione di contesto e non nello studio di una relazione diretta di causa/effetto.
Esempio di fenomeni che si potrebbe voler studiare:
- influenza del colore sulla conversione;
- influenza del numero dei link ad altre pagine;
- osservazione dello spostamento oculare in funzione delle parti attive presenti;
- dispersione dell'interesse in funzione della catena dei click;
- abbandono del sito in funzione della presenza di link outbound.
Prima di iniziare l'attività occorre preparare un foglio elettronico destinato ai dati finali da analizzare e l'impostazione dei report. Il fatto che ciò si faccia prima di arrivare alla fine della registrazione dei dati, consente di capire in tempo che l'esperimento non sta memorizzando le informazioni necessarie a produrre poi le statistiche che ci servono. Cosa molto più frequente di quanto non si creda.
La riduzione delle interferenze
Definito il fenomeno da studiare, occorre che sulla sua landing siano ridotte al minimo le interferenze. Spesso, infatti, gli studi risultano falsati dal fatto che la visita non "gira" come noi vorremmo, ma è influenzata da fattori che non avevamo previsto.
Invece che tentare di capire cosa potrebbe influenzare, in modo da evitarne l'uso, consiglio che si riduca al minimo ogni cosa non attinente allo studio del fenomeno, indipendentemente dal fatto che poi nella realtà ciò si potrà fare o no. Con lo studio, infatti, vogliamo capire, non produrre.
Ovviamente fa eccezione quanto, pur non collegato al fenomeno, lo influenzerebbe in modo sostanziale. In tal caso, addirittura, l'esperimento sarebbe da dividere in due. Ad esempio, se vuol studiare l'influenza di un certo carattere, è probabile che un colore ne possa influenzare il risultato. Il Gotico, in particolare, è influenzato dal colore perché psicologicamente il visitatore si aspetta che sia usato in contesti scuri. Ecco un esempio di fenomeno che difficilmente si riesce a ricondurre ad una variabile sola. Segue una lista di possibili interferenze.
- Colori troppo forti o dal forte significato psicologico, sociale, razziale o religioso.
- Eccessiva presenza di componenti attivi che potrebbero distrarre.
- Link a pagine esterne o ad altre informazioni.
- Messaggi di eccessivo richiamo, rispetto al fenomeno principale.
- Suoni (salvo che non siano proprio loro l'oggetto dello studio).
Evitate un errore. Il bianco è un'interferenza lui stesso. Una pagina bianca potrebbe non essere la scelta migliore perché lungi dal sembrare asettica, su Web potrebbe sembrare eccessivamente caratteristica, al punto da influenzare certi studi. Si tratta di un fenomeno a sé, in sostanza.
Una grafica molto semplice
Ipotizzando che il fenomeno da studiare non sia la grafica, che grafica deve avere la landing per essere più asettica possibile per questo aspetto? Aspetto neutro, verrebbe da dire. Una grafica essenziale, ma non assente, senza fronzoli eccessivi, senza parti attive, senza colori violenti, senza rimandi comunicativi ad altro che non sia l'oggetto della pagina. Ad esempio, considero sbagliato, in generale:
- la presenza di disegni, immagini e foto che richiamino il logo o il marchio di un prodotto;
- la scelta di un layout che piaccia molto. Ciò che piace molto, può non piacere ad altri;
- l'eccessiva presenza grafica rispetto al contenuto;
- l'assenza totale di grafica;
- la sola presenza di contenuti grafici;
- la trasmissione di contenuti emozionali.
Un semplice esempio. Attualmente pare di moda avere immagini con la testa delle persone tagliata. Piace? Non piace? La mia considerazione è che si dovrebbe evitare, proprio per non influenzare lo studio (salvo che non sia proprio quello che vogliamo osservare).
Colori
I colori dominanti hanno un'importanza troppo spesso sottovalutata. Il viola, per esempio, da molte persone è considerato "portatore di iella". Il fatto che sia dominante potrebbe mettere a disagio molti visitatori, soprattutto in certi settori.
Anche se il sito finale dovrà essere viola, i test andrebbero effettuati su altri colori, per meglio isolare i fenomeni oggetto dello studio. Il suo utilizzo, invece, sarà un ulteriore test separato.
Un colore andrebbe evitato non solo se ritenuto negativo, ma anche se ritenuto positivo. Studiando dei fenomeni, infatti, occorre sgombrare il campo da ogni interferenza, positiva o negativa che sia.
Solitamente si tende ad usare colori chiari, che non risultino troppo evidenti rispetto ai testi e che non abbiano contenuti psicologici ed emotivi. Salvo eccezioni, quindi, non userei il rosso, l'arancione, il viola, l'amaranto, il nero. Se possibile, tendo a preferire il bianco, il celeste, il verde chiaro, il panna.
Naturalmente si parla del colore dominante. Piccole parti in altri colori si ritiene che non influiscano, salvo che non siano di eccessivo contrasto, al punto da farli diventare un fattore di distrazione.
Evitare la presenza di componenti attivi
La landing page di studio dovrebbe avere una sola azione attivabile dal visitatore. Ogni parte attiva diversa dovrebbe essere rimossa per evitare ulteriori interferenze.
Se vogliamo studiare i fenomeni connessi alla registrazione dei visitatori ad una newsletter, non deve esserci la possibilità di inviare una email, ad esempio.
La riduzione dei componenti attivi è fondamentale, per la corretta analisi dei dati finali. Più parti attive, infatti, si influenzerebbero vicendevolmente senza consentirci una reale comprensione dei fenomeni incidenti sulla conversione. Per componenti attivi, intendo:
link ad altre pagine (interne o esterne);
pulsanti e bottoni che attivano funzioni di qualunque tipo;
invio di email o moduli di richiesta contatto;
immagini con link ad altre pagine.
Continua
Abbiamo visto quali sono le caratteristiche visive e funzionali che una landing page deve avere per fungere da strumento di studio. Nella parte successiva, l'argomento sarà la registrazione dei dati e l'analisi dei risultati. Alla prossima settimana.
Nella prima parte, abbiamo visto quali sono le caratteristiche visive e funzionali di una landing page usata come strumento di studio del traffico.
Ci addentriamo, a questo punto, negli aspetti legati alla registrazione dei dati e all'analisi statistica.
Registrare le visite per contare le conversioni
La landing deve avere delle proprie routine di registrazione dei dati relativi alle visite e non impiegare un software di statistica standard. Il motivo di una tale scelta è dato dalla necessità di avere il controllo completo dei metodi di registrazione e degli algoritmi di valutazione delle visite. Infatti i parametri influenti sul numero di visitatori sono diversi ed i programmi di statistica tendono a fare proprie considerazioni. In alcuni casi, addirittura, sono parametri non influenzabili dall'esterno.
Considerando che i dati da registrare sono pochi, specifici e di significato limitato nel tempo, ritengo che l'inserimento di poche righe di ASP o PHP possa dare maggiore possibilità di controllo e quindi di certezza del dato e del suo significato.
Tutto ciò è fondamentale, se stiamo studiando. In una landing definitiva, invece, in vari casi ritengo preferibile impiegare un sistema di tracking reperito sul mercato per motivazioni che non sono pertinenti con quest'articolo e che tratterò in altri.
Per facilitare le attività di analisi dei risultati, ho sempre trovato più comodo registrare i dati in un database. Ho impiegato varie volte MySql senza aspetti negativi di rilievo. Nei casi di studio normalmente non si hanno quei volumi altissimi che potrebbero motivare l'uso di Sql Server. In alternativa, si potrebbe scrivere i dati su un file XML, cosa sicuramente vantaggiosa in termini di performance, anche se rende più laboriosa l'analisi successiva. Prima di procedere, descrivo a grandi linee lo schema della registrazione.
Per ogni visita la landing registra una sola riga nel database. Non ragioniamo in termini di accessi o richieste (hits), quindi, ne di visitatori. Per visita si intende un accesso in arrivo da punto esterno rispetto all'insieme di pagine che costituiscono il contesto del test (solitamente, comunque, una sola pagina).
La visita si registra in due fasi: con la prima si memorizzano sul database i dati di provenienza, la query string e un identificativo; con la seconda si registra se l'azione sotto controllo s'è verificata (ad esempio una richiesta di contatto, la registrazione ad una newsletter, l'acquisto di un prodotto).
I dati registrati
Per uno studio minimo, per ogni visita è necessario registrare i seguenti dati:
- IP del visitatore;
- Data e ora dell'accesso;
- Referer;
- QueryString;
- motore di provenienza;
- chiave di ricerca;
- nome della langing (o suo codice di identificazione);
- flag di azione effettuata;
- ID della visita.
È importante identificare la landing perché la maggior parte delle analisi dei dati saranno comparative. Dato che si studia l'influenza di certi fenomeni sulla conversione, è evidente la necessità di capire quali landing si stanno confrontando tra di loro.
L'ID della visita è indispensabile perché visto che la registrazione si effettua in due fasi, è necessario disporre di un identificativo del record che consenta di effettuarne l'update SQL.
Il flag di azione effettuata indica se il visitatore ha o no svolto quanto ci aspettavamo facesse.
Le routine di inizializzazione
All'arrivo del visitatore effettuo alcune attività prima di procedere con la registrazione vera e propria. Nei box successivi vi riporto le fasi salienti.
Iniziamo con una parte preparativa:
' inizializzazione del sistema di registrazione
'
dim sIPVisitatore
dim sReferer
dim sQueryString
dim sMotore
dim sChiave
dim dtDataOraVisita
dim sIdAccesso
Dim sPaginaVisitata
In questa parte si inizializzano alcune variabili usate nel seguito. Qui potete inserire altri vostri campi.
Segue una routine che consente di analizzare la provenienza della visita ed estrarre la chiave di ricerca:
Function Inizializza()
' campi di comodo
dim iStart ' inizio test
dim iEnd ' fine test
' lettura dei dati del visitatore
' e creazione di un ID della visita
dtDataOraVisita = Year(Now()) & "-" & Month(Now()) _
& "-" & Day(Now()) & " " & Hour(Now()) & ":" _
& Minute(Now()) & ":" & Second(Now())
sReferer = Request.ServerVariables("HTTP_REFERER")
iStart = InStr(1, sReferer, "?", 1) + 1
sQueryString = Mid(sReferer, iStart)
sIPVisitatore = Request.ServerVariables("REMOTE_ADDR")
sIdAccesso = dtDataOraVisita & "-" & sIPVisitatore
Nella maggior parte dei miei esperimenti, l'ID della visita l'ho ricavato come semplice unione della data/ora e dell'IP del visitatore.
'individuazione del motore nel referer
If (InStr(8, sReferer, "altavista",1)) Then
sMotore = "Altavista"
ElseIf (InStr(8, sReferer, "arianna",1)) Then
sMotore = "Arianna"
ElseIf (InStr(8, sReferer, "www.google",1)) Then
sMotore = "Google"
ElseIf (InStr(8, sReferer, "www.msn",1)) Then
sMotore = "Msn"
ElseIf (InStr(8, sReferer, "www.virgilio",1)) Then
sMotore = "Virgilio"
ElseIf (InStr(8, sReferer, "search.virgilio",1)) Then
sMotore = "Virgilio"
ElseIf (InStr(8, sReferer, "www.yahoo",1)) Then
sMotore = "Yahoo"
Else
sMotore = ""
End If
Nell'esempio, si sono riconosciuti vari motori. In molti esperimenti, in realtà, ne basta riconoscere uno solo, se il traffico è alimentato tramite pay per click.
' individuazione della chiave nella stringa dinamica
sChiave = ""
If sMotore = "Google" Then
iStart = InStr(1, sQueryString, "Q=", 1) + 2
iEnd = InStr(iStart, sQueryString, "&")
if iStart=2 then
iStart = InStr(1, sQueryString, "as_epq=", 1) + 7
iEnd = InStr(iStart, sQueryString, "&")
if iStart=7 then
sChiave=""
elseIf iEnd <> 0 Then
sChiave = Mid(sQueryString, iStart, _
iEnd - iStart)
Else
sChiave = Mid(sQueryString, iStart)
End If
elseIf iEnd <> 0 Then
sChiave = Mid(sQueryString, iStart, _
iEnd - iStart)
Else
sChiave = Mid(sQueryString, iStart)
End If
End If
If sMotore = "Yahoo" Then
iStart = InStr(1, sQueryString, "p=", 1) + 2
iEnd = InStr(iStart, sQueryString, "&")
if iStart=2 then
sChiave=""
elseIf iEnd <> 0 Then
sChiave = Mid(sQueryString, iStart, _
iEnd - iStart)
Else
sChiave = Mid(sQueryString, iStart)
End If
End If
' fine zona in asp
End Function
Ho riportato l'individuazione della chiave per due soli motori. Seguendo lo stesso criterio, è possibile riconoscere le chiavi di ricerca in tutti gli altri.
Va considerato, comunque, che le landing di studio sono normalmente alimentate da campagne di pay per click, quindi il riconoscimento della chiave è decisamente più semplice.
La registrazione della visita
La visita la registro sul database con una semplice istruzione SQL INSERT, dopo aver riconosciuto il motore e la chiave nella fase descritta in precedenza:
Function RegistraVisita()
dim oDatabase ' connessione al database
dim sBuffer ' buffer per uso generico
dim iErrore ' Flag di errore
' connessione al database
on error resume next ' trap dell'errore di apertura db
Set oDatabase = Server.CreateObject("ADODB.Connection") oDatabase.open(sStringaConnessione)
If err.number <> 0 then ' test dell'errore'
sBuffer = "ERRORE: Impossibile aprire db log<br>"
response.write sBuffer
iErrore = fdf_errore_apertura_db
end if
on error goto 0 ' resetta il trap
' compone la stringa di inserimento della visita
sQuerySql = "INSERT INTO Visite SET " + _
"IdAccesso = '" + sIdAccesso + "', " + _
"UrlReferer = '" + sReferer + "', " + _
"IpVisitatore = '" + sIPVisitatore + "', " + _
"DataOraVisita = '" & dtDataOraVisita & "', " + _
"ChiaveRicerca = '" + sChiave + "', " + _
"MotoreProvenienza = '" + sMotore + "', " + _
"QueryString = '" + sQueryString + "', " + _
"PaginaVisitata = '" + sPaginaVisitata + "', " + _
"RichiestaContatto = 0;"
' Inserimento record
if iErrore = 0 then
on error resume next ' trap chiave doppia
oDatabase.Execute sQuerySql,, adExecuteNoRecords If err.number <> 0 then sBuffer = "ERRORE: Inserimento non riuscito2<br>"
iErrore = fdf_errore_record_doppio
response.write sBuffer
end if
on error goto 0
end if
' fine salvataggio dati
on error resume next ' oscura errore per db già chiuso
oDatabase.Close ' chiude la connessione
Set oDatabase = Nothing ' rilascia la memoria allocata
on error goto 0 ' toglie il trap
' fine zona in asp
End Function
Nell'esempio, la gestione dell'errore è minima, ma sufficiente per uno studio.
Ricordate che il frammento di codice, da richiamare all'accesso del visitatore alla pagina, ha lo scopo di registrare che qualcuno è arrivato alla pagina, non se ha o no effettuato l'azione che ci interessa.
La registrazione del verificarsi della conversione
Nel momento in cui il visitatore compie l'azione che vogliamo tenere sotto controllo, si avvia la funzione di modifica del record/traccia della visita, per impostare il flag che consentirà di tenere memorizzata l'informazione di avvenuta conversione.
Function RegistraContatto()
dim oDatabase ' connessione al database
dim sBuffer ' buffer per uso generico
dim iErrore ' Flag di errore
on error resume next Set oDatabase = Server.CreateObject("ADODB.Connection") oDatabase.open(sStringaConnessione)
If err.number <> 0 then
sBuffer = "ERRORE: Impossibile aprire db log<br>"
response.write sBuffer
iErrore = fdf_errore_apertura_db
end if
on error goto 0
' compone la stringa di inserimento della visita
sQuerySql = "UPDATE Visite SET " + _
"RichiestaContatto = 1, " + _
"TipoTransazione = '" + sTipoTransazione + "' " + _
"WHERE IdAccesso = '" + sIdAccesso + "';"
' Inserimento record
if iErrore = 0 then
on error resume next oDatabase.Execute sQuerySql,, adExecuteNoRecords If err.number <> 0 then sBuffer = "ERRORE: Registr. non riuscita<br>"
iErrore = fdf_errore_record_doppio
response.write sBuffer
end if
on error goto 0
end if
' fine salvataggio dati
on error resume next
oDatabase.Close
Set oDatabase = Nothing
on error goto 0
End Function
Nell'esempio, la routine si chiama RegistraContatto in quanto si trattava dello studio dei fenomeni incidenti sulla richiesta di contatto per informazioni commerciali. Il nome corretto sarebbe, probabilmente, RegistraConversione, in quanto più generico.
La bonifica dei dati
Durante lo svolgimento dell'esperimento è importante verificare spesso il database alla ricerca di errori nella registrazione dei dati. Arrivare al termine del periodo di tempo riservato all'esperimento e scoprire che i dati non sono quelli che ci si aspettava, implica la ripetizione di tutto il lavoro. Alcuni problemi che normalmente riscontro, sono:
- errori SQL che producono "garbage" sul database;
- visite provenienti da motori non previsti e non riconosciuti;
- chiavi riportate con QueryString diverse da quelle conosciute;
- errori di conversione della data e dell'ora;
- mancato aggancio tra la prima fase della registrazione e la seconda.
Nel caso si evidenzino questi problemi, normalmente si procede ad una bonifica manuale dei dati, quando possibile. Diversamente, tale periodo è da scartare dall'analisi successive.
La modifica delle routine
Se il controllo dei dati evidenzia problemi delle routine, esse vanno ovviamente modificate. In generale, ciò che va tenuto sotto controllo è:
- il riconoscimento di nuovi motori;
- la diversa provenienza dal dominio di terzo livello da un motore già conosciuto;
- una diversa struttura della QueryString, soprattutto per la variabile legata alla chiave (q=).
Tale routine sono di uso generico, per chi fa questi studi, quindi tutto il tempo trascorso a migliorarle non è sprecato.
Analisi dei dati
Finito il periodo di registrazione, si passa all'analisi dei dati.
Per una migliore lavorazione degli stessi, consiglio che i dati siano estratti dal database, dopo aver inserito opportuni filtri, e passati ad un programma di statistica quale SPSS (Marchio registrato di SPSS Inc.) o R. In alternativa può essere impiegato MS-Excel. Mediante tali programmi è possibile ordinare i dati, porre filtri di selezione, oscurare alcuni aspetti o evidenziarne altri.
È importante che tutte le analisi siano effettuate su copie di dati, in modo da evitare di perdere gli originali a fronte di correzioni manuali o di simulazioni.
Consiglio, inoltre, che i risultati delle analisi siano riportati in vari report, con le seguenti indicazioni:
- oggetto;
- fenomeno osservato;
- data dell'osservazione;
- metodo;
- filtri applicati ai dati;
- valori numerici rilevati;
- note dell'operatore.
Conclusione
Realizzare landing per lo studio è un'attività diversa rispetto alla preparazione di landing che saranno poi usate nei contesti reali e definitivi (landing di produzione).
Anche se a tratti potrebbe risultare tedioso, è importante che si segua un metodo che senza essere del tutto scientifico, si avvicini quanto più possibile all'esserlo. In generale, quello che è veramente importante è riportare numeri al posto delle semplici congetture. Troppo spesso si sentono considerazioni fatte senza il supporto di una prova qualitativa e quantitativa. Effettuare questi esperimenti è altamente formativo anche in relazione allo studio del modello comportamentale dei navigatori.