W3Counter should be a model product for Awio going forward. It’s everything I want to be selling:

• Created in-house, so I can be confident in both selling and supporting it effectively. I have full transparency into how it works, so there’s no problem I can’t investigate and solve for a user.
• Costs, in terms of money and time, do not increase significantly with each new user.
• Operation is nearly 100% automated, and since it “just works”, support mails come maybe once or twice a month.
• Providing real value to every user. Unlike the advertising services, it’s free to try, and everyone gets something out of it no matter their experience level.
• Users love it. I’ve had a survey up after log in for over a month now, have received over 100 lengthy replies, and everyone is genuinely happy with it.
• All of these combined lead to a product that can be spread by word-of-mouth rather than paid advertising. I’ve never had to advertise the site, and new users sign up every day.

Adding ads, throwing in tons of teasers, reducing limits… these all detract from what I want W3Counter to be. I don’t think compromising on quality will convince users to upgrade. The real reason few people upgrade is because they don’t see any compelling benefit of doing so. Those that have upgraded did it because they have more than one website — tracking more than one site from an account is a good benefit, but most users only have a single site, and most sites fall within the usage limits of the free plan. The stats-by-RSS benefit isn’t something most people understand, let alone want to pay for. Only a few hardcore developers make use of the API. There’s little left being offered for that $5 to $15 per month.

So what can I give?

It won’t be more reports – I don’t want the free users to feel cheated by not having access to vital information. I want to treat them so well they fall in love with W3Counter and want to upgrade just out of thanks – if only they didn’t have to pull out their wallets. They should be on the brink of doing it at all times, such that when they check out the list of reasons to upgrade, when they see these new reasons, they’ll follow through.

It won’t be date range selectors, or bigger log sizes, or even bigger limits. The business model won’t support free users if the few paid users use drastically more resources. $5 a month doesn’t buy new hardware for that user. The benefits shouldn’t require lots of resources for me to provide, but they must provide value to the users nonetheless.

For starters, I think these two features would add a lot of value to the type of user willing to pay for a low-cost web analytics solution:

1. Export any report to CSV or Excel format. Suddenly the reports have more business value at little cost to me. They currently don’t print well due to the Flash graphs and paging, and can’t be easily analyzed outside the website. They can’t be taken offline or easily sent off to a manager for a status update. Exporting all the data for a report at once in a print-friendly, import-friendly format can provide all this.
2. E-mail any report, and schedule e-mails of any report, to any number of e-mail addresses. This could be easy as a scheduler to run the export, attaching an Excel spreadsheet to the mail. More premium users than not use the daily, weekly and monthly summary e-mails. Now they can do the same with the reports they are interested in. They can get these reports without checking the site, and other relevant parties can get reports without having access to the account or learning to use the site.

I have some other ideas along these lines, but I don’t want to talk about them just yet. Combined with higher usage limits, SSL tracking code, and e-mail summaries, I think this could make a decent feature set to target small business. The type of business without a full IT staff, without a budget for enterprise-grade analytics, and for individuals that treat their sites as more than hobbies.

Aside from improving the features and plans pages of the site to better sell the benefits, I’m thinking of doing some direct mail selling as well. I think if done right, it can come across as something unexpectedly delightful instead of a put-off. I would need to start collecting addresses from free users on signup. I’d send a letter (heavy paper, professionally designed, screenshots and all, like a printed webpage) welcoming the user and highlighting some features, including the premium ones.

I’d also throw in a couple W3Counter stickers. People love free stuff — the inclusion of the stickers can change the perception of the letter into a positive instead of a possible negative. Stickers don’t appeal to everyone, but I think that W3Counter has a certain feel to it that wouldn’t fit the type of person to be turned off by stickers in the first place. It’s bright and shiny. The stickers are perfect for sticking to a laptop lid or computer.

They serve two more purposes – continually reminding the user about W3Counter, and as a trigger for word-of-mouth advertising.

1. They’re shareable. With a handful of stickers, the recipient will be likely try to think of someone to give some to before throwing them away. New people get exposed to the service.
2. They’re a conversation starter. I don’t expect people to get super excited over stickers, but if even a single blogger were to write about it, that’s a new link and new vector for continuing the word-of-mouth advertising.

I haven’t thought this all through yet, but I think I’m on the right track with the plans. I won’t be implementing any of this until after I’m back in Philadelphia in late September. That gives me time to think of more premium features worth paying for, ways to get users to think about them, and continue building on the idea of adding direct mail to the strategy.

I start out with a couple notes — what information do I want in the screen, and an initial idea for how it should be presented. The dashboard is the first thing you’ll see after logging in to a copy of W3Counter tracking one website. It’s your overview of what’s going on today — how many visitors, how many are new, where they’re coming from, and what they’re doing. My initial idea is to have a chart area above a tabular area like the Visitors by Date report I’ve shown before. I’ll split it in half and have a pie chart for the new versus returning visitors, and another for the sources of those visits. Then, in tabular form, a list of the top pages viewed today — for a blog like this, that’d be the top posts people are reading.

I add the action to my controller, create a blank template for the page, and edit the application configuration files to add the new page.

