Web Analytics: applicativi di web e log analyser, uno sguardo sui prodotti che consentono analisi e statistiche sulla navigazione in internet (software selections)

Completo il cliclo di articoli riguardanti la software selections, proponendo un estratto della ricerca di cui sono autore con un benchmark tra i software di statistica (Web e log analyser, i prodotti che consentono analisi e statistiche sulla navigazione in internet).
Non è stato facile orientarsi. Per un’azienda che intende dotarsi di questi strumenti può arrivare a spendere fino a 3/4 mila €uro all’anno (specie nel caso di gestione di più siti con applicativo server). Esistono soluzioni open source.
La mia personale gradatoria, su una base di 73 applicativi di Web e log analyser, come motiverò più avanti, è la seguente:

Rank__ Applicativo di web log analyser__________ Link_____________________________ Criteri %
1 ConversionLab  – TrackSet  http://www.trackset.it/conversionlab/ 87%
2 ShinyStat  http://www.shinystat.com/it/ 83%
3 Site Meter http://www.sitemeter.com/?a=howworks  80%
4 Omniture SiteCatalyst http://www.omniture.com/products/ 77%
web_analytics/sitecatalyst
5 Click Tracks http://www.clicktracks.com/ 67%
6 Php-Stats http://www.phpstats.net/ 67%
7 Clicky – Web Analytics 2.0 http://getclicky.com/ 66%
8 ImetriX Web Analytics  http://www.imetrix.biz/ 66%
9 WebTrends Analytics http://www.webtrends.com/Products/ 63%
WebTrendsAnalytics8.aspx
10 COGITO Monitor (di Expert System SpA – Modena) http://www.expertsystem.net/
page.aspid=1521&idd=191
61%

Criteri di ranking utilizzati nell’analisi/benchmark

I criteri tenuti in considerazione, hanno riguardato il rispetto e/o la presenza dei seguenti requisiti ricercati nell’analisi/benchmark effettuata:

1)  Open Source
2)  Possibilità ottenimento/disponibilità del codice sorgente
3)  Mantenimento dati storici
4)  Funzioni MKT avanzate:
a.  Monitoraggio conversioni
b.  Gestione obiettivi/ROI
5)  Gestione multi utente:
a.  Monitoraggio di più siti
b.  Monitoraggio di più clienti
c.  Gestione admin centralizzata
6)  Piattaforma
7)  DataBase
8)  Business Intelligence
9)  Benchmarking altri siti/categorie
10) Grafica-View

Il primo è risultato ConversionLab  della TrackSet.

Nonostante non sia un applicativo di web analyser Open Source, il primo è risultato essere ConversionLab, per la completezza dei requisiti rispettati e per le funzionalità di analisi e di business intelligence presenti nell’applicativo.
ConversionLab ottimizza il ROI massimizzando le conversioni delle campagne pubblicitarie. Analizza il rendimento di ogni campagna promozionale. Studia l’efficacia della comunicazione in rapporto alle performance di conversione Individua i punti di forza e di debolezza delle pagine web. Studia i percorsi di visita in rapporto alle provenienze ConversionLab risulta essere un solo strumento di Web Analytics per rispondere in modo chiaro e preciso a tutte le esigenze di comunicazione e Marketing: valutare la redditività di ogni attività online per ottimizzare il web media-mix in funzione del ROI, capire i comportamenti dell’utenza per migliorare la propria comunicazione online, monitorare il raggiungimento dei propri obiettivi di marketing.
Per la società alal quale avevo fatto questa analisi, avevo consigliato una partnership commerciale e/o di sviluppo funzionalità. Trackset, tra l’altro, propone un programma specifico per i professionisti della comunicazione e dell’advertising online, le new media agency, le agenzie SEO/SEM. Il team di Trackset lavorerà a fianco dei partner, definendo la configurazione e i tool più adatti al perseguimento degli obiettivi strategici.

Google Analytics, per esempio, è risultato solo diciottesimo. Google Analytics fornisce tutte le informazioni necessarie sulle modalità con cui i visitatori hanno raggiunto il tuo sito e su come interagiscono con esso. Grazie a Google Analytics, si possono inserire gli obiettivi di conversione delle campagne e sulle iniziative che consentono un buon rendimento dell’investimento e migliorare il tuo sito allo scopo di ottenere un numero maggiore di conversioni.

La web analytics disponibile in Open Source

Riporto anche i risultati riguardante gli applicativi che svolgono funzioni di web analytics open source (freeware e/o GPL)

