Web Analytics Applied

Unified Sources

2009-11-11T06:48:44-08:00

Omniture is the market-leader in enterprise web analytics because it is flexible, powerful, and it has been around a long time. But because it has been around a long time, historical legacies in the software have led to patch-ups which newer solutions don’t have to deal with. One such band-aid is the Unified Sources VISTA rule.

I’d not heard about the Unified Sources VISTA rule until about a year ago. But basically, the story, as I understand it, is this: a paid-for campaign, if properly tagged, goes into the campaign tracking code variable in Omniture, with full sub-relations and most metrics available. Organic Search referrals go into the Natural Search reports in Omniture, with only “searches” as the metric, and no subrelations. Other referring traffic, like partner links, or social media, go into the referring domain or referrer reports in Omniture, with “instances” as the metric, and no subrelations. This is how Omniture has been set up almost from the get-go.

Omniture’s clients understandably raised issues with this set-up. They could not run a single report showing them all the sources of visit to their website. So Omniture developed the Unified Sources VISTA Rule. This VISTA rule is designed to take the data from these three reports (campaigns, natural search, and referring domains) and put them in one place. Because the s.campaign variable is automatically set up for full sub-relations, with all metrics available to any eVar, the s.campaign variable was designated as the container for all this information. Additionally, the keyword information (paid and natural, regardless of search engine) was also passed intentionally into a designated eVar. Omniture’s solution is a good one, and the $3000 or so it costs to implement is won back shortly as managers do not need to pore through several reports, or run Data-Warehouse requests, to get a unified picture of site-sourcing.

But the Unified Sources VISTA Rule raised troubling issues as it was implemented on large sites with intense marketing initiatives. These issues came from three places, as I’ve experienced it: reporting legacy, SAINT classifications, and success allocation. In the first case, marketing teams, having implemented Omniture a long time ago, and having developed a reporting template for weekly – or even daily – distribution, suddenly found their reports crowded with referring domains and natural search data. In some cases, the “uniques exceeded” issue cropped up, because even the s.campaign variable has a cut-off point. In other cases, reports on paid-marketing programs suddenly included non-paid data. This led to confusion and a hectic re-working of their existing reports.

In the second case, many of these marketing teams have SAINT classifications that were designed years ago, on which they base internal reporting. The sudden introduction of thousands of new data-elements in the campaign tracking code variable unforeseeably and geometrically expands their SAINT download. The manager who used to spend a few hours doing SAINT uploads now finds herself spending a whole day trying to figure out how to classify referring domains.

Finally, success allocation can suddenly become muddied with the introduction of the Unified Sources VISTA Rule into the campaign tracking code variable. Many teams get their success event data from multiple sources – Omniture, but also third-party advertising vendors, who might manage email campaigns or PPC. Very often, these third parties have implemented a tracking bug (like a spotlight tag) on the “thank you” page, and attribute the success event back to the email or PPC click. These numbers can never be expected to match Omniture’s, but usually they are close enough for comfort. However, with the Unified Sources VISTA Rule, suddenly the numbers drop. This is because the success-event is now no longer be attributed to a paid campaign, but to paid campaigns *plus* natural search or referring domains. The most common setting for campaign attribution is a life-span of 15-30 days, with allocation to “last” or “linear”. Introducing into this variable hundreds or thousands of new data-points dilutes the allocation.

The solution to these issues is to put thought into how the Unified Sources VISTA Rule should be set up. Rather than put the Unified Sources into the s.campaign variable, consider putting it into one or two other eVars. These eVars would have to get full-subrelations enabled, but this solution would allow web analytics managers to get the “unified” view, while at the same time not interrupting the reporting coming out of the campaign tracking code variable.

Web Analytics without JavaScript

2009-09-22T10:58:45-07:00

At the Semphonic XChange web analytics conference, one of the representatives from Yahoo! Analytics made the bold prediction “JavaScript will be gone in 5 years.” The context was a huddle session describing universal tagging strategies, with the idea that data-collection processes, over time, will have to be managed and controlled by in-house, local warehousing, rather than the current web analytics solutions’ “cloud” based on JavaScript tagging.

