From Web Analytics to Business Intelligence to Analytics

Posted on by
2

Right now, there is a shift happening in how organizations see Web analytics. This shift is part of the maturation of data usage within organizations. Before Web analytics, many organizations had investments in business intelligence (BI) solutions and technologies. Then, the Web came about, and dedicated Web analytics companies (WebTrends, Omniture, CoreMetrics, etc.) sprung up to quickly address these new data and reporting needs.

With the existing capabilities to handle large data sets and provide custom reporting, traditional business intelligence solutions really missed the boat. All they needed to do was figure out how to collect and store the data. But now is their chance to catch back up as organizations begin realizing that the Web is just a single part of the puzzle.

In order for this to happen, business intelligence solutions (Microstrategy, Cognos, Business Objects, etc.) need to develop competing offerings that allow organizations to quickly hit the ground running, with the goals of:

  1. Integrating Web traffic data into their solution from existing Web Analytics players (as mentioned above)
  2. Capturing Web traffic data and storing it in a raw form with a proper database
  3. Selling reporting solutions and visualizations that immediately address the shortcomings of “canned” Web analytic solutions.

In addition to the traditional BI providers mentioned above, there are now reporting-focused solutions such as QlikView and Tableau that enable organizations to quickly drop a visualization and reporting layer/solution on top of a, existing data source. So, once an organization can figure out the data collection and storage side of online performance (no small feat of course), these solutions can surpass the canned reporting limitations of the traditional Web analytics providers.

I’m not trying to say that anyone should leave Web analytics for BI here (in favor of one over the other), but what I am saying is that this is the time for organizations to consider how important it is to integrate Web analytics data with other data sources, what they could do if they owned their own data, had ready access to the raw data, and were not limited by “canned” solutions. The line between Web analytics and BI is starting to blur. If the choice were mine today, this is the approach (simplified of course) that I would take as the owner of analytics (not Web or BI) within an organization as we head into the future :

  1. Acknowledge that the Web is only another source of insight
  2. Collect and store my own data (I’m very intrigued by Pion as a collection tool)
  3. Deploy a reporting solution where I could create any visualization or reporting needed by business stakeholders (QlikView and Tableau could do this once you’ve solved the data storage side of things)
  4. Socialize reporting, analysis, insights and recommendations. Make analytics and knowledge sharing collaborative (again, QlikView and Tableau can facilitate this)

As an analyst, why would you not want access to raw data and the ability to create your own reporting and visualization solutions? And, you are no longer limited by the reporting and data integration capabilities of a “canned” solution that tries to do the collection, storage and reporting within a single environment.

This is all easier said than done of course, and could be more expensive than the “canned” solution. But, there are trade offs to be made in which ever direction you head. Will you sacrifice greater data integration, data ownership, and collaboration, or will you sacrifice the safer, easier to implement, solution? The decision is yours to make, but make sure that you weigh both options.

Digital Analytics Tools Aren’t a Strategy

Posted on by
2

What is your digital analytics strategy and how does it help your business achieve success?

Hold that thought until the end…

You’ve got some great analytics solutions in place that measure digital marketing performance (online sentiment, digital marketing automation, site optimization, site performance, digital customer experience, etc.), right? And I’m guessing that you might also have some great documentation that details how these solutions are implemented and maybe even what they’re measuring. But it has been my experience that most organizations consider this their digital analytics strategy. A tool is a means to and end, not a strategy in and of itself.

This is putting the cart (digital analytics) before the horse (that strategy that should pull the company and your digital analytics efforts in the right direction).

Additionally, once a tool or technology is put into place (even if there was a strategy beforehand), we often see that it is used to simply measure and report on the number of times things happen and what things are happening most frequently. At a strategic level, companies aren’t looking for an digital analytics strategy that simply measures the number of times things happen. Companies need a digit alanalytics strategy that will provide answers and provide recommendations that specifically address the business goals and objectives of the company. Nothing less.

So now back to that original question. Can you truly answer that question without naming or considering the tools that your company uses? If not you need to consider developing a true strategic direction for your digital analytics. Here’s one possible answer to that question:

