Sep
21
Last Wednesday, we found out how to make an onion and chocolate sandwich and were left to wonder how it could possibly taste good. With Adobe’s acquisition of Omniture, you can tell that nobody quite gets this one: ADBE stock dipped just slightly, and OMTR hopped up to just under $22 a share, up from around $17 (quite a bump, but still adding up to less market cap than the purchase price, and neither of these responses is anything exciting). So why did Adobe buy Omniture? Let’s take a look at the case.
Financial Reasons
One answer is obvious: now’s as good a time as any to buy Omniture. They’ve scooped up tons of great companies and technology over the past few years (through acquisitions), have a tremendous client roster, and somehow have managed to be squarely in the red almost every year since going public. Adobe must feel like they can manage the business better than the mormons, and they’re buying at a good price.
If you’ve ever been to Omniture Summit or Omniture HQ in Orem, UT, you’ve no doubt realized that Omniture likes things that look cool. They spend a lot on creative work (or have a lot of internal people to do it) because every piece of collateral you touch or presentation you see is filled to the gills with 3D images and fly-throughs that explain their products in more dimensions than you use them. Omniture’s offices are pretty cool, too, but nothing crazy. They’re just pretty cool. You’ll also notice that their employees are paid very, very, VERY well compared to standard Orem, Utah salaries, and that would be okay if their customer service wasn’t such an issue. There are a lot of places for Adobe to step in and manage budgets, without a doubt.
Clients
Adobe has tons of clients. Omniture has tons of clients. They’re probably just about all the same clients…
Business Model
Adobe writes software. Omniture writes software. They both have talented programmers. Check.
Adobe distributes software in boxes and via downloads as client-side design tools, and bills by the product version. Omniture delivers software as a service and lacks the server infrastructure to make the tool as responsive as it should be – and they bill by the byte. This expansion of infrastructure will equal major dollars out of Adobe’s pocket if they want the tool to feel as snappy as Google Analytics any time soon. Ding.
Adobe provides service over the phone or Internet if you have trouble with their software (which is usually your fault). It’s pretty simple. Omniture provides service as a major component of their offering: the tool is incredibly complex, prone to installation error (not their fault), prone to misinterpretation (again, not their fault), and needs a lot of hand-holding. This service model has tiers: account managers for most accounts and engagement managers for big names and big-bucks (or big complainer) customers. Ask any client of Omniture’s what their biggest complaint is. Definitely customer service: the tool is great, but support response time is just awful. Since Adobe has a completely different customer service model, bring out the wallet again! Ding!
The future of computing is definitely software as a service. We have Google Docs, online email, calendars and task management, online photo editors, online design and layout software, and we’re expecting online versions of MS Office in the very near future. So of course, Adobe will want to leverage Omniture’s experience developing online applications, and will definitely want to leverage analytics to improve the user experience over time. No question, although it could be a while. Check.
The Internet, Analytics, etc.
Online marketing is a pie everyone wants a piece of, and integrating SearchCenter into SiteCatalyst was a big step in the right direction for Omniture. While tools like SearchIgnite and Marin still probably capture more interest because of their power in an agency environment, SearchCenter does pretty well and represents a huge investment by Omniture. An investment that has zero benefit to Adobe. Ding.
From a web analytics perspective, it’s a little perplexing until you consider Flash. Yeah, you have Dreamweaver, but that’s so obvious and such an easy cut & paste job that it’s not even worth mentioning (so forget that I did). Getting Flash tracking to be built in without the designer having to do anything is a very big deal, but it won’t be easy to create those hooks. Same thing with Flex/Air, etc. The internet is definitely going the way of the RIA, so an analytics tool that builds itself in is a huge boon.
The trick will be in how to do this. With so much manual naming of page names, site sections, eVars, props, and on and on, these tools definitely aren’t going to do the work for you. There will still have to be a significant amount of strategy developed around analytics, but perhaps with the bonus of not having to worry about tagging. From a time savings and data accuracy perspective, this could be a huge plus.
And comscore?
Now this is definitely worth getting excited about TODAY. Want to know how your page views for yesterday stack up against the industry leaders? Want to know how your conversions stack up? What your traffic source breakdown is vs others? Want to be alerted when your competitor ups their paid search budget? Done. And right next to your data. Very cool.
Hopefully we’ll hear something from these guys on their plans. I’m definitely eager to understand the deal beyond fishing around in the bargain bin.
I’m still confused about…
I still just don’t get it. There are too many places where there is no perceived benefit at all. While there are definitely opportunities to stitch the online components together (creation software like Dreamweaver, Flash, etc.), there are too many places where each company will be speaking a different language. SearchCenter, as I mentioned, will benefit Adobe zero. Photoshop, InDesign, Lightroom, and the majority of Premiere and After Effects will have nothing to do with Omniture. The customer service and sales models are completely different. And Adobe doesn’t stand to benefit from investment in server farms and increased bandwidth for years – until they develop their products as a service.
In other words, the venn diagram that describes synthesis here is just a thin sliver of overlap as far as I can tell, unless the benefits are much farther out than I’m seeing.
Aug
28
Google Analytics Advanced Segment and Custom Report Sharing Going Live…soon
Filed Under Web Analytics News | Leave a Comment
So, the fabled sharing of custom reports and advanced segments is live for select logins in Google Analytics. Guessing this means that we’re going to see this feature released live very soon!
Google Analytics’ Advanced Segments are a powerful way of defining just the cross-section of information that you’d like to see a report for. That might be looking at your Google PPC search campaign, or it might be something as complex as looking at repeat visitors who came in through email referrers and have more than 6 page views. Pretty cool.

