Five Hidden Gems in SiteCatalyst 15

Recently, two bright and well-trained SiteCatalyst 15 users asked me to point out some lesser-known or lesser-used features which help analysts and marketers run a really tight ship. SiteCatalyst 15 looks fairly similar to SiteCatalyst 14, but beyond the obvious platform improvements (e.g., segmentation, unlimited subrelations, etc.) it does contain a number of features that can be easy to miss but which either save users a lot of time/frustration or enhance the analysis that you can do in the tool. Today I’m going to share five things that I would advise all users of SiteCatalyst 15, both newbies and veterans, to consider trying out.

Currently, when you create a segment using the drop-down menu in SiteCatalyst 15, that segment is available only to your login. Your colleagues cannot see it, and need to re-create it on their accounts if they want to use it. However, there are actually two ways to create segments that anyone can use. This allows you, as an admin user, to guide your users to the segments that are applicable to them by pre-creating them with your knowledge of advanced segmentation. Take note that the two different methods I’m going to discuss below cause segments to be shared slightly differently.

The first way to do it is by going to the Admin Console > Report Suites > Edit Settings > Individual Report Suite Settings > Manage Report Suite Segments. A Report Suite Segment is a segment that is available to all users when the given report suite is selected.

Here, I created two suite-level segments, “iPad Visits” and “Visitors from Germany.” Once I did this, these two segments became available to all of the users of the report suite for which I created the segments. You can see them under the ” Data Warehouse” header in the segment drop-down menu:

You can also share segments with your users by creating them in Discover and placing them in a shared folder there. This will cause them to appear for all of your users in SiteCatalyst 15 across all report suites. This can be very useful when your suites share a variable mapping. If eVar1 is the same on all of your suites, then a globally shared segment that uses eVar1 is extremely handy because it can be applied everywhere! The folder structure from Discover is reproduced in the segment drop-down menu in SiteCatalyst, so you’ll likely want to use your folder names to help your business users understand the context around each segment.

2. Segment Individual Dashboard Reportlets

Of course, you can apply segments to entire dashboards, which is incredibly helpful in your analytics journey as it allows you to see all kinds of different types of data for a certain segment of visits/visitors at the same time. This is great because you might not be sure where to start learning about this segment, so you can see keywords, pages, conversion, engagement, etc. all in one place and jump into learning about the segment from there.

What you may not know is that you can also apply segments to individual reportlets within dashboards. This is great for a variety of reasons:

If your dashboard is headed out to executives or others, you can use a single dashboard to focus on a variety of segments that are relevant to your business, as opposed to having separate dashboards for each interesting segment.
It allows you to compare segments side by side within a dashboard.

There are two ways to apply a segment to an individual reportlet.

If you want the segment to be applied only during your current usage of the dashboard but not saved permanently, click on the name of the report suite under the reportlet title. You will get a grey drop-down that has the segment drop-down embedded in it. Find the segment you want to apply to the reportlet, click it, and away you go.

If you want the segment to be permanently saved to the reportlet, as the owner of the dashboard you can click Layout when viewing the dashboard. This will bring up the dashboard editor view. In this view you also have the name of the report suite showing under the dashboard title, but here when you apply a segment and click “Save,” your segment is locked in as part of the dashboard. The next time you send it out to your colleagues and executives, they’ll have a nicely segmented reportlet as part of the dashboard.

3. Learn and Use Processing Rules

As fantasy sports gurus might say, this feature has “sneaky value.” By this, I mean that many customers do not realize what a time saver Processing Rules can be, and so they end up getting overlooked or ignored. In our experience, when SiteCatalyst admins realize what Processing Rules can really do, they fall head-over-heels in love with the idea.

In short, Processing Rules allow you to make minor changes to your implementation without touching a line of code or rule in your Tag Management System. As Adam Egbert described in his thorough post on Processing Rules, “Essentially, this feature allows you to set the value of a variable (prop, eVar, or event) based on the information sent in any particular image beacon.” You can set SiteCatalyst variables based on the values of other variables, or based on other data points such as referrer, page URL, or query parameter.

I’ll quote Adam with a great example of how Processing Rules can be used:

[Let’s say] we have a page named “Product Details Page:[Product ID]” on which we want to start firing a custom success event (event3). We can create a rule to detect this pattern in the page name and place the success event there. That was easy! Again, we are able to do this entirely in the Admin Console of SiteCatalyst without touching our implementation.

