Re: [Summary-Talk] Visitor Tracking Methods

[Jason Linhart <jason@xxxxxxxxxxx>]

On 2/4/04 9:58 AM Chris Young (ChrisYoung@synergypoint.net) wrote:

>After looking at their method for tracking visitors it has raised some
>questions.
>
>Apparently they have a system that uses a combination of tracking code
>placed on each web page, cookies, and standard log data. The tracking
>code is supposed to help with server clustering, proxies, and caching.

Summary has it's own approach to resolving issues with clustering and 
proxies that we believe is superior. No system can completely prevent 
counting problems due to caching.

>The cookies helps with return visitors and sessions but doesn't
>eliminate the first visit information like page entry and referrer
>information. The tracking code consists of a JavaScript file that also
>loads a small invisible graphic.

There are issues with using cookies that make them problematic in some 
situations. Many clients don't accept cookies, resulting in misleading 
numbers from any cookie based system. Some end users will complain about 
any site that uses cookies, unless they are used to provide some clearly 
spelled out end user visible feature at the site. Many sites are willing 
to put up with these costs, but we decided not to make cookies a standard 
feature of Summary because of these issues.

In our testing, Summary provides visit tracking information that is just 
as accurate, or superior, overall as the more complex JavaScript based 
approaches. For the best visit tracking results in Summary you should 
turn on "Combine proxy clusters into one host", and turn off "Use session 
IDs to determine visits", both on the Options configuration page.

>I noticed in the Summary documentation that if you enable tracking
>visits by cookies or sessions that the entry page and referrer
>information is not available.

That actually depends on which system you are using to produce the cookie 
information. The simpler cookie systems, such as the one built into 
Apache, will cause these problems, but some of the more sophisticated 
systems don't have these limitations.

>I was wondering if there were any plans to
>enhance Summary so if cookies were used to track visitors that the first
>hit related data like page entry, etc., isn't lost.

Summary's visit tracking without cookies has proven to be significantly 
more accurate than any cookie based system that we have tested, so we 
have not been focusing on improving the session ID based features. 
Session ID based tracking is mostly provided in order to be able to match 
up numbers with other session ID based systems. You can, in fact, get 
entry point and referrer information with Summary using more advanced 
session ID systems, so we have left things as is for now.

>My client seems to want the most accurate accounting of unique and
>returning visitors. Are the extra measures in Urchin likely to produce
>significant results in determining those values?

The entire concept of unique visitors is problematic. There is no way to 
reconcile what you or I would intuitively think a "unique visitor" is 
with the information that is available about web browsing, using cookies 
or not. There are simply too many confounding issues, several people 
using the same computer, visitors that refuse cookies, a single person 
accessing your site from different computers at different times, etc.

On the other hand, cookie based approaches can produce reasonably good 
returning visitor numbers. Summary does not currently even attempt to 
calculate returning visitor numbers, so Urchin would have a clear 
advantage there.

>Is there any way to configure Summary in a similar fashion and in you
>opinion would it be worth it?

That depends on what you are most interested in. Summary is very very 
good at counting visits when configured as mentioned above. But Summary 
doesn't even attempt to calculate returning visitors, something that 
might be worth adding in the future. For tracking visitor paths through 
the site, the approach currently used by Summary and the approach used by 
Urchin each have advantages and disadvantages. It is unclear if it is 
possible to create one system that has the best features of each or not.

>I am also interested in analyzing some E-commerce data from ELF log
>files (Extended Log Format).
>
>Are there any plans to support ELF formats?

Summary supports the W3C ExLF log format (Extended Log Format, sometimes 
referred to as ELF), but not the e-Urchin Log Format (also called ELF). 
e-Urchin Log Format is proprietary to Urchin Software Corporation.

Summary has various e-commerce related features, goals and value for 
example, but they are not as complete as what you can do in Urchin using 
e-Urchin Log Format to supplement the standard logs. Urchin ties in 
particularly well with Miva Merchant. Future versions of Summary will 
have additional e-commerce related features, but they are unlikely to 
exactly correspond to what Urchin does.

Jason

-----------------
Jason@Summary.Net
-----------------
Dr. Seuss books . . . can be read and enjoyed on several levels. For
example, 'One Fish Two Fish, Red Fish Blue Fish' can be deconstructed
as a searing indictment of the narrow-minded binary counting system.
  -- Peter van der Linden, Expert C Programming, Deep C Secrets
-------------
Go to <http://summary.net/list.html> to update subscription info.