Our digital analytics strategy is to analyze online sentiment, social media impact, site performance, site optimization and digital marketing efforts so that we can provide clear recommendations and timely information to directly impact our strategic business goals and objectives.

From there you could further elaborate on the details such as:

  • What those specific goals/objectives are and how they are impacted by the strategic areas of digital measurement
  • What information (not data points) is needed from the specific digital marketing efforts
  • How your going to get the information and disseminate it
  • Etc…
So there’s a lot to condier here well before a tool (again, a means to an end ) is even considered.
Put your horse back in front of the cart.

 

Omniture SiteCatalyst Data Processing Order

Posted on by
1

Since there are so many ways now for an Omniture customer to manipulate their data (standard data collection, APIs, processing rules, VISTA rules, marketing channel processing rules, etc…), I thought it’d be helpful to share this graphic (credit to Omniture) of the order with which data is processed:

Omniture SiteCatalyst 15: Migration Benefits and “Gotchas”

Posted on by
2

First off, I am not privy to the upgrade timeline and what’s involved there in terms of who gets upgraded and when that happens. That being said, I think that it is important for everyone to be aware of both the benefits of upgrading as well as the customer-side factors that might slow down the decision to migrate. I will also preface this with the fact that I am excited for every client that I work with to get upgraded, as the new features and implementation capabilities will greatly increase what they can do with their analytics investment.

