Q: You created ActionSource, Omniture’s tracking solution for Adobe Actionscript-based products. What were the business drivers behind ActionSource’s creation?

A: Omniture was actually an early leader in Flash tracking, having deployed a solution which interacted with analytics through JavaScript in the early days of Flash. This solution was a great start for us, helping a lot of our customers gain valuable insight into Flash based applications when it was considered impossible by most of our competitors. JavaScript was our standard mode of communication with Flash for several years.
I joined Omniture in 2004 after running a marketing agency focused on Rich Internet applications. I had been using Flash since version 3 and loved its ability to provide a rich experience that was not limited by the basic functions of web browsers. It offered an opportunity to do things a traditional web browser could never do. That is why it exploded across the Internet, and that is why Omniture needed a solution that could be as flexible as the Flash technology itself.

I helped a number of customers implement analytics in Flash using JavaScript, but quickly found that because the solution was not native to Flash, it lacked key functionality, and even caused some problems with user experience. The most important element missing from the JavaScript solution was the ability to run the solution independently - as intended with Flash. The flexibility to run a Flash based application in a browser, outside a browser, on your domain, in email, or across a distributed network and always have a consistent and rich experience is incredible. If the solution requires an external JavaScript library, this independence is gone. Another important problem with a solution not native to Flash, and using JavaScript is that when the analytics executes the JavaScript, there is extra processing required which often times causes a hiccup in animation or video playback and can cause a “click” sound in many browsers. Finally, there was also a workflow problem. A Flash developer was also required to build an HTML page and include a JavaScript library and scripts. This was never as simple as it might seem.

With the obvious limitations of a JavaScript solution for analytics in Flash, and my background in Rich Internet Applications, I started working on an alternative solution. At first, it was just for fun, but then I started working with companies like MTV, Lexus, GM, and others who wanted a bettertracking solution for their ever increasing use of RIAs. This created a priority, and I started working in earnest on an ActionScript solution. It was fun. I loved the thrill of reaching certain milestones. One that really stands out was in 2005 while Iwas working with a customer in Europe and spent every night of my break working through the night, providing new alpha versions, and talking with the customer on the phone to implement the early version. It worked and they loved it (although my wife would have liked me to spend less time working on my break). My early prototype was successful and suddenly the sky was the limit.

From there I introduced it to Omniture and we started refining and packaging the solution for our customers. Our biggest milestone was when I introduced it at our annual user conference, the Omniture Summit. We had one of the biggest rooms at the conference and it was packed so full that people were standing all around the room. Customers were hungry for a solution that would match the incredible distribution freedom that Flash allowed.

We launched the official solution in the spring of 2006 and we saw incredible adoption. Not only were customers able to understand their Flash based Rich Internet applications as never before, but because of the insight Omniture was able to provide, they had the confidence to deploy RIAs in mission critical areas of their sites. Omniture provided the analytics that enabled companies to use Flash in areas they had never before dared.

Referencing a 2007 Omniture Summit presentation - In 2006 Nike transitioned from all JSP based sites to Flash RIA based sites, and it was only through the native ActionScript solution from Omniture (named ActionSource) that they were able to have full visibility of mission critical metrics and visitor behavior across the application experience from load to purchase. The timing of the Omniture solution for Nike and other customers was perfect as RIAs using Flash really started to go mainstream.

Q: What’s the difference between ActionSource and standard javascript tagging?

A: Standard javascript tagging relies on a javascript file or library and scripts to accompany the Flash file wherever it is deployed in order to use analytics. The primary limit imposed by this approach is that the Flash application is no longer independent and easily distributed. In order to deploy the Flash file and get analytics with javascript, the two have to always be packaged together and this is a major problem with desktop applications like AIR or RIAs distributed across networks, via email, or embedded virally. In addition, the processing required for the javascript communication can cause poor user experience in rich media applications.
The Omniture ActionSource solution which uses native Flash ActionScript is part of the compiled Flash application, so it can seamlessly transmit analytics data wherever the application is displayed and without any impact on user experience.

Q: You’ve continued to innovate around RIA tracking at Omniture. How has ActionSource changed since you first created it?

