Rapid expansion of mobile internet usage: Opera’s September State of the Mobile Web report pegs year-over-year US mobile page view and unique user growth at 309% and 123% respectively; Pew Internet reports daily mobile web users comprise 19% of all US adults (a 73% increase in 16 months)
Emergence of new mobile markets: rough estimates place the market size of Apple’s App Store at around $150 million annually
Mobile market share up for grabs: while Baidu is the clear leader in China for web searches, Google’s mobile investments have made competition nearly even for mobile searches in China

Opportunities

In school way back in 2000, my class reviewed a Harvard case study which centered on the impact of new internet brokerage firms like E*TRADE on Charles Schwab. The case debated whether Schwab should chase the internet leaders or stick to its core “brick & motor” business, forgoing internet channels entirely.

Some students at the time maintained Schwab shouldn’t invest at all in internet channels—rather they should focus on their “high touch” positioning since their best clients weren’t currently engaged with online channels. Fast-forward ten years and the class debate looks pretty archaic, until you consider a recent review of the top 100 internet brands which contends that only 1 in 3 brands has an effective mobile web presence (incidentally, Schwab and E*TRADE both got it right).

While the recent review had considerable subjectivity in the way “effective mobile web presence” was measured, my personal experience validates that many brands are still sitting on the sidelines. Businesses not engaging users in the mobile channel bring us back to the old debate—”should we build a [mobile] website?”.

These businesses should be warned—brand dominance in the mobile space is not a foregone conclusion. Recent search engine market share data from China (as reported by Analysys International) shows Baidu, the leading search engine, has not maintained its dominant position in mobile search. In fact, several providers with virtually non-existent market share for standard web search have captured a significant proportion of the mobile search market (e.g. 3GYY).

Emergence of completely new business models and markets is also creating significant business opportunity. A case in point is the iTunes App Store. Rough estimates place the paid app market within the iTunes app store at $150 million annually—not shabby for a market that didn’t exist 2 ½ years ago!

Explosive growth of mobile web usage, business innovation in the mobile sector, and uneven investment by the dominant players in the traditional web has unfrozen market share and created completely new business models, revenue streams, and growth opportunities. All of these factors are reminiscent of internet growth from ten years ago—is your business still partying like it’s 1999?

Sources:
http://www.opera.com/smw/2009/09/
http://pewinternet.org/~/media//Files/Reports/2009/Wireless-Internet-Use.pdf
http://www.pcworld.com/businesscenter/article/171371/ googlebaidu_rivalry_goes_mobile_in_china.html
http://www.marketreportchina.com/market/article/content/3376/200908/206975.html

As my fellow blogger Ed Hewett pointed out in an August post, there is a gap between interest in mobile analytics and mobile Web usage. Or to put it as he did, “you don’t know what you don’t know” about your mobile traffic if you don’t have best-in-class tools to track the activity. The fact that mobile has arrived is hardly earth-shattering news, but recently, a client who’s still on HBX asked me about the benefits of moving to SiteCatalyst. A significant portion of this client’s business revolves around handheld devices, so this was like shooting fish in a barrel. Let’s review what you’ll get on the mobile front when you migrate from HBX to SiteCatalyst.

First off, development on the HBX platform essentially ceased in 2007 as Omniture devoted its development efforts to SiteCatalyst. Matt Belkin, the former head of Omniture Consulting, started a new group focused on Emerging Technology, with a maniacal focus on mobile. SiteCatalyst customers are now enjoying the first fruits of their labor unprecedented insight into mobile visits. Take a look at the difference in the out-of-the-box mobile reporting the two tools offer:

For starters, HBX doesn’t even know what an iPhone is. That’s how antiquated its mobile tracking is. SiteCatalyst not only recognizes the iPhone but can also report on screen size, video support, DRM and even Decoration Mail support. What the heck is that? It’s a service, mostly being used in Japan, which allows users to “decorate” (customize) their mobile emails by customizing the background, font and even attaching things like animations. Who cares? OK, perhaps you don’t but in Asia, many marketers are interested in DecoMail. It’s an example of us presaging a need for the US market, while creating a timely solution for our many Asian customers.

