Certifications
Posts Tagged ‘Omniture’
OmnitureCare mailbag #2
Time for another installment of OmnitureCare mailbag, where I answer real user questions that weren’t quite long enough to justify their own blog post, but that I think might be helpful to many of you.
On a personal note, I’m busy preparing for Omniture Summit 2010 along with the team I’ve assembled to speak on advanced SiteCatalyst strategies that can help you better optimize your site(s); you can read about it on my Summit 2010 blog. Summit is probably my favorite week of the entire year. Let’s review some of my top 10 personal highlights from the 2009 edition:
- Omniture University training the day before the event.
- Met face-to-face a ton of people in the user community whom I had already gotten to know via Twitter.
- Soaked up knowledge from a great selection of keynote speakers and breakout presenters. Learned more about online marketing than I could have in a dozen semesters of my MBA program.
- Began to really figure out this social media thing, thanks in large part to trailblazers Jeremiah Owyang and Frank Eliason.
- This video.
- Also this one.
- Good food is one of my favorite things. So are hotels, come to think of it.
- Did I mention the people? Oh, wait, I did.
- Brett Error’s feedback session ultimately (albeit indirectly) led to the creation of this blog.
- This photo. That’s Glen “Big Baby” (err, I mean “Uno Uno”) Davis’ NBA championship ring. Am I wearing it? Yup, I am. (Granted, that probably won’t happen this year at Summit—the Utah Jazz are on the road that week—but who knows what else might? Did I embarrass myself by asking Davis whether Kevin Garnett had “mellowed out” since winning a title, only six weeks after this happened, because I hadn’t seen it on SportsCenter? Yes I did.
Anyway, I’m hoping to see many of you there! But enough about me. On to your questions.
Q: How can I tell whether my application will generate server calls or consume API tokens (or both)?
BG: As a general rule, if your application pushes data into SiteCatalyst, it will generate server calls. If your application retrieves data, manages your account, or does anything other than collect data, it will consume API tokens.
Consider the Data Insertion API. It is used as an alternative to JavaScript for data collection, and therefore each post to Omniture’s servers constitutes a server call, and not an API token. You might then use the SAINT API to classify that existing data, but since SAINT classifications are metadata and not actually new data from your web site, no server calls are accumulated through use of this API. Rather, the SAINT API consumes tokens.
Q: My videos are page-agnostic and can play nearly anywhere on my site. How can I see which pages played certain videos?
BG: You can set up a correlation between Video and any traffic property using the Admin Console. This will allow you to break down the video name by a variety of data points. One of the options here is Page Name, but be careful: page name data is not recorded on media image requests. So, just as a correlation between Custom Links and Page Name doesn’t yield data, a correlation between Video and Page Name may leave you wanting.
But don’t fret; there’s an easy way to get the data that you need. On your media requests, set a Custom Traffic (s.prop) variable with the page name. Then correlate Video with that Custom Traffic variable rather than with Page Name. This also works nicely for data points other than page name, such as if you want to see things like video by Flash version (which can also be passed into an s.prop variable).
Q: How can I hide a “base” report from my users while leaving the classification reports based on it available?
BG: In some cases, you might want to hide the report on which your classifications are based, while leaving the classification reports visible. For example, let’s say you wanted to avoid confusion by hiding the Tracking Code report, but you needed the user-friendly Campaigns report to be visible. What would you do? The Admin Console allows you to rearrange, rename, and hide reports on the left nav menu in SiteCatalyst. However, hiding the “base” report also hides any classification reports that build on it.
If you’ve run up against this before, here is your workaround: set up a custom report based on each of the classification reports. You don’t need to customize these custom reports heavily (although doing so might make life easier for your users in many cases!); the idea is just to bring them into existence. Once you’ve got them all set up and saved, go ahead and hide that Tracking Code report. Your users will be able to access whatever classification-based data they need using the new custom reports.
Q: Sometimes I need to know which eVar corresponds to the report I’m looking at, and going to the Admin Console every time is annoying. Isn’t there an easier way to quickly check which eVar is behind the report?
BG: Absolutely there is; at least in SiteCatalyst v14, the secret is in the URL of the report. When the report loads, check the query string in your browser address bar for an “rp=” parameter. It will contain a value followed by a pipe character and then a number. The number corresponds to the variable behind the report. For Custom Conversion reports, this number begins with 101 for eVar1 and runs up through 150 for eVar50. For Custom Traffic reports, the number begins with 3 for Custom Traffic 1 and continues up through 52 for Custom Traffic 50. Hopefully this will save some of you some time.
NOTE: SiteCatalyst relies on URL query parameters to know exactly what data to return. While you can, in some cases, change the number in this query parameter to switch reports, changing to values outside of the ranges described above will return invalid reports, or nothing at all.
Of course, you could make this even easier by appending the variable name to the end of the report name (e.g., “Internal Search Terms [eVar6]“), but that’s your call. You might not like that option because it may lead to questions from other users at your company about these strange values in the report names.
Q: I don’t really care about capturing the browser plug-ins (in the “p=” parameter) that users have installed, and it’s making my image requests too long. How can I keep the SiteCatalyst code from grabbing this information without altering the base code?
BG: Special thanks to Andreas Dierl (@ad0815) for alerting me to this one; somewhat embarrassingly, the ability to prevent the capture of plug-in data (available in the Visitor Profile > Technology > Netscape Plug-ins report) has been around for more than two years, ever since the release of H.11 JavaScript code. If you are using H.11 code or newer on your site, and want to kill this data, simply place the following code within the s_doPlugins() function:
s.plugins=""
(NOTE: It must be in s_doPlugins(); it cannot be set on the page.) And you can do the same thing for any of the following variables belonging to the Visitor Profile > Techology area in SiteCatalyst: s.resolution, s.colorDepth, s.javascriptVersion, s.javaEnabled, s.cookiesEnabled, s.browserWidth, s.browserHeight, s.connectionType, s.homepage.
Before you ask, the answer is no, you cannot really repurpose these variables as new Custom Traffic reports and set your own values into them; they all have a very specific data type, and do not accept arbitrary values like Custom Traffic reports do.
So there you have it; a few good questions and (I hope) answers that will help you out in your analytics efforts. As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter or LinkedIn, or by e-mailing omniture care [at] adobe dot com.
Code version H.21 released
Those of you who logged in to the Admin Console in SiteCatalyst since this past Thursday afternoon to generate new JavaScript code may have noticed that we released code version H.21. The primary purpose of this update was to add ClickMap support for the <button> element, so that you can see the number of clicks on form buttons using the ClickMap plug-in. If need to be able to report on button clicks immediately, you may want to consider upgrading to this new code version after testing it extensively in a development environment.
Speaking of ClickMap support for the <button> element, we strongly recommend using the s_objectID variable in the onclick event handler of your <button> elements. In our experience, use of <button> almost always involves an onclick event handler which performs the button’s practical function (e.g., submitting a form, launching a pop-up, etc.). They never involve an href (and never should). This leaves ClickMap needing to use the onclick function to identify the page element, and this gets messy—especially when you consider that IE and Firefox report them to ClickMap differently.
Fortunately, there’s an easy solution: put an s_objectID variable—with a value unique to each distinct button—in the onclick for the button. For example:
<button type="submit" onclick="var s_objectID='abcd1234';myFormSubmitFunction();">
<button onclick="var s_objectID='some_unique_value';launchPopup();">
(Also, note that while the “type” attribute is not expressly required, when it is omitted—as in the second example above—IE will assume a type of “button,” and other browsers will assume a type of “submit.” This means that depending on which browser you are running ClickMap in to view the page, you will see a different number of clicks for the button, as it will only be reporting on the portion of the data which matches the implied type for the browser you are using. This limitation is also overcome by using s_objectID.)
COGS – Cost of Goods Sold – A Dream Come True
The Cost of Goods Sold (COGS) VISTA solution is one of my favorite solutions because it gives context. As we all know data are basically useless without context and revenue is no exception. What would you rather have A) $1,000 in revenue or B) $100,000 in revenue? Ok, I am obviously going to have a twist here. Here is more context, product A, with $1,000 in revenue only costs $1, whereas product B costs $99,999. I am sure you understand by now that Company A is making more money. They are netting $999 where Company B is netting $1. So in conclusion data without context might lead you in the wrong direction.
The Solution(s):
Adding context to data is obviously important but how to do it is not as obvious. There are three solutions that will solve the problem of getting COGS data into your Omniture reporting.
- First, you can tag the purchase page with an incrementor event that will hold the COGS of the product. The main problem is a web savvy user will be able to see that information.
- Second solution, is to tag the purchase page the same way as you would in the first solution, but instead you can tag with an encrypted value. And you can request a VISTA solution to decrypt the encrypted value.
- The third solution is the COSGS VISTA Solution which will act in the same way as the first and second solution but everything is handled server side. It requires no change to your implementation.
COGS VISTA Solution:
The COGS VISTA Solution is a DB VISTA solution that automates placing an incrementor event into hits with a purchase event. Let’s talk about what you get after everything is setup.
The below image is an example the Traffic Sources > Search Keywords – All report.
There are three metrics in this report that are not normally available.
- Cost of Goods – Is the cost of the goods sold where the user searched for a keyword and made a purchase because of it.
- R – COGS – Is the revenue minus cost of goods sold. This metric is your basic net profit metric. You can use this metric to analyze the true income you get from each keyword.
- Gross Margin Perc – Is the gross margin percentage. In other words, it is the percentage you are profiting from the keyword. If you take a look at the example report you can see “pda” has a 73% margin. That is definitely a search term you want to put more resources into.
Below is a second report SearchCenter > Campaigns.
Again, this report has metrics that are not normally available. Also, this report only works if you are a SearchCenter customer.
- ROAS [COGS] – Is your return on ad spend taking into consideration your COGS. This column will be extremely valuable as you will be given a more holistic view of how your ads are performing. Clients that implement the COGS VISTA solution often find campaigns that are producing negative revenue when they look at the ROAS[COGS] metric. This metric is calculated as such (Revenue – COGS ) / Keyword Cost.
The two reports pictured above are only a couple reports out of hundreds you can pull that utilize the COGS metrics. There are simple reports such as the products report, and there are complex reports such as female users who came from a search engine who posted a comment.
If there is one point to remember from this entire post it is this:
The COGS VISTA solution will give you a more complete view for all reports that involve revenue.
What is needed from you:
The COGS solution needs you to produce a table with the product ID and the cost of the product. This can be done manually and if you have a lot of products or have products that change often then it can be done programmatically. There are a lot of complex systems out there so it is difficult to judge simplicity, but in my experience with my website it took me no more than two hours to set up a script that would update the COGS table once a day. Your engineering department should be able to set up a similar script in a reasonable amount of time.
As always, post your comments or e-mail me at pearcea (at) adobe.com. It is your comments and e-mails that keep me posting and give me ideas for future posts.
Other posts you might be interested in:
- Unified Sources – The DB VISTA solution that makes other VISTA solutions cower in fear
- Excellent Blog Post – Getting More from your Omniture Implementation.
Developer Q&A with Stephen Hammond, Product Manager at Omniture
I recently spent time with Stephen Hammond, Product Manager at Omniture- an Adobe Company, at AdobeMax 2009, where he spoke to the Adobe developer community about trends and technology advances in RIA tracking. Stephen has consulted with hundreds of the Internet’s largest and most innovative companies in optimizing online marketing and developing Internet applications and rich media. During his tenure at Omniture, he developed a rich interactive media player, which streams hundreds of thousands of interactive videos each year, and invented Omniture ActionSource™ a patented solution for measuring and optimizing rich Internet application usage. In this Q&A, Stephen shares his thoughts about the history of Omniture tracking of Rich Internet Applications (RIA), his creation of ActionSource, and the future potential for integrating Adobe + Omniture technologies.
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.
WAA President Responds to Adobe Acquisition of Omniture
I, like probably all of you, was caught totally by surprise by the news this morning that Adobe has bought Omniture. My reactions ranged from “WOW!”, to “Wow!”, to “wow” and pretty soon the emails started arriving from friends in…
Adobe’s Acquisition of Omniture Benefits the Entire Industry
In terms of unexpected prizes, today’s news that Adobe has purchased Omniture is a gold ring for the entire web analytics and measurement industry. There will be a great deal of speculation over the coming days about what this $1.8 billion acquisition means. But a few things are already clear in my mind:
The importance and value of analytics and measurement have never been greater.
Why else, in today’s economy, would Adobe pay upwards of $2 billion for Omniture, a company with a market cap of less than $1.3 billion? The days of best-guess marketing and business investments are well and truly over. Companies are demanding quantifiable results from their marketing and other business investments, and want to be able to consistently use the insight they gain from their web analytics and other measurement tools to improve the performance of their web site, online campaigns and other marketing investments.
I want to congratulate Adobe and its CEO Shantanu Narayen for recognizing the importance of analytics and measurement, and wish them best of luck integrating Omniture into their organization and offerings.
Homogonous solutions don’t work in today heterogeneous business world.
Adobe has already signaled its intention (check out the graphic) to create a closed loop of closely knit content development, publishing and measurement tools for its customers, a large majority of whom reside on the creative side of marketing teams.
Approaches to marketing and other business matters differ from industry to industry. Even businesses in the same industry located on different ends of the same block are likely to assemble vastly different IT and marketing tools. In fact, it’s not uncommon for different teams within the same company to use different tools from multiple vendors. One-size-fits-all, single-vendor solutions simply don’t address such diverse needs. Open systems fueled by standards-based data integration will pave the road forward.
The value of independence and openness are also growing.
I wouldn’t be surprised if other web analytics and measurement providers merge or get acquired by larger companies looking for a piece of an increasingly valuable pie. It’s a simple reality of business in an industry that offers in-demand services.
Omniture’s acquisition leaves Webtrends as the largest independent company in the analytics and measurement industry. Further consolidation would only magnify the importance of Webtrends’ independence, as well as our support for open standards. This approach is already paying off for Webtrends and our customers, who have rewarded us with several of the most profitable quarters in the company’s history over the past years.
As an independent company, Webtrends can continue to create solutions that bring analytics and measurement tools closer to the marketer. We also can continue to address the distinct needs of an increasingly diverse customer base by creating partnerships with other leading marketing services providers. Our support for standards-based data integration and no-fee data access APIs makes integration of our offerings with those of other service providers easy and cost effective.
The result: organizations can eliminate the online and offline information silos that have long stymied their efforts to gain true enterprise-wide insight into their customers and business trends.
Finally, I think one of the really exciting things that might become lost in the ensuing conversation from today’s news, is that our industry still has a long way to go. We have come a long way from simple web site analytics and slogging log files. But there’s so much further to go. Simply put, there is room for more. More innovation, more customers and their deserved satisfaction, and ultimately more economic growth. Adobe’s acquisition of Omniture means more.
