>I have a similar problem... I've inherited a site which uses a custom >CMS to manage all the pages... Everything is referenced through one file >(ala Fusebox though it's not a Fusebox site) and URL parameters. > >index.cfm?cat_id=23&content_id=320 > >At their old host - they had WebTrends but for the most part it was >useless as they had to build a matrix to decipher all the links, and of >course as more pages are added the matrix became outdated. > >So now I'm looking at building them some kind of simple stats package >that records clicks per URL and then ties that back into the CMS so they >can see what page was clicked. > >I'm curious if anyone has done anything similar? I know at one time >there were some Fusebox stats projects which I'll probably take a look >at since they are similar.
I've done this for the exact same reason (fusebox and webtrends). Here's some suggestions: 1) Use a third party solution. Really. You can get reasonably feature rich stuff quite cheaply and it will pretty much always be better than the stuff you write yourself. 2) Still reading? Guess you decided to build your own. In your case, the easiest way is just to trace through the code of the cms to find out where it builds and sends the page and put in some hit logging code (cfquery inserting into a database). 3) STILL reading? I can't give you a straight copy-paste of the solution i did because it belongs to my employer, but here's how it works: There are two cf parts to the solution: - a custom tag that you put on pages you want to track and - a cfm page that captures the tracking data and puts it in the database. The custom tag uses js to dynamically embed an image in the tracked page. I've already posted a snippet of that to another thread here: http://houseoffusion.com/cf_lists/messages.cfm/forumid:4/threadid:45198#235814 The source of the image is a cfm file which does the following: a) sets cf headers for - cache control - p3p policy if you are going to use persistent cookies to track returning visitors b) sets cookies if you are going to use them. As an aside, i don't - it would require the legal department making a wording change to the site policy to bring it into line with p3p and empires have fallen waiting for legal. The basic idea is two cookies: a persistent cookie to identify repeat visitors and a session cookie to track page requests in the same visit. c) cfparam in case any information from the url got lost along the way. d) insert into the database e) cfcontent to serve up a 1 x 1 transparent gif which will serve as the actual source of the tracking image. 3) some thoughts for the DIY solution: a) Use cftry/cfcatch and swallow all errors gracefully! If your page throws an error, an http status code of 500 will be returned to the client and funny things may happen like ie showing a "this page is busted" message. Bringing an otherwise functioning web page down because there's a problem with your stats tracking code is.... so.... wrong. b) Optimise your database table for inserts: in practise, this means use as few indexes as possible. As long as your insert code hasn't run, the client hasn't gotten the image, and the "waiting for page to load" throbber is still going. It might not make your page any slower in real terms, but it wil make the page seem slower. If you have access to cf enterprise, this could be a good place to deploy a asynch gateway. c) p3p - learn it. It's not about "tricking" browsers into accepting persistent cookies under high security settings, it's about being upfront and honest with your customers about what kind of information you would like to track and why. Even if you have to comment it all out later, this stuff is worth understanding. d) Use a geolocation service to map tracked ip addesses to countries (depending on how much you are willing to spend, you can map down to a ridiculous degree of detail, esp. for visitors in north america) Finally: i had to go with the tagging solution because the client wanted a way to track "some" pages - not all. I'd still recommend it over a straight out "tell the cms to log every request to the database" approach because you can use it to track pages that aren't under the control of the cms, plus you can be sure that every logged request came from a page that was actually delivered to the client. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:235832 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
