Tag Archives: webstats

Alexa – dados fieis de outros sites

Published by:

Um destes dias o Sérgio Rebelo questionava-se se os dados do Alexa são fiáveis, e se não que dados teriamos para comparar o tráfego de sites.

As respostas simples e curtas são “não” e “nenhuns”.

Alexa

Não, os dados do Alexa não são fidedignos devido à forma como são recolhidos e calculados. O Alexa baseia-se em dados fornecidos por alguns ISPs e em dados recolhidos pela utilização da sua barra.

Não sei se existe algum ISP português que lhes forneça dados, penso que não. Mas a existir representa apenas uma amostra dos utilizadores de um portal. E certamente que não são fornecidos logs de todo o tráfego desse ISP, mas apenas uma amostra desse tráfego.

A barra, em contrapartida, tem uma taxa de penetração relativamente pequena. Mas além de uma taxa de penetração pequena, a barra é utilizada especialmente por pessoas mais ligadas à internet, como webdesigners, programadores web, editores e jornalistas de sites.

Alexa tem certamente dados reais de vários sites, incluindo aqueles que têm os gráficos em todas as páginas, o que lhes permite calcular depois rácios tão precisos quanto possível que depois utilizam para estimar da melhor forma possível o tráfego real dos sites para os quais apenas têm amostras de tráfego.

São os dados apresentados pelo Alexa realmente precisos? Não, são apenas estimativas. O Alexa tenta que os dados sejam o mais precisos possível para os grandes sites.

Uma consequência da dimensão dos grandes sites é serem acedidos por pessoas com interesses e actividades muito distintos, terem um publico muito genérico e englobante. Em consequência disto, a percentagem de utilizadores da barra do Alexa no total de utilizadores de cada um desses sites não varia muito.

Mas se formos comparar dados de um site genérico com um site temático destinado a pessoas ligadas à internet, o resultado vai ser completamente diferente, pois os utilizadores com a barra do Alexa representam uma percentagem muito maior dos utilizadores do site temático do que na generalidade dos grandes sites, fazendo com que o ranking dos sites temáticos seja largamente inflacionado pelo Alexa.

No entanto, no caso dos sits genéricos, como os principais portais portugueses, os dados do Alexa são (normalmente) relativamente fidedignos. Quando estava no Sapo tinhamos essa prespectiva da informação do Alexa, e algumas vezes durante o tempo em que fui responsável pelas estatísticas do IOL verifiquei essa mesma informação.

Mas se formos utilizar o Alexa para comparar dados de sites em áreas temáticas diferentes podemos ter surpresas, que não têm ligação directa com a realidade.

Mas quando se comparam sites com uma mesma temática e foco, poderão obter-se resultados comparativos muito interessantes (especialmente se soubermos o tráfego real de um dos sites comparados).

Outros

Mas, se os dados do Alexa não nos dizem o real tráfego de um site, existe alguma forma de obtermos esse tráfego?

Bem, seria possível, mas não seria fácil. E que eu saiba não foi feito ou tentado sequer.

Para se conseguir dados de vários sites seria preciso convencer as empresas responsáveis pelos respectivos datacenters a deixarem-nos colocar uma maquina a receber uma replica de todo o tráfego dos servidores desses sites.

Nos meus tempos de IOL a recolha de logs para processar as estatísticas era feita desta forma, ainda que do lado de dentro da firewall da Farm do portal.

Para processar apenas as estatísticas do IOL era preciso uma maquina a fazer a recolha dos logs e outra a processar logs 24/24h. Eu acredito que o Sapo tem cerca de 3 vezes mais tráfego, distribuido por duas salas de servidores distintas, ou pelo menos em duas zonas C, o que significa que provavelmente iriamos precisar de duas maquinas a gerar logs e pelo menos mais duas a processá-los.

Em seguida precisavamos fazer o mesmo com qualquer outro site que quizessemos ter estatísticas precisas, e iriamos incluir pelo menos o Clix, e talvez o aeiou e outros.

E isto em relação ao tráfego nacional. E em relação ao tráfego internacional? Bem, esse teria que ser registado monitorizando todos os links internacionais do nosso querido pais. Ainda são alguns. E precisariamos de maquinas com capacidades práticamente infinitas. Não existe a capacidade em Portugal, e duvido que algum pais do mundo tenha a capacidade para processar todo o tráfego web que ele próprio gera.

Ou então talvez me esteja a escapar alguma coisa e seja possível. O que acham?

Estatísticas Web – Percursos

Published by:

O percurso de um utilizador dentro de um site pode ser uma informação bastante útil. Ele permite saber como esse utilizador vê o site, e como navega nele.

Com esta informação podemos reorganizar o site por forma a levar o utilizador a fazer mais vezes o tipo de acção que pretendemos que ele faça.

Há locais em todos os sites que são completamente ignorados pelos utilizadores, e apesar de haver vários gráficos indicativos de quais as áreas mais “quentes”, mais vistas, esses gráficos não são mais do que indicativos.

Aquelas que são áreas mortas num site podem por vezes mostrar-se as zonas quentes noutro site devido a pequenas alterações de design.

Mas, então, o que são os percursos?

Um percurso é a lista de urls visitados por um utilizador desde que entra num site até que saí dele.

Um percurso comum em muitos blogs hoje é os utilizadores visualizarem a homepage e irem-se embora. Isto acontece especialmente nos casos em que os conteúdos estão completos na listagem.

Se noutros casos este percurso pode dar alguma indicação, isto não acontece neste caso específico.

Se a listagem apenas contiver cabeçalhos dos artigos, e o utilizador apenas visitar a homepage, isso indica-nos que os cabeçalhos listados não conseguiram despertar a atenção do nosso utilizador.

E se os nossos cabeçalhos lhe tiverem despertado a atenção isso também nos é claramente indicado, pois além de visualizarem a homepage irão ver também o url relativo ao(s) artigo(s) que lhes interessaram.

Mas os percursos são especialmente importantes antes e depois de se alterar a estrutura de um site. O estudo da alteração dos percursos aquando da reestruturação de um site permite perceber da eficácia ou não da remodelação.

A capacidade de manter um utilizador no site é também algo que se pode verificar através da análise dos percursos.

Saber que um utilizador que entra no site pela homepage abre vários URLs, sempre a partir da homepage, ou de outras listagens, e em que raramente os utilizadores saltam de um artigo para outros artigos relacionados ao artigo, provavelmente precisaria de uma listagem de artigos relacionados na página do artigo.

Infelizmente, não conheço ferramentas opensource ou disponíveis por um preço aceitável que disponibilizem esta informação.

Ao contrário do que se passa com a maioria das métricas de estatisticas web, devido a ser uma informação complexa de calcular e pouco habitual não existem normalizações em relação a ela.

A quantidade de informação que se extrai desta forma do tráfego de um site depende em grande medida da dimensão do próprio site, e da capacidade de processamento existente.

Se, por um lado, num site de pequena dimensão pode ser interessante conhecer os percursos por unique user. Por outro lado, num grande portal, para manter esta informação utilizável, alguns tops e percursos significativos são o bastante.

Alguns dos dados que se poderiam tentar obter seriam:

  • Percursos mais comuns
  • Percursos mais longos
  • Percursos mais curtos

Esta informação já permite saber com alguma exactidão os caminhos mais usuais num site, e a forma como os utilizadores navegam nele.


Estatísticas Web – webalizer

Published by:

webalizer é provavelmente a ferramenta de estatísticas opensource mais utilizado.

Em primeiro lugar é de utilização bem simples, fácil de configurar e executar automaticamente.

Em segundo lugar é pouco exigente a nível de recursos, ainda que a sua capacidade de escalar seja algo limitada.

Em terceiro lugar suporta três dos formatos de logs mais utilizados, nomeadamente CLF (combined/cummon log format, utilizador pelo Apache, por exemplo), FTP ou xferlog (o formato de logs do wu-ftp e outros servidores de FTP) e logs nativos do Squid.

Estes três servidores representam uma percentagem razoavelmente elevada dos servidores HTTP, FTP e proxies utilizados hoje em dia em ambientes de hosting e servidores de administração privada, pelo que os formatos de logs suportados são os mais usuais.

Ao nível de possibilidades de reporting, por seu lado, o webalizer disponibiliza quase toda a informação que se pode encontrar nos seus concorrentes mais fortes.

webalizer permite proceder a reportes incrementais e mantém um histórico de até 12 meses.

