logga träffar - spåra unika besökare

Varje unik besökare (dator) får du ut från REMOTE_ADDR och REMOTE_HOST (hostnamnet, behövs inte...). Spara varje ny besökare i en tabell. Varje gång sidan får en request så kollar du i tabell om ip-adressen redan finns... resten av det du vill veta är bara att stoppa in i tabellen.

tblRequests
---------------
strRemoteAddr
intCounter
.
. ' bara att lägga till det extra du vill ha med
.

Dim rs As RecordSet
dim strRequest, strSQL

strRequest = Request.ServerVariables("REMOTE_ADDR")
strSQL = "SELECT strRemoteAddr, intCount FROM tblRequests WHERE strRemoteAddr = '" & strRequest & ";"
rs.Open strSQL, [i]connection[/i]

If rs.eof Then 'Ny besökare
    strSQL = "INSERT INTO tblRequest VALUES ('" & strRemoteAddr & "', 1);"
    [i]connection[/i].Execute strSQL, , 128
Else 'Besökaren har varit här redan...
    strSQL = "UPDATE tblRequest SET intCounter = " & CLng(rs("intCounter") + 1) & _
    " WHERE strRemoteAddr = '" & rs("strRemoteAddr") & "';"
    [i]connection[/i].Execute strSQL, , 128
End If

Skrivet rätt upp och ner, så om det har blivit något fel eller något är otydligt så var det väl inte meningen ;)

ehh... när jag drar ut rapporter så löser man ju det där i databasen... jag vill ha en rad för varje sidvisning.

men man måste ju kombinera ip't med fler fält när man gissar unika besökare, det blir ju ganska fel annars.

En rad för varje request för alla sidor? Där missförstog jag dig en aning.

Gissa unika besökare? vad är det för unikt med att gissa?

Uppenbarligen vill du veta något helt annat än vad jag svarade på... you've lost me :l

jag vill ha en rad för varje sidvisning

Nja, det är ju inte att rekomendera .... om det inte rör sig om ett par hundra sidvisningar om dagen. Om det nu skulle röra sig om 15 000 sidvisningar om dagen så fyller man rätt snabbt databasen ..... Normalisera databasen ....

cya,
PatrikB

det kommer bli runt 12 miljoner nya rader i tabellen i månaden ... men det var ju inte problematiken runt det jag undrade över :)

jag ville ha lite tips angående vad jag kan få ut och spara ned som hjälper mig att skriva en korrekt rutin för att räkna ut (eller gissa med finess) en unik besökare... vad jag kommit fram till själv sen första inlägget är nog att jag i första hand sätter ett guid i en cookie om det inte redan finns, sparar det i db och grupperar på det sen. är cookies ej tillåtna hos den besökare går man på ip-numret i kombination med USER_AGENT... typ?

Den typen av loggning du vill ha sköts bättre om IIS'en loggar istället för varje separat sidvisning som ASP tolken skapar. Det är en mycket smidigare lösning att köra något statistikprogram på servern. Loggfilerna kan man ju alltid exportera till olika format.

Genom att ändra inställningarna i IIS'en för loggfilen på den aktuella platsen (utökad loggning) så får du ändå det du vill ha + en massa mycket mer, gratis och ganska enkelt.

Sen finns det 3:e parts programvaror som kan användas.

+ om man har en högtrafikerad site så ska man ställa in i IISen att skapa loggarna en ggn per timme .... så att filerna blir mer hanterbara ;)
[r]
Om filerna fortfarande är stora så ställer man in max storleken. När max uppnås skapas en ny ..
[/r]

cya,
PatrikB

Jo, har koll på det där... Kör bl a WebTrends på vissa sajter nu. Men som jag skrev så ska jag även spara ned en del parametrar från mitt publiceringsverktyg och sen göra urval på dem. Då känns sql betydligt smidigare än att bläddra igenom loggar.

Frågetecknet är dock fortfarande hur unika besökare räknas fram, exempelvis WebTrends klarar ju av det enbart med hjälp av att lägga till cs(Cookie) i IIS-loggningen har jag för mig.

cs(Cookie) ger dig information om vad som finnes sparat per användare för just denna site ...... dvs, vissa användare har inte sparat ned ngn cookie.