SiteCatalyst 15 Migration Benefits:

  • The new context variables and processing rules
  • Real-time segmentation (you’re living under a rock if you don’t know about that one!)
  • Segment sharing between Omniture Discover and SiteCatalyst
  • Upgraded dashboards (including segmentation of the dashboards themselves)
  • True unique visitors (matching the # in Omniture Discover)
  • Visits are now calculated for non-cookied visitors
  • Full subrelations enabled on all eVars (i.e. conversion variables)
  • Visitors, Visits and Page Views available on all reports
  • Bounce Rate available on more reports
  • More accurate calculation of time spent on site/page
  • Deduplication of visitors in classification reporting and in merchandising eVars
  • Enhanced video reporting and measurement
  • Better Data Warehouse functionality such as editing a request, scheduling a previously created request, and better status/error reporting

I’m sure that I’m missing some things here, and that there are more benefits, but these are the ones that stood out for me as a regular user of these features. Now, a few of what might be challenges for some customers.

SiteCatalyst 15 Migration “Gotchas:”

  • Segmentation will only work for data collected under the new platform. So, you will not be able to segment your data in SiteCatalyst prior to the migration. The implication here is that you will have to wait for year over year segmented data. However, how useful is that data really anyway? Tell me an actual change you’ve made on your site after looking at how Jan 2010 did compared to Jan 2011?
  • In order to utilize the processing rules feature there will be a certification process that has to be passed. This is to safeguard the implementation integrity so that an accident does not cause a significant problem for an implementation.
  • As with segmentation above, the new visitor metric will only be available from the date of the migration, moving forward.
  • The new calculation of visits (i.e. the inclusion of non-cookied visitors) will increase your numbers for the visits metric. I’d doubt this will be a huge increase, but nonetheless, it will need to be something you are aware of and will need to educate your users as such.
  • The new calculation of time spent will change this data moving forward only. The impact being that your time spent will be more accurate, but that again there is a change of which you will need to educate your users.
  • Video measurement in SiteCatalyst 15 will require an upgrade to your video implementation. This probably won’t be any more complicated that your original implementation was, but it will need to be done. So, the tricky thing here is timing a video implementation that you need to do now, while knowing that you will eventually be upgraded to SiteCatalyst 15 and might have to recode it. Again, since I’m not privy to the upgrade timeline for everyone, this is something you’d need to discuss with your Omniture account manager. Also, I’d point out that this is about all that I know about the video measurement. The upgrade to video measurement will work for v14 and v15 as well (when it’s out of beta), so there is that good news.
  • Segmentation is not in the Excel Client or Report Builder with the initial release of SiteCatalyst 15. I am positive that this will come at sometime down the road, but the point is that if you use these tools for reporting and dashboards, you will not be segmenting in them until the time that there’s an upgrade there.
  • SiteCatalyst 15 will not provide ASI slots/segments. This makes sense since you will have segmentation, but the real challenge is to cope with not having access to those old ASI slots for reporting once you migrate to SiteCatalyst 15.

If you have any questions or other thoughts, leave me a comment below!

Omniture SiteCatalyst 15: Context Variables & Processing Rules

Posted on by
11

A big deal was made at the Omniture Summit of the segmentation available in SiteCatalyst 15. While the advantage of this feature is obviosu to everyone, I do not consider this to be the most significant part of the upgrade of SiteCatalyst to version 15. I consider the greatest new feature of SiteCatalyst 15 to be two things, that when put together, could change how every implementation of SiteCatalyst is undertaken and managed on a regular basis. These two things are context variables and processing rules. Below, I will detail what context variables and the processing rules are, and then discuss how they can be used in conjuction to streamline a SiteCatlayst implementation.

Context Variables:

Those familiar with SiteCatalyst are aware of what events, props and eVars are. With the release of SiteCatalyst 15, there is a new type of variable, the context variable. Here’s what you need to know about context variables in general:

  1. There are an unlimited number of context variables
  2. There is no character limits on what you can place in a context variable
  3. You can name a context variable with any name you prefer (meaning that developers don’t need to worry about eVarX, propX, etc.)

To detail how a company might use a context variable, I will provide a code example of custom download measurement via traditional SiteCatalyst variables vs. context variables. The goal here is to track the name of the download, the URL of the download and a success event for the download.

Site Catalyst 14 and Prior (assume eVar1 and eVar2 are set by the implementation):

s.eVar1="download name"
if (s.eVar1){
s.prop1=”D=v1″
s.events=s.apl(s.events,’event1′,’,',2)
}

s.eVar2="Download URL"
if (s.eVar2){
s.prop2="D=v2"
}

SiteCatalyst 15:

s.contextData['Download Name']="download name";
s.contextData['Download URL']="download url";

That’s it!

SiteCatalyst 15′s solution is a little simpler (at least in terms of coding), huh?! What makes this great is that giving direction to your developer for implementation is extremly straight forward, and anyone looking at these varibles in the code, should be able to easily determine what’s gonig on. Keep in mind that you can make the names of the context variables anything you like. So now that these context variables are in place, the developers are no longer needed in the implementation of SiteCatalyst (for downloads anyway!).

Next, Processing Rules will bridge the gap between the context variables and SiteCatalyst reporting. So below we will continue discussing the implementation of download measurement while using the context varialbes above with the new processing rules.

Processing Rules:

Many may be famailar with Omniture’s Marketing Channel Report and the processing rules that go along with that great feature (if not you should be!). Now, Omniture customers can create processing rules in a similar way that will allow them to set events and variables (as well as more advanced options) based on simple or complex rule sets. To demonstrate how this is done, we will assume that our developers have implemented the two “download” context variables above.

Now you can login to the admin console of SiteCatalyst and setup two easy rules:

  1. If “contextData["Download Name"]” is set at anytime, move that value to eVar1 and prop1 as well as set event1
  2. If “contextData["Download URL"]” is set at anytime, move that value to eVar2 and prop2

That’s all you have to do to implement custom download measurement once your context variables are in place.

Context Variable and Processing Rule Caveats:

This could warrant an entire other blog post, but here’s a brief summary of a few caveats of which to be aware when using context variables and processing rules:

  1. You will have to upgrade to the H23 version of the s_code (i.e. Omniture data collection code) in order to leverage context variables.
  2. While context variables can be unlimited in length, you will still need to be aware of the total 2080 character limite in Internet Explorer. Also, the props and eVars within the reporting itself still have their limits. The advantage of the unlimited length is that you could create a processing rule to evaluate the entire context variable’s value. Ex: if a campaign code contains “google” then set eVar3 as “Paid Search.”
  3. Don’t get your hopes up for SAINT here, the processing rules will not populate SAINT classifications.
  4. Context variables are not stored. Once they are captured and used in any processing rules, they are not maintained by Omniture. So, any processing rule (as should be expected) would not work on old context or other data.
  5. Obviously, the improper setup of a processing rule could compromise an entire SiteCatalyst implementation since processing rules are essentially a “VISTA Lite.”
  6. Debugging an implementation could be tricky using context variables. While you can see the context variables in a debugger, it is the eventual processing rules that would determine how a report is actually populated. This means that not only will you have to validate the site-side implementation, but you will also have to validate the setup of any processing rules. Here’s an example of what you might see in a debugger (easy to read, and no more c1, v1, etc…):
    SiteCatalyst 15 Context Variables in Debugger 

  7. The product string, cannot be set using context variables or processing rules. The product string is simply to complex. If advanced manipulation of the product variable is needed, then Omniture Engineering may need to be involved with an actual VISTA solution (unless you can do it on the code-side of course).

So, while segmentation is a great feature (maybe even the one that most users will value), the above features will enable Omniture customers to more easily manage implementations. The post above only scratches the surface of what can be done with context variables and processing rules. If you have any other questions,  leave me a comment below!

SiteCatalyst SAINT Classifications: Concatenation

Posted on by
Reply

SAINT Classification is one of the most useful features of Adobe SiteCatalyst. However, most company’s that use the tool use it simply for the ability to upload single dimensions for a key. For example, if a company is uploading SAINT classifications for marketing reporting and analysis for paid search, they will often upload classifications such as the following for paid search tracking codes:

  • Search Engine Name
  • Paid Search Campaign Name
  • Paid Search Ad Group
  • Paid Search Keyword Phrase
  • Paid Search Match Type

While all of this information is critical for the effective analysis of paid search campaigns, there is one limitation of SiteCatalyst that this does not help overcome. That is, the fact that directly within SiteCatalyst, you cannot subrelate by more than one classification to another. Yes, there are classification hierarchies, but the setup for this is in the admin console and is not as flexible as might be desired by many SiteCatalyst users. So, there is a simple solution that most company’s are not using. This simple solution is to create additional classifications that will mimic the ability to subrelate to additional levels of depth. So, in addition to the classifications above, the following additional classifications could be setup:

  • Search Engine Name > Paid Search Campaign Name
  • Search Engine Name > Paid Search Campaign Name > Paid Search Ad Group
  • Paid Search Engine > Paid Search Keyword Phrase
  • Paid Search Engine > Paid Search Match Type

As an example of how this might be used, the SiteCatalyst user could run a “Paid Search Engine > Paid Search Match Type” and then subrelate that to “Paid Search Keyword Phrase” to see a report that would look as follows:

  • Paid Search Engine > Paid Search Match Type
    • Paid Search Keyword Phrase

OR…

  • Google > Exact
    • Web Analytics

As you can see here, this mimics the effect of being able to subrelate to a third level. While this is not the perfect/ideal solution until unlimited drill down (without the hierarchy restrictions of the admin console), this simple concatenation of SAINT classifications should provide the users of SiteCatalyst reports and dashboards with more useful information on which to base business and marketing decisions.

Omniture SiteCatalyst Menu Customization and Custom Reports

Posted on by
7

Updated on November 3, 2011: Apparently custom reports cannot be copied to other report suites, not can they be shared with other report suites. So in essence, if you plan to customize the UI across multiple report suites with custom reports, you will have to duplicate your efforts for each report suite. I highly recommend that you go to the Omniture Idea Exchange and “promote” the request to make custom reports able to be copied to other report suites:

http://ideas.omniture.com/t5/Adobe-Idea-Exchange-for-Omniture/allow-to-share-custom-reports-across-suites/idi-p/5763

Original Post:
Without a doubt, two of the most underused features of Omniture SiteCatalyst have to be menu customization (the ability to customize the standard menus in the left-hand navigation) and custom reports. When these two great features are combined, they can make the adoption of Web analytics (and of course Omniture SiteCatalyst) all that much easier for an organization. The great thing about these features are that they can be used to make you analytics reporting intuitive to your stakeholders. In fact, if you are not using this feature, I can’t see how your company is getting the most out of the SiteCatalyst user interface. Just as an example on my blog, here’s a screen capture of the SiteCatalyst Menu for my report suite:

Omniture SiteCatalyst Menu

As you can see here, I’ve changed the default menu to a great degree. But if a user were to log into Omniture SiteCatalyst where no menu customization has been applied, how would they know just where to look for information about the performance of internal search? From my menu above, it’s pretty obvious where to go for reporting on Internal search performance.

In addition to the custom menus, custom reports can also be inserted into these custom menu items. Most companies that have a significant marketing spend, will most certainly be using SAINT classifications to apply meta data to their marketing tracking codes. And, many marketing reports are the result of breaking down one marketing classification by another, or even breaking down something like paid search engines by most popular product categories. In stead of having to train your marketing team on how to do classification breakdowns, you should be creating custom menu folders for marketing channels where you also have custom reports where classification breakdowns have already been created.

In short, you are doing your stakeholders and your business a disservice if you are not fully leveraging custom menus and reports. If you are not doing this, I would challenge you to meet with the stakeholders of your company as soon as possible to identify custom reports that they could benefit from, and then making those available in custom menus.

Omniture SiteCatalyst Plug-ins

Posted on by
11

Omniture SiteCatalyst is without a doubt one of the best Web analytics solutions out there. However, like all analytics solutions it be can difficult to implement when you are not a dedicated programmer or you do not have the available programming resources at your disposal. Many times Web analytics and other people that are responsible for the Web analytics function within a company will also not have access to server-side code to implement better page names and to set events and variables when you need to in certain circumstances. And this is where the Omniture SiteCatalyst plug-ins enter the equation.

The primary advantage of the SiteCatalyst plug-ins is that they allow you to implement SiteCatalyst and its more advanced features without the need to touch the server-side code. It should be noted thought that editing server-side code to pass dynamic data to SiteCatalyst is almost always the preferred avenue if it is available to you. That being said, Omniture has created many plug-ins that allow data to be sent to SiteCatalyst so that you can implement by only touching your basic “s_code.js” file that is a part of the implementation. Some of the more useful plug-ins (my opinion of course) include:

  • Append List (s.apl)
    • This function is one of the most useful and versatile for someone without easy access to source code. As an example of how this function might be used, assume that you have a registration confirmation page that needs a success event fired. By using the “s.apl” function, you can write some very simple JavaScript that will detect the Omniture page name and if it is a match, this plug-in will fire your success event. All being coded from directly within the Omniture JavaScript file.
  • Link Handler (there are 3 of these)
    • There are three flavors of the link handler plug-in. One controls clicks on regular links, another controls exit links and the last controls download links. The “s.downloadLinkHandler” plug-in is especially helpful if you want to track all of the PDFs on your site by setting a specific custom event for only clicks on PDFs, while at the same time sending the URL of the PDF into a commerce variable (a.k.a. an eVar). By using these three plug-ins, you can easily begin tracking the clicks of select links on your site.
  • New vs. Repeat Visitors (s.getNewRepeat)
    • The name of this plug-in says it all. By using this one, you will be able to segment all of your visitors and their interactions with your site into behavioral groups for new and return visitors. Very useful when the Omniture prop and/or eVar is correlated or fully subrelated, respectively.
  • Query Parameter (s.getQueryParam)
    • This might be the most basic plug-in, and is a part of almost every Omniture SiteCatalyst implementation that I’ve ever seen. While simple, it is extremely useful. Using this plugin, you can capture the value of any query string parameter and send that value to an eVar or prop. When you couple this plug-in with one like “s.apl” you have an easy way to capture your internal search phrases while at the same time setting a custom success event for internal searches.

These are but a few of the many plug-ins offered by Omniture. There are also more advanced ones such as:

  • Channel Manager (advanced tracking of your campaign data)
  • Cross Visit Participation (provides an understanding of campaign impact across visits)
  • Form Analysis (enables reporting on form errors, abandonment, etc.)

This last few are more difficult to implement in most cases, and you might consider contacting a consultant here.

The plug-ins are one of the most useful features of a SiteCatalyst implementation but are often overlooked. I think that a session on a few of the more advanced plug-ins would be an excellent idea for an Omniture Summit session, don’t you?

Site Optimization and Targeting

Posted on by
1

All visitors are not the same, they can come in through different marketing channels, enter your site at different pages and view different parts of your site. One of the great things about the Web and the tools that we have, is that you can not only know that your visitors are doing different things, you can measure and then act on it. TV for example has to rely on sampled, panel services (i.e. Nielsen) where you might make an estimation about the different groups of people that saw your ad. On the Web, we know what visitors viewed and exactly who viewed it! If you have a robust analytics solution, you already have this data. The question is, what ,if anything, are you doing to act on it?

As an Omniture user, I have always relied heavily upon tools like Omniture Discover, because of the fact that it lets you segment your visitors into more meaningful groups. So, I can easily see for an e-commerce site, that the people clicking on the “View Larger Image” link on a product details page have a conversion rate that is 200% higher that those visitors that do not click on that link. Shouldn’t I be doing something about that? Like running a test to optimize that link for the visitors that have not been clicking it?

If you are currently or will be running a site optimization solution like Omniture Test&Target, you should always be running monitoring campaigns on your site. This can allow you to always be tracking and reporting on how different segments of your visitors are converting on your site, allowing you to quickly act by launching a test that is targeted towards a high-value segment of your visitors.

You should consider targeting your site optimization efforts towards different segments of visitors such as:

  • Logged in visitors (vs. not logged in)
  • Visitors from paid search campaigns
  • Visitors from natural search
  • Visitors using specific keyword phrases on search engines
  • Visitors from email campaigns
  • Visitors that stop at a certain point in your conversion funnel
  • First time visitors
  • Repeat visitors
  • Visitors that enter your site via a specific page
  • Visitors from a specific geographic location

Targeting your site optimization efforts to segments for visitors is usually more effective than just launching a test that is served to all visitors of your site as if they were equal. The reason, is that with different segments, you have an idea of their intentions. For example, if you are targeting a test that changes laptop product imagery for visitors that are entering your site after searching for “laptops” on Google, you know that your test is being served to the segment of visitors that is actively considering purchasing a laptop at this time or in the near future.

When considering site optimization, always ask yourself for which group or segment of visitors is this test targeted? You should see your site optimization efforts paying off more quickly if you are targeting your tests.

Content Site Optimization

Posted on by
Reply

Most of the blogs and literature that you will see on the Web about site optimization is going to be about e-commerce Web sites. The reason? Anyone can understand your results when you say you’ve increased conversion rate by 20%, thereby seeing an incremental lift in revenue of $100,000 over the next 30 days. The case for optimization here is pretty obvious. This doesn’t mean that content sites and publishers that aren’t selling a product on their site should not be optimizing their sites.

One common excuse on the part of a lot of content and publisher sites is that they are not selling anything. If you are in business and making money while not selling anything, please let me know what business you are in so that I can start one up too! The reality of the situation is that often, it’s just harder to measure revenue from online activities and marketing for a content site or publisher. Your are in fact “selling” some product or service to the visitors to your site, whether or not that “sale” is made online. Once you’ve realized this, you should also realize that your site could be better at selling to its visitors. In order to start optimizing your site, the first step is to identify and track your “converions,” not just basic traffic data. For publishers or lead generation sites, these conversions could include (but are not limited to) any of the following:

  • Page views
  • Ad views
  • Completion of a registration form
  • Registration for a newsletter
  • Completion of a contact form

Once you have identified your conversions on your site, you are ready to optimize your site so that you can get your visitors to view more ads, visit more pages, complete your lead generation forms, and sign up for your newsletter more than ever before.

Many site optimization platforms, such as Omniture Test&Target, will integrate directly with your already existing Web analytics solution, making it even easier to optimize your site since you won’t have to re-tag all of the conversions on your site. All optimization solutions should let you track “non-ecommerce” events in some fashion though, but if you can leverage your existing Web analtyics tagging, you should do so.

In terms of content sites, here are a few tests that you should be running on your content. These are what you might call the low hanging fruit common to a lot of content sites:

  • If running paid search campaigns, test different ways of presenting calls to action for your conversions
  • Test what you have above the fold of your homepage so that you can decrease bounce rate and increase conversions
  • If you have search on your Web site, change how you are presenting search results

These are just a few, very generic options. The options available are unique to every company out there, and you each have your own opportunities to optimize your existing content.