Também cria tops de vários dados, bem como permite criar listagens completas com todos os dados de determinada categoria.

Os tops que o webalizer consegue gerar são:

  • top de sites por pageviews, que é a lista de IPs/hostnames dos utilizadores que mais pageviews geraram no site;
  • top de sites por tráfego, que é a lista dos IPs/hostnames que mais tráfego geraram;
  • top de URLs por pageviews, que é a lista dos URLs mais visto;
  • top de URLs por tráfego, a lista dos URLs que originaram mais tráfego no site;
  • top de referrers, a lista de URL de onde vinham a maioria dos utilizadores;
  • top de User Agents, a lista dos browsers mais utilizados para aceder ao site;
  • top de países, a lista dos países de onde foram originados a maioria dos pageviews do site;
  • top de páginas de entrada, a lista das páginas por onde os utilizadores mais entram no site;
  • top de páginas de saída, a lista das páginas onde os utilizadores mais vezes terminam as suas visitas ao site;
  • top de pesquisas, a lista das pesquisas com que o site foi encontrado mais vezes.

Além dos tops, o webalizer permite ainda criar listagem de todos os dados de uma determinada categoria. Os dados para que o webalizer gera estas listagens são:

  • Sites
  • URLs
  • Referrers
  • User Agents
  • Expressões de Pesquisa
  • Utilizadores

webalizer pode ainda criar ficheiros de dumps dos dados referidos, que podem depois ser utilizados com outros programas.

Apesar de ser uma ferramenta já antiga continua a ser uma das melhores para quem pretende correr a sua própria aplicação de processamento estatístico e disponibiliza toda a informação que hoje se pretende, incluindo a tão falada Long Tail, que é na prática a listagem de todos as Expressões de pesquisa com que o site é encontrado.

A grande desvantagem do webalizer é que apenas corre em plataformas *nix (Unix, Linux, Solaris, etc).

webalizer pode ser encontrado em http://www.mrunix.net/webalizer/.


Estatísticas Web – Novos dados

Published by:

Hoje, especialmente entre os bloggers, procuram-se novas informações ou utilizam-se de forma mais intensa informações que anteriormente eram quase ignoradas.

Nem sempre essas informações são obtidas exclusivamente através de dados de tráfego do site. Algumas dessas informações apenas se conseguem quando se cruza dados de tráfego com dados provenientes de outras fontes.

Entre os novos dados estatísticos que se encontram hoje na moda estão:

Long Tail

A Long Tail é levar um pouco mais longe uma informação que anteriormente já se considerava.

Trata-se das palavras utilizadas nos motores de pesquisa e que resultam em visitas ao site.

Anteriormente desta informação era apresentada apenas um top, entre 10 e 50 palavras (e/ou expressões) mais utilizadas. Hoje os webmasters e bloggers querem saber não apenas quais as mais utilizadas, mas todas as palavras que resultaram em visitas ao site.

EPM (Earnings per Thousand) ou CPM (Comission per Thousand)

O M em EPM ou CPM vem no numero mil em numeração romana (M). CPM pode também ser utilizada para significar Cost Per Thousand, o que faz sentido especialmente do ponto de vista do anúnciante, que é quem tem o dinheiro para anúnciar, e consequentemente a quem normalmente os termos se adequam.

Na prática este indicador permite ter uma ideia da rentabilidade do tráfego de um site.

Das muitas informações que se podem calcular acerca do tráfego se um site este é uma das poucas que apenas está disponível quando o site faz venda directa de espaço publicitário.

No mundo dos blogs, se esta informação fosse disponibilizada permitiria encontrar os nichos de mercado em que mais facilmente se rentabilizaria um blog. Claro que isso poderia acabar por criar um excesso de sites nesse nicho, e consequentemente criar mais espaço para anúncios que os anúncios existentes, baixando com isso o valor do nicho.

Algumas das redes de anúncios, como é o caso do Google Adsense, proíbem mesmo os seus associados de revelar este valor.

Earnings Per User ou Lucro por utilizador

Este indicador, tal como o E/CPM é indicativo da rentabilidade do tráfego, mas considera os utilizadores únicos do site ao invés dos pageviews.


Estatísticas Web – Recolha de Dados

Published by:

Antes de processar estatísticas é necessário recolher os dados relativos ao tráfego do site.

Existem vários tipos de dados e várias formas de obter esses dados.

