OmnitureCare mailbag #3

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.

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.

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.

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:

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.