PubForge Blog

Most public media sites, even those with a strong news focus, show relatively poor overall loyalty stats, with the average visitor coming twice a month or less. The standard report segments in Google Analytics don’t give a very clear picture of what differentiates the loyal visitor, who returns twice a week or more to your site, from the visitor who beams in from a search results page and is never seen again. This makes it difficult to do testing that targets the loyal visitor.

Fortunately, this can be overcome by using the newish (still in beta) “advanced segments” feature at Google Analytics. Here’s how to create and use an advanced segment that looks at monthly traffic from the loyal visitor–one who visits the site between 8 and 100 times during the selected period (I limited the visit number to 100 on the assumption that people who hit your site more often than that are using it for a browser home page):

1. Go to your Google Analytics Dashboard
2. Under Settings, select “advanced segments”
3. Select “Create new custom segment”
4. Under Dimensions, expand “visitors” and drag “Count of visits” over to the “dimension or metric” box.
5. Under “Condition” select “Greater than or equal to” and give it a value of “8″
6. Select “Add ‘and’ statement”
7. Drag “Count of visits” over to the “dimension or metric” box.
8. Under “Condition” select “Less than” and give it a value of “100″
9. Name the segment something like “Deeply Loyal” and click “Create Segment”

Now the new custom segment can be compared with standard segments such as “All visits” using the advanced segments tab on any report page.When I applied the segment to traffic at North Country Public Radio, I got some immediately useful information:

1. Frequent return visitors account for a little over 20% of visits and of page views. This means that my loyal visitors don’t visit more pages on any particular visit than does the general visitor.
2. A little over 30% of views to NCPR’s top three pages (home, news, and listen) come from the loyal segment. So loyal visitors are 50% more likely to visit one of the top destinations than are visitors on average.
3. The real jump, however, comes with features that are visitor-contributed or visitor-interactive. More than 50% of visits to our popular Photo of the Day page come from the loyal segment. More than 40% of visits to our top blog destination come from the loyal segment. Increases over average loyalty of 250% and 200% respectively.
4. The lowest scoring pages among the loyal segment were individual story pages, with less than 10% of views coming from the loyal segment. Individual stories are primarily reached via search, or via syndicated feeds, and so are often outside our core visitorship.

These findings suggest a number of strategies:

1. To increase the overall loyalty of visitors, increase the opportunities for interaction and content contribution on your top destination pages.
2. The loyal segment is more likely to already be a paying supporter, so member messaging on the pages most popular with loyal visitors might focus on membership upgrade and referrals to other pages with interactive features.
3. Popular pages more often viewed by the less loyal could be a target for new member recruiting, content-specific micro-giving, “about the station info,” and referrals to pages related by search topic.

Dale Hobson
North Country Public Radio

Bill Haenel of Haenel Communications Technologies has added geotagging functions to the main content modules of North Country Public Radio’s custom implementation of his open-source CMS, Public Media Manager. These features operate within both the news module and the events calendar module, adding precise geocoordinates to individual stories and events, derived from text addresses entered by the content creator.

These coordinates are exported from the CMS database into the site RSS feeds in “georss:point” format. By passing the geoRSS feed address as a search query to Google Maps, the feed items can then be rendered on a Google map that will update whenever a new item is added to the feed.

Why bother?

The internet is structured to serve communities of affinity much better than it serves communities of residence. A topical search term, for example, gives you a much better presentation of relevant search results than a geographical search term does. That is in part because content creators have traditionally had much better tools available to provide topical metadata, than they have had to provide location metadata. GeoRSS can provide that missing dimension. This is of increasing importance as traditional media continue to disinvest in local reporting. Geocoding resources also add an extra dimension to content syndication and collaborations where place may be as important as topic.

Some example maps:

North Country News Map: the latest twenty audio news features from North Country Public Radio. GeoRSS feed source: http://www.northcountrypublicradio.org/topicalRSS.php

A Year of Hard Choices Series Map: All the stories in an audio series on the economic impact of the recession in Northern New York. GeoRSS feed source: http://www.northcountrypublicradio.org/topicalRSS.php?topic=hardchoices

NCPR Community Calendar Map: All today’s events from the North Country Public Radio Community Calendar. GeoRss feed source: http://www.northcountrypublicradio.org/upnorth/comcal/rss.php

Basic work strategy:

To get buy-in from content creators, the process had to be dirt simple from their end. On the news side, reporters were provided with an Ajax look-up tool as part of the story submission form. They enter a text-based address, such “Canton, NY” or “80 E. Main St., Canton NY.” This queries the Google Maps API, returning latitude and longitude for the address. These coordinates are written into the story metadata in the news database when the form submits. On the calendar side, prexisting venue addresses were converted into latitude and longitude via a bulk query to the Google Maps API and were added to the venue table in the calendar database. A tool was then added to the venue creation form that would do the look-up as a background process upon creation of new event venues. In this way, content creators were not required to enter anything but a standard text address.

Feed modification:

To exploit the new geodata, the existing site feeds needed to be modified. The feed type had to be modified to reflect the geoRSS namespace. At the item level, the latitude and longitude had to be called out in valid georss:point form. And, of course, the feed needs to be valid RSS in all the usual ways as well.

Address to geopoint “on the fly”

Why use latitude and longitude in the database when the Google Maps API can do the look-ups on the fly? This can be done in theory, but runs into problems in application. If you are mapping only a few items and your traffic is low, this can work. We found that we quickly used up our query limit (15,000 queries per IP in a 24-hour period) at the Google Maps API using this method. Once the limit is reached, Google will not process the feed until the new 24-hour period begins. The better approach is to query the API once when the content is created. Thereafter, the feed item delivers latitude and longitude, which is read without further processing. Also, the number of lookups requested by a text-addressed feed hugely slowed the rendering of the map, and would often time out before completion.

Untagged content:

We found that it was important to have a default location for when no specific location had been applied to the content. In our implementation, we use our headquarters location as the default. This way, all items in the feed have a valid geoRSS:point tag.

Multiple items at the same location:

Google Maps does not stagger map pins for multiple items at the same location. This means that only the newest item at the location can be delivered by clicking on the map. This is a practical problem for NCPR, where we might have multiple reports from our state capital correspondent all located as “Albany, NY.” This can be addressed in a number of ways. Applying different street adresses to each item will differentiate them on the map. In practice, I have been manually editing the coordinates, offsetting them by one minute of latitude or longitude in different directions. A better approach we are looking into is to introduce a random “fuzziness” factor into locations that do not have street addresses. This would provide a unique latitude and longitude to each item, exposing them as discrete pins on the map.

More information:

For stategic implementation and other topics fuzzy enough for an English major, write to me: dale at ncpr dot org. For code and other deep geek: write to bill at hcomtech dot com.