A: ActionSource was originally intended to provide analytics for Rich Internet applications, primarily around loads, interactions, path analysis, visitor behavior and more. It has been enhanced to ensure compatibility with all versions of Flash, Flex, AIR, and any other Adobe solution which uses ActionScript, including mobile applications and other devices which use Flash Lite.

Omniture’s very talented engineering team now manages the ActionSource component and its ongoing improvements. Most notable of these improvements are media tracking for full analytics of video and audio playback, and integration with our optimization products. Now customers can not only understand the behavior of visitors using their applications, and how on and offline campaigns are influencing these, but they can also understand full streaming data, and using Test&Target they can test variations of their applications and create dynamic and self optimizing experiences within the applications.

These improvements are opening the doors to a whole new generation of Rich Internet Applications. It will be exciting to see what companies continue to do in leveraging these technologies.

Q: You attended and presented at AdobeMax 2009, what did you learn from the Adobe community?

A: It was refreshing to see the excitement and enthusiasm of those who were learning about how they can use analytics and optimization to lead a new evolution in Rich Internet Applications. I presented at the conference showing how analytics and optimization are integrated into RIAs, and the participants were fully engaged and very excited, particularly in the area of the analytics driven optimization. Many talked with me about how this was opening new revenue and creative channels for them. That is where innovation is driven.

The Adobe developers, designers, and creative managers have shaped the current Internet with their cutting edge ideas. As they leverage the new combined technologies of Omniture and Adobe, they will lead a new evolution in Rich Internet Applications based on real-time objective analytics and optimization.

Q: What’s next on your roadmap for Omniture?

A: Existing and future Omniture and Adobe customers will see a continued focus on analytics and optimization across all industries. Omniture is being run as a business unit within Adobe, focused on our core competency which is online optimization. The combination of Adobe and Omniture is a promise of more and better for all our customers, whether they are in retail, media, B2B, finance, travel, telecom, or any other industry. They will benefit from the combined opportunity of Omniture and Adobe. It is very exciting.

You can expect to see a lot of exciting convergences of the Omniture and Adobe technologies. Early on, we will see the existing ActionSource components for analytics and optimization included as options for streamlined instrumentation of these technologies in the Adobe development applications. The net result of this is that companies using Omniture technologies will continue to see the high standards of products and services they are used to, but they will also have opportunities to streamline implementations and improve communication and collaboration across their business units, even extending their ability to optimize their online and offline channels.

Adobe and Omniture are extremely innovative companies, with top talent across multiple industries. The innovations and integration opportunities we see today will be expanded many fold in the months to come as synergies between applications and processes are extended, and as customer feedback helps us find new opportunities.

Stay tuned, you will see a lot of incredible, and value oriented solutions come from Adobe with the Omniture technologies and services. Very exciting.

1. Don’t assume that all of your mobile users execute JavaScript

I don’t know what I would do without my JavaScript-enabled smart phone by my side, but not everyone shares my enthusiasm for constant connectivity and script execution. Measurement on mobile-specific sites should not be implemented using JavaScript. Omniture provides several approaches for implementing these initiatives without JavaScript including hard-coded image requests, server to server HTTP requests, and the Data Insertion API.

But what if you want to track mobile usage of your non-mobile web site? One option is to implement a hard-coded image request on your site using <NOSCRIPT> tags just below your SiteCatalyst JavaScript tags. For example:


/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)//--></script>
<noscript><a href=”http://www.omniture.com” title=”Web Analytics”><img
src=”http://bengaines.112.2o7.net/b/ss/gainesweb/1/H.20.3–NS/41782378?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&c1=blog”
height=”1″ width=”1″ border=”0″ alt=”" /></a></noscript>


If you don’t like this approach, but would still like to seize the mobile opportunity for your business, some excellent guidance can be found in a previous blog post by Adam Greco.

2. Don’t rely solely on cookies—and especially not on third-party cookies

Mobile measurement actually has some huge advantages in capturing visitor data. HTTP requests from a mobile devices often include special carrier headers that SiteCatalyst can use to distinguish visitors from one another. Because these parameters do not change and cannot be disabled or “cleared” (a la browser cookies), they are much more effective at identifying mobile visitors. And who doesn’t want their mobile visitor data to be as complete as possible?

To ensure that Omniture is leveraging these special headers first where available, make sure to include /5/ instead of /1/ in the path of the request. For example,

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&c1=blog" height="1" width="1" border="0" alt="Omniture image request" />

