Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Add table: ticket_metrics for zendesk support connector

Answered
Srinivasa Valiveti User

Connector name:zendesk support

Table name: ticket_metrics

API documentation link: https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_metrics/

Description / Justification:

We request adding native support for syncing the /api/v2/ticket_metrics.json endpoint directly as a ticket_metrics table within the Zendesk Support connector.

While Fivetran currently recommends calculating core KPIs downstream using raw tables and the dbt_zendesk package, both community feedback and our real-world production usage highlight severe functional and cost limitations with this approach:

  • Inaccurate & Incomplete Metrics:

    • Messaging & Chat Replies (author_id = -1): In Zendesk Messaging/Chat, replies recorded under system placeholder IDs fail to match user tables, causing them to be filtered out in dbt. This leaves critical metrics like reply_time_in_minutes blank and results in incorrect reply counts.

    • Private Opening Messages: When tickets originate via API or web forms with a private initial comment (public = false), dbt skips the agent's actual first public reply, skewing response-time accuracy.

    • Pausable Update Time: Metrics such as pausable_update_time cannot be reliably recalculated from available raw data.

  • Massive MAR Spike via Event Tables: To work around messaging discrepancies, Fivetran support recommends enabling event tables like TICKET_CHAT_EVENT. However, this generates upwards of 1 million rows per month, creating an unsustainable and cost-prohibitive spike in Fivetran Monthly Active Rows (MAR) just to fix a handful of reply metrics.

  • Excessive Warehouse Compute Overhead: Recalculating these metrics continuously requires executing 60+ intermediate models in the dbt_zendesk package on an hourly basis, driving up database compute costs.

  • Source-of-Truth Parity: Zendesk pre-computes native metrics (reply_time_in_minutes, reply_count, etc.) directly via API. Syncing this table directly ensures 100% parity with Zendesk Explore reporting while adding minimal MAR (1 row per ticket update) and eliminating downstream compute dependency.

Please sign in to leave a comment.

Comments

3 comments

Date Votes
  • Official comment
    Vignesh Rengaraj Fivetranner

    Hi Srinivasa,

    Really appreciate the detail here, especially the specific stuff around author_id = -1 on messaging replies, private opening messages skipping the real first reply, and pausable_update_time.

    I am going to take those three to the team that owns the package and get their read on it. If they're real gaps (and honestly, from your description they sound like they could be), we'd patch them in the package quickly so that you folks get the right metrics downstream.

    Understand your rationale behind ticket_chat_event and other event tables being high MAR, and enabling them just for a few reply metrics does seem counterproductive. That said, we've seen that the majority of customers actually prefer building metrics from raw data, since it also lets them customize to their own workflow, SLAs, etc. The reason we don't sync a pre-computed metrics table directly is that a synced value is locked in at the point it's synced. If a calculation needs correcting later, whether it's a schedule change, an edge case, or something specific to your setup, there's no way to go back and fix it. Building the metrics from the raw ticket, comment, and tag data means it can actually be recalculated correctly when something's off or if you want to customize the calculation as per your logic 

    We're actually looking at a more elegant way to solve this, something that doesn't pile on extra cost on your end while also making sure we're not just syncing a snapshot that could carry the wrong numbers. We'll keep you posted as that takes shape.

    Best,
    Vignesh 
    Fivetran Product team 

  • Srinivasa Valiveti User

    Also, i see there is same feature request with 18 upvotes got rejected. https://support.fivetran.com/hc/en-us/community/posts/1500000704041-Connector-Improvement-Add-table-for-Ticket-Metric-Events-to-Zendesk-Support-connector?page=1#community_comment_43382386269719

    Not sure what is the reason. But, request you to consider this since it is helping not only our team but also others who are using zendesk support connector.

  • Srinivasa Valiveti User

    Hi Vignesh,

    Thanks for looking into those package edge cases with your team.

    The key challenge for us is that we don't actually need custom transformation logic—we rely entirely on Zendesk's native standard definitions, which worked seamlessly in our legacy Meltano/Dataflow pipeline.

    Having to run 61 dbt_zendesk models every hour and sync high-MAR event tables just to populate reply_time_in_minutes and reply_count creates unnecessary compute costs and operational overhead. Ingesting ticket_metrics directly remains the cleanest, most efficient path for our setup. Hope this provides clearer context on why direct ingestion is so critical for us