With an ever increasing number of people going onto version 15 of SiteCatalyst I thought that it would be a perfect opportunity for me to write a blog post about segmentation, which is the major functionality improvement. It looks like it is something that should be easy to do, but if you follow my easy instructions below, you'll get the best out of it. Remember, the data you get from it is worthless if you don't do anything with it!
1. Page Views Based Segments
It seems to make sense to start with page view based segments first, because they are the lowest denominator in the world of web analytics.
But in the case of segments, I find these things the most difficult to deal with and I'll try and explain why in the hope that it will make it easier for you to understand, as perverse as that sounds.
The main reason that I have trouble with page views based segments is that I can't really relate them to visits, which is the metric that I use most frequently, but I think I have some diagrams that will help explain the situation:
I'll explain in a minute how to create the segments themselves, but lets get our heads around the values first. Your segment only includes a subsection of all the pages on your website. The visit and visitor do not get counted unless they land in your segment. This has a couple of implications:
- The entry page to the whole site may not be in the segment, so the segment's entry page will be the first page in that segment that the user arrives at
- This also means that the referrer when the user does eventually get to a page in the segment is going to be from an internal source (not the original entry source)
- The user may leave to pages outside the segment before returning - in pathing reports SiteCatalyst will not represent the leaving part
- The exit page to the whole site may not be in the segment, the exit page of the segment is the last page the user viewed in their visit in that segment
- A visitor may have visits to the site which don't touch the segment affecting the visit number reports - a New Visitor is only new to the segment
- Creating a defining rule to show a number of pages to include (or exclude)
- Creating more than one defining rule to show a number of pages, of which the rules have overlap
- Creating more than one defining rule to show a number of pages, some of which may not have overlap
- Use greater than and less than for numeric values
- Contains, starts with and ends with are great for situations where you want to do a search type filter
- is null is great for situations where you can't work out which pages don't have certain tags
Visits based segments are much more intrinsically obvious. You deal with them all the time in the world. There the staple of Google analytics segments, so I won't dwell too long on them.
However there are some things that you should know about them. If you create a segment based on visits, then it will include the whole visit, not just from the point of that it qualifies for the segment.
The other thing to note is that this may affect the way that your conversion reports work. If your conversion report is set to a length of time different to a visit, then it's possible that your reports may be slightly misleading. Remember that in conversion reports, the value of the conversion is related to the time of the event, not of the time the value was written to the report. So you could have a report that is showing you values from previous visits in your report, if you event is included in the segment.
For example, my segment could be people who viewed the home page. But I didn't view the home page on my first visit when I came through a campaign, so my first visit isn't included in the segment. In the second visit, when I am included in the segment, my conversion on my campaigns report, set to 30 day time out, converts against the campaign from the first visit.
3. Visitor Based Segments
Visitor based segments work in a similar way to visit segments, but instead of including just the visit, they will include everything that the visitor has done. This leads to some interesting scenarios:
The visitor might have done the action that puts them in the segment during the time period of the report. For example I set up a segment for people who have bought one of my products as a visitor segment. If I am looking at a report for December 2011, it's possible that I am looking at visits and visitors where they bought that product in January 2012.
It's also worth remembering that the rules for the custom conversion reports still hold - if you create a visitor segment based on the value in one of your eVars, but the time out for that report is set for visits then subsequent visits by the visitor will convert against the value for that visitor.
This has some good effects. If you create a segment for people who come to the site through Facebook, you can look at the referring domains report to see what started the visit that actually caused the conversion. Don't forget that this visit from Facebook could have been after the conversion.
4. Event based variables
You can also add events in as your containers. This sounds a little odd, but remember that you can set events on any pages (or on clicks) that you like, so creating something that only shows when the event occurred could make sense, although it does bring us nicely into the next section...
5. Combinations of the above
Event based segments only really work where they have one of the other three containers involved first. You can add a container that is for visits and then specify that the only visits you want are the ones where they had an event in them. This is great for looking at just those that bought something or those who signed up to emails and so on.
Obviously you can also have visitor segments which only look at particular visits or particular pages and you can have visit segments that only include a number of page views.
However they don't work the other way around, you can't specify a subset of pages and then say only give me visits who came from search engines. Follow the heirarchy and you'll be fine.