It’s been a while since I’ve done one of these, and I think it’s about time that I got back to blogging about the Omniture Suite and not about baseball (although my previous post was really fun to write). Once again, these are real questions that I have received via Twitter and other channels.

Q: How do nested and parallel containers work in Data Warehouse segmentation?

BG: You can do some really powerful things with nested containers (i.e., containers within other containers, such as a Page View or an Event container inside of a Visit container) and with parallel containers (multiple, distinct containers at the same level) in your segmentation. It’s a big topic, and I meant to cover it in greater detail here, but let’s walk few just a few examples to get familiar with the concept. There’s much more to be said, but I’ll leave that for another post.

Parallel containers function as an “OR” statement if they are not placed within another container. For example, let’s look at the segment below.

Data Warehouse segmentation

Notice that both of the Visit containers are at the top level, and one hasn’t been placed inside of the other. Data Warehouse will treat this as an “OR” statement, reading this as, “Include any visit that contained a tracking code of 123456 and where the category was Shoes, OR any visit where the tracking code was ABCDEF and the country was Australia.” The use case for this type of segmentation is reporting that requires, essentially, the combination of two distinct segments. For example, let’s say you’re targeting two different user segments with slightly different variations of the same campaign. You might have two tracking codes, and you want to know how both user groups responded to these tracking codes, but you’re only interested in how Group A responded to code ABC, and how Group B responded to DEF. . . but you want it in one report. The method described above is your answer.

This behavior changes when we nest these two Visit containers inside of a Visitor container, as shown here.

Data Warehouse segmentation

Because the two Visit containers are now within a Visitor container, Data Warehouse will require that all criteria be met by using an “AND” operator instead of “OR. Data Warehouse would read this segment as, “Include all visitors who had a visit where tracking code equaled ABCDEF and the country equaled Australia, and also had a visit where tracking code equaled 123456 and where the Category equaled Shoes.” You might find yourself relying on this sort of a segment if, within the nested containers, you have OR statements. For example, you want to see all data for any visit that contained Page A or Page B, but also where the user saw Product X or Product Y.

One final example shows how you might get data for all visitors that had at least one visit that met one of multiple criteria.

Data Warehouse segmentation

Notice that the Visitor containers are parallel in this segment; as discussed above, that means they will be treated as an “OR.” The effect of this is that Data Warehouse reads the segment as, “Include all data for any visitor who had a visit where the page name was Board, OR any visitor who had a visit where the page name was Share.” The use case here is similar to the one discussed in the first example, but allows an extra level of complexity so that you can slice and dice your various segments in any number of ways to get exactly the reporting that you need.

Q: I have a number of SAINT classifications, and when I upload data for some of the classifications dealing with campaign details, they show up in reporting as a valid value, but it’s the wrong value for that campaign. Why?

BG: The most likely cause of this issue is that you’ve assigned multiple “sub-classification” values to the same campaign. Let’s say you have a SAINT structure looking something like this:

SAINT classification structure

In this case, Campaign Type, Campaign Owner, and Campaign Channel are all sub-classifications of Campaigns, as indicated by the tree structure. This means that each of these sub-classifications are treated as descriptive of the values assigned to Campaigns, which is their “parent” classification. Campaign Type describes Campaigns. Campaign Owner describes Campaigns. Campaign Channel describes Campaigns. What’s the point?

Because these classifications describe Campaigns, they can only be as granular as Campaigns. In other words, you can’t have multiple Campaign Type values for a single Campaigns value. A Campaigns value can only have one Campaign Owner, and only one Campaign Channel.

When you see Campaigns getting tied to the wrong Campaign Type (or similar classification on your account), it is often because you have tried to use two different Campaign Type values for the same Campaigns value. When this happens, for a given Campaigns value, SAINT will use the last value in your upload for the given sub-classification. So if I have 10 rows in my SAINT upload where the Campaigns value is “Summer 2010 campaign,” and the first five of those rows have “Paid Search” as the Campaign Type, and the last five of the rows have “Affiliate” as the Campaign Type, all 10 rows will receive the value “Affiliate.”

How do you get around this? The best way is to ensure that when you set up sub-classifications, you recognize that those classifications will be used to describe the parent, and therefore cannot be any more granular than the parent. You can have the same Campaign Owner for all campaigns, but you can’t have multiple Campaign Owners for a single campaign. If you need to sub-divide on a more granlular basis, consider making the classification a peer rather than a child, as this allows you be as granular as you want.

Q: Why don’t my Data Insertion API posts show up in SiteCatalyst when I use the <timestamp> element as part of the request?

BG: Make sure that your Account Manager or Omniture ClientCare has enabled timestamp support for your report suite. Omniture automatically timestamps all data coming into your report suites, but has also added the ability to timestamp your own Data Insertion API requests in cases where you may have some buffered data or historical data that you want to load into a report suite. However, because this overrides standard timestamping, it must be enabled prior to use. Data send into SiteCatalyst with the <timestamp> element will be discarded if timestamp support has not been enabled on your report suite.

There is no charge for using this feature, but keep in mind that a report suite can use either default, automatic timestamping applied by Omniture or manual timestamping via the <timestamp> element, but not both. Also note that the SiteCatalyst JavaScript code does not support manual timestamping, so it isn’t possible to mix API requests using the <timestamp> element with data collected using JavaScript in the same report suite. Therefore, you should never ask for timestamp support to be enabled on your production, real-time report suite collecting data from your web site using JavaScript.

As always, I welcome any questions, concerns, comments, etc. that you might have about any of these posts (or about anything else related to the Omniture Online Marketing Suite. Please feel free to comment on this or any other blog post, or to contact me via Twitter (@OmnitureCare) and I’ll do my best to get you the information that you need.


So in your second exapmle it means Visitor { Visit [(ABCDEF) AND (Australia)] AND Visit [(123456) AND (Shoes)]}. A Visit with the tracking code ABCDEF in the category Shoes and a second Visit from Australia with the tracking code 123456 is not sufficient. Right?

Ben Gaines
Ben Gaines

Nic, That is correct, and I'm glad you pointed it out. It would have to be in the same visit. Thanks, Ben