Web Analytics

Customer Relationship Management (CRM) is an indispensable piece of infrastructure in the effective management of prospect and customer information in any organization. With the advent of Internet marketing, there is a vast amount of information collected about prospective clients, or existing clients to whom services are sold and delivered using the Internet.

Considerations for migrating to Drupal from a static website or other CMS

Web Content Management Systems have unfairly been blamed for killing traffic by compromising Search Engine Ranking as a result of the so-called Search Unfriendly URLs. to properly migrate a well-indexed static website to Drupal or any CMS without compromising your ranking, it is necessary to maintain existing paths. In my opinion, using a good CMS has so many advantages that the misplaced fear of machine URLs (no-longer an issue with mod_rewrite and ISAPI Rewrite).

Advantages of using a CMS

• Findability of content in development and production - Even the meticulously organized and labeled static folder structure can leave one wondering where his/her content is located; and just because you know where your pages are does not mean that your visitors know your structure.
• Automation of routine procedures - it's a life-saver when the schedule automatically publishes and archives content for you, especially when it's time-sensitive (events, announcements, press releases etc)
• Although server-side includes SSI may seem like they make it possible to create one piece of content and reuse it in multiple places, Web CMS makes it possible to add logic to the locations where you would like the content to appear

These and many other smaller advantages that one discovers while using a CMS have the potential of improving your SEO efforts (when properly used) by availing related content and links along with certain pages. Also, CMS make it possible to track content accesses at a granular level that regular logs cannot provide. As such, here is what I propose when migrating a static website to Drupal:

1. Clean URLs: This feature is indispensable in making sure than even legacy search engines can access and index your pages
2. GsiteMap: Google Sitemaps make it possible for site-managers to guide the way that google indexes pages on a website by providing priority guidelines. When using a WCMS, content is created and manipulated (published, archived, accessed) in a very dynamic manner that availa a virtually limitless linking structure. This makes it very difficult for you (the site owner) to create a list of documents in XML and submit the file to google on a regular basis. This module will ensure that google is informed of your (healthy) constantly updated website and any new pages you publish as well as how to find them. In addition, the WatchDog module in Drupal can log all the times when google visits and indexes a page.
3. URL aliases: This feature in Drupal enables you to control the path-name of your pages thus enabling you to recreate already indexed static paths in your new CMS so that search results continue to point to your content in the new CMS home.
4. Click tracking: I am the kind that constantly monitors traffic and wants to know what's working ad what's not, so by using this nice module, I can track upto 10 channels to know which traffic sources are bringing in the most traffic, and comparing these numbers as well as results from the tracker and browscap module, you can establish what is causing a perceived increase or decrease in traffic instead of guessing.
   
5. Even without the click module, Drupal Tracker logs the referrers and will tell you who is bringing in the most traffic. Compare this with your past server-logs and you will not only be able to know the traffic sources, but also which pages are popular.
6. PHPOpentracker: As tricky as it can be to properly install and configure, this application can show you exactly what paths your traffic is taking thereby helping you decide what pages need help/updates

Cookies written using Javascript is a technique that enables a wensite owner to store information about a given user for submission in a form, or so manipulation at a later browsing session by the same use. Being that cookies are stored on the user's machine (client-side), they do not present a fail-safe way to handle information, but they are essential in accomplishing this task in situations where the web programmer does not have access so server-side programming and scripting plateforms such as ASP, JSP and PHP (just to mention a few).

AWStats is a powerful and free website log and metrics presentation and analysis tool that enables website owners and operators to get both a summary, and a detailed view of traffic origins, demographics, and destination pages.

Having installed all the basic infrastructure for a WAMP web server and a WCM system, it is necessary to have a tracking tool that can aid in the interpretation of the log file(s) that Apache generates and make meaning of the numbers so as to swiftly and accurately make decisions relating to content management and Web Marketing.

An impressive candidate for this task is AWStats. It is swift, web based and very detailed in addition to be being a frequent choice for reputable hosting companies. The fact that it's free does not hurt either.

Requirements
Perl/CGI engine
Web server (Apache 2.0.55 in this case)

Perl/CGI Engine
This is made possible by installing ActiveState Perl for Windows. It will detect both IIS and Apache and make some recommendations on how to configure it. That task is straight-forward and show work as explained. Please remember to restart your server OS and Apache so that the %PATH additions will take place and Windows will know where to find perl.exe. Also, you may be prompted to add an ISAPI line in the IIS configuration so that IIS can know what to do with *.pl files (just the same way that we did for PHP installation). This may sometimes be done automatically, but it does nto hurt to check and make sure that IIS is configured to refer all *.pl requests to the Perl.exe or other perl engine that you choose to point to. I say 'other' because the installation of Perl provides you with several CGI engine-files.

AWStats Installation
The automated installation will place the application all all kinds of places. To maintain control, since this is not an application that needs to add registry keys, all you need to do (I make it sound so simple) is to make sure that you make adjustments to the config file that refers to the web server you want to track.

Make sure that:

- You modify the CGI reference at the top of the 3 *.pl file sin the awstats/cgi-bin folder to that they can properly reference the Perl engine.

- The references to the log file is done properly without the # at the beginning of an absolute path to the Windows file system

- Since Windows does not have cron-tab by default (Here is how to implement CronTab in Windows), it is smart to make it so that updates can be done from CGI/web view (if the log file is large, this could cause timeout if not done often) so modify the config file to enable an update button in the view.

If you need step by step detailed instructions, please comment on this entry and I will be glad to walk you though or drop me some feedback.

Restricting Access to Metrics
This can be accomplished by restricting the IP addresses or block of IPs that have access to scripts in AWStats from Apache as explained in this post.

403 errors on Perl *.pl files
This small problem can sometimes lead to a whole lot of hair-loss; at least for me it took about 3 hours of configuring and reconfiguring every line in apache before I remembered that I had previously moved the WCMS to the root folder and the relevant .htaccess file with it. This particular .htaccess file has a line in it blocking access to *.pl files along with other application-only files such as *.module, *.inc, *.sql etc. Much as .htaccess files are meant to help secure applications, if you do not pay special attention to seek them all out and modify them, you could spend a lot of time reading configuration manuals. The silver lining in all of this is that I now understand the configuration of Apache for perl much better and I got to read some good documentation.