Carlos Sena

Para fechar esta série de posts sobre audiência em Portais, vou falar um pouco sobre métricas.

A maioria das ferramentas de audiência Web, principalmente aquelas baseadas em processamento de logs, nos fornece indicadores brutos como a quantidade de visitantes únicos, a quantidade de páginas servidas e páginas mais e menos vistas. Estes indicadores brutos nos fornecem pouca informação sobre a “saúde” do nosso site. Para gerenciar a performance do nosso site devemos primeiro identificar os nossos objetivos e então encontrar as métricas capazes de representar a nossa eficácia em atingi-los.

Digamos que o objetivo seja aumentar a visitação na área de produtos, e que para isso vamos fazer uma mudança na navegação do web site. Precisamos encontrar métricas que meçam a efetividade das alterações da navegação e acompanhar a tendência desta métrica ao longo do tempo. A simples medição de páginas vistas, ou mesmo do ranking de páginas mais vistas é incapaz de nos dizer se a mudança surtiu o efeito desejado.

Neste caso seria muito mais efetivo acompanhar a Bounce Rate das páginas desejadas. A Bounce Rate mede a quantidade de visitas que iniciaram nesta página (por exemplo, chegaram na página através de uma pesquisa no Google) e abandonaram o site em seguida (por exemplo, digitaram outra URL ou fecharam o browser). Uma Bounce Rate alta indica que muitos usuários abandonam o site, talvez por não encontrar nesta página outros conteúdos ou links interessantes, ou por não encontrar um link para comprar o produto, e por isso interrompem a navegação. Se a mudança no desenho do site estiver surtindo efeito, a Bounce Rate deveria ter uma tendência de queda.

Outra métrica que anda junto da Bounce Rate é a Conversion Rate, que mede a porcentagem de usuários que efetuam uma ação a partir de uma determinada página. Por exemplo, quantos usuários clicam no link de compra a partir da página com a descrição do produto. Se um dos seus objetivos é aumentar as vendas de um produto ou aumentar o número de funcionários que acessam o novo treinamento de RH na Intranet, você deve acompanhar a tendência da Conversion Rate.

Em todos os casos você deve primeiro definir seus objetivos para então escolher suas métricas e começar a acompanhá-las. Não basta ficar gerando relatórios de páginas mais vistas e não ter idéia das tendências nos números, ou o impacto das mudanças que você está fazendo no site. E por falar em mudanças, mude apenas um aspecto de cada vez (navegação, layout, disposição dos conteúdos, banners) e verifique o impacto nas métricas correspondentes. Se você mudar tudo de uma vez vai ser difícil de medir a efetividade, além de confundir a cabeça do seu usuário.

Para quem começou a usar o Google Analytics, aproveite os dois excelentes sites: Conversion University e Google Analytics Blog.

No último post falei sobre os sistemas de audiência Web por tracking pixels, como o Google Analytics. Estes sistemas permitem analisar a audiência de um site Web sem o processamento de logs, independente da tecnologia em que o site é implementado. No entanto, ao usar o tag padrão do Google Analytics em um site dinâmico, os relatórios gerados exibem URLs que não fazem sentido. De que adianta saber que a página mais acessada do nosso site é /wps/portal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_4S9/_s.7_0_A/7_0_4S9?

Um pequeno truque no tag do Google Analytics é forçar um parâmetro na chamada de urchinTracker() (outra opção é setar variáveis antes da chamada da função; baixe e abra o arquivo urchin.js para ter uma idéia das variáveis disponíveis) . Este parâmetro será a URL da página que desejamos que apareça no relatório. Por exemplo, a seguinte URL faz muito mais sentido em um relatório do que a que mostrei acima:

urchinTracker("/produtos/cds/blues/Buddy Guy");

A forma de gerar esta URL depende da ferramenta usada. Por exemplo, no JetSpeed você vai introduzir o tag do Google Analytics em decorations/layout/meulayout/footer.vm. O JetSpeed usa as macros do Velocity. A variável $site.getMenu(“breadcrumbs”) contém o breadcrumb trail para a página atual. É muito fácil customizar as macros em decorator-macros.vm para gerar um path para ser incluído dentro do urchinTracker().

E se a sua empresa não quiser usar uma ferramenta externa para analisar estatísticas? Uma coisa que pouca gente sabe é que o Google Analytics é resultado da compra de uma empresa, a Urchin. O que menos gente ainda sabe é que o Google ainda vende o Urchin em uma versão que você pode instalar em um servidor dentro da sua empresa! É uma versão paga e menos atualizada do que o Google Analytics, mas o fato de ser uma solução instalada pode ter um peso decisivo no momento da escolha.

Digamos que além da audiência das páginas do Portal você esteja interessado na audiência de cada portlet. Algumas ferramentas como o WebSphere Portal podem ser configuradas para gerar logs detalhados de logins/logouts, páginas, portlets, aplicações, etc. Existe um bom artigo sobre como configurar o WebSphere Portal e uma ferramenta de processamento de logs (no caso o OpenSource AWStats) para obter estatísticas de Portal. Note no entanto que a geração excessiva de logs pode penalizar a performance do Portal.

Pra fechar a série sobre estatísticas, no próximo post vou falar sobre métricas úteis. Até lá!