Rank_ Applicativo di web log analyser Link Criteri
%
06._ Php-Stats
_____________________
http://www.phpstats.net/ 67%__
12. PhpMyVisites http://www.phpmyvisites.net/ 59%
16. Piwik  http://piwik.org 56%
24. Castwave http://sourceforge.net/projects/castwave/ 47%
26. PHP/SWF Charts  Joined per ROI http://www.maani.us/charts/index.php?menu=Gallery&submenu=Joined 46%
29. Webmensa http://sourceforge.net/projects/webmensa/ 46%
30. Accessible Web Statistics (AWS) http://sourceforge.net/projects/aws/ 43%
36. Mint http://www.haveamint.com/ 39%
37. The Mellow Project http://sourceforge.net/projects/mellow/ 39%
39. AWStats 6.7   http://awstats.sourceforge.net/?seenIEPage=1 37%
42. Weblinks Status Analyzer Lite  http://www.hotscripts.com/Detailed/64106.html 36%
43. WSA (Web Site Analytics)  http://sourceforge.net/projects/wsa-project/ 31%
48. Visitors Web Log Analyzer  http://www.hotscripts.com/Detailed/39155.html 29%
49. Web Log Analyzer  http://www.mailnavigator.com/
downloadanalyzer_italy.html
 
29%
51. Barracuda TDS – Traffic Development Software  http://www.boonex.com/products/barracuda/ 27%
53. Open flash chart http://teethgrinder.co.uk/open-flash-chart/ 27%
55. Lightweight Servlet Analytics http://sourceforge.net/projects/servletstats/ 24%
56. A J-Bot Finder  http://www.quickwebloganalysis.com/ 23%
58. AlterWind Log Analyzer Lite  http://www.hotscripts.com/Detailed/51027.html 19%
60. LLOOGG http://lloogg.com/ 19%
62. AlterWind Log Analyzer Standard 3.3 http://www.download.ro/~it~/6197/alterwind-log-analyzer-lite.html 11%
64. TrackSite Free 5.4.1 http://www.download.ro/~it~/904/tracksite-free.html 9%
71. Web Stat.ms http://www.webstat.ms/Statistiche_Web 6%

Per approfondimento e per avere l’analisi completa "Web_Analysis_Strumenti a confronto" (in pdf), potete richiederla con un e-mail al mio indirizzo: Richiesta documento.

Leonardo Milan

Condividi questo articolo:

technoratiTechnorati oknotizieOKnotizie segnaloDelicious segnaloSegnalo segnaloDigg

Contatore utenti connessi

Scegliere un’architettura: linee guida e ruolo del middleware

Come già trattato nell’articolo precedente “Dallo studio di fattibilità; alla software selection: analisi e scelta degli strumenti e delle tecnologie“, un team di sviluppo ha a disposizione un insieme ragionevolmente ampio di scelte e alternative. Inoltre, i diversi stili architetturali possono essere combinati per ottenere strutture e architetture complesse. I criteri principali (e iniziali) si riferivano alla scelta tra prodotti/applicazioni industriali e prodotti/applicazioni Open Source.

Introduzione metodologica alla scelta architetturale

Come si sceglie un’architettura?
Come si giunge a scegliere uno stile architetturale (o una combinazione di stili) tra i tanti possibili?

Se è vero che l’architettura di un sistema non è derivabile in modo diretto dalla natura e struttura del problema, quali criteri e linee guida occorre seguire nel progettare la soluzione? In realtà questo passaggio costituisce uno degli elementi più critici e complessi del lavoro iniziale della analisi architetturale.
In questa fase entrano in gioco aspetti quali l’esperienza del team di sviluppo, della sua capacità di analisi e sintesi, ma anche di intuito e di creatività. Il problema da risolvere in ordine allo sviluppo e/o reengineering di un sistema informativo è stato “osservato e studiato”.
In generale, è difficile ricondurre la scelta di una soluzione architetturale a un mero processo o metodo sistematico che determina in modo meccanico quale alternativa preferire. Ci sono peraltro una serie di criteri e di linee guida che possono essere seguiti come qui di seguito andiamo ad enunciare.

Linee guida e aspetti considerati

a) Scelte architetturali già perseguite in casi simili: il DSSA – Domain Specific Software Architecture, l’ambiente e le caratteristiche del dominio applicativo dell’azienda.

Esempio: DSSA Domain Specific Software Architecture Activity Flow
(Fonte: The Domain-Specific Software Architecture Program)

In primo luogo, esistono soluzioni architetturali per specifici settori applicativi. Per esempio, nel caso dei sistemi di controllo, vi sono architetture di riferimento che possono essere raffinate e adattate al caso specifico. Nel mondo delle applicazioni per Internet, la stessa architettura (Java Platform, Enterprise Edition) identifica una serie di elementi e componenti per la costruzione di applicazioni distribuite client-server multilivello.
Il team di progetto, a fronte di un problema, può quindi innanzitutto valutare le scelte architetturali già perseguite in casi simili e che si sono rivelate efficaci per quel tipo di problemi. Negli anni scorsi, è stata creata l’espressione Domain Specific Software Architetture proprio per indicare soluzioni architetturali ottimali per “specifici domini applicativi”.

