Posts tagged analytics

Revisiting web stats for the California Food Stamp Guide

Part of its ongoing “Safety Net” series, this morning’s New York Times features Once Stigmatized, Food Stamps Find Acceptance, a story about the increasing demand for food stamps. In an earlier article, the NYT published one of its peerless national maps illustrating food stamp usage across the country. (“The number of food stamp recipients has climbed by about 10 million over the past two years, resulting in a program that now feeds 1 in 8 Americans and nearly 1 in 4 children.”)

This historic escalation is reflected in the web stats for the California Food Stamp Guide. A year ago, we drew attention to how the usage patterns at the FSG were a sign of the economic times. If so, then it has only gotten worse. Since then, as illustrated below, current Google Analytics for the FSG show monthly visitor sessions have increased to nearly 10,700 (a 52% increase), with over 101,000 page views (a 27% increase) and a bounce rate of only 0.25%. Annualized, this increase in the monthly usage rates of the FSG comes to more than 128,000 visitor sessions and 1,216,000 page views.

"A List Apart" search / usability trifecta

Search is nothing new but it is, paradoxically, the new new within some circles of web design and definitely a core element of any sensible usability construct for web sites and web applications. On that note, A List Apart, the New York Times of web design, today publishes a search cum usability trifecta hitting on several issues I will be alluding to during the upcoming TIG conference, including what to make of your metrics. All the articles are read-worthy:

Web traffic as a sign of economic times

This is a web metric that tells us, on the one hand, we are doing something right but, on the other, reflects how grim things are out there.

It’s like this: Two months ago, in a different context, we observed that traffic at the California Food Stamp Guide seemed to have reached an annualized plateau of about 54,000 visitor sessions and 570,000 page views. Pretty much what we were expecting based on our experience with traffic at the earlier version it replaced.

That was then. This is now: Traffic at that site has escalated dramatically in the last two months, to 7.000+ visitor sessions with 79,000 page views, per month, which annualizes to 84,000+ visitor sessions and now approaching a million page views, at 948,000+ page views per year:

Translation: In the last two months, there has been a 55% jump in visitor sessions and 66% jump in page views. And the bounce rate now falls regularly below 1%, hovering around 0.65% most days. More people are finding it and sticking to the site.

What’s going on? During this more recent 30-day period, illustrated above, 86% of the visitor sessions were driven by 3,841 different keyword searches (the proverbial long tail). People have always been looking for help getting food stamps. But a whole lot more are now out there looking.

Google love comes to FeedBurner

It is now official: Google has acquired FeedBurner. Whew, are we happy now that we have wallowed so purposefully all these many months into using FeedBurner for tracking all the LSNC feed content, while also working our way deeper into Google Analytics. Major FeedBurner synergy here, people.

Object lessons on capturing race data

A few weeks ago I was helping out with an in-service Pika CMS training for one of our special programs, and the experience was a sharp reminder of what has surfaced at all such trainings in the past, namely, how frequently and persistently all of us (myself included) misunderstand, misinterpret or are simply confused about the categories commonly used for tracking client race and ethnicity. I have written earlier about the threshold problem of client self-identification and how the data you get is directly affected by how it is solicited; and the related need to re-calibrate the institutional view of race and ethnicity data to conform to Federal funding requirements, to assure the data categories are understood as they are by the Census Bureau. The following is not an apologia on behalf of the Census categories. It is more a statement about the realities that intrude on organizations that select to track racial and ethnic data based on the client’s self-identification rather than the organization or its funding sources defining it.

Here’s what happened at the recent training:

It was my responsibility during the training to explain why LSNC had changed how it records race and ethnicity. The brief history lesson for the trainees was that the Pika defaults, like our prior case management system, were configured to track client race data using four long-used specific race categories (white, black, native american, asian/pacific islander), plus two additional generic catch-alls (multi-racial and other). I explained that, while these categories are still commonly used, even if incorrectly by some federal funding sources, they are not properly calibrated to conform to current Census race categories that have been in place since the 2000 Census. Among other things, the Census Bureau dropped “multi-racial” as a survey selected category years ago, instead opting to allow the individual to self-identify with one or more of the six Census-defined racial categories. I also explained that the Census Bureau categories include an all encompassing demographic view of the world such that all persons are either Hispanic/Latino or non-Hispanic/non-Latino. It took a few moments for the gathered crowd to wrap its collective head around these concepts, but at this initial level of abstraction no one voiced any concerns or confusion. They understood the basic but familiar racial categories, even if the particular labels had changed slightly, and the dichotomy of Hispanic/non-Hispanic made sense.

So far, so good. Then I walked them through how LSNC had redesigned the fields for tracking this information, with the initial question to the client being broader, i.e., whether he or she identifies as Hispanic or Non-Hispanic, followed by a more specific racial identity question, relying on the six basic Census categories:

OK, still so far, so good. But then we all danced our way, at times somewhat gingerly, through LSNC’s Pika CMS Race and Ethnicity Quiz-o-rama! Admittedly, several of the quiz questions are intentionally tricky, to challenge folks about their perceptions. And there was the rub. Without getting too much into particulars, several staffers were startled to confront what they assumed incorrectly (in terms of Census definitions) to be the racial or ethnic identity of some of their clients. And some were visibly uncomfortable with how some clients may self-identify. For example, for some it was news that some Latinos identify as “white.” Or that clients from two bordering countries like Iraq and Iran may or may not self-identify as “white” or “asian” or both, or even something else (“other”). And then there were the inevitable funding-driven concerns, along these lines: “Wait, you mean if a client from Morocco identifies herself as being Hispanic and/or white, we can’t record the person as African-American? But our funding source really wants to see that we’re serving Blacks/African Americans.” I answered, “Not if the client does not self-identify that way.” Not a popular answer, with some. And an instructive example of how organizations are prompted to perceive clients within categories driven, if not explicitly defined, by a funding source.

The problems with tracking racial data are compounded by the failure of many funding sources to catch-up with the prevailing Census race and ethnicity categories. I use here an example familiar to LSC-funded programs, but not to single out LSC. It does what a lot of funding sources currently do, including the California IOLTA program. But it is a good example of how race and ethnicity data can get muddled by confusing Hispanic ethnicity with the basic racial categories, however labeled.

Take a look at this example of the LSC Form G-4(a). Every LSC-funded field program has to fill this form out annually:

The problem with this form is that it demands totals of data categories that are of a different type, i.e., it lumps “Hispanic” ethnicity in with all the other categories which are racial, as the terms are understood by the Census Bureau. Tallied in this fashion, one cannot possibly get a statistically accurate total. Why? Because even if the first two categories (white and black) excluded those who identify as Hispanic, the three other racial groups (native american, asian or pacific islander and other) do not. And those groups are not Hispanic because…? Who says so? And if you say they may be, then if you total the “Hispanic origin” data with these three same groups, you are double-counting, no?

How should this been done properly? Take a look at HUD’s Race and Ethnic Data Collection Form (HUD Form 27061):

The difference here is that the form asks for numbers that correspond to the basic Census racial categories (or understandable but consistent variations of them) in the second column, but then parses out each of those rows with a third column to identify how many of each presents Hispanic/Latino ethnicity. Easier to understand. Consistent with the Census definitions and demographic data. And statistically accurate.

It is precisely that type of argument I am now making to varied funding sources, including most of our seniors funding grantors, to resolve inconsistencies between us and them and among themselves about the race and ethnicity data they demand.

Working for the weekend

A typical result, via Google Analytics, for top-level content traffic at the LSNC.net main website. The site flatlines every weekend.

Whatever happened to 24/7, people?

Graph of weekly traffic for LSNC.net

Props to FeedBurner for explaining stats

When a feed subscriber stat is reported back for your site by FeedBurner, what does it really mean? Well, the FeedBurner folks earn props this week with a helpful, detailed post explaining how to better interpret the feed stats they provide: FeedBurner’s View of the Feed Market. As the article explains, it’s all about engagement.

Getting collaborative with DataPlace Groups

DataPlace, one of our favorite web-based GIS mapping and data analytical sites—with a national scope to boot—raised the bar today with the beta debut of DataPlace Groups. This is one very major, expansive collaborative feature-set upgrade to the DataPlace interface. You need to register (for free) to tap into it, but it offers the type of collaborative tools that are becoming more common with web-based applications. Managing and collaborating on a map or data project within DataPlace groups is not as simple and intuitive and user friendly as say, Basecamp, but then Basecamp does not even begin to attempt anything as complex as DataPlace does. So, there is more of a learning curve but you can now do a whole lot more with others on mapping and data projects. Very, very impressive stuff.

GIS for the people, people!

A tip o’ the hat to Jen Flory, Skadden fellow at the Western Center on Law and Poverty, for the heads up about Group Maps City Access to Healthy Foods, an NPR story on how GIS mapping has been used to dramatic effect by advocates in Philadelphia to show that “people in poor neighborhoods need more places to shop for healthy food.” One eye opener for us was the history lesson revealed in the story: “Mapping” is anything but a new idea for advocates. “In the late 1890s, the civil-rights pioneer W.E.B. Du Bois created a map of houses in a narrow strip of central Philadelphia. The map showed houses where African-Americans lived, highlighted and color-coded to indicate their class.”

Diggin’ data with Google Analytics

And since we’re on the topic of how diggin’ data is so cool, there is a helpful two-parter, Google Analytics Part 1: Getting Started with Site Tracking and the follow-up Google Analytics Part 2: Examining Analytical Data, both freebie articles at Community MX. It’s pretty basic but informative stuff, and includes in part I useful bits about the scripting options for using Google Analytics to track static and dynamic PHP sites, ASP pages and JavaScript events, and in part II what to make of the data you get. (At LSNC we have been using Google Analytics for several months now, and have found it to be a very stable, reliable and quick-loading web-based analytic tool.) A few months back, we posted an item about outsourcing your web statistics, which included tips on how to use Google Analytics with your WordPress and MediaWiki installations. Community MX is a subscription site for web developers, with a heavy emphasis on the Dreamweaver market. The freebie articles posted there are, of course, teasers to get you to buy in. But Community MX regularly posts a lot of high-quality free articles that you may find helpful. Well worth the perusal.