HubSpot Custom Report Builder: Choosing a Chart Type, and What Each One Is For

You pick a data source in the custom report builder, drag two properties into slots, and HubSpot offers ten ways to draw the result. Nothing in the interface says which one answers the question you came in with, so the chart chosen is usually the familiar one. That is how a portal ends up with forty reports, six of which anyone opens.

This article covers three things in order: how a report is assembled, from object through property to parameter; what each chart type is actually for, and which shape of question it answers; and what to do about the reports that accumulate and quietly cost you credibility. The join and primary-source mechanics that decide whether a total is correct are covered near the end, because they matter enormously and only after the chart can answer the question at all.

Two terms first, because the builder's whole behaviour follows from them. A dimension is a field with no aggregation — a stage name, an owner, a month. A measure is a field with an aggregation method set on it — a count of deals, a sum of amount, an average of days to close. HubSpot displays dimensions in grey and measures in green, and the colour tells you where the field is allowed to go.

Objects, Properties, Parameters

A report is built in three passes, and doing them out of order wastes the time.

The object pass decides the record universe: you choose a primary data source, may add related sources, and that choice fixes what the report can count. A report built on deals counts deals; adding contacts lets you break deals down by contact properties, and it does not turn the report into a contact report.

The property pass fills the field slots, and the two field types are allowed in different places: dimensions occupy the X-axis and the breakdown slot, while measures occupy only the Y-axis, to a maximum of twelve per report. If a field will not drop where you want it, the reason is almost always that you are trying to put a dimension on an axis that needs an aggregate, or the reverse.

The parameter pass is filters and display, where filters use ALL of the filters below or ANY of the filters below, with custom filter rules available for AND/OR grouping when the plain form is not enough. Display settings carry the axis scale, legend position, data labels, and axis minimum and maximum.

The order matters because each pass constrains the one after it. Choosing a chart before the object pass means choosing a picture before knowing what is in the room it has to describe.

Chart Types and the Questions They Answer

The builder offers vertical bar, horizontal bar, line, area, combination, donut and pie, KPI, gauge, pivot table, table, and scatter, plus a smart chart that suggests one. They are not interchangeable, and each answers a different shape of question. The panels below hold the data constant and change only the rendering, so every difference between them is a property of the chart.

KPI. One number against a target or a prior period, for the figure someone would ask for by name — pipeline created this quarter, deals closed this month. A KPI with no comparison is a number without a verdict, so set the comparison period.

Gauge. One number against a fixed goal drawn as progress, answering "how far through" rather than "how much", which suits quota attainment and onboarding completion. Where there is no fixed target, a KPI is the honest choice.

Vertical bar. Comparison across a small number of categories, or a count over time where the periods are discrete. It stays readable to roughly ten bars, past which the labels collide and a horizontal bar carries the same comparison better.

Horizontal bar. The same comparison when the category names are long or numerous — owners, industries, lead sources, lifecycle stages. Long labels read straight across instead of at an angle, and that legibility is the entire reason to choose it over the vertical form.

Line. A trend in a continuous measure over time, for when the question is direction rather than magnitude — whether average deal size is rising, whether time-to-close is drifting — and note that a line drawn through four points is a bar chart rendered badly.

Area. A trend where the total and its composition both matter — pipeline by stage over time. It reads well for three or four series and becomes unreadable past that, because the bands stop being separable.

Combination. Two measures on different scales, typically a count as bars and a rate as a line — deals created and win rate, sessions and conversion rate. This is the chart most often needed and least often chosen, because people build two reports instead and put them side by side, where nobody compares them.

Donut and pie. Composition of a whole at one moment, and only where the parts are few and add to something meaningful. Angle and area are read less accurately than position along a common scale, which is the measured reason a bar chart beats a pie for comparison and a pie survives only where the question is genuinely "what share" (Cleveland and McGill 1984). Five slices is a limit rather than a target, and if the question involves change over time this is the wrong chart entirely.

Scatter. The relationship between two measures across records — deal size against days to close, for instance. It is the only chart in the set that answers "do these move together", and it is almost never used.

Table and pivot table. Where the reader needs the values rather than the shape, or wants to export them. A pivot table is the right answer more often than teams expect, particularly for a operations audience who will act on rows rather than trends.

Choosing by the Shape of the Question

Rather than starting from the chart list, start from what is being asked. Questions come in six shapes, and each maps to a small set of charts.

A question about a single value wants a KPI, or a gauge where a fixed target exists. A question about comparison between categories wants a bar, vertical for few and short labels, horizontal for many or long ones. A question about change over time wants a line for a rate or an average, a vertical bar for a count of discrete periods. A question about composition wants a donut for one moment or an area chart for composition over time. A question about relationship wants a scatter, and a question about the values themselves wants a table rather than a chart at all. Later replication of the perception work confirmed the ordering across a much larger sample, so this is a finding rather than a house style (Heer and Bostock 2010).

If a question does not fall into one of those shapes, it is usually two questions, and it should be two reports.

The Reports Nobody Opens

Report clutter is a credibility problem rather than a tidiness one, and it compounds.

