The "Freeola Customer Forum" forum, which includes Retro Game Reviews, has been archived and is now read-only. You cannot post here or create a new thread or review on this forum.
OK, this site is NOT finished! There are still lots of pages which don't work - i.e. broken links. That's cos I haven't made 'em yet.
However, I am still working on it and I would appreciate opinions so far. I have started going through and removing the anti-aliasing on the menus but I've only done it on the main menu so far. I will do the others too.
If you find any bugs when using the site, please let me know. If the site doesn't work, please let me know.
[URL]http://www.xymail.co.uk/tracker/website/[/URL]
Username: test
Password: test
The test page that contains the counter to add data to the database is [URL]http://www.xytracker.com/test.htm[/URL]. Please feel free (and I encourage you to) add some hits to give the site a feel of what it's like with more hits. It will also help ensure my detection works correctly on different browsers etc..
However, I am still working on it and I would appreciate opinions so far. I have started going through and removing the anti-aliasing on the menus but I've only done it on the main menu so far. I will do the others too.
If you find any bugs when using the site, please let me know. If the site doesn't work, please let me know.
[URL]http://www.xymail.co.uk/tracker/website/[/URL]
Username: test
Password: test
The test page that contains the counter to add data to the database is [URL]http://www.xytracker.com/test.htm[/URL]. Please feel free (and I encourage you to) add some hits to give the site a feel of what it's like with more hits. It will also help ensure my detection works correctly on different browsers etc..
Page:
OK, having another look at the Code of Practice, I think I've worked out a way to make the hit counter well worth the money. The thing my client made me realise is that with all the other hit counters, you're paying for the data.
To make it truely saleable, you need to offer something more - you need to offer them more than data. If you think about what companies would want the hit counter for, you can offer them it on a plate. They want to find the growth of the site, the most popular articles, etc.
I can produce reports in XML, RTF, CSV format that they can export straight into their files. But I can go one stage further - I can produce the reports they want, with processed data such as growth rates. And I can have it set up to email them customised reports each day/week/month/whatever.
Plus, if it complies with the PA Code of Practice Revision 1, then it is even better :) The list of compliant vendors at the moment is mainly publishers - e.g. Oxford University Press. There are no companies addressing small publishers. That's where I come in. It's gonna take a lot of work though.
To make it truely saleable, you need to offer something more - you need to offer them more than data. If you think about what companies would want the hit counter for, you can offer them it on a plate. They want to find the growth of the site, the most popular articles, etc.
I can produce reports in XML, RTF, CSV format that they can export straight into their files. But I can go one stage further - I can produce the reports they want, with processed data such as growth rates. And I can have it set up to email them customised reports each day/week/month/whatever.
Plus, if it complies with the PA Code of Practice Revision 1, then it is even better :) The list of compliant vendors at the moment is mainly publishers - e.g. Oxford University Press. There are no companies addressing small publishers. That's where I come in. It's gonna take a lot of work though.
Nimco wrote:
> The thing with server logs is it makes it very easy to track sessions
> - since the server logs the exact time that every single request is
> made to the server.
>
> With my hit counter, it only logs when the counter (i.e. a picture or
> JS script) is loaded. Unless the client includes the counter on every
> page, I can't track the session lengths. This is part of the code of
> practice of the COUNTER project.
>
As I mentioned in a previous post you should support multiple page tracking else you're severely restricting what you can generate in terms of stats. And ultimately that means less sales, as anybody wanting to pay for such things will regard tracking throughout the site as a must.
> Btw, on a slight aside, how would people deem the best way of
> differentiating between a hit and a visit? A hit is every time the
> counter is loaded, but how do you define a visit?
>
The usual convention is that a visit is defined by time, the first new hit is the start of the visit which expires after 12-24 hours. That way you can easily measure unique visitors per day and have a moderately accurate figure. How you track that is up to you, advertisers like cookies/sessions these days to do it. IPs are ok, as long as you take account of proxies and things like AOL.
> The thing with server logs is it makes it very easy to track sessions
> - since the server logs the exact time that every single request is
> made to the server.
>
> With my hit counter, it only logs when the counter (i.e. a picture or
> JS script) is loaded. Unless the client includes the counter on every
> page, I can't track the session lengths. This is part of the code of
> practice of the COUNTER project.
>
As I mentioned in a previous post you should support multiple page tracking else you're severely restricting what you can generate in terms of stats. And ultimately that means less sales, as anybody wanting to pay for such things will regard tracking throughout the site as a must.
> Btw, on a slight aside, how would people deem the best way of
> differentiating between a hit and a visit? A hit is every time the
> counter is loaded, but how do you define a visit?
>
The usual convention is that a visit is defined by time, the first new hit is the start of the visit which expires after 12-24 hours. That way you can easily measure unique visitors per day and have a moderately accurate figure. How you track that is up to you, advertisers like cookies/sessions these days to do it. IPs are ok, as long as you take account of proxies and things like AOL.
The thing with server logs is it makes it very easy to track sessions - since the server logs the exact time that every single request is made to the server.
With my hit counter, it only logs when the counter (i.e. a picture or JS script) is loaded. Unless the client includes the counter on every page, I can't track the session lengths. This is part of the code of practice of the COUNTER project.
Btw, on a slight aside, how would people deem the best way of differentiating between a hit and a visit? A hit is every time the counter is loaded, but how do you define a visit?
Cookies - i.e. only one visit per person for the life of the cookie?
IP Address? - i.e. only one visit per IP address?
Time - i.e. only one visit per rolling period of time?
And then how should visits expire? Per hour? Per day? Week? Ever?
With my hit counter, it only logs when the counter (i.e. a picture or JS script) is loaded. Unless the client includes the counter on every page, I can't track the session lengths. This is part of the code of practice of the COUNTER project.
Btw, on a slight aside, how would people deem the best way of differentiating between a hit and a visit? A hit is every time the counter is loaded, but how do you define a visit?
Cookies - i.e. only one visit per person for the life of the cookie?
IP Address? - i.e. only one visit per IP address?
Time - i.e. only one visit per rolling period of time?
And then how should visits expire? Per hour? Per day? Week? Ever?
Nimco wrote:
> Cool, cheers. That was a really useful post. I think I am gonna
> re-write the menu in HTML/CSS. Do you think it should be moved to the
> left so it doesn't ovelap the line?
>
Now that I understand that was your intent I've got used to it, but at least my first impression was that it was out of position. You've clearly framed your main content area, it just doesn't look natural with something overlapping borders I think.
> She also referred me to a project called COUNTER which is run by the
> Publishers' Association. She thinks if I can conform to their
> standards, I could get a lot of custom. However, from what I can tell
> by the Code of Practice, I think it requires server log analysis. If
> anyone fancies giving me a second opinion on that, it would be useful
> - just Google for it.
I cant really see anything that you cant accomplish, after all a fully featured hit tracker like you're doing will give you near identical data (plus a bit more) to what ends up in server logs. Maybe I missed something though?
Speaking of server logs, something I've done in the past that you might consider is write something that'll handle both anyway. If you write something that analyzes the server logs, you can make your tracker url so that rather than log details to a database etc. when called, it writes to a log file (in the format that apache etc. already put out) instead. And you just point the account in the direction of the correct log files to produce data. That way you can work towards a solution you can deploy in any manner you or a company wants. Erm...wandered a bit off topic. :P
Anyway, following codes of practice is an excellent idea, most companies are prepared to pay silly money for compliant products.
> Cool, cheers. That was a really useful post. I think I am gonna
> re-write the menu in HTML/CSS. Do you think it should be moved to the
> left so it doesn't ovelap the line?
>
Now that I understand that was your intent I've got used to it, but at least my first impression was that it was out of position. You've clearly framed your main content area, it just doesn't look natural with something overlapping borders I think.
> She also referred me to a project called COUNTER which is run by the
> Publishers' Association. She thinks if I can conform to their
> standards, I could get a lot of custom. However, from what I can tell
> by the Code of Practice, I think it requires server log analysis. If
> anyone fancies giving me a second opinion on that, it would be useful
> - just Google for it.
I cant really see anything that you cant accomplish, after all a fully featured hit tracker like you're doing will give you near identical data (plus a bit more) to what ends up in server logs. Maybe I missed something though?
Speaking of server logs, something I've done in the past that you might consider is write something that'll handle both anyway. If you write something that analyzes the server logs, you can make your tracker url so that rather than log details to a database etc. when called, it writes to a log file (in the format that apache etc. already put out) instead. And you just point the account in the direction of the correct log files to produce data. That way you can work towards a solution you can deploy in any manner you or a company wants. Erm...wandered a bit off topic. :P
Anyway, following codes of practice is an excellent idea, most companies are prepared to pay silly money for compliant products.
Cool, cheers. That was a really useful post. I think I am gonna re-write the menu in HTML/CSS. Do you think it should be moved to the left so it doesn't ovelap the line?
I agree totally with what you say about the analysis and trends and things. This is something that I was planning to build in anyway, but speaking with the person yesterday made me realise just how important it is.
She also referred me to a project called COUNTER which is run by the Publishers' Association. She thinks if I can conform to their standards, I could get a lot of custom. However, from what I can tell by the Code of Practice, I think it requires server log analysis. If anyone fancies giving me a second opinion on that, it would be useful - just Google for it.
I agree totally with what you say about the analysis and trends and things. This is something that I was planning to build in anyway, but speaking with the person yesterday made me realise just how important it is.
She also referred me to a project called COUNTER which is run by the Publishers' Association. She thinks if I can conform to their standards, I could get a lot of custom. However, from what I can tell by the Code of Practice, I think it requires server log analysis. If anyone fancies giving me a second opinion on that, it would be useful - just Google for it.
Firstly, I'll say forgive the critical nature of this post but I feel the need to play devil's advocate here somewhat since nobody else has pointed out the obvious flaws in this site.
The design looks fine to me, but as somebody already pointed the menu looks misplaced (even if was a design decision). I can only put down the flash menu to a moment of insanity on your part, as its provides nothing that cant be easily accomplished in plain css/html but at the same time provides all the annoying quirks you associate with flash links, cant right click on them etc.. Its use of flash for the hell of it really, and thats always a bad start.
As for the actual site content, I'm sure you know yourself that its behind alot of the competition at the moment, but its a work in progress so understandable. Alot of the stats are for the most part curiosities or things I might be interested when designing a site or thinking about changes. Browser stats are very interesting... interesting enough to pay for? not a chance. The stats that are interesting and worth paying for aren't developed enough. All stats used should be tracked over a period, I should be able to see trends develop, totals are all very well but ultimately not much use to somebody who wants to pay for services like this. You should also support creation of anchors that can be placed throughout the site so you can track progress through a site, even if its only in a crude manner. Simply there needs to be more analysis of the data, all thats being done at the moment is reproduce the data you get from visitors, the trick is to start deriving useful statistics from that it. Offering stuff like exporting data is nice, on the other hand you should also look at it from the point of view that if somebody needs to export data then perhaps theres some statistics that you aren't providing them.
Innovation is the key with these types of services now I think as i) the market is saturated (especially with free services) and ii) its increasingly common for hosts to provide log analyis by default which by their nature mean they can provide far better and useful statistics.
Having said all that, good start and where as I've been critical, I think you have the basis to do something useful.
The design looks fine to me, but as somebody already pointed the menu looks misplaced (even if was a design decision). I can only put down the flash menu to a moment of insanity on your part, as its provides nothing that cant be easily accomplished in plain css/html but at the same time provides all the annoying quirks you associate with flash links, cant right click on them etc.. Its use of flash for the hell of it really, and thats always a bad start.
As for the actual site content, I'm sure you know yourself that its behind alot of the competition at the moment, but its a work in progress so understandable. Alot of the stats are for the most part curiosities or things I might be interested when designing a site or thinking about changes. Browser stats are very interesting... interesting enough to pay for? not a chance. The stats that are interesting and worth paying for aren't developed enough. All stats used should be tracked over a period, I should be able to see trends develop, totals are all very well but ultimately not much use to somebody who wants to pay for services like this. You should also support creation of anchors that can be placed throughout the site so you can track progress through a site, even if its only in a crude manner. Simply there needs to be more analysis of the data, all thats being done at the moment is reproduce the data you get from visitors, the trick is to start deriving useful statistics from that it. Offering stuff like exporting data is nice, on the other hand you should also look at it from the point of view that if somebody needs to export data then perhaps theres some statistics that you aren't providing them.
Innovation is the key with these types of services now I think as i) the market is saturated (especially with free services) and ii) its increasingly common for hosts to provide log analyis by default which by their nature mean they can provide far better and useful statistics.
Having said all that, good start and where as I've been critical, I think you have the basis to do something useful.
I met with someone yesterday who gave me some really useful pointers. She suggested things to do a more in-depth analysis of the data - e.g. % growth of a given browser over time, month-by-month comparisons, etc.
I'm also going to add in support to allow data to be exported via RTF and CSV.
I'm also going to add in support to allow data to be exported via RTF and CSV.
sweet!
Yup - scripted the whole jobby myself. I much prefer coding to designing, but I'm pretty happy with how it has turned out. And it gets me £120 per year per user without me having to do much from now on - other than make sure it can handle new browsers etc..
Good stuff. Nice product too. Is Hit Counter something you created yourself?
Page: