Introducing Sueetie Analytics Page Rules

I’m excited to start working on Site Analytics Page View Reporting thanks to Page Rules, the final step in managing page logging and now part of Sueetie Analytics.  Page Rules eliminate redundancy and enforce consistency in Sueetie Analytics Page Urls and Titles. 

I didn’t anticipate all of the attention I’d be giving to data gathering in an Analytics Module, but it’s really an interesting study, focusing on all of the aspects of site access and url generation in a Community Website like Sueetie.

Page Rules started as business logic in preparing a RawUrl for logging.  I knew when I started writing the Logging Prep code a few days back that I would be refactoring it as a UI configurable management tool.  The result is Page Rules, and when you look at its affect on request logging, it’s a powerful tool to ensure data integrity of the Analytics Reporting coming up.

Below is the newest Sueetie Wiki How-To on Enforcing Consistent Analytics Page Urls and Titles with Page Rules.


Data Integrity Insurance with Page Rules

You’ve heard me say it before, Data Integrity is a very big deal in Sueetie Analytics. To provide accurate site analytics reports we need to ensure we’re capturing accurate data. We also want to eliminate redundancy in  our analytic logging data. Page Rules gives us the ability to assign a single page url to multiple variations of the same url. Rules also provide a means to assign a more descriptive title to pages which have duplicate or generic titles.

What Bad Data Looks Like

Let’s start by looking at some bad data, without any page rules applied. An easy example for understanding page rules would be the site login page shown below. A Page Rule has three elements: Url Excerpt, Recorded Url and Page Title.  Thus, the Page Rule for the Login Page would be [any page with the excerpt of] "/members/login.aspx" [would be recorded as] "/members/login.aspx" (removing any returnUrl query string), and [have the title of] "Login Page."


Another example of applying a Page Rule would be the Forum Post Message Page. This is what is looks like in the Request Logs without any Page Rules applied.


We don’t need to record every unique Post Message Url, or even display the title of the post message. We are gathering that data in Sueetie Analytics elsewhere. So we’re going to apply to Page Rule to Forum Post Messages Pages.

  • Url Excerpt: /yaf_postmessage.aspx
  • Recorded Url: /util/misc/yaf_postmessage.aspx
  • Page Title: Discussions – Post Message

"/util/misc/yaf_postmessage.aspx" is a dummy page, used for consistency and giving us the ability to add the page later. Using the actual /forum/yaf_postmessage.aspx without the required query string would generate an error. Applying this Page Rule to Forum Posts keeps our Request Logs smaller, report generation performance faster, and our analytics reports cleaner.

Page Rules Management Page

Here is the Page Rules Management Page in Sueetie Analytics. The list of existing rules is at the top of the page, with the ability to edit or delete, followed by the Create Page Rule form at left and a Clear Page Log form at right to remove discovered redundant urls from the Request Log. At bottom are Request Log Pages for review.


A Closer Look

Here’s a closer look of the Page Rule list and Create Page Rule form.


Final Takeaway

A good way to look at Sueetie Analytics Page Rules is that they serve to eliminate redundant pages being stored because their query string varies. These pages are generally utility pages like search pages, or pages listing non-specific Sueetie Content (a list of Forum Topics as opposed to a single SueetieForumTopic Content Item.) Page Rules remove query strings that serve no value and cause unnecessary redundancy and dilute analytics results.

Article written by

A long time developer, I was an early adopter of Linux in the mid-90's for a few years until I entered corporate environments and worked with Microsoft technologies like ASP, then .NET. In 2008 I released Sueetie, an Online Community Platform built in .NET. In late 2012 I returned to my Linux roots and locked in on Java development. Much of my work is available on GitHub.