This is an intriguing prediction, and there are many arguments for this point of view. JavaScript tagging has been around, in force, for let’s say 6 years. Before then, web analytics was a matter of crunching server log files, either locally hosted in a data-warehouse, or delivered to third-party vendors who had internal proprietary software by which to analyze these files and produce reports. With Omniture, HBX, WebTrends, NetInsight, CoreMetrics, and Google, the web analytics paradigm shifted to JavaScript tags, executing image-requests on the page and storing the data externally, which is accessed through an online interface. This has taken off, and I see no reason why this model will not continue to be vibrant in the next few years.

However, and inspired by this comment from Yahoo!, there are valid arguments why companies may start to shift slowly away from the JavaScript tagging model. Firstly, there’s Mobile. Unless mobile technologies universally enable JavaScript encoding, large chunks of traffic to a website will go un-noticed. Non-JavaScript solutions for Mobile tracking are, of course, possible, but these are band-aids used to essentially trick the solution into accepting data through raw image-requests. Such implementation requires many resources, and is often not well-integrated into the overall measurement solution. Not to mention persistent cookies on a mobile device…

Secondly, there is more and more interest in data-integration. Offline data is used to integrate with online data for marketing, merchandizing, and optimization purposes. Purchase transaction data (always more accurate in a back-end system than in a web analytics solution), call-center data, catalogue purchases and registrations – basically, all the tools traditionally managed by a BI team, are increasingly being married to online web behavior. This is all good, but at the same time, does it really make sense to push data to an Omniture or WebTrends if the sole purpose is to pull it back to your database?

Thirdly, there is the increasing issue of cookie deletion and cookie rejection. Whether you’re using first-party or third-party cookies, the elephant in the room suggests as much as a 3-7% rejection rate, depending on what kind of site you have. Media sites have a smallish rejection rate, but it tends to be higher for retail and financial services sites, where visitors are more naturally inclined to increase their privacy settings (and imagine what this rate might be for adult entertainment sites!). Solutions like Omniture can still track visitors based on IP Address or other hints, but customized tracking remains problematic. Cookie-deletion is also a problem: Norton AntiVirus Software now labels DoubleClick, Omniture, WebTrends, and other web measurement cookies as a “non-virus tracking cookie”, with “low risk”, but nevertheless recommends their deletion after a scheduled computer scan. This obviously has an impact on visitor measurement over time. My out-of-the-box Norton Antivirus software runs once a week.

JavaScript-based tagging solutions for web measurement are not going away any time soon, but in five years, the web analytics industry may well start to go back to where we were 6 years ago, using and integrating internal log files and databases. I can only imagine and wonder where we would be now if there were no such thing as JavaScript tagging, and the solutions for log-file integration had been given 6 years to advance.

Web Traffic for Free

2009-01-21T17:55:37-08:00

In this economy, there is growing interest in understanding, measuring, and increasing, the amount of traffic coming to a website from non-paid sources. A year ago, much of the reporting and analysis I did was about analyzing the performance of banner ads, paid search, direct mail vanity URL's, and other marketing initiatives. Now, what people want to know is how much traffic is coming to their website without their having to pay for it. Not surprising, as marketing budgets are being cut across the board. But Web Analytic solutions have not kept up to speed in terms of measuring free traffic accurately, or actionably.

When one thinks about free traffic, one naturally thinks about Organic Search. Surely enough, this is usually an out-of-the-box reporting element in most analytical solutions. But it doesn't tell the whole story. Basically, a "search engine referral" in most web analytics solutions means that a visitor has typed in a keyword on a search engine, and the tag on your website recognizes that a search has taken place. It thus parses the referring URL to populate keyword and search engine reports.

