2009-07-29 11 views
7

¿Cuál es una buena manera de implementar un contador de página web?¿Cómo implementar un contador de página web confiable?

En la superficie, este es un problema simple, pero se vuelve problemático cuando se trata de robots y rastreadores de motores de búsqueda, clics múltiples del mismo usuario y clics de actualización.

Específicamente, ¿cuál es una buena forma de garantizar que los enlaces no solo sean 'cliqueados' por el usuario al hacer clic repetidamente? ¿Dirección IP? ¿Galletas? Ambos tienen algunos inconvenientes (las direcciones IP no son necesariamente únicas, las cookies pueden desactivarse).

¿Cuál es también la mejor manera de almacenar los datos? Incremente un contador individualmente o almacene cada clic como un registro en una tabla de registro, luego resuma ocasionalmente.

Cualquier experiencia en vivo sería útil,

+++ Rick ---

+1

Usted está haciendo una pregunta muy difícil. Solo piense en cómo aborda Google el problema del fraude de clic y obtendrá una idea de cuán grande puede ser la respuesta de su pregunta. – backslash17

+0

Estoy de acuerdo ... no es un problema fácil ... aunque siempre me he preguntado por qué los servidores web no ofrecen buenas soluciones de análisis. Digo bofetada Google Analytics y lo llamo hecho ... a menos que intenten reinventar la rueda francamente reconocida. – madcolor

+0

Entendido, pero es por eso que estoy preguntando aquí: -}. Realmente no busco análisis aquí, pero un contador similar al aquí en SO para mostrar el número de visitas al menos de manera semi-confiable. –

Respuesta

2

Así que jugué un poco con esto basado en los comentarios aquí. Lo que se me ocurre es contar un contador en un campo simple. En mi aplicación, tengo entidades de fragmentos de código con una propiedad de Vistas.

Cuando un fragmento se considera un método filtra el (lista blanca) justo lo que posiblemente serán navegadores:

public bool LogSnippetView(string snippetId, string ipAddress, string userAgent) 
{ 
    if (string.IsNullOrEmpty(userAgent)) 
     return false; 

    userAgent = userAgent.ToLower(); 

    if (!(userAgent.Contains("mozilla") || !userAgent.StartsWith("safari") || 
     !userAgent.StartsWith("blackberry") || !userAgent.StartsWith("t-mobile") || 
     !userAgent.StartsWith("htc") || !userAgent.StartsWith("opera"))) 
     return false; 

    this.Context.LogSnippetClick(snippetId, IpAddress); 
} 

El procedimiento almacenado a continuación, utiliza una tabla separada para mantener temporalmente las últimas vistas que almacenan la ID de fragmento , fecha introducida y dirección IP. Cada vista se registra y cuando aparece una nueva vista, se verifica para ver si la misma dirección IP ha accedido a este fragmento en los últimos 2 minutos. si es así, no se registra nada.

Si se trata de una vista nueva, la vista se registra (nuevamente SnippetId, IP, ingresada) y el campo Vistas reales se actualiza en la tabla Fragmentos.

Si no es una vista nueva, la tabla se limpia con cualquier vista registrada que tenga más de 4 minutos. Esto debería dar como resultado una cantidad mínima de entradas en la tabla de registro de vista en cualquier momento.

Aquí está el procedimiento almacenado:

ALTER PROCEDURE [dbo].[LogSnippetClick] 
    -- Add the parameters for the stored procedure here 
    @SnippetId AS VARCHAR(MAX), 
    @IpAddress AS VARCHAR(MAX)   
    AS 
    BEGIN 

    SET NOCOUNT ON; 

    -- check if don't allow updating if this ip address has already 
    -- clicked on this snippet in the last 2 minutes 
    select Id from SnippetClicks 
     WHERE snippetId = @SnippetId AND ipaddress = @IpAddress AND 
       DATEDIFF(minute, Entered, GETDATE()) < 2  

    IF @@ROWCOUNT = 0 
    BEGIN    
     INSERT INTO SnippetClicks 
      (SnippetId,IpAddress,Entered) VALUES 
      (@SnippetId,@IpAddress,GETDATE())   
     UPDATE CodeSnippets SET VIEWS = VIEWS + 1 
      WHERE id = @SnippetId 
    END 
    ELSE 
    BEGIN 
     -- clean up 
     DELETE FROM SnippetClicks WHERE DATEDIFF(minute,Entered,GETDATE()) > 4 
    END 
