Data discrepancies between Zendesk Explore and Geckoboard

Learn why you might be seeing different numbers in Zendesk Explore than on your Geckoboard widgets.

Updated over a week ago

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

  • Created 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

Sync times

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.

Mismatched start of the week for reports and filters

In Zendesk, you can decide which day of the week should be considered the start of the week, which affects the reports and filters the user builds in Explore. In Geckoboard the week starts on Monday, and this is currently not configurable.

By default, the Language field in your user profile in Zendesk Support determines which day is considered the start of the week. For example, if your locale is English (United States), then the start of the week in reports and filters is Sunday. If the your locale is English (United Kingdom), then the start of the week is Monday. Learn how to change your start of the week in Zendesk.

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.

SLA policies

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

Did this answer your question?