Recolha de dados por inclusão

Uma das formas de recolher dados de tráfego mais utilizada entre os bloggers é através da inclusão de um código HTML em todas as páginas do site.

O código adicionado pode ser uma imagem ou um ficheiro javascript, ou mesmo um conjunto dos dois.

Nos casos em que é adicionada uma imagem esta é muitas vezes utilizada para mostrar um dos dados calculados a partir do tráfego (pageviews, unique Users, tamanho da long tail, depende de solução para solução, veremos detalhes de algumas delas mais à frente noutros posts), ou pode ser utilizada apenas para divulgar a solução utilizada.

Nos casos em que é utilizado um script javascript este pode ser utilizado para obter algumas informações adicionais acerca das condições de navegação do utilizador, que não são possíveis de recolher de outras formas. Alguns exemplos desta informação é a resolução do monitor ou os plugins que estão activos. Quase tudo o resto pode ser obtido por outras formas.

A grande vantagem das soluções de recolha de dados por inclusão é o software que faz a recolha trata tudo, sem ser necessário ter privilégios especiais no servidor onde o site está a correr. No caso dos blogs que estão nas principais plataformas grátis (blogger.com, blogs.sapo.pt, weblogs.pt, etc) esta é mesmo a única forma de se obter informação acerca do tráfego do site ou do blog.

A inclusão de código javascript em particular é a única forma de saber, por exemplo, que resolução têm os monitores dos utilizadores do site.

As desvantagens destas técnicas estão relacionadas com os utilizadores que não vêm imagens ou não correm javascript e os robots.

Com esta técnica os robots não correm os scripts javascript, pelo que não conseguimos saber quando é que o site é indexado, e mesmo quando se utilizam imagens os robots apenas a pedem um número muito restrito de vezes, e não sempre que pedem uma página onde elas apareçam.

O mesmo se passa com utilizadores que tenham as imagens ou o javascript desactivado ou que não suportem esse tipo de funcionalidades, como nos casos dos browsers de texto (como o links ou o lynx).

Recolha no servidor

A recolha de logs no servidor é uma das melhores soluções, e das mais simples de implementar quando se têm acesso às configurações do servidor.

A grande vantagem da recolha de dados no servidor é que todos os pedidos a que o servidor responde ficam registados nos ficheiros de logs, independentemente de serem feitos pelos robots dos motores de pesquisa, por browsers com suporte de imagens e javascript ou por browsers minimalistas, que apenas mostram texto.

Esta soluções, no entanto, nem sempre está disponível, como no caso em que o site se encontra numa das muitas plataformas de alojamento gratuito (ou nas ferramentas de blog grátis).

Recolha por sniffing

Uma terceira forma de recolher a informação de tráfego é sniffando essa informação da rede.

Esta é uma situação pouco comum, mas é bastante satisfatória quando existe uma grande quantidade de servidores, por vezes a correr em plataformas diferentes, mas em que todo o tráfego passa num ponto comum da rede, pois permite centralizar a recolha de logs, facilitando bastante a gestão dessa recolha, especialmente porque muitas vezes plataformas diferentes (IIS em Windows e Apache, por exemplo) produzem formatos de logs distintos, que são depois difíceis de comparar e analisar conjuntamente.

Conclusão

Estas três são as mais comuns formas de recolha de logs. Cada uma delas têm o seu próprio lugar, e pensar que uma delas é melhor ou pior é esquecer que na realidade cada uma delas se adapta mais facilmente a um determinado ambiente.

A forma como os dados são recolhidos depende do tipo de ambiente em que os sites a analisar se encontram, mas também da ferramenta de análise que se pretende utilizar. Algumas ferramentas incluem já o processo de recolha, normalmente por inclusão, outras dependem de formatos específicos de logs.

Nos próximos artigos ao analisar algumas das soluções de estatísticas mais conhecidas e utilizadas falarei sobre as formas de recolha de dados a utilizar para cada uma delas.


Estatísticas Web

Published by:

Nos últimos tempos, e especialmente entre os bloggers, volta a falar-se de estatísticas.

Mas o tipo de informação que se procura extrair dos dados de tráfego de um site ou blog é cada vez mais extensa e mais diversa.

