How to build HubSpot reports that actually work (and the mistakes that quietly break them)

Most teams do not have a HubSpot data problem. They have a HubSpot reporting problem. The numbers are usually fine. The way the reports are built is what turns good data into misleading dashboards.

Here is how we approach reporting at Uspeh, including the traps we see clients fall into most often and how to avoid them.

Start custom, not with the built-in reports

HubSpot's out-of-the-box reports are tempting. In a few clicks they get you to roughly 80% of what you need. The trouble is the last 20%. That is usually the exact customisation that made the report worth building, and built-in reports will not stretch that far. Try to rework one later and it tends to cause more problems than it solves.

So our default is to build custom from the start. A custom report can grow with the business instead of hitting a wall the moment requirements change.

There are a handful of genuine exceptions where a default HubSpot report can't simply be rebuilt in the custom report builder. Usually that's because the report relies on a system-calculated metric or on data the builder can't reach. A couple can be approximated with extra configuration; the rest can't be reproduced there at all.

• Funnel reports. The custom report builder (single and cross-object) doesn't include a funnel chart type. You can still create a funnel using HubSpot's dedicated Funnels report type, but you can't reproduce that funnel visualisation inside a custom report.

• Deal waterfall. Waterfall isn't an available chart type in the custom report builder, so this Sales Analytics visualisation can't be recreated there.

• Deal push rate. This is a metric calculated by the Sales Analytics tool rather than a stored property, so it isn't selectable as a field in the custom report builder. You can approximate the logic with calculated properties, but the native metric itself can't be pulled in.

• Sales win rate. Also a calculated value rather than a true property, so the built-in figure can't be retrieved by the custom report builder. You can rebuild an equivalent with a report formula field (won amount divided by total closed value, for example) or read conversion from a deal funnel, but the native win rate can't be selected directly.

• Web traffic analytics. Reports built on session-level data, including traffic broken down by original source or UTM parameters, draw on web analytics data that the custom report builder can't access. Exporting from the Traffic Analytics tool is the only route. One important caveat worth spelling out: the original source and UTM values stored on individual contact records are fully available in the custom report builder, so contact-level reporting on those isn't affected. It's the session and page-view data specifically that's out of reach.

Choose the right primary source

When you create a custom report, the primary source should be the object you actually want to visualise. If you want the number of contacts broken down by something, contacts are your primary source. If you want deals created over time, deals are.

This sounds obvious, but getting it wrong is the root of the most alarming reporting bug of all.

The duplication trap: when 100k looks like 300k

Imagine a single deal worth 100k with three contacts linked to it. Build a report with contacts as the primary source, pull in deal value, and the report can proudly show 300k.

The system has not malfunctioned. It has answered the question you accidentally asked: show the deal value associated with each of these contacts. It counts the same deal once per contact because nothing told it not to.

The fix is in the setup, not the data. Pick the object you truly want to measure as your primary source, and be deliberate the moment you combine objects. When you genuinely need complex, layered filtering, a list or segment is often more flexible than a report. Build the segment first, then report on segment membership.

The property that is quietly reporting on the wrong thing

Native properties such as Create Date exist on contacts, deals and companies, all with the same name. Choose the wrong object's version and the report will quietly measure something you did not intend. Everything looks correct. It is simply answering a different question.

This is the single most common reason a report appears broken, both for clients and for experienced builders reworking an existing report. The fix takes seconds: click the pencil on the field and confirm which object the property belongs to. Naming your report and relabelling your fields clearly saves the next person from the same confusion.

A correct report can still be useless

A report can be technically accurate and still tell the client nothing, and the culprit is usually the chart. Match the visual to the decision:

• KPI for the single headline number at the top of a dashboard
• Column or bar for groups of data, such as records created per month
• Line for trends over time
• Horizontal bars for funnels and deal-stage breakdowns
• Pivot tables for the breakdown of a breakdown that clients love to request
• Tables for sanity checks, using Record ID so rows stay clickable
• Combination charts to reveal whether more deals actually means more revenue

Watch for one subtle issue. When large and small numbers share an axis, the smaller series flattens into a line that looks like nothing is happening. Adjust the aspect ratio, or split the data across two reports.

Never read data in isolation

Say most of your contacts arrive on a Monday. The instinct is to staff the weekend to catch the rush. But drill into the original source and the story can fall apart. Some of those Monday contacts might be an import. Others might be emails cleared over the weekend through an inbox extension, stamped Monday when they synced.

The number was real. The story was wrong. Never read a data point in isolation, and validate as you build, especially once filters and nested breakdowns start stacking up. One shaky assumption early on is inherited by every layer after it.

The details are important

Good reporting is also about trust and polish. When a dashboard looks careless, people start treating the numbers with the same suspicion. That sounds cosmetic, but it is not. Presentation affects whether someone reads a report quickly, understands it correctly, and trusts it enough to act on it.

Set the report colours to your brand so the dashboard feels like part of the same system as the rest of your reporting, not an isolated export dropped into HubSpot. Format monetary values properly, with the correct currency symbol, decimal treatment and separators, so nobody has to stop and work out whether they are looking at revenue, count, or percentage. Place the legend where the eye naturally goes, and rename labels when HubSpot's defaults are technically correct but unnecessarily hard to scan. If a chart is showing share, conversion or split, add percentages so the relationship is obvious immediately rather than forcing someone to estimate it from bar length or segment size.

Small details like these do real operational work. They reduce hesitation in meetings. They prevent the needless back-and-forth that starts when someone asks what a number means instead of discussing what to do about it. A proper report should not just be accurate. It should be easy to read, hard to misinterpret, and ready to support a decision the moment it appears on screen.

The takeaway

Reliable HubSpot reporting comes down to discipline: build custom, choose the right primary source, verify you are measuring the right object, validate as you go, and pick visuals that serve a decision. Get those right and your dashboards stop being a source of doubt and start being something the whole team can act on.

If your HubSpot reports keep almost working, or you are not sure you can trust the numbers on your dashboards, Uspeh can help. As a HubSpot Platinum Solutions Partner, building reporting people can rely on is what we do.