But Yahoo, MSN, and even Google now have many "free traffic" venues that would not be picked up in standard Organic Search Engine reports: blogs, posts, chat, news, and emails coming from search engines might well not have a keyword query string in the incoming referring URL, and may not be counted as Search Engine (free) traffic. To give an example, one recent analysis I did showed that while the analytics solution reported 25% "Search Engine Referrals", in actuality 38% of traffic was coming from a Search Engine site (like Yahoo Mail, or Yahoo chat). This is also why referring domain reports, when parsed manually to look for search engines, usually come up higher when compared to a Search Engine report in a solution like Omniture SiteCatalyst.

Email traffic is part of a kind of referral usually called “viral”, and this kind of referral is usually free. A visitor has seen an offer on a site, or an interesting news story, and emails their friends with the link to the site. Unfortunately, unless these friends are using a web-based email solution (like Yahoo Mail), the referral is un-measurable and appears as a “direct load”. To my knowledge, there is no systematic study that might provide a proxy for how much email traffic is coming to a site that can be related to "measurable" email sources. Such a study would look for measurable referrals, and establish a coefficient which would estimate to the total email referrals based on the sample that is measurable.

The other type of “viral” referrals which has also not received as much attention in web analytics solutions as they should is blogs, posts, chats, personal websites, or other sites with user-generated content. These are picked up as referrers, but unlike search engines, there is no “Blog” report that would identify certain referring domains as blog sources. This can be done manually, but is a tedious exercise. Some sites I’ve looked at receive between 7-12% of their total traffic from these kinds of sources. While it may be difficult to maintain a list of all such sites, certainly the big players in this space like facebook, blogspot, fatwallet, slickdeals, missycoupons, or mommy$avesbig could be flagged by a web analytics tool and categorized.

How can one increase or influence viral traffic? Some sites put up distinct links for “tell a friend about this offer”, or they will put up direct links from their site to other post or share sites. Other managers monitor the larger post or blog sites using their web analytic solution, and will physically go into them to promote a particular product. In any event, as marketing budgets are being cut, one question that naturally comes up is “how much will this cut affect my overall traffic?” Measuring “free” traffic is a necessary step to answering this question.

Referrers: When Bad Practices can be Best

2008-07-02T09:05:39-07:00

Omniture is the kind of tool where redundancy in data allows you to still get reporting and measurement from one kind of report when something breaks in another report. Ironically, sometimes not following “best practices” can provide measurement and reporting capabilities in places you might not expect. When websites are being launched with minimal control over tracking, or convoluted technical impediments to clean implementation, this redundancy or “dirtiness” can be a life-saver for reporting.

Take the familiar “best practice” guideline of filtering out internal domains. When you set up a report suite in Omniture (or an account in HBX or WebTrends), guidelines and support will tell you to make sure you define what your internal domains are, so that these can be treated as “internal” and can be filtered out of referrer reports. Sounds good – internal campaigns, or campaigns being driven by affiliate channels, would be measured and tracked through campaign reporting, with the appropriate campaign tracking codes appended.

But suppose this campaign tracking breaks? Tracking codes from vanity URLs might not be implemented correctly, or the tag is on a page-frame that can’t pull the parameter from the URL, or a dozen other technical bugs might be present that could interfere with tracking these campaigns. Source data is therefore lost, and marketing managers frustrated. But if you did not define internal URL’s, often this kind of data will show up in referrer reports. Here are some of the data we’ve been able to pull from referrer reports because (unintentionally) internal URL’s were never defined:

· Incoming campaign source codes: the parameter is usually still preserved in referrer reports. Data Warehouse can even de-duplicate this for visits metrics.

· Engagement or success clicks from external sources: your media initiative goes to an external website, where the visitor is encouraged to drive to your website. The source code www.external.com/?source=MEDIA shows up in your external referrer reports. Combined with third-part media response reporting, you can get conversion rates without any tag being present on the external site.

· Universal header and footer links driving to your site: your tag may be on the main frame of your site, blind to universal headers or footers. But you might find www.mysite.com/include/header.html in referrer reports.