Omniture will not be a follower in mobile analytics. In fact, those who attended this year’s Summit in Salt Lake City heard Josh James, proclaim (and I’m paraphrasing here) ‘the personal computer, as a medium, is dead.’ While even Josh would admit that prediction is a bit ahead of its time, there is no denying some of the business use cases for advanced mobile tracking. Just a few include:

• Determine the true size of your mobile audience
• Use mobile campaigns for timely promotions such as one-hour sales
• Opt-in customers to receive text messages as an alternative to more costly and inefficient contact methods
• Analyze traffic and mobile device capabilities to tailor the user experience when launching or redesigning a mobile site
• Gauge affinities common to users of a particular device, service or app to optimize their mobile experience and recommend relevant content or product
• See causality of mobile visits in terms of success event completion as shown below in a SiteCatalyst report:

Anyone who’s worked in User Experience knows about the “Rule of 1.” It states that if more than 1% of your site audience is unable or in any way hindered from viewing your site, you need to make adjustments for them. For most sites, the mobile traffic is at or above 1%. I have seen some sites where it’s in excess of 10% and a handful where is more than 35%. So if you’re still using HBX, you’re missing an important opportunity to hone your mobile approach while there is still time. Rich apps like Flash work on mobile devices. People are downloading entire TV shows or movies and viewing them on their handhelds. In Japan, folks are using QR barcodes as “mobile coupons” instead of paper coupons.

Mobile is here - it has been. It’s everywhere. Is your organization taking advantage of it? If not, call your Omniture Account Manager and ask them to show you what SiteCatalyst can do to help improve your mobile efforts.

Figure out why internal search terms are valuable and implement around that

Not surprisingly, businesses will use internal search information differently. For example, a retail site is probably interested in the keywords that convert most effectively into orders, as well as the keywords that return no data (since this can sometimes identify holes in your catalog of products). A media site, on the other hand, may be more focused on the traffic generated by each search term, as well as the banner ad click-throughs which follow. While the implementation of internal search measurement may be similar across different business needs, it is nevertheless important to keep in mind why you care in the first place; it ensures that your implementation strategy will provide the data and key metrics that you really want.

Use a Custom Conversion (eVar) variable when you want the search term to persist, so that subsequent conversion metrics can be tied to it. For example, a user may perform an internal search at the very beginning of his/her visit, but not convert until 20 page views later. Use an eVar to allow that search term to receive credit for the order that occurred much later on. Using an eVar will also give you a total count of the number of searches performed in the Instances metric, allowing you to create a calculated metric within this report, [Orders] / [Instances], to see which keywords are most and least effective at producing conversion.

A Custom Traffic (s.prop) variable measuring internal search terms, as the name suggests, traffic-oriented. It can show you the number of page views, visits, and daily/weekly/monthly unique visitors per keyword on your site. This is ideal for business that care about searches per visit (or per visitor), and also those that care about pathing. I’ll discuss pathing by search keyword more below.

It’s worth noting that I suspect that many of you will want to use both an eVar and an s.prop to capture internal keywords, and this is just fine. In fact, it’s common. Best of both worlds, right?

At least two popular implementation methods

This is described in the SiteCatalyst Knowledge Base:

There are two recommended approaches for populating a Custom Traffic (s.prop) variable with internal search keyword data. One is to use server-side variables to write out the desired variable and search keyword, and the other is to use the getQueryParam plug-in capture this data out of the query string in the URL of your search results page and pass it into a variable. In the examples below, we will use s.prop3 as an example of a destination variable for your internal search tracking, but you can use any Custom Traffic or Custom Conversion (s.eVar) variable for this purpose.

Server-side approach

The specifics of this method will vary depending on your server-side language of choice and implementation. In short, your server should have access the search keyword, either in a GET or a POST variable, and you can copy those over to regular variables, do any desired manipulation, and then write the keyword to the page.

/* You may give each page an identifying name, server, and channel on the next lines. */
s.pageName="Search Results"
s.channel="my site section"
s.prop1="user search"
s.prop2=""
<? echo "s.prop3=\"" . $_GET['keyword'] . “\”" ?>
s.prop4=”"
s.prop5=”"

If the user had searched for “little saplings handmade toys,” the result would be that “little saplings handmade toys” would be written out, and passed into SiteCatalyst on the page load, as the value of s.prop3:

s.prop3="little saplings handmade toys"