Har för mig att WebTrends räknar olika ip-nummer för att få fram unika besökare

Det du kan göra är att ha en tabell som sparar ipnummer.
När en användare kommer till siten kolla om dennes ipnummer redan finns sparat och hämta det unika-idet, annars lägg till ip'et och hämta dess unika id. Detta unika id refererar du i dina andra tabeller.
Samma "logik" ska utföras på alla data som du vill spara.

Ha sedan en tabell (SiteStats) som du sedan sparar de olika id i för att kunna referera till vart datat sedan finns sparat.

Som sagt, mycket av datan kommer att vara "samma"/"lika" så det är ingen bra ide att skapa en ny rad för varje sidvisning med lika data för varje rad ..... Normalisering ;)

cya,
PatrikB

rent prestandamässigt så är det ju att i det här fallet att föredra att bara sätta in en en rad i tabellen... ska jag göra nån form av check med en select sats eller ännu värre uppdatera en rad med något så slöar det ner betydligt, i det senare fallet skapas säkerligen en del låsningar i databasen också, det är inte kul...

Du skulle behöva börja om från början med ditt problem. Skriv ned det du behöver spara och försök splitta detta till så små tabeller som möjligt... ett steg i normalisering.

Mer om normalisering (För Accessdatabaser)
Och här (Normalisering för relationsdatabaser)

hmmm... jo tjena...
i själv loggnings-förfarandet ska det gå så snabbt som möjligt, alltså ingen logik där mer än att plocka in värdena. att sen samma ipnr, URL eller referer finns på flera rader är inget problem. det är ju saker som funkar lika bra som nyckelvärden som nån form av id med koppling till tabell bredvid eller vad det nu är du föreslår.

Den prestanda "förlusten" tror jag inte att du märker.

Kika in på denna sida https://www.vasterviksbk.nu (den har ni aaaaldrig hört förr) där jag håller på med ett "litet" experiment i denna riktgningen. Siten har 1000 unika beskare minimum om dagen (unika ip). Loggar inte så mycket som du verkar vilja logga, men jag tror inte att du märker av min "loggning".

cya,
PatrikB

Unika besökare betyder inte nödvändigtvis unika IP, det kan ju vara en skola eller ett företag med en massa användare tex.

Det är antalet sessioner som man räknar för att få ut unika besökare.

Om du nu ska logga med en databas, så använd sessionsnummret som utångspunkt, och spara den info du vill i databasen.

Fast, det är inte heller "bullet proof" som "unik" besökare då samma besökare får olika sessions idn för varje gång han/hon återkommer.
Det säkraste sättet (minst fel faktor) är att logga ip ..... möjligtvis skulle man kunna hantera session idet tillsammans med cookie ... men, går ju att komma runt då många inte tillåter att cookies sparas .....

Så, att logga "unika besökare" är svårt ... mycket svårt.

cya,
PatrikB

Även om man kräver att varje besökare måste registrera sig och så vidare (user/pass), så kan man fortfarande inte veta att det är en unik besökare. Det enda unika man kan vara till någorlunda säker på är hur många unika ip-adresser som kommer till sidan.

Statistik har ju tyvärr dessa naturliga fel/problem. Statistik på sidan är skoj däremot ;)

he, he ... ja, med statistik kan man visa allt till sin egen fördel ;)

Vi får nog vänta till IPv6 så att det finns utrymme för alla få sitt eget unika ip-nummer för att kunna mäta "unika besökare" utan feltolerans :e

cya,
PatrikB

Fast, det är inte heller "bullet proof" som "unik" besökare då samma besökare får olika sessions idn för varje gång han/hon återkommer.

Unik besökare är enligt definition just unik besökare och inte en och samma besökare som återkommer.

Dvs. en person som återkommer flera gånger med olika sessionsnummer är en unik besökare för varje besök.

Mao. en session = unikt besök, oavsett IP osv.

Vill man logga varje person och antalet besök, så måste man använda någon typ av inloggning, eftersom man aldrig vet var personen befinner sig.

nja, det vill jag nog inte hålla med om.
En unik besökare definierar jag som en unik individ ... dvs, spelar ingen roll om en besökare återkommer flera gånger så ska den bara räknas som en unik besökare.

cya,
PatrikB