Our Merchandising Consultants have been preaching to you that you need to pay attention to not only failed searches, but also your Top 100 successful keyword searches. What does this exactly mean? What should I be looking for in my reports? How should I approach analyzing my data when it comes to “search”? What defines a “successful” search?

The primary purpose of the Quality of Search (QoS) testing that our consultants teach you is to ensure that the results we’re returning are as relevant as possible – indeed a very important part of the optimization process, but that’s just the beginning. Basic QoS testing directs you to look at your Top 100 Searches sorted by ”Instances” or the number of times that a particular term has been entered into the search box on your web site.

Now if you really want to optimize site search you need to sort and analyze these reports in a variety of ways – slicing and dicing the data. You may be surprised by what you find when you start looking at your internal search reports from various angles, not just instances. Consider looking at your top searches by conversion, orders, AOV, visits and total revenue.  You’ll be surprised by what you learn.

Next you need to run through the customer experience. What is the customer seeing when they search for these terms? Are they coming into the site from a Google search and have landed on an internal Search Results page? Is the messaging clear and the refinement path intuitive for that customer so he or she can narrow the search accordingly. Where are shoppers falling out after they have executed a search?

The data is there, but what you do with the data determines whether your site search is optimized or only randomly relevant. The process is not completely scientific or mathematical – rather, it’s a blend of art and science. This requires that your merchandisers and analysts engage in equal amounts of right brain/left brain activity – balancing intuition and creativity in terms of what is a great shopping experience, with analysis and metrics-based merchandising.

Having an in-house creative services team has been viewed as a luxury to mid-market companies, or a burden to the enterprise. “Our agency does that…” Right, and you pay for it in money and time. The traditional procedure is to hire an outside agency, or contractor (usually Web first, print second) to handle your creative projects for you. But this model presents a number of challenges.

A Real Need for Real-Time

An in-house team provides you with immediate access, flexibility and an ability to react and optimize in real-time. Even minor changes to a Web site like a banner, a page update or a new offer take several days; as you contact your agency, pay out the wazoo and then wait for them to make the change. Take that time and cost, multiply it over a year, and you’ll end up with a number that you won’t like. You probably would have paid for 2 or 3 in-house people that would have actually gotten the work done on time with less supervision.

Instead of viewing creative resources as a cost-center, there are a number of reasons to change your view to see it as a profit-center, with a potentially high return on investment-if running correctly.

So how do you align your in-house resources to support your direct marketing initiatives? There are a few key areas that will optimize your creative team to become a valuable resource in your marketing programs.

1. Put Your Money Where Your Mouth Is

• Headcount: Invest your headcount by supporting programs that have a tangible impact on your business. It is essential to have someone-in the marketing team-that is managing your Web site. Probably a couple actually.
• Budgets: There are a couple of ways to manage your money. Either to outsource everything to contractors and agencies, do it all in-house, or both. Print is much easier to outsource than Web, though banner production can be shipped out.

2. A Little Help for Your Friends

• Make sure your objectives are aligned with the objectives of the demand team. Objectives should be something like: supporting campaigns and programs, support brand and awareness and general services.
• Teach each member of your creative team demand principles. Guide their solutions to business and creative problems toward improving response either through copy, creative or a combination of the two.

3. Don’t Go Following the White Rabbit

• Focus efforts on demand creative. Prioritize demand-creation projects (offers, landing pages, banners, etc.) over projects that yield lesser tangible results (like t-shirts, or mudflaps for your boss’s truck).
• Avoid distractions. Its easy to get caught up on details, or pining over perfection, rather that getting solutions to market.

4. Nothing Wrong with Cookie Cutters

• Templates are your friends. Banner, headers, guides, whitepapers, product overviews, landing page mark-up and even some email can be outsourced. Original concepts should be home-grown, but all production should be outsourced to allow your designers to move on to the next project.

• Why doesn’t the sum total of visits from each line item in the Pages report add up to the visit total at the bottom of the report?
• Why doesn’t the sum total of orders from each line item in the Products report add up to the order total at the bottom of the report?
• Why doesn’t the sum total of [any success metric] from each line item in my merchandising eVar report add up to the total at the bottom of the report?