getQueryParam approach

A more common option is to allow the getQueryParam plug-in to capture your internal search keywords and to pass them into a variable of your choosing. The majority of site search engine implementations will give you the user’s keyword in the query string of the results page, and SiteCatalyst can grab it. For instance, if the user searched your site for “Little Saplings toys,” the search results page might have a URL similar to this:

http://www.yoursite.com/search/results.html?q=little+saplings+handmade+toys

In this case, you could use the getQueryParam plug-in to search for the value of the “q” parameter and to capture it in s.prop3. (Note that the plus signs are automatically stripped and replaced with spaces.) For example, you might include the following within the doPlugins() function in your SiteCatalyst code (within the s_doPlugins function in the s_code.js file):

s.prop3=s.getQueryParam('q')

Make sure to standardize the case of search terms

The point of passing internal search terms into SiteCatalyst is to determine the popularity of various values over time and their effect on success—however you define it. As such, you probably want to group different case variations of the same term, assuming that these variations return the same results. You don’t care to see “Little Sapling handmade toys” and “little sapling Handmade TOYS” as separate line items, because the search results (and, thus, the user experience based on this search) is almost certainly going to be the same. (NOTE: For sites with a high traffic volume and tons of internal searches, case issues can also increase the total unique values in reports significantly.)

So, if you’re using JavaScript to capture internal search terms, make sure to attach the toLowerCase() to the variable that is capturing the keyword. For example, you might do something like this, building on the example above:

s.prop3=s.getQueryParam('q').toLowerCase();

For server side languages, you would use something like the strtolower() function in PHP to do the same thing.

Capture the number of search results—especially zero—in a separate variable

On top of this, you can pass plenty of other useful information into other conversion and traffic variables. For example, if your internal search engine returns the count of results for each search, you can capture this information in an eVar to see how the number of results affects conversion; are the search targeted and accurate based on what the user is searching for, or do you confuse potential customers with many irrelevant results?

When no results are returned, pass a zero or “null” into this variable, so that you can break down “null” by the keywords which returned no results. This will help you understand what your users are searching for in vain. It can also help understand where your product meta data isn’t speaking the same language as your potential customers.

Use SAINT to combine singular and plural keywords (where appropriate)

Just a brief point here: your search engine may return the same results for singular and plural forms of a search term (e.g., the plural “Little Saplings handmade toys” versus the singular “Little Saplings handmade toy”). In this case, I would recommend passing the search keyword into SiteCatalyst as-is, then (if desired) using SAINT classifications to “group” these similar values. The singular and plural forms of the keyword would both be key values in your SAINT upload, and a single classification column, with the same value for both the singular and plural forms of each keyword, would give you an additional report where these variations are combined into one.

Pathing on search terms

As mentioned earlier, you can have pathing enabled for Custom Traffic variables, and this allows you to see how users’ interaction with your internal search engine evolves. These reports will display not just individual search keywords and their popularity, but the actual series of searches performed. For example, what does this “search keyword path” tell you?

There are a few possibilities, but these might be users who are interested in purchasing not only an iMac, but also bluetooth accessories. Do you need to add a “Recommended Items” section to help users locate these products more easily—so they don’t need to perform search after search after search? If you already do product recommendations, is there a reason users aren’t finding these accessories there?

This is just the tip of the iceberg—internal keyword pathing opens a world of powerful optimization opportunities. It is absolutely possible, completely customizable to your needs, and fairly straight forward for you or your developers to implement. As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter, FriendFeed, LinkedIn, or by e-mailing omniture care [at] omniture dot com.

Transactions

This whole process is state-less by definition.  This means that the protocol doesn’t have any concept of memory to remember something from one request to the next.  To compensate, both the client and the server have come up with a way to keep track of state between requests (cookies and sessions respectively).

The upshot of all of this is that the web is built upon a series of transactions of data, each one consisting of a request and response.  A user action in a browser, such as clicking a link, triggers a request to a server (please give me the contents of this page) and the server processes the request and sends a response (here are the contents of that page you asked for).

This is the way that web analytics data collection works as well.  Usually the sending of the request is handled by JavaScript which is triggered by the loading of a new page.  The request contains all the information about the page and visitor that you want to record.

