Как реализовать надежный счетчик веб-страниц? - PullRequest
7 голосов
/ 29 июля 2009

Какой хороший способ реализовать счетчик веб-страниц?

На первый взгляд, это простая проблема, но она становится проблематичной, когда приходится иметь дело с поисковыми роботами и роботами, многократными щелчками одним и тем же пользователем, обновлением кликов.

В частности, каков хороший способ гарантировать, что ссылки не просто "нажимаются" пользователем при повторном нажатии? Айпи адрес? Печенье? У обоих из них есть несколько недостатков (IP-адреса не обязательно уникальны, куки могут быть отключены).

Кроме того, каков наилучший способ хранения данных? Увеличивайте счетчик индивидуально или сохраняйте каждый щелчок как запись в таблице журнала, а затем иногда суммируйте.

Любой живой опыт будет полезен,

+++ Рик ---

Ответы [ 4 ]

4 голосов
/ 29 июля 2009

Использование IP-адресов в сочетании с сеансами. Считайте каждый новый сеанс для IP-адреса как один удар по вашему счетчику. Вы можете сохранить эти данные в базе данных журналов, если считаете, что вам когда-нибудь понадобится их просмотреть. Это может быть полезно для расчета, когда ваш сайт получает больше всего трафика, сколько трафика в день, по IP и т. Д.

2 голосов
/ 30 июля 2009

Так что я немного поиграл с этим, основываясь на комментариях здесь. Я придумал счетчик в простом поле. В моем приложении есть фрагменты кода со свойством Views.

Когда просматривается фрагмент, метод отфильтровывает (белый список) только то, что должно быть браузерами:

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

Затем хранимая процедура использует отдельную таблицу для временного хранения последних представлений, в которых хранятся идентификатор фрагмента, введенная дата и адрес IP. Каждое представление записывается в журнал, и, когда появляется новое представление, проверяется, получал ли тот же IP-адрес доступ к этому фрагменту за последние 2 минуты. если так, то ничего не регистрируется.

Если это новое представление, представление регистрируется (снова SnippetId, IP, Entered), и фактическое поле Views обновляется в таблице Snippets.

Если это не новое представление, таблица очищается с помощью любых зарегистрированных представлений, которые старше 4 минут. Это должно привести к минимальному количеству записей в таблице просмотра журнала в любое время.

Вот хранимый процесс:

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

Кажется, это работает довольно хорошо. Как уже упоминалось, это не идеально, но похоже, что оно достаточно хорошо при первоначальном тестировании.

0 голосов
/ 29 июля 2009

Если бы я был тобой, я бы в первую очередь разочаровался в своей стойке.Каждое решение (например, файлы cookie, IP-адреса и т. Д.), Как вы сказали, имеет тенденцию быть ненадежным.Поэтому я думаю, что вам лучше всего использовать избыточность в вашей системе: использовать cookie-файлы, «Flash-cookie» (общие объекты), IP-адреса (возможно, в сочетании с пользовательскими агентами) и идентификаторы пользователей для тех, кто вошел в систему.

Вы могли бы реализовать какую-то схему, где любому неизвестному клиенту присваивается уникальный идентификатор, который сохраняется (надеюсь) на клиентской машине и повторно передается при каждом запросе.Затем вы можете привязать IP-адрес, пользовательский агент и / или идентификатор пользователя (плюс все, что вы можете придумать) к каждому уникальному идентификатору и наоборот.Временная метка и уникальный идентификатор каждого клика могут быть записаны где-нибудь в таблице базы данных, и каждый клик (по крайней мере, каждый клик на ваш сайт) может быть пропущен или отклонен в зависимости от того, как недавно последний клик был для того же уникального идентификатора.Это, вероятно, достаточно надежно для краткосрочных всплесков кликов, и в долгосрочной перспективе это не будет иметь большого значения в любом случае (для проблемы кликов, а не для счетчика страниц).

У дружественных роботов должен быть свой пользовательский агентустановлен соответствующим образом и может быть проверен по списку известных агентов-пользователей роботов (я нашел один здесь после простого поиска в Google), чтобы его можно было правильно идентифицировать и иметь дело отдельно от реальных людей.

0 голосов
/ 29 июля 2009

Если вы используете PHP, вы можете использовать сеансы для отслеживания активности определенных пользователей. Вместе с базой данных вы можете отслеживать активность с определенных IP-адресов, которые, как вы можете предполагать, принадлежат одному и тому же пользователю.

Используйте временные метки, чтобы ограничить количество посещений (например, не более 1 попадания в 5 секунд) и сообщить, когда происходят новые "посещения" сайта (например, если последний переход был более 10 минут назад).

Вы можете найти свойства $ _SERVER [], которые помогут вам обнаружить ботов или тренды посетителей (например, использование браузера).

редактирование: Ранее я отслеживал хиты и посещения, считая просмотр страницы как посещение, и +1 за посещения при создании нового сеанса. Он был достаточно надежным (более чем достаточно надежным для тех целей, для которых я его использовал. Браузеры, которые не поддерживают файлы cookie (и, следовательно, не поддерживают сеансы), и пользователи, которые отключают сеансы, в настоящее время встречаются довольно редко, поэтому я не стал бы беспокоиться об этом, если нет причин быть слишком точным.

...