If you're comparing the data on Geckoboard against a report in Zendesk Explore and it doesn't match up, first of all, make sure your dashboard's timezone is set to your Zendesk's profile time zone. Explore uses user profile time zone and Geckoboard uses the dashboard's time zone. Because of this, you may see different results in reports that use dates.
Other common reasons for discrepancies are:
Time period attribute filters
Some metrics in Zendesk Explore allow you to pick specific time period attributes. For example, for First Reply Time (FRT) in Explore you can choose to have the metric filtered on Ticket updated_at date, Ticket solved_at date, etc.
In Geckoboard, time period filters are predefined for each metric. For First Reply Time, we use Ticket created_at date. We do this because the question the FRT metric commonly answers is “How long does it typically take for an agent to respond to a ticket after it’s first created?” and filtering on Ticket solved_at date, or any other time attribute, would not answer that.
Here's a list of the time predefined attributes we use:
All tickets, New tickets, Open tickets, Pending tickets, On-hold tickets, Unsolved tickets, Unassigned tickets: no time attribute, all-time but limited by the bounds of the import
Received tickets: Ticket created_at
Solved tickets: Ticket solved_at
First resolution time: Ticket solved_at
Full resolution time: Ticket solved_at
First reply time: Ticket created_at
On hold time: Ticket updated_at
Agent waiting time: Ticket updated at
Requester waiting time: Ticket updated_at
Satisfaction rating: Rating created_at
Updating On-Hold tickets outside the initial data import
It's possible this discrepancy is being caused by the initial import range, which is the past 30 days. When you initially connected your Zendesk account to Geckoboard, we import all tickets that were updated_at in the last 31 days. If tickets in the On-Hold status have been updated outside of this time frame for the initial import of your data, they won't be included – initially.
Triggering a supplemental data import
We have a method of triggering a supplemental import of data beyond those 31 days we brought in. To trigger a supplemental import, you can set one of your Zendesk Support widgets to a date older than the initial import (i.e. it will trigger if you set a date to Past 90 Days).
Note: There is a limit of 120 days due to what data is offered via the Zendesk APIs. Anything older than 120 days that has not been updated within this time period, won't be included.
Unlike Geckoboard, Explore isn't a real-time reporting platform. In Explore, data syncs hourly for Professional plans and every 24 hours for Lite plans. Explore's new Enterprise plan has a Live dashboard that's closer to Geckoboard as its data syncs faster than every hour and all other dashboard's data sync hourly.
Geckoboard, on the other hand, syncs data every 10 minutes.
Date ranges used
Equivalent Explore and Geckoboard queries and metrics might be filtered by slightly different time ranges. For example, the default "Ticket created - Last 7 days" Zendesk Explore metric looks at the last seven days starting from yesterday. This ensures that it always returns data for seven full days.
In Geckoboard, a similar metric looks at the seven days starting from today to ensure the data on your dashboard is up-to-the-minute fresh.
Field value changes reporting
Each ticket update consists of multiple field changes which are submitted by agents or automated by the system. Zendesk Explore records only one field change per update per field, but Geckoboard records all changes of the field. For example, a ticket status was changed from Pending to Solved by the agent and during the same update, a trigger changed the status to Open.
In Geckoboard this ticket is considered as reopened because one of the status changes was Solved to Open. However, in Explore this ticket will not be counted towards the Tickets reopened metric as it considers the Solved status an intermediary change corrected by the trigger.
Geckoboard calculates SLA metrics using fulfil events on the ticket metrics endpoint this differs from how Explorer calculates SLA metrics. We are currently working on matching our formula to Explore's