The response is an image file (hence the name “image request”).  The only reason that anything comes back at all is because there must be a response.  That’s the way the web works.  No one really cares about the image itself, so we make it a 1×1 pixel transparent image that’s easy to hide away somewhere where no one will see it.

State

Abraham Maslow is perhaps best known for defining the hierarchy of needs.  He also coined a now-famous phrase that you’ve all heard before.  “If the only tool you have is a hammer, you tend to see every problem as a nail.”

State introduces a new aspect of web measurement.  Standard web measurement tells us how many things happened within a certain time frame. By contrast, state measurement tells us how many of something there are as of a particular point in time.  The funny part is that we, as humans, actually deal with states all the time without ever thinking about it, but it’s almost entirely foreign within the realm of web analytics.

The Difference

How much money did you make?  How much money do you have?  Two related, but very different questions.  The first is transaction-based asking how many dollars rolled in during a given period.  The second is state-based asking how many dollars are in your pocket?

You’re starting to hear the difference.  One is past-tense and one is now.  So what are the analytics equivalents?  Transaction-based would be something like how many visitors did we have last month?  Now let’s try the state-based version.  How many customers do we have?

Soul Searching

When was the last time you asked a question like that?  I’d wager most of you never have.  In 2.5 years as a member of Omniture Consulting, never once did a client ask me a question like this.  Why not?  Why don’t we ask questions like this?  Perhaps we’ve trained ourselves not to ask them because we don’t expect the answers to come from our analytics tools (but they can!).

I’m not debating the power and insight that rests in transactional data nor am I suggesting a replacement.  I’m stating that adding an understanding of status to your transactions can greatly enhance an understanding of your online presence.  Use transactional data for transactional questions and use status data for status questions.  With a little twist on standard implementation, SiteCatalyst can be used to help you keep track of your status.

Next time I’ll discuss in detail how we use status tracking within Test&Target to understand campaign usage,  but in the meantime, take a moment to think about how state applies to you and ask yourself a few questions you haven’t asked before. The how many new registrations did you get last month question can be enhanced by the how many registered users do you have question.  The percentage change in new user registrations question can be enhanced by the percentage change in the total size of the customer base question.  And also note that the status version of the question also accounts for attrition!  There are so many applications!

Photo Credits: A pocketful of change ca. 1970 by a.drian and Close Up of The Thinker by Brian Hillegas

Make sure that key configuration variables are always consistent—even across collection methods

This is a common problem which is, unfortunately, easy to make. You’ve implemented a first-party data collection domain in JavaScript (in your s_code.js file) using the s.trackingServer and s.trackingServerSecure variables. For example:

s.visitorNamespace="awesomesite"
s.dc="112"
s.trackingServer="metric.myawesomesite.com"
s.trackingServerSecure="smetric.myawesomesite.com"

This will cause the s_vi cookie to be set on, and read from, the “myawesomesite.com” domain. Now let’s say you begin to implement SiteCatalyst in a Flash application that will live on your site. You download the ActionSource code and component from SiteCatalyst. In your excitement, you forget to implement the two variables discussed above:

s.visitorNamespace="awesomesite"
s.dc="112"

This will cause your Flash application to use a different data collection domain than your JavaScript code. The result? One visitor ID value for JavaScript image requests and a separate visitor ID value for Flash image requests, which means that you’ve duplicated visits and unique visitors for anyone who touches both your Flash and your non-Flash implementation.

The same thing applies (although a bit differently) when mixing JavaScript and Data Insertion (XML) API implementation. There, you would want to read and parse the visitor ID cookie value in your API implementation and pass it using the <visitorid> element. If you pass a different <visitorid> value, or leave <visitorid> out of your implementation, SiteCatalyst will not tie the data passed via the API to the data passed using JavaScript, even if all of this data came from the same user.

Leave that s.visitorNamespace variable alone

This applies primarily to those implementations based on third-party data collection domains. As described briefly above, the data collection domain determines where the visitor ID is set; as such, it must be consistent from page view to page view and from visit to visit. The s.visitorNamespace variable controls the subdomain for data collection. Because it frequently matches or suggests the name of your organization, you may feel tempted to change it when your company’s name changes or when you are introducing a new brand.

s.visitorNamespace="myawesomesite"
s.dc="112"