When users ask this question (in any of its forms), I typically explain that the report in question involves a one-to-many relationship between the metric being viewed and the line items in the report. But this explanation can be difficult to grasp. I have been trying to come up with an analogy to help explain these phenomena, and I think I’ve got one. I’m hoping it will clarify this behavior for you, or will help you better explain it to the users at your organization.

There are few things that I enjoy more than relaxing on my couch on an autumn weekend (in between home improvement tasks requested/mandated by my wife, of course) and watching football from all across America. Being the sports geek that I am, I often have my laptop by my side so I can check scores and stats from games that I’m not watching. The reason I mention this, and as the title of this blog post suggests, there’s an apparent statistical anomaly in football that parallels this behavior in SiteCatalyst.

When a quarterback throws for a touchdown, someone has to catch the pass—usually a wide receiver. When this happens, the quarterback’s numbers reflect that he threw for a touchdown. At the same time, the wide receiver’s numbers show one touchdown:

If you didn’t know better you would see a touchdown tallied on both the quarterback’s stat sheet and on the wide receiver’s record and conclude that the team must have scored two touchdowns, and therefore that this represents 14 points (two separate touchdowns). Of course, this isn’t actually the case. There is simply a one-to-many relationship between touchdowns and players involved. There is no way for these statistics to show both players involved in the touchdown without showing a touchdown associated with each of them.

Hopefully I haven’t confused you. (If you’re a hockey fan, there’s a similar analogy in there, where two players can be credited with an assist on a single goal. And if you’re not a sports fan at all, hopefully the rest of this post will still make sense!) Consider the order discrepancy described above in the list of questions. Here’s what a typical order might look like.

s.events="purchase"
s.products=";Macbook 13.3-inch;1;1199.99,;Adobe Photoshop CS4;1;799.99,;Kingston DataTraveler 16GB Flash Drive;1;39.99"
s.purchaseID="220236197"

Based on this order, in the Products report you’d see something like this:

The line items add up to three orders, but there was really only one order—you saw it above—so how should SiteCatalyst handle this?

Show 0.3 orders for each product, so that the line items add up to one? Well, that wouldn’t be quite right, because then you would see a bunch of strange numbers that wouldn’t give you a real sense of how popular an item is; its popularity would be determined in part by how many products belonged to the order (e.g., an order with five products would assign 0.2 orders to each product, but an order with 10 products would only assign 0.1 orders to each product).

Show the summed total of the orders from each line item at the bottom of the report? That might lead users to think that your site had a lot more orders than it really did.

Instead, SiteCatalyst shows the site-wide total regardless of the sum of the line items.

De-duplicating your favorite metrics

Saying that you need to add up the metric totals for various line items for any reason is really just a way of saying that you need classifications around your report values so that they’re grouped appropriately. For example, why would you add up the orders for all product names containing the word “shoes” other than to get a sense of the total orders for shoe-related products (taking into account that some orders may involve multiple such products)? This can be accomplished using SAINT classifications and Omniture Discover.

After all, it might be hard to make sense of exactly how many points a football team scored just by looking at the individual players’ statistics, but the handy “scoring summary” that you’ll see in newspapers and on web sites will correctly pair quarterbacks with receivers to give you a better sense of how much scoring really went on:

Now that clarifies what happened! Randy Moss, a receiver, caught a 14-yard pass from the quarterback, Tom Brady. And we can see that the New England Patriots scored once, not twice. We’ve de-duplicated the number of touchdowns that the team has scored.

To de-duplicate your data and show the exact total number of [metric] that occurred across multiple line items in a report, create a classification category to meet your needs and apply the necessary classifications to group line items in the parent report however you need them.

When these classifications sync into Discover, you’ll be able to go to the associated report, add the Orders metric, and see de-duplicated orders within that category as a line item. To continue with the example above (products containing the word “shoes”), if an order contained five product IDs that involve the word “shoes,” and you add a category classification and label each of these product IDs as belonging to the “Footwear” category, then you will correctly see one order for the “Footwear” category in Discover when you run the report that corresponds to the classification you’ve set up (e.g., Product Category)—even though this order involved five products.

