Add page URL as default breakdown in data warehouse



without passing URL into a separate prop, one can't report on it in Data warehouse.

URL is in the data feed, why can't it be in the data warehouse?

8 Comments (8 New)









Thanks for your suggestion.  I'd like to ask a follow-up question.  How will/do you use URL in data warehouse reports? How is it useful to you?  Thanks very much,





I AGREE!  I NEED THIS!  We DO pass the url into a PROP but do to bad coding, sometimes it's null or plain old wrong.  We have lots of issues whereby maybe a url is recorded to one report suite & yet not our global when it should.  It would be IMPOSSIBLE to check out every page of the site to make sure it's coded to both.  If I could run URL in datawarehouse for the Global report suite and the subordinate report suite, I could then do a reconciliation to see what urls are not hitting both.


Another reason to have URL in DW is that sometimes our developers reuse the same page name for multiple pages...and then what ends up getting passed into the prop which is suppose to be url is garbage.  If I had the url in DW, I could easily run a segment saying give me all urls associated with those pagenames.



There are literally tons of uses for URL in a DW report. while we all probably pass some variant of URL into a prop, there are just times, like cgg above state, where the code might be wrong. Another example might be conversion funnels. For us these are highly dynamic and it is tough to get a read on them using the basic pagename variable.


Also, because of multiple query strings and complex URLs, one can't pass everything easily into a prop. by putting URL in the DW, we'd make the Site Catalyst tool that much more useful.



Yes, I completely agree!  I was literally SHOCKED when I realized that URL was not included in the data warehouse.  This is the most obvious element to include, it blows my mind why it was missed.


Matt, to answer your question: Without this feature, you cannot determine the difference between paid and organic search in the data warehouse because the Omniture data warehouse also does not include a paid/natural flag!  Since I'm in charge of Search Analytics, this is a serious problem.



I agree!  I spoke to ClientCare about this a few weeks ago - this is a MUST!!



Having the URL would allow for a lot of troubleshooting capabilities, rogue tracking codes, bad parameter passing for campaigns (site parameters, not like cmpid), landing page issues (coding), etc.



This would be a HUGE help for troubleshooting and auditing since Data Warehouse can utilize segments.  Data Feeds are sometimes too much to handle when you want to slice and dice data, especially when having to do event lookups.  Although storing it in a prop and/or eVar isn't difficult, it typically isn't setup when you need this and doing historical reporting on the page URL is nearly impossible.