Web Analytics Tool Time

Excel Integration for Google Analytics!!

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. 

Omniture SiteCatalyst Implementation Question Two- Form Lead Tracking

Click here if you would like some context for this Q/A, otherwise please proceed at your leisure...

Question:
What is the process I can use to implement tracking on a short Ajax lead generation form that is designed to convert users’ offline?

Answer:
On the macro level the form page should be tracked as a site page to get exposure to page views, visits and visitors.   Additionally, the form completion page should be tracked as a separate page so that basic conversion ratios can be calculated.  These pages can either be passed into the standard Omniture pages report or their own Ajax specific pages report.  The decision of where to place the pages should be based on if your business views these pages as being seamlessly integrated in the primary site or if Ajax content is differentiated from other pages.  An advantage of tracking the form and completion pages as standard Omniture pages is that you will get all associated pages report including pathing and page time.  

Given that completing this form is clearly a site success it might also make sense to track the completion page as an evar and/or event.  Tracking the initial form page itself in a similar manner could also have analytic value, but should be a lesser priority, especially if you are limited in available evar or event slots.

Looking at the micro level it is possible to implement form tracking on the Ajax form to determine areas that were filled out and overall percent completion.  This type of tracking should be implemented if you would like to have a very detailed funnel report to show visits reaching the form complete page.  If you have worries about users exiting the form due to not wanting to provide required fields, such as last name or email, you might get some insight by implementing this type of tracking.  Additionally, if you think stakeholders will question what is or isn’t getting filled out, then you should implement this level of detail.  With those considerations in mind, in this instance the small size of the form probably would  make detailed form tracking uninteresting and difficult to interpret.  To some extent, that level of detail might muddy the analytic picture and could cause incorrect conclusions to be drawn.  Form tracking should only be implemented if you see a specific need for it.

Depending on your technological barriers this might be an opportunity to marry the offline conversion data with the Omniture API.  By using email address or a back end system identifier you should be able to line up online and offline behavior and establish a true conversion funnel from internet visit source to offline conversion.  If successfully implemented, you should also be able to track post conversion online behavior and compare it to the behavior of non converting form submitters (oh the analytic possibilities!).  

Omniture SiteCatalyst Implementation Question One- Capturing Impressions for Different Ad Types

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 Evolution of Omniture Excel Integration Tools

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.

Surfing Through an Omniture Implementation

As a Northern Californian surfer I have spent many a day in bad waves.  I’d retire (and do pro bono web analytics)  if I had a buck for every time I could describe a surf session’s waves as blown out, chop, slop, ankle biters, flat or close out.  I could turn around at the site of bad waves, but I rather surf in slop than not at all.  Keeping my expectations low on bad days makes just getting in the ocean and getting a few short, unimpressive rides enough to make me happy.  I’ve leaned, the hard way; the same cannot be said for those who don’t understand the challenges crappy waves present.  In the background of an infamous homemade surf video my girlfriend can be heard saying, “Jesse sucks a surfing.”

As a Semphonic web analyst I have spent many days with poorly implemented web analytics tools, and really they aren’t so different from waves.  Not much can be done with a weak web analytics tool implementation.  As an experienced tool user I can recognize an implementation’s limitations, but the untrained eye often expect more than is possible.  Similar to how it is impossible to get a 15 second ride when the waves last three, you cannot report on a metric you didn’t implement.  

There is one big difference between Nor Cal waves and your web analytics tool -- control.  I can forgive the powers that be when bad waves roll through, but for a company that is serious about web analysis a bad implementation is unforgivable.  

But wait…assuming you’re implementing Omniture SiteCatalyst, (and my not so psychic prediction says you are) Semphonic has a product that can help.  Our recently revamped Getting Started Toolkit will walk you thorough developing, deploying, and testing your Omniture implementation. 

Semphonic has approached writing this document first and foremost as web analysts and secondarily as Omniture experts, a perspective you will not get purely using Omniture implementation engineers.  By building or crosschecking your implementation with the Toolkit you can be assured your implementation will be rich and full of analytic possibilities.  Even if you are already using Omniture implementation engineers (and one again my not so physic prediction says you are) the Toolkit can give your piece of mind and save you money. With the document you should be able to more clearly understand what pieces of the implementation your staff can handle, keeping the number of Omniture consulting hours you use down.  For example, the QA checklist within the Toolkit will make it easier for comprehensive QA to be done in house. 