And there you have it. Hopefully this clarifies (at least a little bit) what can be a confusing situation for many users. And unfortunately for me, I’ll never again be able to look at football statistics without thinking about de-duplication.

As always, please feel free to follow me at OmnitureCare on Twitter and/or FriendFeed. I’m also available by e-mail at omniturecare@omniture.com and would love to hear from you via any of these channels!

Partner Enablement API
The partner enablement API includes web services for integrating data and configuring integrations between partner applications and Omniture. Using the partner enablement API, a partner can map and test the data exchange between apps, then easily expose their integration within Genesis so customers can use the drag and drop interface to automatically connect integrations to the Omniture Online Marketing Suite.

In the past, it took a lot of teamwork between partners and Omniture to build new Genesis integrations and expose them in the suite. The new APIs give partners greater independence in the process, which should result in richer and more robust integrations along with faster upgrades to integration functionality. With over 200 Genesis partners, it’s important that our partners are as self-sufficient as possible in building and maintaining their integrations… this new partner enablement API does just that.

Developer Sandbox (Beta)
In addition to the partner enablement API, we’re also rolling out a Beta developer sandbox for select partners. The sandbox is designed to give partners a full-featured SiteCatalyst development environment with access to both the partner enablement API and all product APIs that currently support the suite. These include:

• Data Import APIs - these APIs enable the import of product and content classifications for enhanced SiteCatalyst reporting, import of data from internal or third party systems for combined measurement of offline and online marketing initiatives and the ability to perform server-side website data collection
• Reporting API - this API enables third-party applications to access SiteCatalyst’s core report data
• Administrative API - the Administrative API allows third-party applications to configure SiteCatalyst user permissions and report suite access
• DataWarehouse API - the DataWarehouse API enables partner applications to define and export targeted visitor segments for remarketing campaigns

In addition to API access, the sandbox also provides a live demo data feed that automatically populates the development test report suite with artificial hit-level data. Developers will also have the option of uploading their own test data to an empty demo report suite.

While still in Beta and available only to select partners, Omniture intends to provide access to the developer sandbox to all partners, including our 500-plus channel partners, over the course of the second half of 2009. That’s a very large pool of innovators and potential innovation wating to be unlocked. The possibilities are endless … new marketing automation tools, segmentation and targeting across multiple marketing channels and technologies, and advanced predictive analytics are just a few things that come to mind.

Partners interested in accessing the sandbox should contact their partner account manager to request participation in the beta program. To learn more about becoming an Omniture Partner please visit http://www.omniture.com/partners.

Typically, we would treat these uncontrollable phenomena that affect unique visitor tracking a fact of life in the web analytics game. Matt Belkin has blogged about this extensively right here on Omniture.com. The method I am about to suggest is definitely not for everyone and should only be considered where a system is in place to assign unique IDs to individual visitors in a reliable manner. By this, I mean that the unique ID must be assignable to a user on every single request that the user generates, without exception. It’s an awesome solution in the right environment—intranets, webmail apps, desktop apps, etc.—where you have a way to identify the user on every page view. If there are “‘logged out” page views, though, please proceed with extreme caution.

I should note that it’s also great for sites that, for whatever reason, do not want Omniture to set a cookie. This doesn’t necessarily get around cookie deletion and other similar limitations of visit/visitor measurement, but setting s.visitorID will prevent new s_vi (visitor ID) cookies from being set on users’ computers. Thus, the variable allows you to set your own visitor ID cookie and pass its value into SiteCatalyst.

(Admittedly, what I describe below doesn’t completely address the need of the user who originally asked me about it. I think it’s still worth covering, though.)

Beginning with code version H.9, the SiteCatalyst JavaScript code allows you to assign your own visitor ID to users on your site; the Data Insertion API contains this functionality in the form of the <visitorid> element. This means that can marry a visitor ID to each user ID on your site and then pass that visitor ID whenever the given user ID views a page on your site. For example:

Then, whenever a user hits your site, your servers would detect the user ID (e.g., bgaines), and look up the appropriate visitor ID from the table (16278468165) and place this into the s.visitorID variable:

s.pageName="Intranet Home Page"
s.visitorID=”16278468165″
s.channel=”Home”
…

This is actually pretty cool. Cookies are a good method for associating visit/visitor behavior (as described in a previous post), but if you can assign out your own visitor ID values, you aren’t bound by cookie deletion or any of the other limiting factors mentioned above. When a user logs in, you can track him/her as a unique visitor regardless of browser/computer/cookie status. (Yes, this also means you can track visits for users who do not accept persistent cookies. Huzzah.)

A few warnings straight out of our Knowledge Base:

• As described above, you must be able to set the s.visitorID variable on every page of the visit. If you cannot do this, then the s.visitorID implementation is not for you.
• Similarly, if set, the s.visitorID value for a visitor should not change (in other words, if I can navigate your site anonymously and then sign in, only then allowing you to know who I am, make sure that this does not cause the visitor ID to change). If this cannot be reliably achieved, we recommend against this implementation strategy.
• Any existing Omniture-set visitorID (stored in the s_vi cookie) will be migrated to the new s.visitorID value one time without cliffing the visitor (counting the visitor twice and inflating visitor counts.
• We recommend pushing the update at the time of least traffic to the site. When the update is pushed, any active visits will end causing an inflation of visit counts for the day. If the update happens when traffic is minimal, you reduce the effect of the spike.

The reason it’s so important to be perfectly consistent in assigning visitor IDs when using this system is that if Omniture code ever does not see an s.visitorID value, it will set an s_vi cookie, and begin to count data for a new visit/visitor. If you then begin to pass an s.visitorID value mid-visit, SiteCatalyst will use that instead, thus counting a new visit where there wasn’t really a new visit. Consider a user who views a “logged out” page and receives an Omniture visitor ID in the s_vi cookie. Then the user logs in, and his username is mapped to the visitor ID pulled from the s_vi cookie. Later, using a different computer, the same user hits another “logged out” page and receives a different visitor ID from Omniture. He then logs in using his former username.

Now you’ve got a problem: Either you change your mapping to reflect the new visitor ID, or you change the visitor ID that you’re using for this user. Either way, you’ve just inflated your visit and visitor counts. If you want to track logged in users across browsers, my recommendation is to just track the logged in pages of your site so that the non-logged in hits won’t inflate visitors. Most sites don’t have enough logged in users for this to be practical, but many do (such as webmail, intranets, on-demand software, etc.).

As described above, implementing a system such as this can allow you to track visitor-based metrics (e.g., Visit Number, Original Referring Domain, etc.) without relying on cookies. This means that, for some types of web applications, a person who last visited your site in 2006 from Sheboygan, Wisconsin, using IE 6 can be identified, three years later, as the same person now logging in from Liverpool, England, using Firefox 3 in 2009.

As always, please feel free to follow me at OmnitureCare on Twitter and/or FriendFeed. I’m also available by e-mail at omniturecare@omniture.com and would love to hear from you via any of these channels!

The desire of our clients to run these tests probably has a lot to do with the state of the economy. It’s no secret that a Flash homepage is much more expensive to maintain and to make changes to. It’s also makes it more cumbersome to make quick updates to the page, or to test new concepts. Don’t get me wrong - no one loves a useful Flash homepage more than I do. But most companies simply don’t have the in-house skills to keep a Flash page updated.

For each of our clients, the tests were very simple. Point 50% of users to the default, Flash version of the homepage, and point the other 50% of users to a static version of the homepage. In both cases, the static version retained much of the functionality of the Flash version; however, the static versions often got users to content faster. For example, on an insurance company’s website, the Flash version played a video when a user clicked on a type of coverage, while the static version took people directly to the coverage page.

In both tests, the business users behind the tests were rooting for the static versions to win. They wanted the ability to update their pages more easily, without having to go through a lengthy production process. Essentially, the original decision to use Flash on their site was taken without a clear business need.

And the results?

For the major insurance company that we worked with, we were able to declare the “static” version as the clear winner. There was no negative impact on leads generated for new policies when serving the static version. More impressively, pageviews to internal site pages increased by more than 40%. This led us to start planning a new test to optimize lead generation from those internal pages.

For the office products supply company, the static version also performed better than the Flash version on all key metrics, although by a smaller margin. However, this test was definitely a win for the client. By moving to a static page, our client now has much more freedom to quickly update the homepage with new content and offers, sparing precious internal resources.

Remember that a static page by no means implies a boring page, or a page without a lot of great features. In fact, the static versions for our clients often maintain much of the most important functionality of the page.

So, when does Flash make sense for your site? First of all, look at your site from your users’ perspective. Is the Flash serving a real purpose for your users, by adding meaningful functionality? If so, Flash will likely outperform a static version of your homepage. If, however, you’re using Flash for eye candy, or because you’ve been told that everyone is doing it, then a test might be in order. If you can give yourself more control and flexibility without sacrificing performance against key metrics, why not try it?

As always, post your comments or e-mail me at paurigemma (at) omniture.com.  It is your comments and e-mails that keep me posting and give me ideas/material for future posts.  If you do decide to purchase a Engineering Services solution than make sure you mention the blog and I will make sure you get extra special care.

What is Unified Sources?
Simply put it is a combination of the campaigns report and referrers report, giving you a single report with all your paid campaigns and non-paid campaigns.  The other feature is it grabs the keyword and places it into another eVar for simple keyword reporting.

How is Unified Sources Valuable?
Value is unique to each business and their needs, but let me highlight a couple benefits of the rule.

• Event credit is applied to all traffic sources based on the same rules that apply to campaigns. This allows you to more accurately measure how well each traffic source or campaign ultimately results in conversion.
• The keyword placed into an eVar by Unified Sources is the actual keyword searched for by the visitor. If you are using broad match for your Paid Search and capturing the broad search terms into another eVar (via SearchCenter or otherwise) you can break down the keyword you paid for by the actual keywords that the visitor searched for. Keywords that are performing especially well or poorly can be discovered and your paid search efforts modified accordingly.
• Natural Search terms can be classified for simplified SEO reporting and analysis.

Requirements for Unified Sources VISTA Rule:
This rule requires little to no work for you.  If you are already populating the s.campaign variable or another eVar with your tracking codes then you are all set. The only thing we need from you is to know which eVar you are placing the tracking codes in, whether we should use that eVar or a separate eVar for the main Unified Sources report, which eVar you would like us to place the keywords into and finally we need a list of internal domains.

Internal domains list - The confusing part of the rule:
This is usually the most difficult part to understand when requesting a rule but it really is simple.

If you have one main site and all report suites are based on traffic from the one main site then all you want to do is provide a single list of internal URL domains and you are done.

If you have multiple sites and you want to see how traffic goes from one site to another (ie. consider traffic from one of your other sites as “external” traffic) then you want to provide us with a list of internal URL domains for each of the report suites you plan to put the rule on.

If you need to be able to change the list of internal URL domains for your report suites on a regular basis then we can build another DB table into the Unified Sources VISTA rule that will allow you to upload a new list of internal domains whenever you want.  This does add cost but it will save money if you have to alter your list of internal domains more than twice.

The icing on the cake:
As you can imagine, a single list of all your tracking codes, organic search sites and referring domains will become quite bulky. Once the rule is in place you may want to classify the Unified Sources eVar in ways relevant to your business to take full advantage of one of the most useful solutions Engineering Services has to offer.

If you already have Unified Sources VISTA solutions, how do you use it?

If you don’t then feel free to send me an e-mail ( paurigemma (at) omniture.com)  with questions.  Or contact your Account Manager and they will help you get started.

]]> http://blogs.omniture.com/2009/06/09/unified-sources-the-db-vista-solution-that-makes-other-vista-solutions-cower-in-fear/feed/ http://blogs.omniture.com/2009/06/09/unified-sources-the-db-vista-solution-that-makes-other-vista-solutions-cower-in-fear/ http://feedproxy.google.com/~r/omniture/blogs/all/~3/aujbGGeD3GQ/ http://blogs.omniture.com/2009/06/08/managing-implementation-on-multiple-sites/#comments Mon, 08 Jun 2009 14:40:54 +0000 Ben Gaines http://blogs.omniture.com/?p=274 A fellow SiteCatalyst user recently asked me via Twitter how best to manage deployment on multiple sites. Many companies operate several distinct web sites; consider a firm that owns multiple brands. If I own BrandA and BrandB, the odds are that each of these brands will have its own site.

