| << tópico anterior | próximo tópico>> |
Estatísticas do sitepor André Kischinevsky (revista Internet Business de 01/2000)
Quem nunca leu uma notícia exaltando os milhões de hits de um site qualquer? "Em agosto, o site Xyz teve quinhentos mil hits", "No último semestre, alcançamos a marca de um milhão de hits...". Com frases assim, os "marketeiros" divulgam aos quatro ventos o sucesso de seus empreendimentos.
Usuários incautos logo associam o número de hits ao número de visitantes do site. Imaginam que um site com um milhão de hits foi visitado por um milhão de usuários.
O número de hits de um site é uma medida técnica. Não é útil para uma análise de mercado, e deve ser usada apenas pelos administradores do site. Os hits indicam o número de "elementos" acessados (imagens, páginas em HTML, programas Java etc.). Como as páginas são freqüentemente compostas por dezenas de imagens, a cada passo da navegação de um único usuário, são atribuídas dezenas de hits. Veja um exemplo: Imagine que um usuário acessa o site Xpto e navega por oito páginas. Imagine também que cada página possui 14 imagens. Neste caso, somente com uma visita o site vai computar mais de 100 hits!
Dessa forma, com apenas 100 usuários no mês o site Xpto pode divulgar a seguinte nota: "No mês passado, o Xpto atingiu a marca dos 10 mil hits!" - Em palavras mais honestas, foi deixado às moscas na maior parte do tempo, com apenas três navegantes por dia.
Outra forma de conseguir um enorme número de hits são as salas de bate-papo. Um usuário que fique batendo papo por cerca de uma hora vai proporcionar centenas de hits para o site, pois para cada frase digitada alguns hits são computados.
Por estas razões, fica claro que o número de hits não é uma medida confiável. Como é possível, então, medir a visitação de um site?
Alguns utilizam o conceito de page views. O número de page views de um site é o número de vezes que as páginas foram visitadas. No exemplo acima, o número de page view é de oito, pois o usuário navegou por oito páginas. Como algumas páginas são compostas por "sub-páginas" (tecnicamente, isto se chama "frames"), o número de page views de um site não é tão simples de ser analizado.
Esta contagem também pode ser influenciada por serviços de bate-papo, janelas que se abrem automaticamente com propaganda e outros fatores. Por isso, não é muito confiável. Para minimizar os erros, pode-se analisar o tráfego de usuários no site através do número de page views exclusivamente da página principal. No exemplo acima, você teria marcado apenas um page view. Entretanto, neste caso, temos o problema oposto: se você chegasse no site por qualquer outra página, que não a principal (home-page), não teria sido "contado" como visitante.
O parâmetro mais confiável na análise de qualquer site é o número de visitas (às vezes chamadas de sessões), que representa o número de usuários que estiveram no site, independente de quantas páginas visitaram. Se um site divulga que recebeu mil visitas (ou sessões) num mês, você deve entender que por mil vezes o site recebeu um usuário em suas páginas.
Vejamos um exemplo: Você visita diversas páginas do site da Xpto. Independente do número de páginas visitadas, a Xpto contará apenas uma visita. Entretanto, se você deixa de acessar o site por algum tempo e depois volta, conta-se outra visita. O intervalo mais aceito para computar-se uma nova visita do mesmo usuário é de 30 minutos.
Não se deixe enganar por números estratoféricos de hits. E lembre-se também de perguntar como a visitação foi auditada antes de acreditar realmente nos números.
Andre Kischinevsky é diretor do Instituto de Formação Internet - Infnet
Para entrar na página de estatísticas de seu site, vá para o endereço http://www.seu.domínio/stats/. Serão pedidos seu nome de usuário e senha, os mesmos que você usa para acessar o Painel de Controle ou fazer FTP.
A página que entrará terá links para a versão com frames e sem frames das estatísticas. a versão com frames é mais prática, mas exige que seu browser rode JavaScript (a maioria dos browsers atuais já fazem isso).
Um servidor web, na linguagem da Internet, é um programa que está sendo executado em uma máquina ligada à Rede, esperando por conexões do mundo exterior para apresentar certos documentos solicitados por um browser.
Para se comunicar, o servidor e o browser usam um método de comunicação assíncrono conhecido como HTTP (Protocolo de Transferência de Hipertextos). Funciona da seguinte forma:
1. o usuário abre o browser e digita uma URL (Localizador Uniforme de
Recursos -- é o endereço de uma página HTML ou outro arquivo);
2. o browser conecta-se ao host (nome dado ao computador de uma rede que fornece
serviços e arquivos a outros computadores) e solicita um documento específico.
3. o servidor de internet processa o pedido e envia uma resposta:
a. se o documento existir, o servidor web o entrega;
b. se o documento não existir ou o acesso não é autorizado, o servidor web envia uma mensagem de erro.
O documento entregue como resposta pode conter elementos. Esses elementos são, simplesmente, URLs apontando para outros recursos, seja um outro documento, uma imagem, uma applet Java, um "fluxo" (stream) de audio ou vídeo, ou qualquer outro arquivo endereçável por uma URL.
![]() |
O browser então solicita ao servidor web todos os objetos que estejam presentes na página, de acordo com os passos 2 e 3 acima, antes que possa concluir a exibição da página. |
| Como as solicitações do browser são geralmente atendidas por processos diferentes no servidor ou subprocessos (threads) de processos, não há nenhuma relação entre as entradas do relatório de acessos (logfile) do servidor web e a solicitação de um documento e de seus objetos. | ![]() |
Por exemplo, a ordem em que o servidor registra a transmissão de um documento e dos objetos que nele estão contidos não é previsível e depende do tipo de documento e objetos, velocidade do servidor, da carga do sistema e da rede e muitos outros parâmetros.
Toda e qualquer solicitação feita para o servidor -- quer esteja indicando sucesso, erro ou mesmo um timeout (sem resposta em tempo hábil) -- é registrada no relatório de acessos (logfile) do servidor. Cada entrada no relatório é chamada de hit. Em outras palavras, o número total de hits deve ser igual ao número de linhas do arquivo menos o número de linhas corrompidas (pela metade) ou vazias. Uma entrada de logfile no formato Common Logfile Format (padrão) tem geralmente a seguinte aparência:
hostname - - [01/Feb/1998:10:10:00 -0300] "GET /index.html HTTP/1.0" 200 4839
O campo hostname contém o nome qualificado completo de domínio (FQDN) do site que está acessando o servidor (veja "Casos especiais" abaixo). Os dois próximos campos geralmente contêm um sinal de menos ('-') para indicar que estão vazios. A data do acesso fica dentro de colchetes. O próximo campo contém a solicitação, em forma de comando HTTP. Ele contém o método de solicitação (GET, por exemplo), o nome do documento solicitado e a especificação do protocolo (HTTP/1.0). O campo seguinte indica o código de resposta do servidor (200 significa "tudo ok", enquanto que 404 quer dizer "Documento não encontrado", por exemplo). O último campo contém o tamanho em bytes do arquivo (alguns servidores registram o número de bytes que foram transmitidos, enquanto outros registram o tamanho do arquivo solicitado. A diferença está na possibilidade de o usuário interromper a transmissão do arquivo antes que tenha sido completamente transferido).
Existem mais outros dois formatos de logfiles, o Combined e o Extended Logfile Format. Eles acrescentam os campos user-agent (identificação do browser) e a referrer URL (URL que referenciou -- a página que contém o link para o documento solicitado, no caso de ter sido acessado ao se seguir um link, ao invés de o usuário ter digitado a URL diretamente no browser) à entrada do logfile. Nesses dois formatos de logfile, os dois campos extras são adicionados geralmente das duas formas seguintes:
<campos normais>
Mozilla/2.0 (X11; IRIX 6.3; IP22) http://foo/bar.html
<campos normais> "http://foo/bar.html" "Mozilla/2.0
(X11; IRIX 6.3; IP22)"
Observe que da segunda forma, o user-agent e a referrer URL ficam entre de aspas, o que os torna ambíguas em certos casos como referrer URLs mal-formatadas, que contenham aspas. Por isso, o primeiro formato deve ser o preferido sempre que possível.
As entradas mostradas acima são as únicas informações que o servidor grava no logfile. Pode haver muito mais informações sendo transferidas do browser para o servidor, e, embora essa informação adicional esteja disponível a scripts CGI que rodem em seu servidor, ela não é gravada no relatório de acessos. Por isso, o http-analyze só pode mostrá-lo um resumo da informação disponível no logfile nada além ou aquém disso.
Cache do browser:
Logo quando uma página é armazenada no cache
(local de armazenamento que onde o browser guarda arquivos recentemente usados, como
páginas HTML e arquivos gráficos, na suposição que precisará deles depois) de disco
do browser, o browser pode enviar solicitações condicionais por documentos ou objetos da
página. Nessa solicitação condicional, o browser pede ao servidor web para enviar o
documento/objeto somente se tiver sido modificado desde a última vez em que foi carregado
(se a página ainda estiver no cache do browser). Desta forma, o tráfego na rede sofre
uma sensível redução, pois os documentos serão transferidos somente se eles tiverem
sido modificados recentemente. Se uma solicitação condicional chega, o servidor irá
responder com um código de status 304 (sem modificações) para indicar que o documento
não foi modificado ou com um código 200 (OK) se o documento foi modificado no período.
Como o browser pode estar configurado (e geralmente está, por padrão) para somente
enviar solicitações condicionais uma vez por sessão e depois sempre usar os arquivos no
cache, você pode nem chegar a ver uma resposta código 304 se esse usuário visitar seu
site novamente na mesma sessão de uso do browser. As solicitações condicionais são
enviadas somente se o usuário fechar o browser e voltar a usá-lo novamente mais tarde.
Cache num servidor proxy:
Organizações com grande número de usuários - tais como companhias, universidades
ou provedores de acesso - geralmente usam servidores proxy por duas razões principais:
1. Geralmente tais organizações têm um firewall
(sistema de monitoração de tráfego que verifica tudo que sai e entra do provedor e
implementa outros protocolos de segurança) para proteger suas redes internas contra
intrusos. Isso significa que a rede está logicamente separada do resto da internet e eles
precisam usar um servidor proxy, que será capaz de se comunicar dentro e fora de sua rede
local.
2. Para reduzir a carga na rede, um servidor proxy age como uma
máquina de cópias locais. Quando uma página é carregada por um browser através de um
servidor proxy, ele salva uma cópia desta página em seu cache de disco da mesma
forma como o browser faz, mencionada anteriormente. Assim, documentos solicitados de forma
freqüente por usuários em uma mesma rede local só precisam ser transferidos para o
proxy uma vez, e que responde a futuras solicitações para uma mesma página usando seu
cache local ao invés de se conectar ao servidor web de origem daquele documento.
Estas duas formas de caching tornam tecnicamente impossível a contagem de visitas ou o a visualização do caminho percorrido de seus visitantes através de seu website. Tudo o que será visualizado no arquivo diário (logfile) de seu servidor será somente alguns hits iniciais do servidor proxy ou browser e provavelmente algumas respostas de código 304 resultantes de solicitações condicionais enviados pelo proxy ou browser, dependendo das configurações de ambos.
O http-analyze é capaz de fornecer as seguintes estatísticas sobre os acessos a seu site:
• Year (ano): estatísticas dos acessos para os últimos 12 meses (relativos ao campo mês/ano).
• By Month (por mês): estatísticas de acesso para o mês especificado no campo mês/ano.
• Wday/Hour (dia da semana/hora): acessos por dia da semana e hora do dia.
• Top URLs (URLs mais acessadas): arquivos/páginas de seu site que foram mais acessados.
• Top Domains (domínios que mais acessaram): principais domínios dos quais vieram seus visitantes, que têm link para seu site.
• Top Browsers (browsers principais): principais browsers usados para visitar seu site.
• Top Referrers (principais endereços de origem): páginas em outros domínios (sites) de onde vieram seus visitantes (ou seja, que têm link para seu site).
• Country (países): países de onde seus visitantes acessaram.
• URLs: número de acessos por aquivo/página de seu site.
• Not Found (não encontrados): arquivos/páginas solicitados em seu site que não foram encontrados.
• Domains (domínios que acessaram): domínios dos quais vieram seus visitantes, que têm link para seu site.
• Rev. Domains: igual a "Domains", só que os domínios estão ao contrário (ex.: "www.site-de-busca.com.br" vira "br.com.site-de-busca.www").
• Browser: browsers usados para visitar seu site.
• Referrer (endereços de origem): todas as páginas em outros domínios (sites) de onde vieram seus visitantes.
A tabela seguinte resume o significado de alguns termos do relatório de estatística:
| Termo | Cor | Significado |
|---|---|---|
| Hits | Um hit é qualquer resposta do servidor a uma solicitação enviada por um browser, mesmo que não seja algum documento ou arquivo texto. Se, por exemplo, uma página HTML tem duas imagens incorporadas, o servidor gera três hits se essa página for solicitada: um para a própria página e um para cada uma das imagens. | |
| Arquivos | Se o usuário pede um arquivo e o servidor realmente retorna esse arquivo como resposta, isso é contado como código 200 (OK). Cada resposta desse tipo é contada como um arquivo, de qualquer tipo, não apenas documentos. | |
| Código 304 | Uma resposta de código 304 (Não Modificado) é gerado pelo servidor se um documento não foi modificado desde a última vez que foi solicitado pelo usuário e portanto, não há a necessidade de enviar os arquivos para este documento. Isto acontece se o browser (ou cache de um proxy entre o browser e seu servidor web) ainda possui uma cópia atualizada da página armazenada (cache) e portanto pode mostrar a página sem requerer o conteúdo atual. Esta técnica é usada para reduzir o tráfego na rede, mas também causa uma imprecisão nos relatórios de estatísticas no que se refere ao número de visitantes, por que o browser ou proxy geralmente envia somente uma solicitação condicional por sessão, somente se ainda tiver uma cópia atualizada do arquivo. Entretanto, a relação entre arquivos e 304s reflete a eficiência total dos mecanismos de armazenamento (cache), pelo menos para aqueles hits que conseguiram chegar até o servidor. | |
| Pageviews | Os pageviews são todos os arquivos que podem ter tanto um sufixo de formato texto (.html, .txt) ou são arquivos de índice de diretórios (ex., index.html, default.htm, etc.). Esse número permite saber o número real de documentos transmitidos pelo seu servidor. Se for definido de maneira correta, o http-analyze avalia os arquivos texto (documentos) como pageviews. Esses pageviews não incluem imagens, scripts CGI, applets Java ou outros objetos HTML, exceto todos os arquivos que terminam com um dos sufixos pré-definidos como sufixos de pageviews, tais como .html ou .txt. | |
| Outras respostas |
Existem muitas outras respostas além dos códigos 200 (OK) e 304 (não modificado), especialmente as especificadas na versão 1.1 do protocolo HTTP. Por exemplo, o servidor pode gerar um código 301 (redirecionado) caso uma página tenha sido mudada de localização, uma resposta de código 401 (acesso não autorizado) caso o acesso ao documento tenha sido negado ou uma resposta de Código 404 (não encontrado) se a página solicitada não existir no servidor. Veja as especificações do protocolo HTML para mais informações sobre todas as respostas válidas de um servidor web. Nota: o http-analyze reconhece as respostas do protocolo HTTP 1.1 conforme o RFC2068. | |
| KBytes transferidos | Esta é a quantidade de dados enviados durante todo o período do resumo relatado. Note que alguns servidores anotam o tamanho dos documentos solicitados ao invés do número real de dados transferidos. Enquanto que na maioria dos casos não há diferença, se um usuário interrompe a transmissão ao pressionar o botão "Stop" de seu browser antes da página ter sido totalmente carregada, alguns servidores (por exemplo, todos os servidores web da Netscape) não irão anotar a quantidade de dados transferidos, mas sim, a quantidade de dados que teria sido transferida se o usuário tivesse carregado a página completamente. | |
| KBytes solicitados | Esta é a quantidade de dados solicitados durante todo o período de resumo relatado. O http-analyze computa este número somando os valores de Kbytes transferidos e Kbytes armazenados no cache (veja abaixo). | |
| KBytes armazenados no cache | A quantidade de dados guardados pelos vários mecanismos de cache em servidores proxy ou nos browsers. Esse valor é computado somando-se os tamanhos dos arquivos cujas solicitações tiveram respostas do servidor de código 304 (não modificado). Nota: como o http-analyze só pode determinar o tamanho de um arquivo se ele for solicitado pelo menos uma vez durante o período do resumo, os valores para Kbytes armazenados no cache e Kbytes solicitados são somente aproximações dos valores reais. | |
| URLs diferentes (Unique URL) |
URLs únicas ou diferentes é o número de todas as URLs distintas e válidas solicitadas em um determinado período. Isso mostra o número de todos os arquivos que foram solicitadas pelo menos uma vez durante o período correspondente. | |
| Hosts diferentes (Unique sites) |
Esse é o número total de computadores diferentes que acessaram o servidor durante uma janela de tempo de um mês. Isso significa que se um computador acessa o seu servidor com muita freqüência, ele só será contado uma vez durante o mês inteiro. Somente o número de hosts distintos no mês será indicada no relatório de estatística. | |
| Visitas (Sessions) | Como a estatística de Hosts diferentes, esse é o número de computadores distintos que acessaram sua conta o durante a janela de tempo de 24 horas. |
| << tópico anterior | próximo tópico>> | |