You should avoid explaining why you aren’t capturing an essential metric at all costs, so buying copy of the $895 Getting Started Toolkit should be a no brainier.  Take control of your implementation and you’ll never get the sinking feeling of a surfer staring down blown out, sloppy, close out, ankle biters. 

Transitioning Your Excel Reporting From HBX to Omniture, Part II

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.

Speculating on the Future of Omniture's Excel Client

Usually in the blogosphere someone will write a blog and other people will comment.  I am responding to my own blog, "The Future of Omniture's Excel Client" because:

A. I have more to say that didn't seem appropriate in the more journalistic style blog (couldn't you tell I once wrote microscopic blurbs for a 200,000 copy a day paper?).

B. I fear though that the overwhelming popularity of my blog (Google Page Rank 4/10!) has labeled my writing as untouchable.

My interview with Ray Rauch left a lot to be desired.  Extracting exact details from him was a bit like pulling teeth with no Novocain.  I tugged, he made some noise, but nothing substantial came out.  

On one hand his silence gave me no clear sense of the product line, but on the other hand he left me plenty of room to speculate.  Emphasis in the last sentence should be on "speculate."  Other key words to keep in mind as you read this blog are "guess," "hypothesize" and "don't sue me."

From the interview I truly got the sense that Omniture has done and will continue to do their client needs homework (or they simply read my "Open Letter to Omniture"). In promotional materials and conference speeches, preaching about product development based on client requests sounds great, but I have fears that the process isn't as democratic as it sounds.  The interview left me with worries that Omniture has unequally weighted the needs of the most engaged Report Builder users.  This is perfect for me and the other supertool users, but I have worries that this direction will create substantial barriers to entry for infrequent users.  In addition to committing to adding complex features it probably would have been wise for Omniture to focus on making Excel Client more smooth and intuitive.

The main takeaway clients or potential clients should have about the client induced direction of the tool is be vocal about your desires.  Omniture has promised that if they get enough momentum behind a request it will be put in place (assuming it is possible).  Make them put their money (actually YOUR money) where their mouth is.

The additions that will come first in the "sooner than you think" update are anyone's best guess.  Based on some of the emphasis in the conversation I would think the ability to copy and paste request, with both absolute and relative references, is what we should expect.  Rouch made it very clear that copy and paste was a request they had received from many, many clients so it seems logical it the capability would be in the initial update.  The update also makes sense because Excel Client already has limited copy and paste functionality, so it should not be a stretch to enhance it.

It seems very possible that copy and paste functionality will be integrated into an Excel Client without complementing additions, but I'm going to give Omniture more credit than that.  I trust that Omniture will recognize that without adding the ability to add data blocks without accompanying text, the ability to copy and paste them is significantly less valuable.  The Omniture mandate that all data blocks come with text showing the date range, metric type, etc. in relatively inflexible formats make data blocks big and clunky, difficult to reference and nearly pointless to copy and paste.  

The strength of Report Builders copy and paste functionality come from the ability to set up the cells data blocks will references, whether they be with page names, dates, segments, etc. in advance of building a single data request.  Then being able to build one data request, copy and paste it over and over and have a neat, tidy and compact report before you know it.  

In order to get this type of speed and flexibility with Report Builder my guess is Omniture will install a check boxes or toggle button to allow users to select non-data, written items they would like included in each data request.  Or at very least Omniture will provide an all or nothing button so users can either include all the usual text or none of it.      

In addition to adding robust copy and paste functionally, I would guess the next generation of Excel Client will have one other change, the look and feel.  Although, Omniture acknowledge they were aware Report Builder users loved the interface and process of building data blocks, I have serious doubts an updated Excel Client will resemble anything close to Report Builder.  Given the direction of the Omniture family of products I would guess the look and feel changes would mostly be used to make the tool more inline with the new Omniture Suite.  

This partially makes sense because Report Builder has promised to add functionality to extract Discover data in the short run and probably will add it for other products in the long run.  But unlike the Omniture Suite, Report Builder would probably be better suited for seamless integration of other Omniture products where users are only conscious of the data they want, not whether it is coming from Discover, Search Center, etc.

The look and feel changes that I'm projecting might slightly improve the flow and usability of the tool, but not bring it anywhere close to that of Report Builder.  In my perfect world an updated Excel Client interface would be 80% Report Builder, 10% old Excel Client and 10% Omniture Suite, but I would expect a distribution more along the lines of 50% old Excel Client, 40% Omniture Suite and 10% Report Builder.

