|
|
Posted by Gordon Burditt on 11/11/25 11:17
>We have about 10 different domains that are linked very closely and we
>want to identify and track every single user that surfs our websites.
>Later we want to analyse user paths and find out the search robots with
>the referring search words.
>
>What are the possibilities?
Require the users to log in with an ID and password after registration.
That may not be an option. You also probably need sessions to keep
track of the fact that they HAVE logged in.
When the user first hits one of your pages, the URL passed from
many search engines gives you the keywords. This you can get from
Apache logs, or with PHP. Figuring out where the user goes after
that is harder, especially across domains.
>Cookies are not accepted by 40 % of our users and in addition to that
>for each domain a different cookie is created what makes it really
>complicated.
>I guess a combination of Browser type, Operating System, Hostname etc
>is really insecure as there are many users using the same stuff.
I hope 'secure' is *NOT* what you are looking for, and what you are
looking for is more like 'accurate Big Brother watching'. If
'security' is any kind of issue (say, you are a bank or doctor or
auction site), you shouldn't even be thinking about fingerprinting
browsers as a way of identifying users.
Browser fingerprinting is inaccurate for a number of reasons:
(a) load-sharing proxies make requests for even stuff on the SAME
page come from several different IP addresses (and I believe
most AOL users go through one).
(b) If you don't use IP address, there's not enough info to distinguish
the users (what percentage are using IE(latest) with Windows XP?
Over half?)
(c) NAT gateways make lots of really different users appear to come
from the SAME IP. See (b) for why you can't tell them apart.
It might work OK for marketing stats but not for anything requiring
'security'.
>I think the only secure way to logg this is by the way of using
>sessions.
Well, you've got a problem. To keep track of a session, you need at
least one of (a) cookies, (b) session IDs passed via URL transparently
using trans_sid, (c) session IDs passed explicitly via URL manually,
or (d) hidden form variables on the page.
(a) doesn't work across domains and besides, a lot of your users have
them turned off.
(b) only works with relative URLs (which have to be the same domain).
(c) is a pain in the butt and may offend users for the same reason
they have cookies off,
and (d) works only if every link is a form, and is also a pain in the butt.
I presume that if cookies are often turned off, Javascript is also often
turned off.
You're essentially stuck with (c), with the others sometimes working
as a backup.
>One disadvantage of sessions is that they take very much performance of
>the server when there are many users at the same time.
It is possible to write session handlers to stuff the session info
into a MySQL database instead of using lots of little files in a
directory. Whether or not this is a performance increase or decrease
depends on your setup and things like how much data gets stuffed
into sessions. Among other things this gets you is the ability to
share session data between different (load-shared) physical servers.
>Is there a way to reduce performance of the sessions?
You could always add time-wasting code such as checking whether a
user is logged in several thousand times on each page, but I don't
think this is what you meant to ask.
>Are there any other possibilities except sessions?
There are some do-it-yourself methods which essentially re-implement
sessions, often poorly, using the methods (a) through (d) to
keep track of a session ID. Once you can track the session ID,
you can stuff the session data anywhere you need to (files, database,
whatever).
>Are there freeware php statistic functions that allow the reuse of
>their statistic data in our own implementations?
Probably, but I'm not sure how calculating mean and standard deviation
of something is going to get you the raw data in the first place.
Gordon L. Burditt
Navigation:
[Reply to this message]
|