b) L’analisi dei requisiti e dalle caratteristiche

Occorre chiedersi: quale architettura è più coerente con le richieste del committente?
Più in generale, la definizione dell’architettura di un sistema complesso viene effettuata studiando i requisiti (vedi anche “Implementazione di un CRM: un confronto tra approccio applicativo e organizzativo“) e le caratteristiche del problema sia da un punto di vista funzionale che non funzionale.
I risultati di queste analisi sono confrontati con le caratteristiche e proprietà tipiche dei diversi stili e da questo nascono le ipotesi architetturali. Se il problema, per esempio, è l’integrazione di archivi dati gestiti da organizzazioni autonome, è evidente che nascono (almeno) due possibilità:
– o si consolidano tutti i dati in un archivio centrale, con un sistema client-server (magari a più livelli per ottimizzare le prestazioni complessive)
– oppure si adotta un’architettura P2P – Peer-to-Peer, nella quale ciascuno continua a essere “padrone e gestore unico” dei propri dati. In questo secondo caso, si pone il problema di come propagare query e operazioni di aggiornamento delle informazioni. Quindi si potrebbe pensare a un sistema P2P ibrido oppure a un’architettura composita P2P + publish-subscribe.

La scelta tra queste diverse alternative deve considerare il trade-off (vantaggi e svantaggi della scelta, considerando anche gli aspetti di costo-opportunità) che ciascuna soluzione comporta.
Se per esempio le funzioni e operazioni svolte da ciascun nodo autonomo sono le stesse e avvengono su dati assolutamente identici, non ha senso avere una replicazione dei sistemi: un sistema centralizzato (magari ridondato per garantire fault-tolerance e affidabilità) è la soluzione più conveniente dal punto di vista economico e gestionale. Se invece i diversi nodi hanno, almeno in parte, dati diversi con funzioni che possono mutare o evolvere in modo indipendente, è preferibile (se non obbligatorio) attuare una strategia distribuita P2P.
In ogni caso, è evidente che il team di progetto si trova di fronte a un insieme non limitato di alternative.
Spesso, esse non sono presenti solo o principalmente a livello di stile architetturale, ma anche e soprattutto a livello di variante o specifica implementazione dello stile o di combinazione di stili.
Sono l’esperienza, le competenze, l’intuito e la professionalità di un team di progetto a costituire la chiave di volta per affrontare questo passaggio in modo efficace e convincente.

c) Il deployment le infrastrutture IT: le prestazioni e l’efficienza del sistema

 

La scelta di un’architettura deve essere guidata anche da considerazioni di carattere prestazionale. Potrebbe essere necessario, per garantire un certo tipo di prestazioni, dover valutare quale architettura risulti più conveniente, oppure come una certa architettura debba essere rivista o adattata per conformarsi al problema specifico.

– Per esempio, dovendo gestire un alto carico di richieste in un sistema client-server multi-tier, potrebbe essere utile avviare studi che valutano, dal punto di vista della capacità complessiva di risposta, architetture a tre o quattro livelli, con diversi meccanismi di distribuzione delle funzioni applicative o dei criteri di replica e gestione dei tier intermedi.
– Da tempo, questo tipo di analisi è condotto simulando e studiando il comportamento delle diverse architetture tramite modelli matematici basati sulla teoria delle code (o tecniche simili). Tali approcci sono piuttosto diffusi in molti settori dell’ingegneria e sono certam
ente di ausilio anche al team di progetto.

d) II ruolo del middleware (Orchestration, ESB – Enterprise Service Bus e WorkFlow)

Da Wikipedia: con il termine middleware
oggi si intendono una serie di strumenti come DBMS, Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, servizi Web e architetture orientate ai servizi.
Un aspetto importante che influisce in modo significativo sull’attività di progettazione è la scelta del middleware. Infatti, è indubbio, e alcuni studi lo hanno dimostrato, che l’utilizzo di una particolare tecnologia di middleware influisce sulle scelte architetturali. Può persino accadere che l’adozione di un tipo di middleware renda più o meno facile (e persino possibile) la realizzazione di una soluzione basata su una specifica architettura.

– Tecnologie a eventi
Un caso esemplare è costituito dalle tecnologie di middleware a eventi (tipo – Java Message Service).
Queste tecnologie forniscono operazioni e servizi per gestire la pubblicazione e ricezione di eventi: offrono il dispatcher e i servizi di publish, subscribe, push e pull.

– Architettura
Dovendo realizzare un’architettura , è indubbio che la disponibilità di questo tipo di tecnologia faciliti grandemente tutto il processo di sviluppo.
Il team di progetto può concentrarsi nell’identificazione dei diversi componenti dell’architettura, dei tipi di eventi da scambiare e della gestione della chiamata dei servizi offerti dal middleware, ignorando gli aspetti implementativi della gestione degli eventi.Questa architettura consente un’elevata .