When the dust settles on the next round of Excel Client updates I expect to see a prettier tool that is no easier to use but has one significant HBX/client inspired addition.  It will be one step in the right direction, but no giant leap for webanalyticskind.  Omniture will probably still need two more years and two more updates to catch the Excel Client product up to and (maybe) surpass Report Builder.  Sigh.

Author's note- The correct answer was B. 

The Future of Omniture’s Excel Client

Click here to read the introduction to this blog

Out of this year’s Omniture Summit came word that Omniture’s Excel integration product, Excel Client, would be evolved to integrate features of HBXs Report Builder

In late March I had the pleasure of speaking with Ray Rauch, Omniture’s Vice President, Customer Support, regarding the future of Excel Client, specifically regarding the Report Builder additions.  Rauch spent four years with Visual Sciences prior to the acquisition and now and now works with customers currently engaged with or transitioning from HBX.  His team is constantly listening to the thoughts, ideas and needs of clients.      

In the beginning of our conversation, Rauch was surprisingly honest and quick to admit some of the superiorities of the HBX Report Builder tool over Excel Client.  He noted that numerous clients he had conversed with touted the speed and flexibility of Report Builder.  In both those respects Rauch explained that Excel Client has a “poor competitive advantage” and it was something they were aware of and working on.

Trying to get to the details of the tool convergence, I asked some very specific functionality questions during the interview.  They included:

• Will copy and past using absolute or relative cells be added?
• Will the Excel Client interface remain in its current form or will it take no the look and feel of Report Builder?
• Will Excel Client adopt technology that will allow for the full range of Excel formatting capabilities of data blocks?
• Will it be possible to pull single numbers without any text as data blocks?
• Will functionality to Report Builder’s matching and trending be added to Excel Client?
In various ways Rauch acknowledged that just about all my questions were one that had come up in the past, but chose not to elaborate on any in particular.  He suggested that additions along these lines are what Omniture is looking into for the next Excel Client update.

Despite mostly talking in generalities, what Rauch was willing to discuss did in fact turn out to be quite revealing.  He said that a “…tremendous amount of really positive feedback and really great ideas…” has already been collected from clients to help dictate the product direction.   

“Were really hoping…to look into how we can integrate those features of Report Builder into Excel Client.  It’s pretty safe to say that we did not run across anything the customers said that they wanted, that they enjoyed in the Report Builder interface that we couldn’t do under Excel [Client] it’s just a matter of the timing of those specific features and how they’ll be integrated so were keenly interested… that ReportBuild has the best...features”

The convergence of the two product lines will not happen overnight.  Omniture plans to
“…get the most important things out in the first iteration and then evolve the product.”
For the first step in converging the products Omniture appears to be more focused on speed than a comprehensive update as it, “may require a step back…so we can get it out quickly.”  After the first update Rauch explained Omniture will, “Continue to develop that line and mask sure we work with customers over time.” Additional Report Builder functionality will be added, “If we get enough momentum and critical mass behind it…”      

But talk is cheap, when can you expect to see Report Builder functionality in Excel Client?  During our conversation Rauch pointed out that until very recently the two products were developed for many years in separate vacuums and have stark differences that go much deeper than functionality.  Despite the challenges ahead of the Excel Client development team, Rauch sounded confident Report Builder functionality would be found in Excel Client “sooner than you think.” 

Up Next:

Early next week- Thoughts, reaction and speculation for the future of Excel Client
Shortly after- Transitioning your HBX Excel reporting to Omniture Excel Client   

 

An Excuse and An Introduction

Click here to go directly to “The Future of Omniture’s Excel Client,” otherwise go ahead and wade through the following (pathetic) excuse.

A. Stagnant. Neglect.
B. Holding pattern. Pause.

Pick either A or B and you have described my treatment of this blog.  If you look back and see my last post, which promised an immediate follow up, was on February 21st you might pick A.  But let me make a case for B. 

I was planning on writing about transitioning Excel based reporting based on the assumption that HBX’s Report Builder and Omniture’s Excel Client would remain as two (completely) separate tools.  Then flowing down from the mountains of Utah came word that my assumption isn’t quite correct.  The two tools will converge with time. 

At that point I would have put on the breaks, admitted I knew nothing of what Omniture meant by “converge,” and blogged about something else if it wasn’t for one June Dershewitz.  Using her rare combination of web analytics skills AND social skills, she made acquaintance with “someone, who knows some people” (or a fellow in Omniture marketing, but is there really a difference?). 

