It’s mid July. Stepping outside your likely to get a whiff of smoky ribs, boiling chlorine and, if the wind is just right, intellectual X Change. Yes, the X Change Conference is rapidly approaching and less than two months away.
This year the main conference promises to be stellar, with the key note by founding father of web analytics and an impressive huddle lineup, but I'm most excited about Think Tank. Think Tank, which is the newest addition to the X Change lineup, is a series of classes taught by Semphonic and Web Analytics Demystified practitioners that cover everything from building the most functional Excel report of your life to tagging a Web 2.0 site to maximizing value from web analytics within your organization. The idea is that regardless of if you are a analyst, developer, manager or some hybrid, you'll be able to find three perfect classes amidst the many offered that make you better at what you do.
Our promise, as with all of X Change, is that the classes will contain no fluff, no sales and no bull s**t. In short, you won't walk out of Think Tank with the same sinking feeling that your vendor sponsored training left you with.
Think Tank is really a coming out party for many of the folks at Semphoic. Sure you have the rare opportunity to take microscopic (in participant size, not content value) classes from Eric Peterson and Gary Angel, but those guys get out all the time. People like me have toiled for years in the annals of Semphonic, building report after report, doing analysis after analysis and now finally we are being set free. We promise to be socially awkward, pasty white from the lack of sun exposure and covered in web analytics grime be we come packed to the gills with years of daily hands on experience.
In one of my classes, where I will be discussing building dynamic Excel reports, I'll be backed by the experience of building 15 - 20 large scale, dynamic report and in the neighborhood of 500 total web analytics reports. I won't break it down into hours, but that’s a truckload of trial and error that participants will never have to wade through. And Semphonic is no report farm. Everything we do is custom based on client’s specific needs, so the breath of report types and diversity of clients I have worked with allows me to have a variety of vantage points and strategies. My name isn't one that wows anyone in the industry, but I, as well as all the other Think Tank instructors, promise to pack a knowledgeable punch.
To quote a used car salesman I admire, Think Tank "is a screamin' deal!" With three classes going for $599 for X Change attendees or $899 if purchased alone, you'd be hard pressed to find a better way to spend your budget. And while you’re at it, you might as well stay a few more days for the world's premiere web analytics conference.
My colleague, Phil Kemelor, raised an interesting question when he asked is Google Analytics is the elephant in the room for Omniture. To me, the resounding answer must be YES. Google Analytis, especially after its recent update, has and will continue to pluck away low to mid range clients from SiteCatalyst. For better or worse, Omniture has shown an unwillingness to drop annual Site Catalyst contracts below the $10,000 to $14,000 threshold, which effectively removes a potential client base. If I were Omniture the part that would scare me the most is how closely Google Analytics sits from Google's core product. The recent recession, has shown that Google probably stretched their arms too far away from what matters most to them: ad revenue. But Google Analytics isn't an example of Google Video, its use has a direct relationship with ad spending. Should the Google Dragon awake from his slumber tomorrow and decide to truly invest in Google Analytics, the fair maiden atop her perch in Orem should be very afraid.
But I'm not writing this blog to support Phil and his Elephant theory. Instead, I wanted to point out another competitor to our friends in Orem -- themselves.
The typical Google Analytics users, with the low volumes and small investment in web analytics, sit at one end of the spectrum, while mega volume, mondo budget properties reside at the opposite end. The middle group is those who are best suited as Omniture clients, particularly with SiteCatalyst. They likely demand the flexibility, number of custom variables and variety of reporting options available in SiteCatalyst. And, more importantly, their usage volumes fit nicely within the SiteCatalyst framework.
The super sites of the world are a different story. Although it is the pockets of these companies that Omniture dips into the deepest, SiteCatalyst can hardly claim to fit all their needs. With the largest properties, variable cardinality limits, even when bumped to 500,000, can come into play just days into a month. This can leave huge volumes of key data, such as external search keywords, completely untracked. Even in the instance where everything in a particular variable slot is tracked (or a user is content with a fraction of the actual tracking), pulling up reports can be like pulling teeth. As the volume of variables in a report increases, so do the chances it will time out before the user ever becomes privy to the data. Reloading then becomes a game of Orem Roulette. Large site users that struggle to pull up large reports can forget about taking advantage of even basic sorting functions. Care to see a list of top brand keywords? Feel free to download and sort it yourself.
For the largest properties key SiteCatalyst tools like SAINT and ReportBuilder, which are so useful for midsized properties, become afterthoughts. SAINT quickly becomes cumbersome even the most basic classifications are like brain surgery when the volume of variables are staggering. ReportBuilder suffers from the same timing out and sorting issues as the SiteCatalyst user interface.
Without endearing themselves to the largest and most profitable clients, Omniture always runs the risk of seeing them walk away when another vendor creates a superior super enterprise level tool (see first paragraph) or a comparable vendor offers a deal that cannot be refused.
It reality it seems unlikely that there will be a mass exodus by Omniture's largest clients anytime in the foreseeable future. But I hope that doesn't lull Omniture into a false sense of security. Forget the ohh and ahh enhancements, the folks in Orem should make the most basic product features functional for their largest clients.
On June 15th, 2009 the web analytics world was changed forever -- A Excel integration plugin for Google Analytics was launched.
http://excellentanalytics.com/
Ok, ok, maybe I'm being slightly dramatic and maybe that's too much pressure to put in a piece of open source software developed as a thesis project by an intern. Regardless, the sheer demand for an Excel tool for Google Analytics should draw a lot of interest and downloads.
Yours truly is currently configuring the tool and will report back to the world once I have had a chance to review it. Vegas odds are currently 4:1 that it will be less buggy than Omniture Excel Client -- Those wishing to monetarily weight in are welcome to send bets to my onshore bookie.
Naysayer: Two blogs in week? Couldn’t be at tooltime.typepad.com. All that guy does is surface every couple of months to bash Omniture and put me to sleep with the nuances of report building.
Jesse: In spite of the naysayers out there, here is my second blog in less than a week. Some might say that I am doing this only because I have content to repurpose (true). Others will claim it is only to boost my traffic so I can play with the cool new features of Google Analytics (truer). A few might speculate that it is to hock a few more Semphonic SiteCatalyst Implementation Toolkits (truthiness). But the real reason I am doing this is to selflessly give back to the web analytics community (false).
Prior to this year’s X Change conference Semphonic announced a contest where folks in the web analytics community could submit questions about the toughest part of an Omniture implementation. The prize for the top questions would be a copy of the Semphonic SiteCatalyst Implementation Toolkit and all questions, winner or not, would receive a detailed answer from a Semphonic consultaint. In my next three blogs I will post the three winning questions as well as the Semphonic answer to each of them. The winning questions were selected for both the implementation challenges they posed and because of their relevance for a wide audience of SiteCatalyst users. Hopefully someone out there is facing a similar challenge and finds one of these posts relevant and helpful.
Without further ado here is the Q & A for one of the top three questions. You can expect the other two to be posted over the next few days.
Question:
How can I capture ad impressions for six different types of ads, such as paid hero, internal tower, etc., into six different Omniture variables?
Answer:
You most likely can populate a prop and/or evar variable that fires on page load when a certain ad type is detected. Implementing prop and/or evar variables would be easiest and cleanest if you have existing page coding that can identify ad types. In the case that this is not available, you could try hard coding the variables. This approach works if each page on your site is set up to consistently populate ads in the same location(s) upon each load. In a site where the same page will sometimes load with an ad and sometimes without, you will have to implement a check to determine if the ad exists prior to sending (or not sending) the hard coded ad tracking. Unfortunately, if there is no consistency of ads populating on a page and no way to determine within the coding if an ad has populated or not you’re out of luck and won’t be able to get the impression tracking you desire.
Assuming it is possible to implement tracking, the impression variable(s) could be placed in an assortment of Omniture reports. You could populate a prop and/or evar report with the ad types and the impressions associated with them. This prop and/or evar report could look like:
A. Ad type (i.e. tower)
B. Ad type and paid/house (i.e. tower-paid)
C. All ad types and paid/house on page (i.e. tower-paid_hero-internal)
You most likely will want to implement tracking at the most detailed level you would like exposure to. Given that you are only interested in impressions, implementing detailed tracking and using SAINT to roll up to more general categories, like ad type, will give you accurate granular and general impression tracking. If deduplication of visits or visitors might be a future need you should consider implementing impression variables with varying levels of detail in different prop and/or evar slots. Any prop(s) and/or evar(s) should have relevant correlations/subrelations enabled to enhance the analytic capabilities of these reports.
As an alternative strategy, it would be appropriate to utilize an evar counter for each of the ad types. This could give breakdowns of the quantity of impressions by visit, visitor or by custom metric like paid search keyword.
The time has come to kill two birds with one stone: blog and give credit where credit is due. It pains me to say, but the Omniture’s Excel integration product line direction is pretty darn good.
ReportBuilder for SiteCatalyst makes so much sense it’s easy to forget it’s an Omniture product. Allowing ReportBuilder diehards and casual users alike the ability to continue using a familiar reporting product post migration is a welcome nudge in the SiteCatalyst direction. At this point I’d love to say more, but given that I have never touched the product, cannot comment on its quality, usability and similarity to the original.
When I last talked to Omniture I got the impression that ReportBuilder and Excel Client would be converged into a single tool. Farther down the road when Omniture grows weary of supporting two Excel integration tools that still seems like a possibility, but for the time being there are still two to consider. Since Excel Client will live on it nice to see it taking steps forward. The improvements in the most recent upgrade don’t significantly affect the tool’s capabilities but does make it cleaner and smoother.
I don’t know about you but most of the Omniture implementations I deal will overlap props, evars and sometimes even events and apply identical names to all. In the last version of Excel Client this was problematic because identically named reports, with access to different metrics, would sit next to each other in the reports dropdown with no clear differentiation. The addition of notes specifying if a report is a “Custom Conversion,” “Custom Traffic” or other not out of the box metrics type is a welcome, if not long overdue, addition.
How many times have you finely hand crafted an elegant, detailed and perfect data block only to press the “Done” button without ever pressing the “Insert” button? Personally, I’ve never made such a simple mistake, but I figured “you” might have. The combination of the “Insert” and “Done” into just an “Insert” button is beautiful simplification within the updated Excel Client. Now if you fail to select an insert location Omniture politely reminds you, instead of exiting out of the data block wizard. It’s nice to know that even with a brief mental lapse “you” won’t lose more than the time spent daydreaming.
If I have one complaint it’s the redesign of the Choose Date window. The date selector tool is now more convoluted and complex than in the previous version of Excel Client. Omniture would have been fine if they had left the date selector unchanged, but made the “Relative” date range tab the default. Maybe I’m taking crazy pills, but since when does it even make sense to build data blocks with fixed date ranges? Not building (or retaining) a simple date range selection tool with relative ranges as the default is a mistake.
But let me end on a positive, sarcasm free, note. Nice job Omniture. Keep up the good work.
Part II:
Excel Integration Since the Omniture acquisition of Visaul Sciences much has been discussed about the how, why and when to migrate an HBX implementation to Omniture. Semphonic has written a comprehensive implementation toolkit and bloggers far and wide, including my Semphonic colleagues, have mused on some of the finer points of migration.
As far as I have read, though, little has been written specifically pertaining to transitioning physical Excel based reporting. Although, transitioning your Excel reporting doesn’t have the same glitz, glamour and sex appeal (are you laughing, disgusted or just worried about me?) as the greater account migration, it ain’t doing it itself.
In the days following acquisition, when no aspect of the Omniture product direction when unspeculated, I hear discussion that maybe an automatic conversion tool, transferring Report Builder reporting to Excel Client, would be built. I immediately dismissed that idea as somewhere between impossible and insane. Surprisingly enough, however, when I surfaced the idea to a VP at Omniture he confirmed that the feasibility of building such a tool was considered. Alas, Omniture quickly concluded the tool had too stark of fundamental differences, leaving us on our own to rebuild reporting.
Obviously before any Excel based report is transferred you must ensure all necessary reporting metrics will be/have been properly tagged. To read more on constructing a reporting ready Omniture implementation click here.
Data blocks cannot be built around data that has not populated in SiteCatalyst, so if you had plans of building reporting in advance, think again. If possible, you should try to have a month or two (or more) window when both HBX and SiteCatalyst are collecting your web analytics data. Having this window will give you an opportunity to build Excel Client reporting, while still being about to deliver your regular Report Builder reporting. Additionally, it’s the perfect opportunity to determine the differences between the tools (I can guarantee at least small ones will exist) and audit your implementation. Frequently, requesting running both tools in parallel will get push back for development or cost implication reasons, but from a data quality and report development standpoint is largely worth the added challenges and costs.
When it comes time to begin building Excel Client data blocks keep a few things in mind. In 99 out of 100 reports you build, you will want to populate your data blocks in hidden places in the report, most commonly one or several tabs. Text and numbers in data blocks cannot be formatted using the full spectrum of options available in Excel. Refreshing a data block will simply overwrite much or all of any formatting applied. Additionally, you cannot build data blocks without pesky (or helpful, depending on your outlook) headers, like “Most Popular Pages.” To ensure you can build a report closely resembling your existing HBX reporting you will need to apply formatting to forward facing tabs which reference your data blocks.
As you are constructing a hidden data block tab make sure to allocate plenty of space for each block, specifically those that might include additional line items with time. Report Builder simply won’t allow one data request to sit on top of another, but when Excel Client data blocks bleed onto one another things get ugly.
Try to format the hidden data tab(s) in a way that make them easy to troubleshoot. Your first few reports probably will have data tabs with data blocks all over the place, especially reports where new metrics are added over time. Try to learn as you go so future data tabs can be intuitively constructed and have room for report expansion. You’ll have to determine for yourself how you can best group data blocks for easy troubleshooting later. I have seen successful reports built with data block for similar types of data grouped together and others that making the hidden tab roughly resembles the forward facing report.
You need to utilize the tools in excel client to keep the data you are referencing in the forward facing tabs in consistent cells. Be especially mindful of dates as it is a common, but rarely obvious, mistake to reference a correct metric but with an inappropriate date range. Excel Client allows you to select specific items, like page names, so that they will always populate on the same line in the data block regardless of volume. Utilize this feature to keep the cells you are referencing on the forward facing tab consistent. Alternatively, you can pull a large data block and utilize a vlookup, on either the forward facing tab or a hidden tab, to populate metrics in a consistent cell.
Above everything else, recognize the thankless task of transitioning reports will take time. No magic conversion tool will ever do it for you. Not even a “sooner than you might think” update of Excel Client promises to make the process any easier. I haven’t heard any stories of HBX clients postponing a migration to Omniture because they are waiting for improvements to the Excel integration tool, but if you consider yourself in that group (even secretly), stop stalling and start building.