The dashboard will have some fundamental differences between the rest of the reports in W3Counter. The date range options are different, there’s no paging, there are no modes to switch between, it won’t be exportable to CSV or XML format since everything it shows is available in detail elsewhere, and it will have two charts. That means I need to tell Symfony to use a different layout to decorate the template with than the rest of the pages, a simple change in the view configuration. I copy the date range template fragment and make a version specific to the dashboard and its three options — today, last 7 days and last 30 days.

With the new layout in place, I edit the template for the dashboard and add the area for the charts to appear, and the header for a data table that will list the most popular pages. These are all pieces I’ve created already for other pages, so it’s just a matter of including template fragments which are already encapsulated for just that purpose.

Next, I get the popular pages list up. I hadn’t created that report yet, but doing so takes no time at all. All I have to do is add a method to the database layer that pulls out that information. The rest of the work was done when I created the first few reports and refactored the common portions into reusable methods and template fragments. There’s no fundamental difference between a popular pages report and a top referrers report except the title of the page and the data in each row.

With that done, I can reuse the method I just wrote for the Popular Pages report to add the 10 most popular for the day, week or month to the dashboard.

Now to the two charts. I still haven’t made a decision on what to do about generating pie charts, but I’m leaning towards buying a license for amCharts, so I used that. I dropped their SWF and JavaScript files into my project and adjust the settings to get the desired look. I’ve broken out the sources into searches, direct visits from type-ins or bookmarks, and other sources.

I initially do the same for another chart on the left side showing new versus returning visitors. But it doesn’t look quite right. It’s not obvious how many visitors the site’s actually received that day, and even with mousing over the chart, nobody would take the time to add the two sections to figure that out. I also wanted to get across the number of page views which doesn’t fit well on the same chart.

Bars didn’t look right either because of the scale — some sites receive very large numbers of page views from each visitor. Instead, I decided to make the left hand side a text display of the relevant information. I use large, bold text to make it clear and the focal point of the page.

Finally, a few finishing touches: link the two headers to the reports with more detail, and add a link to the full Popular Pages report.

I’m sure I’ll revisit this screen several times before it’s truly ready, but I’m satisfied with it enough now to move on to the next set of reports. It’s time to start collecting data to build some of the all-new features — outbound click tracking and analysis.

I’m making good progress so far. I started out with the Symfony framework 1.0-beta2 sandbox, which is an empty project and a copy of the Symfony libraries within the project folder, meaning it can all be zipped up and dropped into a hosting environment without external dependencies. I had to make a few edits to paths in the front controller to eliminate the need for the project to reside in a subdirectory as it’s set up by default.

I then created the database schema, which while similar to the one used by the hosted version, has a couple extra tables to manage new features (such as multiple users per install, and user roles with per-website granularity), and doesn’t create new tables on the fly as the hosted version does. I let Symfony’s command-line interface take my schema definition and build a database access layer out of it, as well as CRUD screens for the objects. I filled in the routing rules and created stub methods for all the controller actions I expect to need.

While it’d be more exciting to start on the new features I want to implement to make this competitive with new services like CrazyEgg and FeedBurner’s new Blogbeat integration, I’m starting with the core functions and building up from there.

Normally interface design doesn’t come first, but I just can’t work on a project if it doesn’t look good, so you can see a screenshot above of what the interface looks like now. I fully implemented a navigation controller that builds the menu from my list of routing rules and highlights the current location. I also built some reusable components for choosing date ranges (and made use of the Script.aculo.us JavaScript library for the first time to slide-in a custom date range entry area when chosen), and for encapsulating database result sets along with paging information.

Symfony comes bundled with Propel for database access, which provides ORM mapping and Criteria based object selection. Unfortunately most of my database queries, which won’t change much between the hosted version and the new one, don’t map well to Criteria. It’d take hours and hours to try to rewrite them if even possible; they usually involve many self-joins, subqueries, and grouping. Even if I get the Criteria working, Symfony’s built-in paging object doesn’t work well with queries that involve grouping, so I had to scrap that anyway. I went instead with a custom class which encapsulates the data as a simpler multi-dimensional array with some additional information about the result set to provide easy paging.

The next step was to implement an authorization module. I started out with a plugin from Symfony called sfGuard which is supposed to be drop-in user and role management for any application, but found it wasn’t easy to adapt to what I wanted to do with per-website access levels. I removed that and wrote my own auth module; basic login/logout with cookies for persistent logins. Symfony still takes care of most of the work in deciding when to send someone to my authorization controller for login, letting me specify what parts of the application require authorization and various credentials in a configuration file.

I think my next step will be to try implementing an HTML-only charting class to use for the dashboard in the first screenshot. I can’t use the same Flash charts as I do in the hosted version as I’d need to purchase a very expensive licensing contract to distribute those (the single server license was much more affordable). If I can’t get something nice working I may have to go back to generating charts as images with the GD library as I did with the original W3Counter. They did look good, but it’s extra coding for me and rendering time for the CPU I wanted to avoid.

If anyone knows of a free, redistributable Flash chart component set, I’d love to know.