Até há pouco tempo atrás os webmasters procuravam saber tops diversos, o número de pageviews e unique Users (e nalguns casos de visitas) de um site, e pouco mais.

Hoje procura-se um pouco mais de informação, especialmente no que diz respeito aos referers, os URLs de onde vêm os novos utilizadores.

Mas as ferramentas não evoluíram de forma completa, então são muitas vezes utilizadas diversas aplicações no sentido de obter informação estatística diversa.

Fiquem a saber um pouco mais sobre estatísticas Web ao longo dos seguintes posts:

Estatísticas – Unique Users

Published by:

O protocolo HTTP, e em consequência disso a Web, não pretende implementar sessões e identificação de utilizadores. Nas últimas versões do protocolo foram adicionadas funcionalidade que permitem, em determinadas condições, obter várias informações acerca dos utilizadores, mas ainda assim não é possível identificar um utilizador inequivocamente.

Em consequência disso, quando se contabilizam utilizadores únicos (Unique Users), recorre-se a vários métodos, que a seguir apresento.

IP + User Agent

O método de identificação de Unique Users que menos implicações tem é implementado através da utilização do IP do utilizador e do seu User Agent, e considera-se um utilizador único cada conjunto de IP e User Agent.

Este método tem vários problemas, nomeadamente, se vários utilizadores acedem à internet através da mesma ligação, com computadores configurados de forma idêntica, como muitas vezes acontece em ambientes empresariais, são contados como se de um único utilizador se tratasse.

Outra situação com idêntico problema é quando os pedidos de vários utilizadores passam por um mesmo proxy, sendo que neste caso o IP que chega ao site é o do proxy, e muitas vezes o próprio User Agent é o do proxy, e não o do browser do utilizador. Diversos pedidos para o mesmo URL, mesmo que feitos por utilizadores diferentes podem não chegar ao servidor e ser servidos de cache pelo proxy.

O problema oposto coloca-se quando um mesmo utilizador utiliza browsers diferentes, ou mesmo computadores diferentes. Idêntica situação ocorre quando o utilizador tem uma ligação à internet com IP dinâmico (o que representa a quase totalidade dos acessos à internet).

Nestas situações, o mesmo utilizador é contado múltiplas vezes, uma por cada par IP (publico)+Browser com que aceda ao site.

Cookies

Quando se utilizam cookies para identificar os utilizadores, sempre que um novo utilizador chega ao site è enviado um cookie ao browser, que depois o reenvia de volta em cada pedido que faz. Este cookie, normalmente, tem uma validade relativamente grande, por forma a permitir identificar os utilizadores ao longo de múltiplas sessões.

Mas também este sistema não é perfeito, pois existem várias situações em que um único utilizador é contabilizado várias vezes. Estes essas situações estão aquelas em que o utilizador apaga os cookies, em que utiliza browsers diferentes, ou mesmo computadores distintos, entre outras.

Noutros casos os utilizadores têm os browsers configurados por forma a não aceitarem cookies, e outras têm programas que impedem o envio dos cookies (normalmente firewalls).

Nesta situação contabiliza-se um Unique User por cada cookie diferente que se recebe.

Username

Alguns sites são privados, ou obrigam os seus utilizadores a registarem-se para conseguírem aceder a parte (ou ao todo) dos seus conteúdos.

Estes sites dispõem, provavelmente, da forma mais fiável de contabilizar os Unique Users, através do username utilizado.

Este sistema pode ainda ser distorcido, como nos casos em que o registo é grátis e o mesmo utilizador cria várias contas (porque um qualquer recurso que o site disponibiliza é limitado por utilizador, ou porque se esqueceu do username ou password originais, entre outras razões), ou nos casos em que o acesso é pago, e vários utilizadores partilham um acesso, reduzindo assim os seus (deles) custos.

Apesar disso, este é talvez o sistema mais fiável de contabilizar Unique Users, porque a maioria dos utilizadores vai autenticar-se com o mesmo username e password sempre que visitar o site, independentemente da forma como essa autenticação for feita.

Mas, nesse caso, porque não se utiliza sempre este sistema? Porque ele obriga a que os utilizadores estejam registados e que se autentiquem sempre que acedem ao site. É uma prática cada vez mais comum entre os grandes fornecedores de informação, como jornais, revistas ou sites noticiosos de grande dimensão, como o New York Times permitirem aceder aos seus arquivos apenas a utilizadores registados.