This tells SiteCatalyst to use these headers first, and to set cookies only if the headers are not available (where as /1/ causes cookies to be set and disregards header identification). You’ll get the same effect using the Measurement Libraries for JSP and PHP (which handle writing the Omniture image to the page—perfect for mobile!) to build your image requests by setting s.mobile = true, as explained in the documentation available in the Online Marketing Suite.

Beyond this, keep in mind that many mobile devices (such as the iPhone) have default settings configured to reject third-party cookies. Therefore, even if primarily using headers for visitor measurement, implement a first-party data collection domain for your mobile site. Using a third-party domain dramatically decreases the likelihood that a mobile device will play nice with your analytics efforts.

3. Don’t forget your Traffic Sources reports!

It’s nifty that a standard, out-of-the-box SiteCatalyst JavaScript implementation will automatically capture referrer data. This information serves as the basis for all of the reports in the Traffic Sources section of SiteCatalyst and Discover, and you don’t even have to do much of anything in order to populate the reports. Mobile implementation doesn’t capture this referrer information quite as easily, although making sure that you grab this data isn’t terribly difficult.

Your server will have access to the referrer (in PHP, for example, you can use the $_SERVER['HTTP_REFERER'] variable), so you can simply write this value to the page in the image request. Here is an example of how this might look when finished:

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&c1=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

I should also mention here that the Measurement Libraries do this automatically.

The result is the ability to attribute mobile conversion and engagement to specific referrers, including search engines. Very important stuff!

4. Don’t leave out image attributes

The image tag should have attributes. Make sure to include a height and width of at least one pixel. You never want a border (I mean, unless you want a nice little box around the otherwise-transparent image returned by the Omniture servers), so set border=0. And don’t forget the “alt” attribute, which you can set to anything at all. Each of these is automatic when using s.mobile=true in the Measurement Libraries. Some devices will not successfully request and receive the Omniture image if these attribute are omitted.

5. Ensure image request parameters follow established naming conventions and syntax

As developers can attest, syntax is critical in implementation, and mobile implementation is no different. However, even experienced Omniture developers can get tripped up when setting up a mobile site because, rather than s.pageName, s.eVar1-50, s.products and the rest of the familiar group of variables, you are building variables directly into the query string of the image request using shorter, very specific parameters.

The full mapping of parameters to SiteCatalyst variables is available in published documentation, so I won’t reproduce it here. I will, however, issue a word of caution: make sure that you are using the desired parameter name exactly as written in the documentation! Take a look at the two image requests below.

Request 1

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&c1=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

Request 2

<img src="http://metrics.yoursite.com/b/ss/gainesweb/5/54781023478?gn=Mobile%20Home&g=http%3A%2F%2Fm.mysite.com%2Findex.html&ch=Home&c1=Mobile%20Traffic&ev=event1&v0=mobile_campaign&r=http%3A%2F%2Fwww.google.com/search?q=little+saplings+handmade+toys&cl=blog” height=”1″ width=”1″ border=”0″ alt=”Omniture image request” />

Identical, right? Mostly. The difference is that the first request has “c1=blog” as a parameter. This would pass a value of “blog” into Custom Traffic (s.prop) 1. The second request is definitely not what the developer intended; there, we have “cl=blog” instead of “c1=blog.” The “cl” parameter controls cookie lifetime (the maximum amount of time that the s_vi cookie can remain on the user’s device. This variable is almost never set manually, and the default is five years; by inadvertently setting the cookie lifetime to “blog” (which makes no sense) the actual lifetime will be the session, rather than five years. This would, of course, dramatically inflate visit and visitor metrics and kill any conversion variable persistence every time the user closed his or her browser app. This might be an extreme example because “c1″ and “cl” happen to look so similar—the more common outcome, assuming that the erroneous parameter did not map to an actual variable—would be missing data in individual reports. Still, that outcome can be just as disastrous to your mobile initiatives. So make sure that the parameters in the request match the variables you intend to populate!

Okay, so this “top five” list probably isn’t as fun or philosophical as those recounted by Rob Gordon. . . but I can guarantee that it’s much better at helping you avoid pitfalls of mobile implementation in SiteCatalyst!

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.

Strategic Developments

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.

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