No post anterior explorei alguns motivos para a inadequação de sistemas de processamento de logs de servidores Web para a análise de audiência de sites dinâmicos e Portais. Os sistemas de tracking baseados em tags são uma alternativa ao processamento de logs. Apesar de não ser uma solução nova, ela ganhou bastante evidência com o Google Analytics.

O pulo do gato usado por qualquer sistema de tracking baseado em tags é o tracking pixel, pixel tag ou web beacon. O tracking pixel é uma imagem transparente, com 1 pixel de altura por 1 pixel de largura. Com estes atributos, ela pode ser escondida em qualquer lugar da página, e normalmente é colocada no final da página. Esta imagem é gerada dinamicamente por um recurso no servidor, como um CGI ou um servlet. No caso do Google Analytics você inclui um JavaScript, que no final gera uma imagem deste tipo:

<img src="http://www.mysite.com/__utm.gif?utmt=imp&utmcid=10">

A imagem “__utm.gif” não é uma imagem; ela é um programa executável em um servidor. Repare que ela recebe parâmetros, e estes parâmetros podem indicar a campanha que se está rastreando, a mídia, o path que queremos gerar nos relatórios, etc.

É fácil – e grátis – criar sua conta no Google Analytics. Depois de preencher um formulário simples, você recebe um código parecido com este, que deve ser incluído em todas as páginas do seu site:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct="UA-xxxx-x";
urchinTracker();
</script>


Onde “UA-xxxx-x” deve ser substituído pelo seu código individual, que foi criado durante o seu cadastro. Agora basta colar este código perto do final de cada página e você comecará a coletar seus dados e gerar excelentes relatórios.

Mas ainda não chegamos onde eu quero. Os nossos relatórios ainda estão sendo gerados com URLs malucas… Isto é assunto para o próximo post!

Acompanhar a audiência de um site é fundamental para conhecer o comportamento dos usuários e promover ajustes para melhorar os resultados. Através da medição descobrimos quais conteúdos tem atraído mais e menos audiência, de onde vem os usuários, qual foi o último conteúdo visto antes de deixar o site, e assim por diante. Um conteúdo pode ser pouco visto por não atrair a atenção dos usuários, ou porque está mal divulgado, ou envelheceu. O fato é que sem a medição não podemos avaliar a “saúde” do site.

Em sites estáticos a medição da audiência normalmente é feita através do processamento de logs dos servidores Web. Ferramentas como WebTrends ou AWStats processam os logs de um período e geram relatórios com as métricas mais comuns: páginas vistas por período, sessões no período, tráfego total no servidor e assim por diante. Estas análises dependem que a informação desejada esteja no arquivo de log. Por exemplo, para saber que a página mais vista do site é “Suporte”, é preciso que a URL desta página seja algo do tipo “/suporte/index.asp” para que seja registrada no log de forma identificável.

O problema se torna bastante mais complexo com sites dinâmicos, onde geralmente as URLs não correspondem de forma óbvia ao conteúdo exibido. Por exemplo, o CD que estou escutando agora tem a seguinte URL no Submarino:

http://www.submarino.com.br/cds_productdetails.asp?Query=&ProdTypeId=2&CatId=11002&PrevCatId=11001&ProdId=216873&ST=BL11002&OperId=0&CellType=2

Esta URL em uma configuração normal será registrada no log do servidor Web como “/cds_productdetails.asp”, o que não registra muita informação. Ao processar os logs no WebTrends ou qualquer outro analisador de logs, todos os CDs serão contados em um único número. Para compensar esta limitação, a maioria dos sites dinâmicos que precisa da informação registra esta audiência de outra forma, como um hit no banco de dados. Nem é preciso lembrar que o custo deste log em banco de dados é bem mais alto do que o processamento de logs.

Para tornar o problema ainda pior, os sites baseados em tecnologia de Portal possuem várias características que dificultam a tomada de métricas e análise:

• URLs dinâmicas – Por exemplo, a URL de uma página do WebSphere Portal tem a seguinte aparência /wps/portal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_4S9/_s.7_0_A/7_0_4S9. No Vignette Portal não é muito diferente: /portal/site/ets/menuitem.435c0b5cc7bd0ae7015d9510c3921509. A maioria das soluções de Portal não usa Friendly ou Vanity URLs (URLs “bonitas”), e conseqüentemente não geram bons logs nos servidores Web
• Personalização – Os Portais são segmentados e personalizados, portanto a página que eu vejo não é a mesma que você vê
• Portlets – As páginas de Portal são feitas a partir de componentes, os portlets. Por exemplo, a homepage da minha Intranet pode ter um portlet de notícias, outro com uma aplicação do RH, outro com os dados técnicos dos produtos da empresa, e assim em diante. Os mesmos portlets podem ser – e são – reutilizados em outras páginas

Apesar de todas estas diferenças, muita gente tenta medir a audiência de sites dinâmicos e Portais da mesma forma que fazia com sites Web estáticos. E apesar dos enormes ganhos obtidos com o Portal, muitos se decepcionam com a perda de visibilidade da audiência, e conseqüentemente da sensação de controle que tinham antes.

Nos próximos posts quero discutir um pouco sobre a audiência, especialmente em ferramentas de Portal. Contribua: envie comentários sobre a sua experiência!