2009-07-29 10 views
7

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

Sulla superficie questo è un problema semplice, ma diventa problematico quando si tratta di crawler e robot dei motori di ricerca, più clic da parte dello stesso utente, aggiornamento dei clic.

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

Anche qual è il modo migliore per archiviare i dati? Incrementare individualmente un contatore o memorizzare ciascun clic come record in una tabella di registro, quindi riepilogare occasionalmente.

Qualsiasi esperienza dal vivo sarebbe utile,

+++ Rick ---

+1

Stai facendo una domanda molto difficile. Pensa solo a come Google gestisce il problema con mfraud di clic e avrai un'idea di quanto può essere grande la tua domanda. – backslash17

+0

Sono d'accordo .. non è un problema facile .. anche se mi sono sempre chiesto perché i Web Server non offrono buone soluzioni di analisi. Dico schiaffo su Google Analytics e lo chiamo fatto ... a meno che tu non stia cercando di reinventare la ruota dichiaratamente rotta. – madcolor

+0

Capito, ma è per questo che sto chiedendo qui: -}. Non sono molto interessato all'analisi, ma un contatore simile a qui su SO per mostrare il numero di visualizzazioni almeno in modo semi-affidabile. –

risposta

2

Così mi sono divertito un po 'in base ai commenti qui. Quello che mi è venuto in mente è contare un contatore in un campo semplice. Nella mia app dispongo di entità frammento di codice con una proprietà Views.

Quando un frammento è visto un metodo di filtri out (lista bianca) proprio quello che dovrebbe essere auspicabilmente 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 stored procedure utilizza quindi una tabella separata per contenere temporaneamente gli ultimi punti di vista che memorizzano il frammento di Id , data di inserimento e 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. se è così non viene registrato nulla

Se è una nuova vista, la vista viene registrata (ancora SnippetId, IP, Immessa) e il campo Visualizzazioni effettivo viene aggiornato nella tabella Snippet.

Se non si tratta di una nuova vista, la tabella viene ripulita con qualsiasi vista registrata che abbia più 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 menzionato, questo non è perfetto ma sembra che sia abbastanza buono nei test iniziali.

0

Se si arriva a usare PHP, è possibile utilizzare le sessioni per tracciare l'attività da particolari utenti. In combinazione con un database, è possibile monitorare l'attività da determinati indirizzi IP, che si presume siano dello stesso utente.

Utilizzare i timestamp per limitare colpi (assumono non più di 1 colpo ogni 5 secondi, per esempio), e di dire quando nuove "visite" al sito si verificano (se l'ultimo colpo è stato oltre 10 minuti fa, per esempio) .

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

modifica: Ho monitorato le visite & prima, contando una visualizzazione di pagina come hit e +1 alle visite quando viene creata una nuova sessione. Era abbastanza affidabile (più che 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

+0

Gli indirizzi IP non sono affidabili a lungo termine – Cameron

+0

Utilizzo di ASP.NET (MVC) e sebbene Sessione sia un'opzione non aiuta l'accesso senza cookie da parte dei robot. La sessione Plus ha un po 'di sovraccarico che questa app altrimenti non avrebbe bisogno. –

4

Utilizzare gli indirizzi IP insieme alle sessioni. Conteggiare ogni nuova sessione per un indirizzo IP come un unico colpo contro il contatore. È possibile memorizzare questi dati in un database di log se si pensa questo sarà utile per calcolare quando il tuo sito riceve più traffico, quanto traffico al giorno, per IP, ecc.

0

Se fossi in te, mi arrenderei il mio contatore è preciso in primo luogo, ogni soluzione (es. cookie, indirizzi IP, ecc.), come hai detto tu, tende ad essere inaffidabile. Quindi, penso che la cosa migliore da fare sia usare la ridondanza nel tuo sistema: usa i cookie, i "Flash-cookie" (oggetti condivisi), gli indirizzi IP (magari in combinazione con gli user-agent) e gli ID utente per le persone che hanno effettuato l'accesso.

È possibile implementare una sorta di schema in cui a qualsiasi client sconosciuto viene assegnato un ID univoco, che viene archiviato (si spera) sul computer del cliente e trasmesso nuovamente a ogni richiesta. Quindi è possibile associare un indirizzo IP, un agente utente e/o un ID utente (più qualsiasi altra cosa a cui si possa pensare) a ogni ID univoco e viceversa. Il timestamp e l'ID univoco di ogni clic potrebbero essere registrati in una tabella di database da qualche parte, e ogni clic (almeno, ogni clic sul tuo sito Web) potrebbe essere ignorato o negato a seconda di quanto recente l'ultimo clic fosse per lo stesso ID univoco. Questo è probabilmente abbastanza affidabile per gli scatti di scatto a breve termine, e a lungo termine non sarebbe molto importante (per il problema di click-up, non per il contatore di pagine).

I robot amichevoli devono impostare il proprio agente utente in modo appropriato e possono essere confrontati con un elenco di agenti utente robot noti (ne ho trovato uno here dopo una semplice ricerca di Google) per essere correttamente identificato e trattato separatamente da persone reali.

+0

Grazie Cameron. Questo è il punto in cui mi trovo a questo punto. Il punto della domanda è stato vedere se ci sono approcci migliori disponibili. –

Problemi correlati