Come implementare un contatore di pagine Web affidabile?

Question

Qual è un buon modo per implementare un contatore di pagine Web?

In superficie questo è un problema semplice, ma diventa problematico quando si tratta di crawler e robot dei motori di ricerca, clic multipli dello stesso utente, aggiornamento dei clic.

In particolare, qual è un buon modo per garantire che i collegamenti non vengano semplicemente "cliccati" dall'utente facendo clic ripetutamente? Indirizzo IP? Biscotti? Entrambi presentano alcuni inconvenienti (gli indirizzi IP non sono necessariamente unici, i cookie possono essere disattivati).

Qual è anche il modo migliore per archiviare i dati? Incrementa un contatore singolarmente o memorizza ogni clic come record in una tabella di registro, quindi riepiloga di tanto in tanto.

Qualsiasi esperienza dal vivo sarebbe utile,

+++ Rick ---

Answer 1

Quindi ho giocato un po 'con questo sulla base dei commenti qui. Quello che mi è venuto in mente è contare un contatore in un semplice campo. Nella mia app ho entità snippet di codice con una proprietà Views.

Quando viene visualizzato un frammento, un metodo filtra (lista bianca) proprio quelli che dovrebbero essere i browser:

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);
}

La procedura memorizzata utilizza quindi una tabella separata per contenere temporaneamente le viste più recenti che memorizzano l'ID frammento, la data immessa e l'indirizzo IP. Ogni vista viene registrata e quando arriva una nuova vista viene controllata per vedere se lo stesso indirizzo IP ha avuto accesso a questo snippet negli ultimi 2 minuti. in tal caso non viene registrato nulla.

Se si tratta di una nuova vista, la vista viene registrata (di nuovo SnippetId, IP, Entered) e il campo Visualizzazioni effettivo viene aggiornato nella tabella Snippet.

Se non si tratta di una nuova vista, la tabella viene ripulita con le viste registrate che sono più vecchie di 4 minuti. Ciò dovrebbe comportare un numero minimo di voci nella tabella Visualizza registro in qualsiasi momento.

Ecco il proc memorizzato:

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

Questo sembra funzionare abbastanza bene. Come altri hanno già detto, questo non è perfetto ma sembra che sia abbastanza buono nei test iniziali.

Answer 2

Utilizza gli indirizzi IP insieme alle sessioni. Conta ogni nuova sessione per un indirizzo IP come un colpo sul tuo contatore. È possibile archiviare questi dati in un database di registro se si ritiene che sarà necessario esaminarli. Questo può essere utile per calcolare quando il tuo sito riceve più traffico, quanto traffico al giorno, per IP, ecc.

Answer 3

Se si utilizza PHP, è possibile utilizzare le sessioni per tenere traccia delle attività di determinati utenti. Insieme a un database, è possibile tenere traccia dell'attività da determinati indirizzi IP, che si può presumere siano lo stesso utente.

Usa i timestamp per limitare gli hit (supponi non più di 1 hit per 5 secondi, per esempio) e per sapere quando nuove "visite" " al sito si verifica (se l'ultimo hit è stato più di 10 minuti fa, per esempio).

Puoi trovare proprietà $ _SERVER [] che ti aiutano a rilevare i robot o le tendenze dei visitatori (come l'utilizzo del browser).

modifica: Ho seguito hit e amp; visite precedenti, conteggiando una visualizzazione di pagina come hit e +1 per le visite quando viene creata una nuova sessione. Era abbastanza affidabile (più che abbastanza affidabile per gli scopi per cui l'ho usato. I browser che non supportano i cookie (e quindi non supportano le sessioni) e gli utenti che disabilitano le sessioni sono abbastanza rari al giorno d'oggi, quindi non mi preoccuperei a meno che non vi sia motivo di essere eccessivamente accurati.

Answer 4

Se fossi in te, rinuncerei al mio contatore per essere preciso in primo luogo. Ogni soluzione (ad es. Cookie, indirizzi IP, ecc.), Come hai detto, tende ad essere inaffidabile. Quindi, penso che la tua scommessa migliore sia usare la ridondanza nel tuo sistema: usa i cookie, " Flash-cookies " (oggetti condivisi), indirizzi IP (forse in combinazione con user-agent) e ID utente per le persone che hanno effettuato l'accesso.

È possibile implementare una sorta di schema in cui a ogni client sconosciuto viene assegnato un ID univoco, che viene memorizzato (si spera) sulla macchina del client e ritrasmesso ad ogni richiesta. Quindi potresti associare un indirizzo IP, un agente utente e / o un ID utente (oltre a qualsiasi altra cosa ti venga in mente) a ogni ID univoco e viceversa. Il timestamp e l'ID univoco di ogni clic potrebbero essere registrati in una tabella del database da qualche parte e ogni clic (almeno ogni clic sul tuo sito Web) potrebbe essere lasciato passare o negato a seconda della recente data dell'ultimo clic per lo stesso ID univoco. Questo è probabilmente abbastanza affidabile per i click-burst a breve termine, e a lungo termine non importerebbe comunque molto (per il problema del click-up, non del contatore delle pagine).

I robot amici dovrebbero avere il proprio agente utente impostato in modo appropriato e può essere verificato in un elenco di agenti utente robot noti (ne ho trovato uno qui dopo una semplice ricerca su Google) per essere correttamente identificati e trattati separatamente da persone reali.