· Links and pages per visit: when your site is not treated as an internal domain, you might find in referrer reports data such as “www.mysite.com/page2….1,025 instances. This data should be interpreted carefully, but can be used to supplement or reconcile pathing or link reports. Furthermore, unlike these latter reports, you can get data from pages on your site that are not tagged.

· Internal Search Terms: these are usually URL parameters, and if tracking them in a custom variable either never happens or doesn’t work, these can often be pulled from referrer reports.

Am I saying that defining internal URL’s is a bad practice? No – defining internal URL’s makes referrer reports more clean and reconcilable to overall traffic metrics. Without internal URL filtering, these reports should not be digested by anyone other than a web analytics practitioner who can interpret the data correctly. But in messy or uncontrolled implementations across many sites, one might consider NOT defining internal URLs in such places as global report suites, so that some of this data may be available in case something else breaks or slips through the cracks.

Flat CTR’s and Google Enterprise Analytics

2008-03-28T07:32:05-07:00

This week, various news outlets reported the results of a ComScore analysis showing that CTR’s on Google ads have essentially flattened out (http://biz.yahoo.com/ap/080328/google_paid_clicks.html). YOY January data showed no change, while February was up only 3% from last year. This compares unfavorably with the historical double-digit YOY growth.

As a web analyst, there are so many reasons this doesn’t surprise me: AdSense ads have now been around for years, and web-users may have become immune to their novelty; saturation of Google ads on top keywords probably reduces user interest or confidence. But above all, it boils down to the inconvenient truth that as a PPC campaign expands, using new keywords, Content Match, Broad Matching, and the like, the quality of leads goes down, with the result that (eventually) advertisers take notice and scale back. It’s a quality-over-quantity calculation that many times leads to the axing of Pay-Per-Click altogether from a company’s media spend, and there’s very little Google can do about it. When PPC visits see bounce rates of 80% or more, or when brand-keywords are used primarily as a substitute for the browser’s address bar, or when most content match referrals come from AdSense gamesters’ auto-search websites or trashy foreign blogs, no wonder advertisers scale back ad placement on Google.

But advertisers don’t know any of this unless they have a web analytics solution in place. Google’s own spin in response to this week’s articles has been that they are going after quality of clicks, not quantity, in order to make each click more “valuable” to the advertiser. That’s good rhetoric, but how is anyone going to validate this, and what will Google do to act on this initiative? Google’s algorithms are still, after all, CTR-based, because, for the most part, they don’t have insight into website engagement or conversion, for which there are few standards anyway.

Enter Google Analytics. Many have puzzled why Google launched this free application to begin with, much like other free toys available from Labs.Google.com (?Google Mars?). But Google may use this flattening of CTR’s to re-think how they market – and use – web analytics. Google may now discover that it might be worth investing in – and supporting – an Enterprise Level Web Analytics Solution that would be able to measure and analyze all these pieces of PPC engagement. By providing this application (for a price), Google might be able to both control and exploit the data it generates to optimize its ranking and bidding algorithms, while putting some action behind the rhetoric of “more valuable clicks”. It could even do this without the advertiser or client ever knowing, just as Google exploits its page-content databases to syntactically model the English language for Search Algorithm refinement. The dozen or so SEM Analyses possible with a robust, enterprise-level web analytics solution could be automated and streamlined by a Google version – much like Omniture’s Search Center but without the third-partly hassles. And because Google has a vested interest in tying this to its PPC, it can probably afford to price such as solution much lower than those currently on the market.

We’ve often pondered whether Google will enter this space, and one answer has always been, “Why would they?” Flat CTR’s and rhetoric about click-value might be a good excuse.

Web Analytics Overkill

2008-03-19T07:56:50-07:00

When people ask me “what should I track?” my usual philosophy is that tracking should be implemented in such a way as to record in detail anything that is analytically valuable, but also in a way as to make reporting as easy and digestible as possible. In a forthcoming article, I’ll be discussing the last piece of this statement; but I’d like to say a few words about the first piece – the key phrase is “analytically valuable”.

There is such a thing as “overkill” in Web Analytics. It often occurs when there is poor communication between the business requirements group or product owner, and the team responsible for designing and implementing the tags, who decide on a policy of “cover our bases” and tag everything they can think of. This means scores of success events on the site, meaningless variable roll-ups, over-complex campaign tracking codes, and custom link-tracking server requests which slow down performance and result in huge amounts of data within the web analytics tool, the analysis of which would not be worth the effort (literally).

What does “analytically valuable” mean, exactly? It does not refer to data for reporting or KPI’s (that’s what variable structure is for); rather, it refers to a data-set whose comprehensive analysis would be worth the time and resources, producing valuable, actionable recommendations about website design, user behavior, or marketing effectiveness. A deep-dive analysis on usage of the “close” button from different popup windows is probably not worth the money. A team implementing web analytics on a site has to not only ask, “can we capture this behavior?”, but more importantly “can I foresee someone analyzing this data to potentially produce actionable results that would be worth the resources expended?”

This last element is why the overall budget allocated to a website – now and in the future -- should be taken into account when designing a WA implementation. As a web analyst, this may sound like heresy, but in the real world, it’s why mom-and-pop shops choose Google Analytics (if anything) instead of Omniture. Alexander’s Pizza Shop on Main Street might have a website with a menu, directions, and pictures, but obviously would waste its money by implementing NetInsight. It would be dishonest to recommend a state-of-the-art, “measure everything” implementation when it is clear that devoting resources to executing it and analyzing it subsequently would be a waste of money because the website is small-scale and not a significant part of business success. That’s overkill. If it becomes a bigger piece of the business, then a more robust implementation might be warranted.

Even within robust, enterprise-level implementations, measurement overkill is possible. Here are some examples:

· extensive tagging of the footer on a site. “Terms of Use”, “Privacy Policy”, “Corporate Info” – these pages on a website usually exist for legal or compliance purposes, and exhaustive measurement of their usage would make no difference.

· an extensive analysis of a Site Map would probably make no difference either, because they often exist more for SEO than for anything else (though if it’s used more than your navigation, you have a problem!).

· Over-use of campaign classifications: channel, creative, ad type, adgroup, keyword, date-stamp, banner size, link within an email, landing page à all these can be legitimate and useful pieces of a campaign tracking code. But requirements and resources will dictate what is more important; thousands of permutations are possible with all these being tracked in combination, and before implementation, questions should be asked as to whether all of these are useful. A walk-then-run approach might be more appropriate.

· Over-Use of success events: while websites typically can have multiple success events, some implementers take advantage of the availability of dozens of success events to tag almost any action as a separate success event. This leads to opaque reporting because it becomes unclear which of these success events gets included in an overall total effectiveness calculation.

· Over-redundancy in page-naming: some sites record pages as the URL, then pass a user-friendly name into one or two variables, then pass a hierarchically-defined page name into another variable, then pass another variable in an onclick handler recording another version of the page-name of the link clicked on, while also populating site section and hierarchy variables. When a manager wants to see a pages report, they don’t know which one to use: “www.mysite.com”, “homepage”, “hp_”, “mycompany|mainsite|homepage” – you get the picture. And chances are, the numbers for these won’t match up.

There are many other examples, and I’m probably guilty of a few.

I’m not saying that a “measure everything” approach is bad – on the contrary, with analytical resources available it can be a vast asset for value-optimization of the online channel. Rather, I’m saying that a “measure everything” approach has to take into consideration the analytical value of the data, and the resources that would be required to implement and take advantage of it.

The Future of Web Analytics Consulting

2008-02-22T09:11:55-08:00

We recently had a Hajj-like gathering of all Semphonic consultants at the headquarters in California, to plan generally for 2008 and discuss web analytics more broadly. One topic that came up was the question: Will Web Analytics still exist as a separate discipline in a few years’ time? It was an offhand remark during lunch, but left me pondering some basic identity issues about Web Analytics as a separate consulting discipline.

The argument goes like this: companies will eventually realize that online business success is not just complimentary to, or an interesting side of, overall business success, but is actually the same thing. This means that a traditional Web Analytics consulting company will no longer be justified in coming in and optimizing the web channel, but must necessarily focus also on all facets of a given business, both online and offline.

Take advertising effectiveness, for example. Traditional web analysts can analyze the quality of leads coming from all online media – banners, PPC, emails, etc. But increasingly, I’ve seen offline media work its way into the picture: vanity URL’s tied to TV, Direct Mail, or other Print media; call center integration with distinct phone numbers or robust visitor sourcing; online activity correlated with offline spending behavior matched through credit card or telephone numbers; more nebulous but certainly valid concepts like “brand equity” associated with website interaction and compared to offline advertising. Where once online cost-per-conversion was the baseline KPI for advertising effectiveness, we now have “lifetime visitor value” or “lifetime user margin”, encompassing all online and offline customer value. “We propose to analyze and optimize your website” may well give way to “We propose to analyze your business,” in this way of thinking.

Such an expansion is exciting, but also dangerous. There already are numerous consultancies who claim to look at all facets of a business and provide comprehensive consulting around this. These are the Accentures and McKinseys of the world, with vast resources, histories, relationships, and branding, against which any Web Analytics consultancy would stand little chance. Web Analytics consultants have thrived in the last few years largely because such companies do not have the expertise to analyze or integrate web data into the “big picture”, and because the online channel has always seemed independent and distinct, with its own “peculiar” issues and challenges, and managed by separate teams within an organization. But if the online business success starts to be treated (as it should be) as consubstantial with general business success, these consulting directions may start to converge. Along this train of thought, Web Analytics consultants will either be bought up by the big consulting agencies, or will have to diversify or partner in order to tackle the non-web aspects of business success.

I don’t think this has to be the case. Web Analytics can continue to be its own discipline and field of expertise as long as the online channel remains at the core of the consulting engagement. A Web Analyst can be happy to analyze call-center data, but only in the context of call-center savings because the same visitors use the website instead of the telephone. Offline conversions are interesting in so far as the same people can be identified as also visiting the website, or were sourced online originally. By not keeping the online channel as the focus of analysis or consulting, Web Analysts run the risk of losing their identity. In my view, Web Analytics consulting has a future as long as it remains true to its core: the online presence of a company and how it contributes to business success.

A Problem with Coupons

2007-12-14T11:00:34-08:00

Suppose you’ve got a site where, deep in the site, there’s a coupon for some kind of offer. Visitors are invited to print the offer or use the offer to link to a merchant website. Some clients I work with have this kind of setup, and we observed an interesting phenomenon on one of these sites.

There was a large traffic spike all of a sudden to the website one week – in the range of a 50% increase in visits. Something close to this 50% increase was also seen in single-access visits, and time on site plunged. Online campaign data showed nothing unusual, and search engine referrals showed nothing unexpected. It was only when we got to the referrer report, that we realized what was happening.

Someone on two websites – Mommy$avesBig.com and FatWallet.com – posted a blog linking directly to a coupon on the site. Visitors then saw the blog, followed it to the site, printed the coupon, and left.

A successful visit? I suppose if the goal of the website is only to drive people to coupons. But clearly the greater intent of a website like this is to drive visitors to many offers, instill brand loyalty, and get visitors to be otherwise “engaged” through browsing and interaction with the site. This kind of visit described above would be like being led, blindfolded, to one item at Walmart and then being led straight back to the checkout counter. I guess it’s better than nothing, but certainly not the desired or anticipated behavior on a site.

What can one do about it? Don’t ignore these coupon pages as the end-in-themselves. Post attractive links on these coupons to drive people elsewhere. Show them similar items or prominently display a homepage link. In other words, don’t count these pages out as an end point, and realize that they might be the first page people see.

Discover 2.5 and Visual Sciences

2007-12-06T09:53:30-08:00

What Omniture will do with Visual Sciences has been a hot topic – and one we’ll be focusing on during our first Ask Semphonic this coming Tuesday (see http://www.semphonic.com/analytics/asksem.asp). It’s impossible to predict the future, but I’ve been using Discover 2.5 recently, and there are things about it which might be a foreshadowing of things to come.

Firstly, at its heart, it’s still Omniture Discover. If its parents are SiteCatalyst and Discover, the genes are almost entirely the latter. If they try to integrate it with Visual Site, which they’re going to have to do, in my opinion, those same strong genes will trump anything coming from VS.

At the same time, there is a strong SiteCatalyst look and feel to Discover 2.5 – the left navigation and color schemes, for example. Discover 2.5 does not, in its present form, replace SiteCatalyst 13.5, but one has to ask whether Discover’s new look hints that this may be Omniture’s intention down the road.

In which case, what would fill the vacuum created by the phasing out of SiteCatalyst? HBX. Or rather, a product whose parents are HBX and SiteCatalyst. The half-way point between the richness of SiteCatalyst and straightforwardness of HBX would be a product that could be too simplistic for a current, heavy user of SiteCatalyst, thus pushing them to Discover 3.X and producing more revenue for Omniture.

In any event, that’s one scenario worth speculating about. Ask me again on Tuesday.

Omniture Excel Client – How to Deal with Bugs

2007-11-17T12:12:29-08:00

The Omniture Excel Client Tool is indispensable for reporting purposes. It is also as sensitive as Middle East politics. I have very little idea of how it technically works, but over the years I’ve found some practices which help make the tool more reliable.

First, how do you know the tool is broken? Here are some things I’ve seen:

1) Data Blocks return all “0’s” where last week there was real data.

2) Line-items you’ve defined come up now as “Undefined” or “Unspecified”.

