It’s been a while since I’ve done one of these, and I think it’s about time that I got back to blog­ging about the Omni­ture Suite and not about base­ball (although my pre­vi­ous post was really fun to write). Once again, these are real ques­tions that I have received via Twit­ter and other channels.

Q: How do nested and par­al­lel con­tain­ers work in Data Ware­house segmentation?

BG: You can do some really pow­er­ful things with nested con­tain­ers (i.e., con­tain­ers within other con­tain­ers, such as a Page View or an Event con­tainer inside of a Visit con­tainer) and with par­al­lel con­tain­ers (mul­ti­ple, dis­tinct con­tain­ers at the same level) in your seg­men­ta­tion. It’s a big topic, and I meant to cover it in greater detail here, but let’s walk few just a few exam­ples to get famil­iar with the con­cept. There’s much more to be said, but I’ll leave that for another post.

Par­al­lel con­tain­ers func­tion as an “OR” state­ment if they are not placed within another con­tainer. For exam­ple, let’s look at the seg­ment below.

Data Warehouse segmentation

Notice that both of the Visit con­tain­ers are at the top level, and one hasn’t been placed inside of the other. Data Ware­house will treat this as an “OR” state­ment, read­ing this as, “Include any visit that con­tained a track­ing code of 123456 and where the cat­e­gory was Shoes, OR any visit where the track­ing code was ABCDEF and the coun­try was Aus­tralia.” The use case for this type of seg­men­ta­tion is report­ing that requires, essen­tially, the com­bi­na­tion of two dis­tinct seg­ments. For exam­ple, let’s say you’re tar­get­ing two dif­fer­ent user seg­ments with slightly dif­fer­ent vari­a­tions of the same cam­paign. You might have two track­ing codes, and you want to know how both user groups responded to these track­ing codes, but you’re only inter­ested 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 behav­ior changes when we nest these two Visit con­tain­ers inside of a Vis­i­tor con­tainer, as shown here.

Data Warehouse segmentation

Because the two Visit con­tain­ers are now within a Vis­i­tor con­tainer, Data Ware­house will require that all cri­te­ria be met by using an “AND” oper­a­tor instead of “OR. Data Ware­house would read this seg­ment as, “Include all vis­i­tors who had a visit where track­ing code equaled ABCDEF and the coun­try equaled Aus­tralia, and also had a visit where track­ing code equaled 123456 and where the Cat­e­gory equaled Shoes.” You might find your­self rely­ing on this sort of a seg­ment if, within the nested con­tain­ers, you have OR state­ments. For exam­ple, you want to see all data for any visit that con­tained Page A or Page B, but also where the user saw Prod­uct X or Prod­uct Y.

One final exam­ple shows how you might get data for all vis­i­tors that had at least one visit that met one of mul­ti­ple criteria.

Data Warehouse segmentation

Notice that the Vis­i­tor con­tain­ers are par­al­lel in this seg­ment; as dis­cussed above, that means they will be treated as an “OR.” The effect of this is that Data Ware­house reads the seg­ment as, “Include all data for any vis­i­tor who had a visit where the page name was Board, OR any vis­i­tor who had a visit where the page name was Share.” The use case here is sim­i­lar to the one dis­cussed in the first exam­ple, but allows an extra level of com­plex­ity so that you can slice and dice your var­i­ous seg­ments in any num­ber of ways to get exactly the report­ing that you need.

Q: I have a num­ber of SAINT clas­si­fi­ca­tions, and when I upload data for some of the clas­si­fi­ca­tions deal­ing with cam­paign details, they show up in report­ing as a valid value, but it’s the wrong value for that cam­paign. Why?

BG: The most likely cause of this issue is that you’ve assigned mul­ti­ple “sub-classification” val­ues to the same cam­paign. Let’s say you have a SAINT struc­ture look­ing some­thing like this:

SAINT classification structure

In this case, Cam­paign Type, Cam­paign Owner, and Cam­paign Chan­nel are all sub-classifications of Cam­paigns, as indi­cated by the tree struc­ture. This means that each of these sub-classifications are treated as descrip­tive of the val­ues assigned to Cam­paigns, which is their “par­ent” clas­si­fi­ca­tion. Cam­paign Type describes Cam­paigns. Cam­paign Owner describes Cam­paigns. Cam­paign Chan­nel describes Cam­paigns. What’s the point?

Because these clas­si­fi­ca­tions describe Cam­paigns, they can only be as gran­u­lar as Cam­paigns. In other words, you can’t have mul­ti­ple Cam­paign Type val­ues for a sin­gle Cam­paigns value. A Cam­paigns value can only have one Cam­paign Owner, and only one Cam­paign Channel.

When you see Cam­paigns get­ting tied to the wrong Cam­paign Type (or sim­i­lar clas­si­fi­ca­tion on your account), it is often because you have tried to use two dif­fer­ent Cam­paign Type val­ues for the same Cam­paigns value. When this hap­pens, for a given Cam­paigns 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 Cam­paigns value is “Sum­mer 2010 cam­paign,” and the first five of those rows have “Paid Search” as the Cam­paign Type, and the last five of the rows have “Affil­i­ate” as the Cam­paign 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 rec­og­nize that those clas­si­fi­ca­tions will be used to describe the par­ent, and there­fore can­not be any more gran­u­lar than the par­ent. You can have the same Cam­paign Owner for all cam­paigns, but you can’t have mul­ti­ple Cam­paign Own­ers for a sin­gle cam­paign. If you need to sub-divide on a more granlu­lar basis, con­sider mak­ing the clas­si­fi­ca­tion a peer rather than a child, as this allows you be as gran­u­lar as you want.

Q: Why don’t my Data Inser­tion API posts show up in Site­Cat­a­lyst when I use the <time­stamp> ele­ment as part of the request?

BG: Make sure that your Account Man­ager or Omni­ture Client­Care has enabled time­stamp sup­port for your report suite. Omni­ture auto­mat­i­cally time­stamps all data com­ing into your report suites, but has also added the abil­ity to time­stamp your own Data Inser­tion API requests in cases where you may have some buffered data or his­tor­i­cal data that you want to load into a report suite. How­ever, because this over­rides stan­dard time­stamp­ing, it must be enabled prior to use. Data send into Site­Cat­a­lyst with the <time­stamp> ele­ment will be dis­carded if time­stamp sup­port has not been enabled on your report suite.

There is no charge for using this fea­ture, but keep in mind that a report suite can use either default, auto­matic time­stamp­ing applied by Omni­ture or man­ual time­stamp­ing via the <time­stamp> ele­ment, but not both. Also note that the Site­Cat­a­lyst JavaScript code does not sup­port man­ual time­stamp­ing, so it isn’t pos­si­ble to mix API requests using the <time­stamp> ele­ment with data col­lected using JavaScript in the same report suite. There­fore, you should never ask for time­stamp sup­port to be enabled on your pro­duc­tion, real-time report suite col­lect­ing data from your web site using JavaScript.

As always, I wel­come any ques­tions, con­cerns, com­ments, etc. that you might have about any of these posts (or about any­thing else related to the Omni­ture Online Mar­ket­ing Suite. Please feel free to com­ment on this or any other blog post, or to con­tact me via Twit­ter (@OmnitureCare) and I’ll do my best to get you the infor­ma­tion 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