These two variables (given the absence of the s.trackingServer and s.trackingServerSecure variables) will cause the data collection domain to be “myawesomesite.112.2o7.net.” Changing the visitorNamespace variable will not prevent data collection, so it’s possible that a change here would go undetected. But since the data collection domain has changed, every visitor will be treated as brand new. This is commonly called “visitor cliffing.” Since every visitor becomes a new visitor, unique visitor metrics will spike; “lifetime” reports, such as Return Frequency, Visit Number, and Original Referring Domain will be “reset.”

Within a single site, stick to one global JavaScript file

I cannot think of a good reason to have multiple s_code.js files on a single web site, but I do see this from time to time. I understand that certain pages may require different variables to be set in different ways (e.g., you use “cid=” in the query parameter to capture campaign tracking codes on pages owned by your team, but another team uses “campaign=” and cannot change this), but this should still be possible by setting variables dynamically within a single file. Using multiple s_code.js files only increases the likelihood of a discrepancy between key configuration variables, such as those discussed above. For example, if you use a first-party data collection domain, this may be set in one file, but not in another, which would cause the second file to rely on a third-party domain. The effect would be similar to the point above regarding the inclusion of s.trackingServer and s.trackingServerSecure in all forms of data collection; because the two JavaScript files would not contain the same configuration variables, you would end up with multiple visitor IDs and, thus, multiple visits and visitor counts.

So what can you do to detect these problems when they occur (so that you can correct them using the information above)?

1. Always debug using visits and visitors—not just page views
Checking your Pages report and your Custom Traffic reports is important, but they may not always tell the whole story—at least when showing the Page Views metric. A visit may involve a number of page views for a certain line item in a Custom Traffic report, but if the number of visits matches the number of Page Views, you might have a problem with visit and visitor measurement. Also, make sure to compare visits and visitors to previous time periods. Some spikes are natural and good—the result of marketing efforts—but sudden spikes in visits and visitors that correspond to implementation changes made on your web site can be a sign of trouble.

2. Check “lifetime” reports
If you typically see 60% first-time visits, and that number jumps to 90% all of a sudden, it probably isn’t that you’re driving away your loyal customers. Rather, you may be seeing visitor cliffing in action.

3. Use a packet monitor while browsing your site
There are a number of debugging tools that will show you the data collection domain that your SiteCatalyst implementation uses. You can use these tools to detect changes—both against historical data collection, and from image request to image request on your site. For example, Tamper Data for Firefox will show all image requests and will update with new ones as you browse. Simply look at the beginning of each request URL to confirm that the data collection domain is consistent. For bonus credit, you can double-click the “Cookies” details for each request to ensure that the s_vi value is consistent from request to request.

Fortunately, issues involving visit and visitor inflation are rare. These issues probably aren’t affecting your data, but when they do arise, they can be difficult to troubleshoot and can give even the best analysts severe headaches. I don’t want that to happen, so I hope this helps you understand the process that you might follow in validating an implementation against visit and visitor inflation, as well as what you can do if you are seeing strange things in your data.

As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter, FriendFeed, LinkedIn, or by e-mailing omniture care [at] omniture dot com.

The number of channels available to marketers for reaching their target audience has been growing dramatically over the years.  It was not long ago when the only options marketers had were print, radio or television.  Today of course, businesses have a whole multitude of channels they can use to get their message across to customers; and on the flip side, customers also have a whole range of channels with which to complete transactions – and these aren’t necessarily the same ones.

Businesses now realize that they need to employ multiple channels in order to effectively reach their target audience.  However, merely having multiple channels does not translate into a true multi-channel strategy.  Businesses need to avoid the costly and ineffective “everything to everyone” approach when putting together their channels. They need to define a true multi-channel strategy where each channel plays a core role and has a defined value proposition for the customer experience.

In order to do this, businesses need to be able to understand customer behavior and preferences.  They need valuable information on the different customer attributes and how these affect purchase behavior, product attributes, sales patterns and channel preferences.  This understanding can no longer be achieved by looking at only one channel – businesses need to bring all this information together from all the different channels in order to see the true big picture.

