# Query email analytics with AI Use an assistant connected to [Bird MCP](/docs/ai/mcp-server) to explore your workspace's email statistics in plain language. You can compare performance, investigate delivery problems, and request time series without constructing API requests yourself. Connect Bird to your assistant and grant email read access to the workspace you want to analyze. These examples read existing activity. Replace example domains with your own and choose a period with available history. The assistant selects tools from your connection; the examples below describe the report you want. ## Review performance > Show my workspace's email deliveries, bounces, unique opens, unique clicks, open rate, and click rate for yesterday in UTC. Include an hourly breakdown. Expect a whole-period summary and an hourly series. Whole-period unique counts and rates are calculated independently of the hourly buckets; adding bucket counts or averaging bucket rates can give a different answer. ## Separate marketing and transactional traffic > Compare marketing and transactional email activity yesterday in UTC. Show deliveries, bounces, bounce rate, and delivery latency for each category. Keep receipts and password resets out of the marketing totals. Expect a comparison using the category recorded on each event. A template or tag can narrow the report to a particular flow. Classification depends on how your messages were sent; the assistant cannot infer it reliably from a subject line. ## Compare templates > Compare the email templates with activity yesterday in UTC. Rank the top ten by open rate and show deliveries and unique clicks alongside each rate. Use template names where you can resolve them, and show the IDs otherwise. Expect one row per template. Check delivery counts alongside rates: a high rate from a small number of deliveries is limited evidence. Template names resolved from current configuration may differ from the names used when the messages were sent. ## Investigate delivery problems > Compare yesterday's bounce rate with the day before, using UTC. Break both periods down by recipient domain and show deliveries and bounces alongside the rates. Which domains account for the largest increases in bounce counts? Expect the assistant to compare the same populations across both periods. A domain with more bounces identifies where to investigate; the breakdown alone does not establish the cause. ## Compare tagged campaigns > Find the campaign tags used in my workspace yesterday, then compare delivery and engagement for those campaigns from mail.example.com. Rank them by click rate and include a 15-minute activity breakdown. Tell me if the tags do not clearly identify campaigns. Expect the assistant to discover the tag names and values before filtering the report. Campaigns may be identified by send-time tags or broadcast IDs in your workspace. Templates can be reused across campaigns, so grouping by template can produce a different report. When you already know the tags, include them in the request: > Compare the spring-sale and welcome values of our campaign tag yesterday in UTC. Exclude the Legacy welcome template. Show deliveries, unique clicks, and click rate by campaign. Expect the assistant to use the supplied tags directly and resolve the template name to its ID. Broadcast activity is determined by events in the requested period; a broadcast created earlier can still have activity today. ## Monitor audience complaints > For marketing email yesterday in UTC, compare complaints, unsubscribes, deliveries, complaint rate, and unsubscribe rate by campaign. Show the counts beside the rates so small campaigns do not dominate the interpretation. Expect campaign-level signals for investigation. Rates alone cannot explain why someone complained or unsubscribed, and a small sample can make a rate look unusually high. Provider spam dashboards can use different populations and denominators; assess their thresholds against their own reports. ## Check delivery latency > For yesterday in UTC, compare median and 95th-percentile time from acceptance to delivery by mailbox provider. Include delivered counts and rank the providers by the 95th-percentile latency, slowest first. Expect one row per provider, with latency in milliseconds. The median describes the middle of the measured samples; the 95th percentile helps inspect slower deliveries. Missing latency samples produce null values. For a transactional flow, name the template and the period of concern: > Customers reported slow password resets yesterday between 09:00 and 10:00 America/New_York. For our Password reset template, show deliveries and median and 95th-percentile delivery latency by mailbox provider, with 15-minute activity. Compare with the same hour the day before. Expect independently calculated period comparisons with the same filters. Delivery latency measures acceptance to mail-server delivery. It does not measure when a message appeared in the inbox or when a person read it. A percentile also cannot give the exact number of messages that exceeded a latency threshold. ## Interpret engagement and business outcomes > Compare our marketing campaigns yesterday by unique clicks and click rate, with deliveries and unique opens for context. Explain what this tells us about engagement and what we would need to measure purchases. Expect measured engagement, with limits made explicit. Prefetched opens can inflate open counts, and excluding known prefetches does not prove human activity. Delivery confirmation does not establish inbox placement. Purchase attribution requires order or conversion data beyond email statistics; a higher open rate alone does not establish an A/B test winner. ## Refine the report Follow up with a narrower population or a different time grain: > Keep the same period and metrics, but restrict the report to mail.example.com and show daily buckets. The [flexible query endpoint](/docs/api/reference/get-email-stats-query) combines compatible filters with one grouping dimension. If a requested combination is unsupported or history is unavailable, ask the assistant to explain the limitation before changing the report's scope. Statistics use event time. An open yesterday can belong to an email sent earlier. To ask about activity, name the activity period; a report about eventual outcomes for emails sent on a particular date requires a different population. Opens and clicks are engagement signals and do not establish that a person read a message or completed a purchase. ## Next steps - [Email stats API](/docs/guides/email/stats-api): aggregate reports and breakdowns - [Query reference](/docs/api/reference/get-email-stats-query): metrics, filters, time windows, and pagination - [Open and click tracking](/docs/guides/email/open-click-tracking): how engagement events are recorded ## Related resources - [Setting up your coding agent](/learn/basics/setting-up-your-coding-agent) (video) - [What is an MCP server, and how does an agent use one to send messages?](/explained/platform/what-is-an-mcp-server-and-how-does-an-agent-send-messages) (answer) - [Coding agents](/ai) (product) - [Build with AI agents](/learn/paths/agents) (course) [Get an implementation brief](/learn/workspace?topic=agents)