This can become problematic as the number of sites you’re managing increases. Let’s say Omniture introduces new functionality in the core JavaScript file (s_code.js). Now imagine that you’re managing 500 sites, each with its own implementation and JavaScript file. Suddenly, if you want to upgrade to the latest release, you may need to make 500 separate updates. This can ruin your entire month.

Generally speaking, with a few major exceptions (discussed below), we have found that using a single, global JavaScript file across all sites is tremendously advantageous in cases such as these.

As one Omniture consultant managing the implementation for a large international brand told me, “This is exactly what we did for [customer]. Now, if we release a new feature in the JavaScript code, I can have it up and running for [customer], worldwide, after testing, in about five minutes.” When you compare that to the amount of time required to roll out a similar change across dozens or hundreds of sites, each with its own s_code.js file, it’s utterly minuscule.

At the same time, using a single JavaScript file across sites may require significant forethought and a solid strategy during initial implementation (or re-implementation). A potential problem with using a single JavaScript file across multiple sites is that different sites may use variables differently. Certainly, the s_account variable (which stores the destination report suite ID), will likely change from one site to another. But the s.linkInternalFilters variable (which controls exit link tracking), s.trackingServer (first-party cookie data collection domains), and other variables may need to be populated dynamically based on the domain or some other site-specific criteria.