No entanto, na maioria das situações, os utilizadores não consideram aceitável registarem-se, especialmente se o site a que estão a aceder não lhes é ainda conhecido. Por isso outro métodos, são muito utilizadores, mesmo em sites onde existe a possibilidade de os utilizadores se registarem.

Conclusão

Estão são as três formas mais comuns de contabilizar utilizadores únicos. O terceiro métodos, do username de acesso, é pouco utilizado, especialmente porque os utilizadores gostam de acreditar que estão a aceder à internet de forma anónima, ainda que em muitos casos esse anonimato seja muito pouco mais que aparente (Como no caso dos dados da AOL, que referi recentemente).

Mas todos estes métodos de contabilizar Unique Users são falíveis, pelo que o valor deUnique Users deve sempre ser considerado como meramente indicativo.

A aplicação que se usa para calcular as estatísticas também tem influência nos resultados, e pode mesmo acrescer um novo conjunto de problemas ao problema apresentado, mas esses novos problemas não dizem já respeito apenas à contabilização dos Unique Users, mas a todo o processo estatístico, pelo que falaremos dele num post mais à frente.

Entretanto, têm estatísticas dos vossos blogs e sites? Que aplicações utilizam para as calcular?


Estatísticas Web – Conceitos

Published by:

Este é o primeiro de uma série de artigos sobre estatísticas Web. Uma breve apresentação da série será publicada nos próximos dias, sendo que, por hoje, vos deixo apenas uma apresentação de alguns dos conceitos e medidas mais utilizadas.

  • PageView: Um pageview é o equivalente a uma página visualizada pelo utilizador. Este conceito tem algumas variantes, como sejam automated pageview (quando a página faz refresh automaticamente) e repeated pageview (quando o utilizador faz refresh no browser manualmente, ou quando volta à página por qualquer razão).
  • Hit: Um hit é um request feito pelo browser. Imagens, ficheiros javascript, CSS, flash, e mesmo frames HTML, todos são considerados hits, mas apenas o pedido inicial é considerado para contagem de pageviews.
  • Unique User: Idealmente um Unique User corresponde a um utilizador único, a uma pessoa. Mas o mundo real está longe de ser um mundo ideal, e por isso este valor raramente coincide com o número de utilizadores únicos reais de um site. Existem várias formas de contabilizar este indicador, cada uma delas com as suas vantagens e desvantagens, pelo que voltaremos a este tópico nos próximos dias.
  • Visit: Uma visita é um conjunto de pageviews efectuados por um unique user, separados entre si por intervalos de tempo inferiores a um valor pré-definido (normalmente 30 minutos).
  • Referer ou Referrer: o referer(em inglês o correcto é referrer, mas referer é bastante mais utilizado) de uma página é o URL onde o utilizador se encontrava antes de vir para o nosso site. Os referers, normalmente, são listagens de pesquisas ou páginas com links para o nosso site. Por norma os referers internos (no próprio site não são considerados, mas podem conter informação muito interessante. Mais uma vez voltaremos aqui mais tarde).
  • Cookie: um cookie é um pequeno pacote de informação, que é enviado para o servidor sempre que são feitos pedidos. Pode ser utilizado para diversas finalidades, sendo a mais comum o controlo de sessões.
  • User Agent: cada browser, bem como a maioria dos robots e crawlers, tem uma assinatura própria, que enviam ao servidor sempre que trazem um pedido. A expressãoUser Agent é utilizada para significar o browser utilizado e a assinatura, sendo que, normalmente, a assinatura é o nome do browser.
  • RobotCrawler: Chama-se Robot a qualquer programa que faça de forma automática, independentemente da finalidade, pedidos de URL’s. Os robots mais comuns são os que indexam os sites para os motores de pesquisa. A este grupo de robots chama-se Crawler. Outro tipos de robots são, por exemplo, programas que copiam sites completos, independentemente da finalidade dessa cópia (com sorte apenas para leitura off-line, sem acesso à internet), programas de monitorização, entre muitos outros. Na maioria dos casos estes programas são identificados pelo User Agent (neste caso a sua assinatura). A razão porque estes User Agents são referidos é porque, uma vez que eles não representam utilizadores reais, não são considerados quando se contabilizamPageViews ou Unique Users.