Every portal accumulates reports built for one meeting, one campaign post-mortem, or one executive question that was answered and never asked again. They stay because deleting things feels riskier than keeping them, and the cost arrives later: a person searching for the pipeline report finds four with similar names, cannot tell which is authoritative, and picks one. When two people pick differently, the meeting becomes an argument about which report is right, and the reporting function loses the argument regardless of the answer.

Three rules keep the library from filling up again.

A report is built for a recurring decision or it is a query. If the answer will be looked at exactly once, run it, screenshot it into the deck, and then do not save it. Saving it is what creates the clutter, and the report will be stale the next time somebody finds it.

Every saved report has a named owner and a review date. Ownership is what makes deletion possible later, because the question "can we delete this" has somebody to ask.

A report with no dashboard is a candidate for deletion. Reports that belong to nothing are reports nobody scheduled, and a report nobody scheduled is one nobody is waiting for.

Where a portal is already past this point, the tractable move is to work from the dashboards backwards: everything on a dashboard stays, everything else goes onto a list with a date, and anything not claimed within a fortnight is deleted. The number of complaints this produces is a good measurement of how much of the library was real.

Naming and Grouping

Names decide whether a report is findable, and the default names are the problem. Deals by owner tells you nothing about the filters that make it specific.

A workable convention carries the object, the cut, and the scope: Deals — by owner — current quarter, new business. It sorts sensibly, it distinguishes the four similar reports from each other, and it tells a reader whether this is the one they want without opening it.

Group reports by the decision they serve rather than by the object they are built on. A folder holding every deal report is a filing cabinet, whereas a folder for the weekly pipeline review is a working set somebody uses. The person looking for a report is looking for it because of a meeting, not because of an object type.

The Primary Source and What It Includes

Chart choice decides whether a report can answer the question, and the primary data source decides whether that answer is true.

The primary source fixes the record universe: the report can only count records that exist in it. A report whose primary source is deals cannot show contacts with no deal, no matter which properties are added, and a report built on contacts will silently exclude a whole segment if the filter set implies a deal association. When a report is missing records everyone knows exist, this is nearly always why.

The second failure is subtler and more expensive. Where a report joins a one-to-many relationship — deals to line items, companies to deals — a record on the "one" side repeats once per match, and any measure summed across those rows is inflated.

The repair is to count the measure at the grain it belongs to. Sum deal amount in a deals report; sum line item revenue in a line-items report; do not sum deal amount in a report that has line items joined to it. Where both are genuinely needed, build two reports and place them together on a dashboard rather than forcing one chart to carry both grains.

Verification Before Publication

Custom reports refresh roughly every two hours, so a report checked immediately after a data change will disagree with the record and be right later. Build that into the check rather than debugging a difference that resolves itself.

The verification worth doing on every report before anyone else sees it is a reconciliation against the index page. Apply the same filters in the deals or contacts index, compare the record count, and compare one summed figure. A report that agrees with the index on both is not necessarily correct, and one that disagrees is definitely wrong. It takes about a minute and it is the difference between a reporting function people trust and one they check.

Symptoms and Their Causes

A measure will not drop onto the axis. The field is a dimension — no aggregation is set on it. Set an aggregation or move it to the X-axis or breakdown slot, where dimensions belong.

Revenue reads higher than the deals index for the same filters. A one-to-many join is repeating the parent row. Move the measure to a report built at the grain it belongs to.

A known segment is missing entirely. The primary data source does not contain those records. Rebuild with the object that contains every record you need to count as the primary source.

Twelve measures is not enough. The report is really two reports and should be split. The limit is a design constraint rather than an obstacle, and a chart carrying twelve measures is unreadable well before it is invalid.

Two reports with similar names disagree. Both are probably correct at different grains or filters. Rename both to carry their scope, and delete whichever is not attached to a dashboard.

Scope and Limits

This covers the custom report builder, not the single-object report builder or the attribution reports, which have their own field behaviour and their own limits. Report allowances differ by subscription tier, and the current numbers live in HubSpot's product catalogue rather than in an article, because they change.

The chart guidance above is a set of defaults rather than rules. A horizontal bar with thirty categories is unreadable on a dashboard and exactly right in a sortable operations review that people scroll. The reason to state the default is to make the exception deliberate.

Nothing here addresses dashboard construction — how reports are arranged, filtered together and scheduled. Dashboards carry their own limits, including a maximum count tied to subscription tier and a fourteen-day window to restore a deleted one, and they are a separate problem and a separate article.

References

Cleveland, William S., and Robert McGill. 1984. "Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods." Journal of the American Statistical Association 79 (387): 531–554. https://doi.org/10.1080/01621459.1984.10478080

Heer, Jeffrey, and Michael Bostock. 2010. "Crowdsourcing Graphical Perception: Using Mechanical Turk to Assess Visualization Design." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: 203–212. https://doi.org/10.1145/1753326.1753357

In Summary

Build in the order the tool implies: object, property, parameter. Choose the chart from the shape of the question rather than from familiarity, and remember that the combination chart exists, because it is the one people need and skip.

Then treat the report library as something that is maintained rather than accumulated. Reports built for a single meeting should not be saved, saved reports should have an owner, and reports attached to nothing should be deleted. Reporting credibility is lost mostly to a room full of similar reports that disagree, and almost never to a single wrong chart that somebody caught.