Apparently Omniture, for better or worse, had been following the Semphonic blogs since they were launched.  In spite of, or as a result of, my previous blogs, Omniture was willing to put me in contact with someone close to the source of the Report Builder- Excel Client tool convergence. 

After an interview with, Ray Rauch, Omniture’s Vice President, Customer Support it no longer seemed appropriate to turn around and immediately blog about converting Report Builder report to Excel Client.  Instead, it made more sense to share my newfound wealth of knowledge about the future of Excel Client.

Making the Switch – Transitioning Your Excel Reporting From HBX to Omniture

Part I: Implementation and Interface

So you’ve looked (hopefully), leaped (bravely) and landed on your feet (hopefully).  You’re now a proud Omniture client, with data coming out of your ears, new platforms to play on and an endless ocean of analytic possibilities.  But before you even begin contemplating your first Omniture based deep dives a series of email pour in, all with the same gist – where’s my daily/weekly/monthly Excel report?  These come in from people who didn’t know about the Omniture acquisition of HBX, that your company has transitioned from tools or exactly how to define a single access visit, the just want their freakin numbers. 

If you haven’t considered how to rebuild existing reporting until the “where’s my report?” emails roll in, you’re already too late.  You have already failed those dependent on you for reporting.  After “looked” and before “leaped” is when you should begin laying the framework for rebuilding existing reporting in Omniture’s Excel Client.  Here is a list (in time relevant order) of steps and considerations for transitioning your HBX reports, especially those of the automated variety, to Omniture.

1.    Its important to realize that many of the HBX interface tools that you can utilize to get reporting data (campaigns, active segments) won’t exist in their same form.  In general, Omniture reports require more forethought and planning because they are more dependent on tagging and less dependent on an interface customization.  Without active segments or campaigns (the HBX kind) to lean on, you’re going to have to start thinking about how they can be replaced with a combination of custom metrics and correlations/subrelations.  It will require a major in shift in thinking going from having a hand full of custom metrics to a boat load of them. And it’s your job to interweave important reporting metrics in the implementation of custom metrics. Often custom metrics for reporting would have been tagged as props or evars anyway, but not always.  Metrics tagged as props are slightly (or vastly, depending on your implementation) different from evars, so be careful when deciding if your metric will be a prop or an evar.  If you have the slots to spare considering doing custom metrics as both, so you get the best of both words.

2.    The other main tool you must consider (A.D. active segments) is correlations and subrelations. Although, these are enabled by calling Omniture, you need to consider them before tagging.  Prop correlations must be set on the same page or a correlation simply isn’t possible.  Subrelations, however, are more flexible since they do not need to be set on the same page and will most likely be integral to your future reporting.  Obviously subrelations/correlations cannot exist in vacuum so as your stretching your mind thinking about your new found wealth of custom variables you have to stretch it further to consider how you want them correlated/subleased and with what.  Personally I’ve always liked puzzles, I hope you do too.

3.    Anyone who spends a lot of time with Omniture will find the words “turned on” and “enabled” seep into his or her frequent vocabulary.  Once your implementation is in place you should make sure to enable visits and visitors for metrics where they are necessary for reporting or might be necessary in the future.  Doing this in advance of needing them will save you a ton of grief.

4.    Once your implementation is in place, correlations/subrelations are connected and visits/visitors have been turned on, spend some time with SAINT.  With Report Builder you might have been using Excel equations, like vlookups, to sum groups of pages or translate page names, but with SAINT this no longer has to be the case.  If your page groupings or lookup tables change more often than each month it's probably easier to continue using Excel equations, but if they are more static take advantage of SAINT.

5.    Even though you lack active segments in SiteCatalyst, Omniture throws you a bone of five ASIs.  You may or may not choose to use these for reporting.  If you do be aware that the bigger the segments population or the more complex the segment the more lag you’ll get on the ASI data.  In general, it’s a bad idea to rely on any ASI for time sensitive reporting in any form.  However, ASI are a powerful tool to help recreate HBX reports in Omniture and if you plan on using them in delayed reporting they should be built as early as possible.

Stay tuned for Part II where differences between HBX Report Builder and Omniture’s Excel Client will be discussed along with the changes you will need to make in your Excel report building technique.  Additionally in II I’ll discuss what the best practices are when you cannot fully automate a report with the Omniture tools available.