Any help with this would be great. I use Adobe every day and so fully understand why this isn't straight forward but I am looking for a work around if anyone know a solution.
I am trying to build the table below for error reporting using a freeform table for errors (tracked as an eVar):
Last week = 1,000 visits
|Visits||Percentage of visits with this error|
|Error Code 1||100||10%|
|Error Code 2||40||4%|
|Error Code 3||30||3%|
|Error Code 4||30||3%|
|Error Code 5||20||2%|
The closest I have managed to get is to simply hide the number on the visits metric leaving a percentage. Problem with this is that I don't want unspecified, and if filter out "unspecified" my number drops from 1,000 to 160 or so, meaning the percentages are out.
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
If you are building this in Analysis Workspace, by default metrics included in a Table show both numbers and percentages. If you hide the Unspecified value, the percentages appear should show you the Percentage of visits with this error. What it won't do, however, is show this in a different column. If you want a separate column called "Percentage of visits with this error", you could create a calculated metric that only includes visits and is called "Percentage of visits with this error". Once created, drag it into your table, click the gear icon next to the metric name, and update the "Table cells" section to only include Percentages.
EDIT: I misinterpreted what the original ask was. You are looking to compare visits with a particular value for this eVar to all site visits. The option I presented above isn't going to show that. Changing the visit metric type to "Grand Total" instead of "Standard" won't work in the calculated metric builder won't work because you are applying the metric to a table with the dimensions listed. Another option is to create a calculated metric for each of the values in the dimension, e.g. "Percentage of visits with error 1". Unfortunately this isn't the most scalable solution.