Atlassian Analytics Research: Dashboards, Metrics, Integrations

[#1]

The launch of Atlassian Analytics kicked up a lot of buzz: What is it? How does it work? What is it for? What can it actually do? Does this mean Marketplace reporting apps should pack up and leave because they’re doomed? (Spoiler: no—but they will need to adapt.) I dug into the details, and here’s what I found.

 

What is Atlassian Analytics?

Think of Atlassian Analytics as a control room for your Atlassian world. It pulls together what’s happening in Jira Software, Jira Service Management, and Confluence and turns it into dashboards you can actually use to make decisions.

A quick note up front: it’s available only for Cloud Enterprise plans. Within an eligible org, you decide who gets access—it’s not locked to specific Jira roles. If you can invite them, they can explore.

So what does it do? You can start with ready-made dashboards (great for service, assets, content, DevOps) or build your own from scratch. It’s designed to answer everyday questions like:

• Where are our bottlenecks right now?
• Are incidents trending up or down?
• Which teams are stuck, and which ones are flying?
• What content gets the most traction?

Under the hood, there’s a visual SQL editor for deeper dives (no need to be a hardcore data engineer), and plenty of chart options—tables when you need detail, bars/lines/pies when you need a story. If your data lives beyond Atlassian, you can plug in external sources like Snowflake, Redshift, BigQuery, SQL Server, PostgreSQL, and more to get the full picture in one place.

It also plays nicely with how teams work: you can embed dashboards where people already look, comment to keep context with the chart, and manage permissions so the right folks see the right numbers.

What it’s not: a magic button that replaces every Marketplace reporting app overnight. Specialized apps still shine for niche metrics, advanced workflows, or opinionated reports your teams already rely on. Atlassian Analytics raises the baseline, but it doesn’t make thoughtful, purpose-built reporting obsolete.

Bottom line: if you want a clear, shared view of how work moves across teams—without juggling a pile of tools—this gives you that foundation.

Next up: how to get your data flowing in (and what to watch out for when you connect it).

Source: https://www.atlassian.com/platform/analytics/what-is-atlassian-analytics#what-is-atlassian-analytics

What is the Atlassian Data Lake?

Think of the Atlassian Data Lake as one home for your Atlassian Cloud data—already organized and ready to explore. Instead of pulling Jira, Jira Service Management, and Confluence data from different places, the Data Lake puts it in a single, queryable spot with modeled/enriched fields (read: cleaner names, useful joins, consistent dates) so you can analyze faster.

What you can do with it

• Plug it straight into Atlassian Analytics. Point your dashboards at the Data Lake and start charting.
• Query prepared data directly. Use visual SQL to slice, filter, and join without wrestling messy exports.
• Blend Atlassian + non-Atlassian data. Connect external sources in Atlassian Analytics (e.g., your warehouse) and see everything together.

Source: https://www.atlassian.com/platform/analytics/what-is-atlassian-data-lake#why-use-the-atlassian-data-lake

How Atlassian Analytics works (and where it shines vs. falls short)

Getting from zero to insights is pretty straightforward. In practice, you’ll move through steps like these:

1. Connect your data sources.
2. Start with pre-built templates to get a quick baseline.
3. Drill down to spot timelines, bottlenecks, and trends.
4. Run SQL your way—use Visual SQL or write queries directly.
5. Pick the right visuals (tables, bars, lines, pies, etc.).
6. Share, comment, download, and embed to drive action with stakeholders.

Templates are a big plus—there are a lot of them, so that most teams can find a decent starting point. That said, the “it’s super simple to build anything custom” pitch is a bit optimistic. In reality, you’ll want someone to own your dashboards—to create, edit, and maintain them—especially once you connect external data. Building helpful charts and tables does take some skill, and not every UI step feels intuitive on the first pass.

Pros

• Cross-product, cross-site reporting out of the box.
  Connects to the Atlassian Data Lake, allowing you to scope which products, projects/spaces, Assets, and ops data to include. Great for “single-pane” KPIs across Jira + JSM + Confluence.
• Visual SQL + SQL editor.
  Build charts with a visual pipeline or write SQL directly; add interactive filters (date pickers, dropdowns) and start fast with ready-made dashboard templates for Jira/JSM/Assets/DevOps.
• Brings in non-Atlassian data.
  Native connectors to popular databases (Snowflake, BigQuery, Redshift, SQL Server, Postgres, MySQL, Athena) so you can blend product data with business data.
• Enterprise governance.
  Separate permissions for data sources and for dashboards, plus an Analytics admin role to centrally manage access.
• Operationalization options.
  Control cache/refresh behavior and share data out to external tools via data shares (e.g., Delta Sharing) for downstream pipelines.
• Improving performance/freshness.
  Ongoing schema and query-performance updates, with “fresher” tables aimed at speeding up common Jira queries.

Cons & Caveats

• Plan restriction.
  Available to Cloud Enterprise only. Free/Standard/Premium plans don’t include it.
• Not real-time.
  Data Lake syncs typically run on ~30-minute (or longer) intervals, and dashboards follow cache settings (e.g., 30 min / 1 hr / 24 hr) unless you refresh manually. Some tables update on multi-hour cycles.
• Limited business-calendar logic.
  No native holiday calendars. Weekends can be excluded via Visual SQL, but holidays usually require workarounds (e.g., JSM SLA calendars or a custom holiday table). There’s interest in exposing SLA goals/calendars in the Data Lake.
• Admin overhead for external sources.
  You’ll need to allowlist IPs, choose schemas, and resync when your external DB changes. Nested/JSON-ish fields may need custom flattening.
• Row/result & performance considerations.
  Result set limits apply; heavy joins can be slow; multiple users refreshing at once can cause queueing/timeouts. Tuning queries and using a cache strategy matters.
• Coverage is broad, not total.
  Focus areas include Jira, JSM (incl. Assets/ops), JPD, and Confluence, plus some platform apps—but not every entity you can imagine is there. Check schemas before you promise a metric.

Atlassian Analytics makes it easier to build a shared, trustworthy view of work across teams—especially if you’re already in the Atlassian ecosystem. You’ll still want a dashboard owner and some SQL/analysis know-how to get the most out of it, but once that’s in place, it’s a strong foundation for decision-making.

Integrations: How to use marketplace app data in Atlassian Analytics

All integration options have already been listed above. I tested the one that is compatible with our Time in Status app — it allows you to access data via Google Sheet.

Here’s the exact flow I used for Time in Status:

1. In Build & save a preset in Time in Status. Use rolling dates (Last 7/30 days, Last month) so the data stays fresh without edits.
2. Create a JSON Data Feed link for that preset and pipe it into Google Sheets with a refresh trigger. Changes to the preset sync into the sheet automatically. 
3. In Atlassian Analytics, add Google Sheets as a data source, ensure dates are typed as dates and numbers as numbers, and then build your charts/filters. (You can also set a default workspace time zone.) 

That’s it—you’ve got a living dashboard fed by Time in Status.

After configuring all the settings, I created this dashboard, but in reality, it's just an idea. You can create more charts and tables based on data from the Time in Status app, depending on your needs.

Your dashboard updates when the sheet updates. That’s it. If you add/remove columns in the preset, you’ll probably need to re-check visuals in Analytics. Stable columns = fewer surprises.

You can combine a few Time in Status presets into one dashboard—each exports to its own tab/sheet:

• Time in Status + Status Count → see both how long and how many.
• Status Entrance Date + Time in Status → when a status changed and how long items sat there, side by side.
• Add splits by Assignee / Project / Issue Type to drill down without writing new reports.

Sharing without leaking data

You can export the dashboard as JSON and share it with another Jira instance. That file is just the layout and settings, not your data.
Heads-up: the other side needs a matching schema (same columns/types) or the charts won’t render correctly.

Things I learned the hard way

• Don’t rename columns casually in Sheets. Dashboards are picky about that.
• Type hygiene matters. Dates must be dates, not text that looks like dates.
• Time zones can cause off-by-one-day headaches. Align app → Sheets → Analytics.
• Keep a key. Include the Issue key/ID and timestamps to avoid issues with joins and de-duplication later.
• Big sheets slow down. Archive old rows or split them by month if the process starts to crawl.
• When numbers look “wrong,” check filters first. (It’s almost always a filter.)

 If your app (like Time in Status) can feed Google Sheets, you can get those metrics into Atlassian Analytics with minimal drama. Use rolling dates, keep the schema steady, and start with the two or three charts your team actually needs. You can always get fancier later.

Conclusion

Atlassian Analytics is a great baseline for shared visibility, but the wins come from focus and care: pick the 3–5 questions that matter, name an owner, and keep your schema steady. Marketplace apps aren’t obsolete—they’re your specialists—so use Analytics as the shared pane of glass and pull in app data when it adds context you can act on.

Want a quick, low-friction start? Try the Time in Status → Google Sheets → Analytics loop and build two or three charts your team will actually use. Keep columns stable, use rolling dates, and expand from there. If you’re curious, give Time in Status a try and turn ticket history into decisions.