I recently came across some customer feedback that is typical for those who have taken advantage of Processing Rules to avoid needing to bother IT to make minor implementation changes:

WOW! I started some rules on Monday. I’ve already made updates that would have been months of work otherwise. And capturing campaign tracking codes set by multiple external agencies is a snap. HIGHLY recommend for any other clients struggling with the same issues. . . I’m able to implement changes with processing rules quicker than I could draft up specs to have code changed. Forget about waiting to fit into a production schedule and explain requirements. We’re talking going from months to minutes for a change. Can’t put a $$$ value on that, but my budget and the lining on my stomach thanks you!

One thing to note with Processing Rules is that, because they can be very powerful—allowing you to manipulate your implementation post-collection—we do require that you certify in their use before you can access them. However, this online exam is free, and we provide all the material you will need in order to prepare. It’s well worth your time! You can get more detail on certification here.

4. Set Default Metrics in Individual Reports

SiteCatalyst has always (well, at least for a very long time) allowed you to change the default metric for a report suite. Maybe you’re a media company, or a B2B site, and you don’t track Revenue. You could choose Leads Generated or Internal Searches or whatever event you prefer.

SiteCatalyst 15 goes one step further with a feature that every company I know of should be using. Admin users can define the default metrics at the individual report level, so that in your Internal Search Keywords report, the best default metrics for you and your users might be Internal Searches (a custom event), Page Views per Search (a calculated metric so you can see how many PVs each keyword subsequently generated), and Leads Generated (so you can see how many conversions each keyword produced). Meanwhile, in the Video Name report, you might want Video Starts, Video Completes, and Ad Views (all custom events). This way, when your users log in and access these reports, they see the data that is most relevant in the context of the given report, as opposed to be limited to the same metrics across all of the different data dimensions you’re collecting.

To do this, simply add the metrics you want to set as default in whatever report you’re viewing. Then click the arrow next to “Add Metrics” above the metric column headers in the table, as shown, and click “Set as Default:”

This will lock in the selected metrics (in this case, Visits, Unique Visitors, and a calculated metric called Time Spent per Visitor) for all users of this report, in this report suite. Only admins can set default metrics for a report, but it’s also worth noting that any admin can make this change for all users. This means that if another admin wants different default metrics for everyone, he/she can do that. I advise sending out a note to all of the SiteCatalyst admins on your account whenever you set default metrics, so that everyone is clear.

“Just Say No!” to irrelevant reports. Set your default metrics today.

5. Use SAINT With De-Duplicated Visits, Unique Visitors, and Orders

My final “hidden gem” doesn’t involve any interface changes, per se, but it’s a platform feature that allows you to get a lot more bang for your buck with SAINT classifications. In previous versions of SiteCatalyst, if you had two individual line items that rolled up into a SAINT classification category—let’s say, Product A and Product B both rolling up into Product Category 1—SiteCatalyst would simply add up the number of Visits, Unique Visitors, or Orders for Product A and Product B. But that isn’t always correct, because sometimes an order includes both Product A and Product B—but this isn’t two orders for Product Category 1, right? It’s one order! Here’s a diagram that might be helpful:

Now that SiteCatalyst 15 “de-duplicates” these metrics, you can rely on SAINT to do all kinds of things that might have previous required implementation and additional variables. The example above illustrates this perfectly. If I needed to know how many orders belonged to Product Category 1 with no chance for duplication, I would have needed to implement an additional variable to track the category so that multiple products in the same category would not cause multiple orders to be counted by SAINT.

In SiteCatalyst 15, a single variable can fill out a whole tree of SAINT classifications without fear of duplication in these metrics. For example, if you don’t have a tremendous need for pathing on site sections, you can do page, site section, sub-section, sub-sub-section, sub-sub-sub section, owner, category, and more, all based on the s.pageName variable, and you’ll know that the Visit and Unique Visitor counts are accurate even if users hit multiple pages that roll up into the same sections, owners, etc.

If I were doing a new SiteCatalyst implementation today, and I were on SiteCatalyst 15, I’d use SAINT heavily and reduce my reliance on disparate variables populated via JavaScript or VISTA (or even Processing Rules!).

Conclusion