– Sistema
Al contrario, se si dovesse realizzare un sistema utilizzando un middleware a eventi, il team di progetto si troverebbe di fronte a problemi non marginali. Certamente è possibile realizzare una chiamata sincrona attraverso pubblicazioni di eventi e sottoscrizioni, ma il compito del team di progetto sarebbe alquanto ostico.
Chi richiede un servizio deve pubblicare un evento con le informazioni sul servizio richiesto.
Il ricevente deve essersi già sottoscritto a quel tipo di evento. In caso contrario, la richiesta va persa e il richiedente rimane inascoltato (senza avere meccanismi efficienti per venirlo a sapere in tempi rapidi).
Quando chi offre il servizio riceve l’evento di richiesta, deve generare un nuovo evento con la risposta.
Il richiedente del servizio deve essersi registrato per tempo, per poter essere sicuro di ricevere l’evento di risposta.
Come si può facilmente desumere, pensare di gestire interazioni client-server con questo meccanismo è semplicemente improponibile: appare quindi evidente che la scelta del middleware possa avere un’influenza più o meno significativa sull’architettura (e viceversa).

In generale, ogni tecnologia di middleware, in modo più o meno invasivo, induce uno o più stili architetturali. Esistono tecnologie di middleware molto semplici e flessibili che possono essere utilizzate per tutti gli stili architetturali.
Altre sono particolarmente adatte a realizzare solo uno o pochi stili.

– Adozione della RMI – Remote Method Invocation
Per esempio, con l”adozione della RMI – Remote Method Invocation, invocazione remota di metodi) si utilizza una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete.
Questa tecnologia include una API (application programming interface) il cui scopo esplicito è quello di rendere trasparenti al programmatore quasi tutti i dettagli della comunicazione su rete.
Essa consente, infatti, di invocare un metodo di un oggetto remoto (cioè appartenente a un diverso processo, potenzialmente su una diversa macchina) quasi come se tale oggetto fosse “locale” (ovvero appartenente allo stesso processo in cui è eseguita l’invocazione). In questo senso, la tecnologia RMI può essere ricondotta, da un punto di vista concettuale, all’idea di chiamata di procedura remota riformulata per il paradigma object-oriented (in cui, appunto, le procedure sono sostituite da metodi).
Con RMI è possibile realizzare sistemi client-server a più livelli e, con un po’ di programmazione aggiuntiva, anche sistemi P2P. Le architetture (Java Platform, Enterprise Edition) sono particolarmente adatti a sistemi client-server multi-tier con codice mobile di tipo COD (tramite gli applet), mentre può risultare (nella sua configurazione completa) particolarmente pesante e onerosa per gestire sistemi P2P con funzioni RE (Remote Evaluation).

Avendo scelto uno stile architetturale, è quindi necessario assicurarsi che il middleware prescelto sia compatibile con la scelta fatta. Il middleware gioca inoltre un ruolo importante anche nella scelta di componenti da integrare in un sistema informatico esistente o già parzialmente implementato.
Infatti, se il componente utilizza meccanismi di middleware e logiche di funzionamento (interfacce) non compatibili con il “sistema ricevente”, si ha una situazione di integrazione impossibile (“rigetto”) o estremamente costosa (è necessario costruire adattatori che facciano da interprete tra le diverse parti).
Ancora una volta, emerge un problema di scelta progettuale che vede il team di progetto giocare un ruolo essenziale. Nel determinare l’architettura del sistema e il middleware di supporto, il team di progetto deve assicurarsi che non vi sia architectural mismatch, cioè incompatibilità architetturali tra i diversi elementi dell’architettura e in particolare tra essi e il mid
dleware
scelto per implementarli.

Da dove partire: l’approccio Top-down e Bottom-up

In diverse circostanze, è emerso un tema particolarmente rilevante: nella progettazione e realizzazione di un sistema informatico si procede in modo top-down o bottom-up?
– L’approccio Top-down
Deriva direttamente dalla logica dello stepwise refinement:
si parte dall’astrazione massima e progressivamente la si raffina in funzioni elementari e quindi in codice. Più in generale, si definisce l’architettura del sistema e si raffinano i ai diversi componenti ed elementi che ne emergono.
“Scendendo” a livello di componente si giunge a progettare il modulo e quindi il codice dei singoli metodi o procedure.
– L’approccio Bottom-up
Si parte da componenti già pronti o facilmente realizzabili e li si assembla progressivamente fino a costituire il sistema completo.
È l’approccio che sfrutta al meglio i cicli di vita basati sul riuso di componenti (component-based development).

Leonardo Milan

Technorati Tag: Studio di fattibilità,Software Selections,percorso decisionale e implementativo

Contatore utenti connessi