posted this on July 20, 2010 08:53
To exclude specific tags from a report in GoodData, you can filter any attribute within the "How" section of the report builder.
Is there a way to do this globally?
For example, on our Zendesk we tend to get 50-100 spam tickets per day being created. I've created a reasonably effective trigger which automatically tags them, and then closes them. Thats fine for day-to-day Zendesk stuff, but I want to be able to tell GoodData to ignore tickets with these tags globally - since they account for a non-trivial amount of tickets and would otherwise distort my reports.
Similarly, we use Zendesk to automate certain processes - so when a ticket is received which meets some parameters, its closed and an event is fired on a target. Again, non-trivial volumes, and I'd like to exclude these.
I've sent you an email with instructions on how to filter an individual report. Unfortunately, there is no global mechanism to add a filter to all reports.
The method described above works well to filter values that are included in your report. In this case, the Tag attribute would appear in the report, and the values of "Tag" would be the selected choices.
However, it is also possible to filter items that don't appear in your report. To do this, you would need to select the "Filter" adjustment control and select the "Select from a List of Values" option.
Hope this helps, and please let us know if you have any additional questions or concerns.
Could I have instructions as well? Thanks!
The screenshot in the main post shows how to do this for an individual report. Also, since this question was first asked, GoodData has released a new feature that allows you to add a dashboard filter which would affect all reports on the the dashboard. To see more about this, please see our Release video here:
Hope this helps, and just let us know if you have any additional questions.
The exclusion of specific tags work as above but when used in a headline report, the filter is removed, can you please help?
I'm sorry, there are some confusing items in this thread, and I will try to make it more clear. Most ticket fields have a 1:1 relationship to the Ticket ID. This means that for every Ticket ID, there can be one Group, one Assignee, one Created Date, one Status, etc.
Tags work differently because one ticket can have many tags, and one tag can be on multiple tickets. This is a many-to-many relationship, and to handle this, we need to treat this differently in the underlying data model. The way we treat this is to store each unique Ticket ID/Tag combination as a separate record. This would look something like this:
Now, when you filter for a specific tag, we can say there are 2 tickets with Tag1 (ID0001 and ID0003). However, when you filter for where Tag ISN'T Tag1, then we remove these results from the set, but a ticket can still be represented if it has another tag:
So this is an inherent limitation in regards to filtering where Tag ISN'T xxx.
That said, all filters are still included in all reports, including headline reports. Headline reports are unique, though, in that they only display 1 number. In this case, any Attribute included in the report is not shown, and is removed. However, attribute filters will still be applied to all headline reports.
I am relatively new to GoodData and this is a limitation for us in terms of reporting ticket count. I was advised that there is a way to utilize a metric as a work around, but am having a bit of trouble. I have attempted to use a metric to exclude Ticket ID's with the associated attribute Closed_By_Merge. It seems to me that the MAQL filter acts in the same manner as the methodology you have shown above (July 11, 2012 15:01). Am I approaching this incorrectly in terms of logic/maql or is it not possible due to the underlying data model as a result of the many-to-many relationship mentioned above? Any insight would be greatly appreciated!
My Metric: SELECT COUNT(Ticket Id,TaggedTicketId)WHERE Tag NOT IN (closed_by_merge)
You're right, this is the case I was describing. Excluding things is a bit tricky, as excluding doesn't ensure that the ticket will actually not be counted, since it can still be represented if it has other tags. I am not sure of the exact use case here, but one thing that can help would be this methodology:
1) Let's start with a pre-defined metric, like "# Solved Tickets"
2) Now, let's create a custom metric that counts how many tickets have the "closed_by_merge" tag. This would be the inverse of what you had. Let's call this metric "# Closed by Merge Tix":
SELECT # Solved Tickets WHERE Tag = closed_by_merge
3) With this new metric, we could subtract out this total from any other metrics. So another new metric could be "# Solved Tix minus Merged":
SELECT # Solved Tickets - # Closed by Merge Tix
I know this starts to get confusing, but I hope this helps! Just let us know if something isn't clear or if you have any other questions.
Not being able to exclude a tag such as Closed_by_merge is a huge issue for us.
Metrics for #Solved tickets in Zendesk are useless as we do not know how many of the Solved were simply closed and merged. There is nothing unique about a merged ticket to differentiate it from an actual closed/solved ticket apart from this tag!
Whilst the workaround listed above works fine for a total count of tickets it doesnt help when trying to list accurate data.
For example we would like to establish how many tickets have actually been solved by agents and not just merged. Then from that actual data check which of those tickets have been solved at different groups such as 1st line, 2nd line, 3rd line etc.
The figures when checked added up ok, so all looks like its working until you drill down and check what tickets are included in the count. The following are listed on a report as What, with the How as Month solved.
Overall solved tickets (SELECT # tickets WHERE status IN (closed,solved) = 399
Tickets closed by merge (SELECT # Tickets WHERE Status IN (Closed,Solved )AND Tag = closed_by_merge) = 45
Solved tickets minus merged (SELECT # Solved Tickets - # Tickets Closed by Merge) = 299
399 - 45 = 299 (all adds up so far)
I then drill down to ticket id's for the 299 value, and picked a couple of tickets at random and they were listed as closed_by_merge. So all the minus metric does is change the overall count value not the data within.
How can we report on Zendesk tickets that have not been merged??
I appreciate the limitation with the way in which tags are linked, but we either need Zendesk and GoodData to work together to resolve or advise a suitable workaround that allows us to drill into our metrics and actually use the data.
have you or Good Data recently come up with a solution to better exclude tickets with a specific tag from reports?
In my case this would be tickets tagged 'spam', but also having other tags assigned to them.
I want to be able to completely exclude tickets tagged 'spam' from my reports.
Now, when I filter the 'spam' tag out, GoodData continues to show me all tickets, incl. the 'spam' tickets, that have tags different from spam.
Clearly this does not help me that much right now.
Excluding tickets with certain tags in GoodData is a bit tricky because often tickets have multiple tags.
As Ray mentioned above though you can create a metric that looks at the "# Solved Tickets" that have the "spam" tag and then create a new "# of Solved Tickets" metric that takes the standard number of solved tickets and subtracts the number of tickets that have a "spam" tag. In your reports you would then use the custom "# Solved Tickets (excluding spam)" to see tickets without that tag. Might help to see that in an equation format:
(original # Solved Tickets) - (# Solved Tickets with "spam" tag) = new "# Solved Tickets (excluding spam)" metric
This "# Solved Tickets (excluding spam)" would be what to look at in reports where you need to ignore tickets with that tag.
wanted to get back to you on this topic for quite some time now.
I completely understand the work-around you are describing here, but that does not change the fact that this is all this is to me: a work-around.
It completely ignores the fact that people might be interested in filtering out tickets they consider spam, and that these tickets might still be counted into other tag captions when they are not only tagged spam.
I have a multibrand account (as you personally know, thanks for the help on getting this up and running), so to stay on top of the ticket flow in the future one of the tags each ticket receives is a brand tag.
Now, if I have three brands A, B and C, then it might be that brand A gets 100 tickets out of which 10 are spam, B 100 out of which 20 are spam and C 100 tickets out of which 30 are spam. Now the numbers in the reporting that I could get would be 300 tickets total, 100 for each brand and 60 spam tickets all in all. So wouldn't it be better to just see the following right away:
A: 90 new tickets
B: 80 new tickets
C: 70 new tickets
Don't get me wrong, the bigger my organization becomes, the smaller the problem with the spam tags relatively, especially because with experience and trying out in our mail filters I got the spamming down to the odd test mail or so.
But I do sincerely think that people need to be able to exclude tickets that have certain tags. Right now the filtering function allows me to exclude certain tags, but the tickets are still being counted, if they have other tags that are not filtered out.
In short: I am looking for something that feels a bit more like Pivot Tables in Spreadsheet software.
I am wondering why this seems to be far away from GoodData's or Zendesk's vision for the Advanced Analytics. Am I missing something here? Or maybe misusing?
Thanks for reading this, and maybe you can let Product know that people are wondering.
Just re-read Ray's comments above, and see the problem more clearly now, but still: Is the n-to-n realtionship really that big a problem that you cannot order the data differently? Meaning each tag becomes an attribute in your data model and the tickets get attribute values of ON and OFF for all the tags used in a Zendesk? Or will this make the data model so slow that working on it will become difficult?
Anyhow, I get it, but this is not the most user-friendly solution I could think of for now, so if you have plans to change it, I am all for it.
We recently switched all our project onto our new query engine, which is the machine that calculates all the numbers within your reports. With this new release, we are finally able to tackle this type of question and exclude specific tags from reports! In order to implement this, we invite you to check out the forum post here: https://support.gooddata.com/entries/25065527-Reporting-on-Tag-Isn-t-
So from what I can tell if I mark a ticket Solved this week, but it reopens next week GoodData still shows it as Solved the week before. Is that correct? If so, does it not count it as Solved for this week? Otherwise it seems we are grossly overstating our Solved numbers.
In GoodData, a ticket will always reflect the current state. So, let's imagine a starting point where we have 1 ticket solved last week, and 0 solved this week.
If the ticket gets re-opened, then after updating your GoodData will show 0 tickets solved last week, and 0 solved this week.
When the ticket gets solved, the report will show 0 tickets solved last week, and 1 solved this week.
The data in GoodData will always reflect the most recent state of the helpdesk at the time of the sync.
Hope this helps!
Support Software by Zendesk