END 

Esto parece funcionar bastante bien. Como otros mencionaron, esto no es perfecto, pero parece que es lo suficientemente bueno en las pruebas iniciales.

0

Si se llega a utilizar PHP, puede utilizar sesiones para rastrear la actividad de los usuarios particulares. Junto con una base de datos, puede rastrear la actividad desde direcciones IP particulares, que puede asumir que son el mismo usuario.

Use las marcas de tiempo para limitar los aciertos (suponga no más de 1 acierto por 5 segundos, por ejemplo) y para indicar cuándo ocurren nuevas "visitas" (si el último acierto fue hace más de 10 minutos, por ejemplo) .

Puede encontrar $ _SERVER [] propiedades que lo ayuden a detectar bots o tendencias de visitantes (como el uso del navegador).

editar: He seguido éxitos & visitas antes, contando una vista de página como un golpe, y +1 a visitas cuando se crea una nueva sesión. Era bastante confiable (más que suficiente para los fines que yo usaba). Los navegadores que no admiten cookies (y por lo tanto, no admiten sesiones) y los usuarios que deshabilitan las sesiones son bastante poco comunes hoy en día, así que no me preocupe al respecto a menos que exista una razón para ser excesivamente preciso.

+0

Las direcciones IP no son confiables a largo plazo – Cameron

+0

Usando ASP.NET (MVC) y aunque Session es una opción, no va a ayudar con el acceso sin cookies de los robots. Además, la sesión tiene un poco de sobrecarga que esta aplicación no necesitaría. –

4

Use las direcciones IP junto con las sesiones. Cuente cada nueva sesión para una dirección IP como un golpe en su contador. Puede almacenar esta información en una base de datos de registro si cree tendrá que revisarlo. Esto puede ser útil para calcular cuándo su sitio obtiene la mayor cantidad de tráfico, cuánto tráfico por día, por IP, etc.

0

Si yo fuera usted, me daría por vencido mi contador es preciso en primer lugar. Todas las soluciones (por ejemplo, cookies, direcciones IP, etc.), como usted dijo, tiende a ser poco confiable. Por lo tanto, creo que su mejor opción es utilizar la redundancia en su sistema: use cookies, "Flash-cookies" (objetos compartidos), direcciones IP (tal vez en conjunto con agentes de usuario), e ID de usuario para las personas que están conectadas.

Podría implementar algún tipo de esquema en el que a cualquier cliente desconocido se le otorgue una ID única, que se almacena (con suerte) en la máquina del cliente y se retransmite con cada solicitud. Luego, podría vincular una dirección IP, agente de usuario y/o ID de usuario (más cualquier otra cosa que se le ocurra) con cada ID única y viceversa. La marca de tiempo y la ID única de cada clic se pueden registrar en una tabla de base de datos en algún lugar, y cada clic (al menos, cada clic en su sitio web) puede permitirse o denegarse dependiendo de qué tan reciente fue el último clic para la misma ID única. Esto es probablemente lo suficientemente confiable para ráfagas de clics a corto plazo, y a largo plazo no importaría mucho de todos modos (para el problema de clics, no para el contador de páginas).

Los robots amigables deben tener su agente de usuario configurado apropiadamente y se pueden comparar con una lista de agentes de usuario robóticos conocidos (encontré uno here después de una simple búsqueda en Google) para ser identificado y tratado adecuadamente por personas reales.

+0

Gracias Cameron. Aquí es donde estoy en este punto. El punto de la pregunta ha sido ver si hay mejores enfoques disponibles. –

Cuestiones relacionadas