As you can see in the screenshots, the new options for “Hide from profile”, “copy”, and “share” are up and running. Also, the same options exist for Custom reports.
Custom Reports, if you’re curious, are a great way to get the exact metrics you seek, when a comparable report isn’t already available in Google Analytics or when you’re too lazy to find it. These are a killer way to see whole numbers for goal completion or get geographic and campaign data mashed up. In fact, they’re a great shortcut for buried reports that already do exist, but a word of caution: the data in custom reports may be sampled and therefore not match exactly to the same built-in report.
Looking forward to seeing these in everyone’s profiles! Not sure how long this has been going, but it’s the first time we’ve noticed it. Kudos to @whitneyhannan for the find.
Jan
15
Many of you probably saw the same email I received yesterday about a whitepaper produced by Tealeaf and semphonic, discussing the virtues of both engaging with and measuring the behavior of mobile web users.
I find myself reflecting on this piece with mixed emotions. Lines like, “the recent entrance of Apple … into the mobile arena,” sting a little bit, since the entrance of Apple into the mobile arena was the entrance of the viable mobile arena itself (in the US), and it really wasn’t “recent”, in industry years (the Internet ages like a dog). On the other hand, this piece is a good reminder of the importance of publishing to mobile users, identifying their unique situation vs. traditional web users, and of course, measuring their behavior to inform the optimization of the mobile site’s performance.
In making its case for the mobile web’s importance to businesses, the whitepaper references an October 2008 study by IBM, a piece I didn’t find particularly compelling. For example, the study cites that 50% of people would either substantially or completely replace their desktop PC with a mobile device. It goes on to say that by 2011, 39% of respondents expected to increase their mobile device use by 40%. To me, these figures seem a little arbitrary - how would your mom respond to the question, “Do you intend to increase your usage of mobile Internet by 2011? If so, by what percentage?”
Mine would probably say, “2011? Sure! I’ll be using it all the time while my new space car is on autopilot!”
It’s important to remember that there are huge differences between the standard and mobile versions of the web, particularly as it pertains to how and when people use each. I don’t think we’re going to hear, “Honey, get the kids and gather around my Treo. I want to show everyone the Wilsons’ pictures from their trip to Hawaii.”
It seems to me that Apple got it dead right in their assessment of the mobile market. In their own documentation to developers, Apple explains that users aren’t using a mobile device like they would use a desktop PC:
Almost by definition, users use iPhone while they are mobile. Whether they’re in a car or a train, sitting in a cafe or on a park bench, taking a walk, shopping, or waiting for an appointment, users use iPhone in environments that are likely to be filled with distractions. This does not mean that your iPhone solution can’t or shouldn’t perform important tasks that require users to concentrate. But it does mean that you must be prepared for the probability that users will not be giving their undivided attention to your content, at least not for long.
Above all, therefore, your iPhone content must be quick and extremely easy to use. You need to grab the user’s attention immediately and help them access the most valuable parts of your content quickly.
But a comScore study quoted in the whitepaper argues the opposite:
Consumption is quickly evolving from brief transactions, such as checking the weather or flight status, to time intensive interaction with mobile Web sites – even without an iPhone.
This conclusion is based on the fact that mobile usage has increased 127% YoY – page views from the 3,500 Windows Mobile, Symbian, and PalmOS devices comScore has in their panel, notably devoid of iPhones. This growth is also a little misleading: the interaction is not getting more sophisticated: it’s getting simpler. Users are spending more time on sites like Craigslist, where one search can render multiple results that a user can quickly duck into and out of. Users are not entering into more complex browsing habits like multi-page drilldowns and shopping carts. The interactions are still light and quick; there are just more of them.
This isn’t surprising, and is probably a result of the proliferation of instant-on data (as opposed to the days of GPRS having to connect), the improvement of device interfaces, and the fact that the average male spends 40 minutes a day in the bathroom*, likely busying themselves with their eBay auctions and Super Monkey Ball (* UK Daily Mirror).
It’s probably true that saying we need to develop product for the present, not the future, is a little shortsighted. But if you’re trying to anticipate and develop for a demand that will exist 12 or 18 months into the future, I can virtually guarantee you that you’re going to miss the entire dartboard.
Toward the end, the whitepaper moves on to discuss the virtues of a customer experience management platform, notably Tealeaf’s. Unfortunately, the piece does so by undermining the virtues of a traditional web analytics system, which arguably is more important in the infant phases of a mobile web site. Not to say that a CEM isn’t important, but it’s not going to help answer any questions like, “Is our mobile site successful?” and justifying the value of a CEM at the expense of a more traditional analytics solution is unfortunate. Truly, a CEM builds on a foundation of understanding brought about through other tools. With a CEM alone, businesses may not have enough context to get the best information the tool has to offer.
Have a look at the whitepaper and let me know what you think, too.
