Practical tips for Nedstat segmentation
This post appears to have been deleted when I recently had to reinstall my blog - here is a new copy of it.
Nedstat released its new upgrade to Sitestat, a segmentation tool, three weeks ago now. It provides the ability to filter any of the standard and custom Sitestat reports using any of large range of variables, either individually or in detailed combinations. However the big question is how to go about integrating this new tool in your web data analysis. Top analysts have probably already found a million and one uses, for most people though I would recommend starting with small steps and extending this over time.
Save some basic segments
When I first started playing with Segmentation, there were some basic filters that I wanted to try out. These are filters that I can imagine everyone, regardless of the type of website, will want to apply to many of the reports they look at, both in their regular and ad-hoc reporting. While it only takes a few seconds to set up each of these filters, setting them up once and saving them means they are very easy to use in the future. They can then be applied to the whole report or an individual report item.
The key filters that I would recommend setting up as pre-saved segments are:
- Each of your traffic sources - direct entry, organic search, external referrers, paid search, online display, email, affiliates (note that different traffic sources will require you to use alternative filters options in order to be set up)
- Type of visitor - either new or returning
- Location of visitor - keeping this simple, just UK and non UK.
- Level of visitor usage of the website - this could relate to the number of visits per visitor or the number of pages viewed. It should be set up for light and heavy users and will require you to define these levels.
- Visitors who bounce - possibly the light users above, this should be users who only viewed one page. Although a better option might be to also combine with the filters for new to the website and/or only made one visit.
Remember that Sitestat segmentation is based on visitors and therefore some of these segments will only be indicative rather than absolute. For example, the segment for paid search will include all visits and pages viewed for these visitors during the defined time period, not just data for visits from paid search.
Comparing website performance for different segments
The first way I started using segmentation was to look at a single report item across the whole website and then for various filter options. A great example of this would be to look at the browse to buy rate for alternative traffic sources in order to understand the effectiveness of your online marketing spend. Other report items that I would find it very interesting to compare across different traffic sources include the frequency table reports (visits per visitor, page views or duration per visit) or navigation reports (funnels and click path explorer).
Create a report containing the single report item but do not create any segmentation filter to be applied to the report. Copy the report item multiple times, once for each segment that you wish to look at - this would mean pressing the copy button five times if you want to compare direct entry, external referrers, natural search, paid search and display advertising. Then by editing each of the copied report items, apply a different segment to each one.
This report now displays a single metric that can be compared across multiple segments and indexed against the performance of the website as a whole. For ease of reading, it can be transferred across to excel. I can imagine managers would appreciate a simple excel table that contains the performance of the predefined website KPIs for the previous month indexed across traffic sources.
Successful Visitors
A blog post that is currently only half written in my head will deal with the concept of successful visitors. It will deal with the idea that what we should be trending and reporting on is only successful visitors/visits instead of all visitors/visits as most people would do currently. This would eliminate visits where the visitor simply bounces and ideally all visits where the visitors was actually not really interested in your website. There should then be a clear correlation between the number of successful visitors in a week and the success of the website during that week as defined by conversions or revenue.
But that is all for a future post.
In the meantime, just putting it simply, it could be worthwhile creating a couple of more complex segments that approximate a successful visitor for your website. This could be a visitor who (for example) visited at least 3 times, viewed at least 6 pages during a visit, viewed the ‘contact us’ page and/or downloaded a PDF. This segment should be refined over time but it would be interesting to look at the percentage of website visitors who are acting like you would like them to. More on this in the future.
Save both the report and the segment
Something which tripped me up a couple of times at first is that the segment that you have applied to a report needs to be saved separately to the report in order for it to be applied to the report the next time it is opened. Also, if you are saving in the report in the shared folder (e.g. so that it can be shared with a colleague), the segment must also be saved in the shared folder for segments. Given this, if you do set up a set of standard segments as I recommend above, this should be done in the shared folder.
Using the AND/OR options in segmentation
The default option within segmentation when using multiple filters within a segment is AND. This means that all conditions must be met in order for the data for that visitor to be included in the report. In order to switch this to OR, the desired filter should be dragged within the boundary of the other filter. Try playing around and you should get the hang of this pretty quickly. However it gets a little more difficult when setting up complicated segments.
For example, a segment that looks like (a OR b) AND c AND (d OR e) is quite straight forward to set up. But a segment that is (a AND b) OR c OR (d AND e) cannot be done within the one operation. The workaround for this is to first create and save two segments, one for a AND b and the other for d AND e. A new segment can then be set up that is ’segment 1′ OR c OR ’segment 2′ using the filter option for include segment.
Using the any/all/first/last options in segmentation
This option is relevant for the many filters that relate to visit level. Examples include the different traffic sources, made a purchase, viewed a certain page, etc. These are all options which a visitor could do in one visit to the website but not in another. You have the option of choosing whether visitors need to meet this criteria during any visit to the website during the selected time period, during every visit or during a specific visit. The default is any visit but the option you select really depends on the business question that you are trying to answer through creating this segment.
The first and last visit options could be very relevant for attributing revenue or conversions to alternative marketing campaigns. The all visits option can be useful in viewing data only for visitors that always perform certain actions. But I imagine that most of the time you will simply leave this as any visit.
Note again that this criteria is used for selecting the visitors whose data will be included in the report. Once the visitor is selected, all of their data will be included regardless of whether any or all is used.
The logic for this may seem fairly straight forward at first. However once more than one filter has been included, it can get a little tricky. It increases in difficulty with multiple filters, combining AND and ORs, combining any visit and all visits and also through using the DID NOT option. If a detailed segment will help in answering a business question, then do go ahead and create it. I just recommend being careful, possibly reading the segment out aloud as a sense check, in order to avoid misinterpreting the data that you have produced.
Tags: Nedstat, Segmentation, Sitestat, Traffic Sources

Thanks for taking the time to write this. The tips on basic segments are especially useful. I’m currently using Sitestat for the first time at a large UK public sector org and I’m pretty sure segmentation reports are being used incorrectly here.
Foreign language versions of a page are tagged with the same sitestat counter as the English language page, differentiated only by a ‘?category=…’ string. This is used to create a segment to get metrics for the foreign lang pages, but of course because segments are based on visitors, results include all the pages visited by those visitors, not just the foreign lang versions. Doh.
Any thoughts? How should it have been done? Cheers, Rob
Hi Rob,
It all depends on the question you are trying to answer. If you would like to know the behaviour of visitors who look at foreign language versions of pages, then that segment is fine. However if you want to know the number of foreign language pages viewed, the segment will not give the correct answer.
In this case though, I don’t believe you need to use a segment as you are using the standard Sitestat variable of category. Assuming my memory serves me correctly and I will check tomorrow, there are a number of standard reports built around this variable which will provide all the information you need. Try doing a search in the report list for a report ‘page views by category’ - I think it is there and it will provide exactly what you need.
Cheers
Peter
I hadn’t noticed this amongst the standard reports, and had high hopes. But the Visitors / Visits / Page views per specified category only returns the overall count of Visitors / Visits / Page views as a single number.
What I really wanted was the breakdown of Visitors across all my (e.g.) category=Arabic pages. Humph.
The data must be in there but I think a custom report might be necessary to get at it. And I have about 200 sites we’d need to get custom reports for…
Many thanks anyway,
Rob