I am running into this issue where I am running an s.prop report using visits as a metric and the total reported is higher than the sum of the line items. I get why the sum of line items can be, and usually is higher than the reported total, but I am seeing the complete opposite. Thoughts?
Regarding total visits displayed in report, it represents the total no. of visits to your site for the selected time range.
It is higher than sum of line items as there may be visits to your site where the user did not perform an action so as to set prop variable you are referring to in your query. Hence, that visit is not credited to any line item.
Hope this helps.
Thank you for your reply. So what you are saying is that although I am running a visits report on prop3 (for example), The total is actually the total number of visits, not the total number of visits where prop3 was set?
Correct, the Total in prop report for Visits metric represent total number of visits to the site.
You may test this against any prop report and you'll get the same Total Visits count.
I have to disagree here.
A prop2 visit report will show at the bottom the total visits (sessions) where prop2 was set. The same applies for all the traffic variables reports. Having the total number of visits reported as the total for the propX report doesn't make sense, and yes, I did check across a few traffic variables out of curiosity.
There must be something related to how Adobe processes the visit count, for instance, it makes sense for the sum of rows to be higher than the bottom total as multiple values for a prop can be set within one visit. I have the exact opposite though.
An instances report will show a perfect match between the bottom total and the sum of rows, however that may not be a good indicator of traffic to the pages/sections as an instance is recorded on every page load and page re-loads can happen for a plethora of reasons.
Do you have an example or screenshot of how your workspace project is laid out? We might be able to provide some more detailed insight there.
here's a screenshot of my report. When adding up the line items, the result is less than Adobe's Total. I do not have any "unspecified" line items.
A couple additional things to try:
- sort the report by visits. It looks like you're sorting the report by another metric.
- segment only hits where the prop in question exists. This will exclude every other hit where the prop isn't present, but if the total visit count is all you're after, this will give you that data.
thank you for the suggestions, both have been applied and the same issue persists. I am thinking it may have something to do with the way Adobe is processing the data. in terms of reporting, my client is expecting to see both the grand total and the single rows. inevitably, the question now is "why isn't the sum of line items equal to the grand total?"
So, for prop2 visit report, you checked, did Total at bottom was different than the value 1,949 shown in your prop3 visits screenshot for that same date range? In your prop2 report, it might be the case you are setting it with some value on each Web page Load in contrast to prop3 where it may have been set for specific pages / action say registration pages only. Just trying to put together my thoughts so as to resolve this question.
Let me know your thoughts.
You are correct, prop3 shows different numbers as it's being used for other purposes. I need to report on visits to certain pages where prop2 is set. Let's say we're looking at a department store and my prop2 is set to identify the store section: seasonal, gardening, shoes, clothing, etc. I am looking at reporting how many visits I got to each department and then the total for those departments. (not the site total)
you can use a segment like this:
"visit" container where "hit"-container has "prop2 exists"
this way you can break down the visits by prop2 and see only visits where in any hit the prop2 is set, the col total is the total to all "prop2" visits ...
thank you for the suggestion. I tried it and it reduces the col total but it's still larger than the sum of line items...
yes, because one visit can have one or more of different prop2. eg. in a visit a user goes to "seasonal", later "gardening" => both row get 1 visit each, but total is 1 visit!
therefore the total of visits must be higher than the sum of the single rows.
following your scenario and logic, isn't the sum of single rows going to be higher than the column total?
gardening - 2 visits
seasonal - 2 visits
if one visit included both departments, we are looking at a total of 3 visits, right?
oh, sorry for that. you're right! the total is smaller than (or max equal to) the sum of the single rows!
regarding your example: if only one visit had a visit in both, youre looking at a total of 3 visits - correct!
The total Visits will be same throughout the tool, regardless of viewing any report. The individual line items sum total will some how differs for different custom reports based on the instances variables are set in the web site. Below link might be of help:
p.s. Best metric for a prop report would be instances for most of the root cause analysis, while for a few business cases, other traffic metrics also plays an important role.
thank you for your suggestion, instances will indeed match but instances also count page reloads and the user movement between pages during the same session/visit.
sorry, can't see the problem
1) did you make a Hit- Segment with defnition prop2 exists?
2) you mean that the sum of all the rows is smaller than the total based ln "visits"?
mayve you can post some more screenshots above those two points...