But be warned: bringing together all data from all channels all at once is too ambitious a task and will likely result in failure.  Businesses should start with one easily measurable channel and augment it with data from just one other channel.  As technologies for web analytics have matured in the last few years, this is a logical place to start.  Most companies with a web presence should already be analyzing customer behavior on the web.  The short term goal should be to augment this analysis by adding data from one other channel – for retailers, this would be in-store customer behavior and purchase patterns derived from POS systems.  For other verticals with heavy call center use, such as financial services, travel or telecommunications, analysis of call data merged with web data would provide quick returns.

By following this approach and then later adding additional channels once the two-channel analysis has yielded benefits, businesses are more likely to develop a successful multi-channel strategy to retain and grow its customer-base.

Then there’s the Dockers shakable mobile display ad which spun up an average engagement of 42 seconds (33% percent of people who saw the ad shook it).

And don’t forget the Starbucks mobile barcode campaign which churned out a frothy 60% coupon redemption rate (the typical redemption rate for print coupons is 1%).

Some attribute these successes to the less cluttered environments these [relatively] new mobile mediums enjoy. Others advocate marketers adopt a conservative approach pointing to very high mobile display CPM rates. While some caution is certainly warranted, the following four mobile channels each represent a unique opportunity for marketers to more effectively engage their mobile audiences:

Apps: Besides many other benefits, mobile applications can be an excellent way to reduce transactional friction. For example, a new feature in the USAA iPhone app allows users to deposit checks directly from their iPhone . Since USAA serves members all over the world but only has a single branch in San Antonio, Texas (USA), the feature significantly reduces the time, cost, and effort of depositing funds by check.