3) Instead of the data-block, you get an Excel version of the Omniture Login screen.

4) Your date-range is nonsensical (such as dates in the 1990’s).

5) You get a “No Data Returned” message when you know data should exist.

6) On “refresh”, the data-block disappears and nothing happens.

7) The structure of the Data Block changes (e.g. dates are now left-right instead of top-down)

8) You get error messages telling you that an Excel-referenced value is missing.

If any of these happens, there’s a bug. Here are some tips to try to fix it:

1) Logout, then login again.

2) If you’re trying “Refresh All”, go to each worksheet and use “Refresh Worksheet” instead (Refresh All is notoriously unreliable).

3) Quit Excel and re-enter, opening only the Omniture-fed document (other Excel Documents might be confusing the Excel Client).

4) Do a “Edit Data Block”, don’t change anything, and refresh the request manually.

5) Make sure there are no other people logged on as you in either Excel Client or SiteCatalyst (I don’t think this affects SiteCatalyst, but I know it effects Excel Client).

6) If you’ve renamed the document recently, go back to the earlier version and refresh that one instead (this is a tip for symptom #8 above).

7) Wait an hour or two, use a different computer, change your IP address, or use a proxy server (I think bugs are specific to different Omniture servers).

To avoid bugs, here are some tips:

1) Keep all Omniture Data Blocks in one worksheet, with no formatting, and have forward facing, pretty tables in other tabs.

2) Never insert, delete, or move columns, rows, or cells in the worksheet with SiteCatalyst Data Blocks.

3) Excel-referenced values should be on the same worksheet as the Data Blocks, and should be kept to a minimum.

4) Don’t move around in Excel when you’re refreshing a Worksheet.

5) When designing the Data Blocks, decide whether to have data going top-down or left-right, and keep that consistent.

6) Use the same login when creating multiple Data Blocks. Also use the same Excel version (2003 or 2007) when constructing the document.

7) The tab with the Data Blocks should be called something very simple – no caps, spaces, or strange characters.

If anyone has other tips or tricks, please let me know. The last thing I ever want to do is call Omniture and open a ticket.