Many variables, such as those mentioned above, are common to all implementations and report suites; every site will need an s.linkInternalFilters value. But what happens when one report suite uses eVar1 to store internal search keywords and another suite uses eVar20 for this same purpose? How can you ensure that each site passes the data into the correct variable for that particular site?

The preferable option here is to standardize variable usage across sites and report suites as much as possible. Even though various sites may have diverse KPIs, there are likely items that you will want to track across all sites. Campaigns provides a common, if simplistic, example. Plan in advance so that all of your sites will use s.campaign to track external campaigns and, say, eVar7 to track internal campaigns. Where query parameters are involved, use the same query parameter to store tracking codes in your URLs across all sites (for example, “cid=”).

Where this isn’t possible, I’ll show in the example below how you can fairly easily ensure that variables are populated differently and correctly based on the domain (or some other criteria).

Example

Let’s consider BrandA.com and BrandB.com, both owned by the same company. It would be great if both brands used a single JavaScript file; that way, when you need to make a change, you can do it one place, one time, and then it’s done across all of your properties. To do this, you would have a single s_code.js file hosted somewhere accessible to both sites. Within the file, you would detect the domain that the user happens to be on (either branda.com or brandb.com), and then set s_account accordingly. For example:

// set report suite ID dynamically based on domain
if(document.domain.indexOf('branda.com') > -1) {
     var s_account = 'brandacom'
} else if(document.domain.indexOf('brandb.com' > -1) {
     var s_account = 'brandbcom'
}

And you can do similar things to set any other variables dynamically based on the domain of the site being accessed. For example, you would also need to set the s.linkInternalFilters variable in much the same manner.

// set s.linkInternalFilters dynamically based on domain
if(document.domain.indexOf('branda.com') > -1) {
     s.linkInternalFilters = 'javascript:,brandacom'
} else if(document.domain.indexOf('brandb.com' > -1) {
     s.linkInternalFilters = 'javascript:,brandbcom'
}

It may be that the sites you manage have already been implemented, and already use the same variables in different ways. In that case, you can use the same logic just described to change the way that these variables are used

// populate the internal search keywords into various eVars depending on report suite
if(s_account == 'brandacom') {
     s.eVar1=s.getQueryParam('kw');
} else if(s_account == 'brandbcom') {
     s.eVar23=s.getQueryParam('keyword');
     s.prop5=s.getQueryParam('keyword');
}

Where there is a large number of variables being used for different purposes across report suites, consider populating them on page itself, rather than in the global JavaScript file. Variables, once allocated for a specific reporting purpose, are not likely to be reapportioned frequently, so putting them on pages typically will not require a bunch of maintenance. This also helps to keep the size of the global JavaScript file under control.

Why you would not use a single JavaScript include

I’ve spoken to a number of members of the Omniture Consulting team, and all agreed that the solution described above is ideal in many cases. There are a couple of reasons why you might not want to handle multiple sites this way:

• Imagine that you work for consultancy that manages the SiteCatalyst implementation and reporting for a wide array of its own customers. Since these customers are distinct entities, each will have its own site to manage. However, you may not want Customer A to see all of the specifics of Customer B’s implementation. In these cases, you may need to use separate JavaScript files for business reasons.
• Hosting a global JavaScript file in one place means that all of your sites will be hitting a single server to retrieve it. This can dramatically increase the demands on that server, potentially affecting site performance if the number of page views across all sites is large enough. This will vary from company to company and from server to server, so unfortunately I can’t suggest a number of page views at which point this would become problematic.
• If the number of sites that you are managing is small enough—say, two or three—it might be enough work to set up the dynamic population of variables that it’s easier just to maintain separate files.

Conclusion

For me to believe that a blog post could answer all of your questions on this topic would be presumptuous in the extreme, but I hope this discussion at least gets the wheels turning at your organization if you’re facing this sort of a situation and don’t know how to handle it. I hope it’s clear that the suggestion to use a single, global JavaScript file isn’t necessarily for everyone, but that in many cases it can make managing a SiteCatalyst implementation multiple sites much easier.

As always, please feel free to shoot any questions/tips/suggestions to me by leaving a comment on this post, via Twitter (@OmnitureCare), or by e-mail (omniturecare@omniture.com). I always enjoy hearing from you!

I like the catchy name, I like that they’re calling themselves a “decision engine” and I like the way the ad campaign tied in the recent financial meltdown, but most importantly I like the way they’ve targeted “head” queries. It’s true they do not do as well on “tail” terms if you’re looking for a very specific response (their database is clearly not as large as Google’s), but I like how they categorize results for queries like “San Francisco” by showing top results then Weather-related results…

…then Hotels, Restaurants and Maps below that.

To truly compete with Google and gain 30-50% market share, they’re going to have do a lot more. I’d like to see them do the following and really change the Search game:

• Buy Twitter: real-time search is here to stay and would be a welcome addition to Bing’s search results

• Integrate Display ads into their search results

• Introduce CPM pricing to the Search world for brand campaigns: many search marketers simply want impressions on high volume queries or to support large brand campaigns, why not give them what they want?

• Maintain their high quality content network but get into the long-tail content network Google is currently dominating

• Fight more aggressively on distribution relationships - they may never wrest AOL from Google given the Tim Armstrong relationship, but if they’re willing to spend $100MM on an ad campaign they should be willing to pay publishers higher rates than Google

• Compete more aggressively for mobile search volume

• Integrate Bing all throughout the Microsoft product suite: I’d like to see a search box on every Windows desktop, a search box in the top right corner of Excel, Word, Powerpoint, Outlook and so on, a search box in the Windows Media Player and on and on. People want to search the Web from whatever application they’re in so let’s get the Bing people to walk across the Microsoft campus to the Windows building and integrate Search into everything Microsoft does

• And finally, they should buy Yahoo! Search: this last move would certainly make the game more interesting and provide a viable threat to Google

Let’s hope Bing is more than just a flash in the pan and continues to make interesting, aggressive moves in the next year. The Search market needs diversity and so far Bing is showing they came to play.

For more on how Omniture has quickly responded to the Bing launch, see this great post from Ben Gaines.