Barcodes: Integrating scan-able barcodes into print and display mediums provides a natural integration point with online channels, a mechanism for immediate response for action-oriented consumers, and the means to measure the impact of offline campaigns. Barcodes were integrated into print and display advertising for the recent launch of Nokia’s new line of Navigator handsets. The campaign was so successful it has been followed up with two subsequent campaigns. “The performance of the 2D code campaign has far exceeded both ours and Nokia`s expectations. Due to the strong response rates and opt-in interest, Nokia will be incorporating more campaigns with 2D codes …”, said Harald Winkelhofer, Founder & CEO of IQ mobile.

SMS/MMS: Push and pull mobile messaging provides a timely way to connect with users. eBay currently leverages SMS push notifications to prompt users when they’ve been outbid or when auctions for watched items are ending soon. The channel creates a distinctive touch point eBay can leverage for these time-sensitive transactions.

Bluetooth: Timing and context often make the difference between campaign success and failure. Recent mobile campaigns for Warner Bros., “The Hangover” and the Chevrolet Spark leverage Bluetooth to reach consumers with rich media. In each case, the location context of the marketing campaigns allowed targeting toward a specific demographic in a relaxed environment; and both campaigns experienced a download rate of 9% and above.

No Mobile Campaign is an Island
While individual mobile efforts can help to drive business objectives, campaigns are more effective if they are tightly integrated with existing marketing channels. In fact, mobile initiatives often have an additive effect when combined with other efforts as is the case when barcodes are combined with print and display.
Whether you choose to leverage mobile apps, barcodes, mobile messaging, or Bluetooth as part of your mobile marketing strategy OR you decide to utilize other mobile channels, you’ll want to ensure you have deployed a mobile measurement and analytic strategy (read this post on deploying measurement for mobile initiatives) and are following mobile advertising best practices (MMA Global Mobile Advertising Guidelines ).

A little while back we deployed Omniture Recommendations on our Web site based on most popular views and downloads. As a company focused on online marketing solutions, it shouldn’t be too surprising that we use our own products as marketing tools (alright, true - lots of companies don’t, as they say, “eat their own dog food”). Our Web team does a great job of optimizing content to ensure that we’re giving Omniture.com visitors the kind of information they’re looking for. The site now recommends content like on-demand webinars and case studies.

As you can see, we’ve placed recommendations on sidebars on a variety of pages. In some cases we’re testing automated recommendations against static default content. And the automated recommendations are winning out: since deploying recommendations on Omniture.com we’ve seen 25% to 45% increases in cross-site conversions! What does this mean? It means that we’re doing a better job of connecting the right people with the right content. And for any business, this kind of relevance is vital to delivering a positive customer experience.

Next post: I’ll share some thoughts with you on how our customers are getting pretty creative when it comes to leveraging SiteCatalyst metrics to influence recommendations and optmize relevance for their customers.

Welcome to the second post in the Web Services API Series.  Here I will describe what you can do with the SAINT API and what to pay attention to.   So stick with me and you will soon learn how you can take advantage of this tool that gives you the power to enhance your reporting experience.

What is SAINT?

SAINT is the tool for uploading classifications of data. In other words, it is a method for you to upload metadata to provide more detailed information about data in SiteCatalyst.  For example, you can classify a product with the products color, size, shape, weight, etc. with SAINT.

What is the SAINT API?

The SAINT API is an interface for you or developers at your company to interface with Omniture and build automatic classifications.  Let’s look at some examples.

Example 1:

Let’s say you want to classify keywords into branded and un-branded or product and general, but you have over 10,000 paid and natural search keywords.  Now that new intern might be kind of annoying and you want to give him a task that will keep him busy for a long LONG time. If you do that, who will get you coffee in the morning?

Solution 1:

We have a solution for your coffee problem.  Naturally, your keywords will have some pattern to them, such as your brand name, product name or branch name.  So you use these patterns to classify your keywords programmatically and then use the SAINT API to upload the data into SiteCatalyst.  It will take you less time to program it than it would to classify half of the keywords and you can use the same programming logic over and over again.

Example 2:

You are importing data into SiteCatalyst such as offline data or data from another company.

Solution 2:

When you are uploading data into Omniture, most of the time you don’t need to upload all the possible data points into traffic variables (s.props) and conversion variables (eVars).  You can use the SAINT API to upload classifications on that data, which will save you variables and allow you to change the data retroactively.

Example 3:

You are importing micro blogging **cough**cough**twitter**cough**cough** data into SiteCatalyst.

Solution 3:

Ok. . . it is no secret, the Twitter integration uses the SAINT API but it is worth noting that with the Twitter integration you get tons of reports and you only ever data source in the Twitter ID.  Everything else is based off of classifications!

Benefits of the SAINT API

You will be able to know exactly when the classifications are uploaded so you can then pull the associated reports knowing the classifications are done processing.  Also, you can upload classifications for more than one report suite in single request.

Things to know

• Omniture’s Engineering Services Team can provide consulting for the SAINT API and all other Omniture APIs.  If you would like a resource to help you get started to advance your current setup, then contact your account manager and they will point you in the right direction.
• You will need to set up one of your user accounts to have Web Services Access ( See Getting Started below).  My suggestion is to create a unique user for each application; it makes it easier to keep track of how many tokens an application is using.

Getting Started

The SAINT API is a programmatic solution, so you will need a developer. First step is to set up your web services accounts. Go into SiteCatalyst then in the upper right hand corner of the page go to Admin > Admin Console.  Then click Manage User Access, then Edit Groups, finally Web Service Access. Inside this interface you can add users to the Web Services Access group.  This will allow that user to pull reports from the reporting API.  (Warning: giving someone access to web services gives them the ability to use all web services functions which includes administrative functionality.)

Next step, get your Web Services API Username and Shared Secret.   First, you want to go into SiteCatalyst then in the upper right hand corner of the page go to Admin > Admin Console.  Then in the menu on the left you go Admin Console > Company.  And finally you click Web Services.  This interface will display the number of tokens each user has used and how many tokens your company has left.  This is also where you will get the username and shared secret you or your developer will use to access the APIs.

Resources

developer.Omniture.com - This is your one stop location for tons of information related to Omniture’s APIs.   Here you will find example code and all the methods that are offered.

Code Gallery - Part of developer.Omniture.com.  Is a location for a ton of prebuilt solutions that utilize Omniture’s APIs.

As always, post your comments or e-mail me at paurigemma (at) omniture.com.  It is your comments and e-mails that keep me posting and give me ideas for future posts.  If you do decide to purchase an Engineering Services solution, make sure you mention the blog and you will get white glove treatment.

Related Posts:

• Web Services API Series - Reporting API, You Have The Power

Personalizing Your Data

All of the reports in SiteCatalyst correspond to a database table somewhere.  Some of these are populated out-of-the-box and some are left to the discretion of a company to decide what to use them for and how to collect the data.

Among these personalized variables are props, evars (also here), and events.  That provides a lot of room for customizing the data you collect and making sure that you’re meeting all the goals laid out in your measurement strategy.

When you organize your report suites into a hierarchy, you have to keep in mind that a single data point is likely going to end up in multiple locations.  A Video Start on the US site will also end up in the global site.  It sounds pretty straightforward, but there are some important effects that we’ll take advantage of.

1.  Some Of Your Data Is Only Important At The Top Level

There are some reports that are only important inside the upper levels of your hierarchy.  Inside the Omniture Suite for example, we capture Product in prop4/evar4.  Every time data is sent to the collection servers, prop4 and evar4 contain a value that simply identifies which product is being used: SiteCatalyst, Test&Target, Discover, etc.

Within an individual report suite, the value is limited, but at the global level, where all the data is, this is extremely valuable.  It provides me a single report that tells me how much usage each product is getting.  Interesting insights are available from watching this trend over time.

This concept will hold true regardless of whether you’ve organized your hierarchy by country, by product, by site section, or something else.  Some of your data is only important when you look from the top down.

2.  Some Of Your Data Is Only Important At The Bottom Level

We keep track of the usage of bid rules used for ad spend optimization, but SearchCenter is the only product that uses them.  An active campaign in Test&Target is its own event and isn’t repeated anywhere else throughout the suite.  We obviously want to keep track of these features, how people use them, and how effective they are.

We keep track of these kinds of things at the bottom level of the hierarchy, but we don’t need to expend the effort to measure them at the top level.  There is no added value in looking at this data at the top level, therefore, there is no need to track it at the top level. In fact there is no need to even turn these variables on at the top level.

Now here’s the neat trick.  Since we don’t roll these values up to the global level, it means that the lower levels can re-use the same variables to mean different things without corrupting any of your data.

3. Some Of Your Data Is Just Plain Important

This follows logically from points 1 and 2, but I thought I’d call it out just to be explicit.  Some of your data makes sense and provides value at the top, at the bottom, and everywhere in between.

Takeaways

When you determine that you need to measure a particular data point, you must decide where it has value, and at which level you need to keep track of it.

If a data point falls into category 1 (provides value at upper levels only), then you must ensure that every report suite underneath implements that data point consistently.  This means they must pass the same values (or kinds of values) as every other report suite, and they must remain constant over time.

If a data point falls into category 2 (provides value at lower levels only) then record it in a way that is consistent within that report suite, and do not even enable that variable at the upper levels.  This reduces risk of latency and also ensures that your users do not waste time trying to derive value from reports that have none.

Inside the Omniture Suite

As an (extremely simplistic) example, the diagram below shows a layout of our variables inside a report suite.  If it’s listed on a report suite, it’s being recorded there.  Orange text is unique to a given report suite and not recorded at a global level.  Faded text are the ones you would pay less attention to on a given level.

Category 1 - Inside the Omniture Suite, we have dedicated about half of our variables (props, evars, and events) that must be used consistently across all products.  There are global standards for implementing these variables so that the values mean the same thing and that they look the same when they come in.  Product Name is an example.

Not all 35 data points apply to every product, but they do apply to more than one.  If a particular data point does not apply to a product, we simply leave it alone.  Report Suite ID is one example.  We obviously want to record that for SiteCatalyst, Genesis, Discover, etc., but it just doesn’t apply to Test&Target or Insight. File Format is another example.  We want to know what formats are most popular when people download and schedule reports, but you can’t do that in Test&Target.  So Test&Target just doesn’t set that variable.

Category 2 - The variables that are not used in category 1 get used in category 2.  These are customized to the needs on an individual product and are not enabled at the upper level.  SearchCenter bid rules, Discover workspace segments, and Test&Target active campaigns are good examples.  Again, note that within this category, I can reuse the same variable to mean different things since they don’t roll up to the global level.

Category 3 - You can actually treat these as a subset of category 1 because the same rules apply.  They must be implemented consistently through space and time for all products.  Login Company is an example that provides value at the individual level and at the aggregate level.

It was Benjamin Franklin that said “An ounce of prevention is worth a pound of cure.”  A week or two ago I mentioned the measure-once-cut-twice philosophy that could be restated by a web analyst to say that “an ounce of planning is worth a pound of development.”  Or maybe it’s worth a pound of headache.  Maybe it’s worth more.