Send yesterday's support tickets into your product analytics

Every day at 6pm, push support signal into my product analytics so support friction ends up sitting next to product usage in the warehouse. Pull yesterday's Zendesk tickets, forward each one into Segment as an event attached to a known user, and finish with a Slack summary for my support lead.

During setup, ask me which Segment Source these events should go into, and collect that Source's write key. This matters: Segment tracking calls authenticate with a Source write key, not with the workspace Public API token, and the write key is issued per Source. Do not assume the Public API token will work for sending events. Also ask me which Slack channel should receive the summary.

Start with Zendesk List Tickets to get every ticket created in the last 24 hours. Sort by created date descending and page through with cursor pagination, stopping once you pass the start of the window. Side-load users on the request so each requester's email address comes back alongside the ticket, instead of making a separate lookup per ticket.

Use judgement to decide what deserves to reach the warehouse. Skip spam and anything automated or system generated: no-reply and mailer-daemon senders, monitoring and alerting bots, out of office autoreplies, bulk marketing blasts, and tickets opened by our own integrations rather than by a person. Skip any ticket whose requester has no email address, and never invent or synthesize an identifier to fill the gap, because a fake id quietly corrupts the user data in the warehouse. Keep a running count of what you skipped and why.

For every ticket that survives the filter, read the subject and normalize it into exactly one short category: billing, bug, how to, cancellation, or other. Fall back to the first part of the ticket description when the subject is uninformative, and choose "other" when the intent is genuinely unclear rather than forcing a ticket into a category it does not fit.

Then send two Segment calls per ticket, identify first so the user exists before the event lands. Use Segment Identify User for the requester, keyed on the requester's email address as the userId unless I tell you my product uses a different user id, with the email and name attached as traits. Follow it with Segment Track Event named "Support Ticket Created", carrying ticket id, subject, priority, status, channel and requester email as properties, plus the category you assigned. Set the event timestamp to the ticket's created date so events land at the time the ticket was actually raised rather than at ingest time.

Set a stable messageId on every track and identify call, derived from the Zendesk ticket id, for example "zendesk-ticket-<ticket id>-track" and "zendesk-ticket-<ticket id>-identify". Segment de-duplicates by messageId within a 24 hour window, which is what makes a re-run or an overlapping time window safe instead of double counting yesterday's volume.

Keep each event small. Truncate long subjects to roughly 200 characters and never attach the full ticket body, because the tracking API rejects any single event larger than 32 KB.

Finish by posting a Slack message to the chosen channel: how many tickets were sent to Segment, the breakdown by category, and how many were skipped for spam or automation versus a missing email address. Word it as "sent", not "delivered". A successful tracking call returns an empty 200 response, which only means Segment accepted the event for processing, not that it reached the warehouse or any downstream destination. If nothing qualified, still post a short note saying so, so the silence is never ambiguous.