Humble Metrics

Product guide

Use the data. Make the next decision.

Humble Metrics is built for developers and small teams who need to understand what changed, why it changed, and what to improve next. Start broad, narrow with a useful comparison, then follow the signal into the report that can answer the question.

A practical starting pointAfter a release or campaign, set the date range, compare it with the previous period, then check traffic, events, and the path to your primary conversion. Do not judge a change from one headline number alone.

Start with the overview

The Overview is the fastest way to orient yourself. Use it to check visitor and page-view trends, then open the relevant breakdown when a movement needs an explanation. Choose a date range that matches the thing you changed: a day or week for a release, a month for content, and a longer period for a recurring acquisition pattern.

Use comparison to put a number in context. A rise in traffic can be healthy, but a rise paired with weaker event completion may point to a mismatch between the new audience and the page. When the result is noisy, compare like-for-like periods and check whether a campaign or deployment explains the timing.

Read traffic without stopping at traffic

Overview, real-time, and breakdowns

Use Overview for the trend, Real-time to validate a launch or see live activity, and Breakdown to group the same traffic by a dimension such as page, referrer, country, device, browser, or campaign. Breakdowns answer the natural follow-up: which visitors or pages account for this change?

Use Sessions when you need the sequence behind an aggregate number. It is useful for inspecting a particular visit, confirming a test journey, or finding the page and referrer that led to an action. Treat individual sessions as investigation clues, not a representative sample of every visitor.

Pages and acquisition

Look at entry pages to see where a visit begins and exits to find where momentum ends. Referrers and UTM reports explain acquisition; page reports explain what happens after someone arrives. For a new post or landing page, read these together: source → entry page → key event → next page.

Understand behaviour and conversion

Events and goals

Events record the actions a page view cannot: a sign-up, download, contact click, feature use, or checkout step. Use the Events report to see volume and properties. Create a Goal for the outcome you want to review regularly, so it has a clear name and can be compared over time.

A good goal has one unambiguous meaning. Prefer account_created to button_clicked; the first captures an outcome, while the second may have several meanings. If you need both, record both and use the outcome as the primary goal.

Funnels, journeys, retention

Use a Funnel when you already know the expected sequence: landing page → pricing → checkout → purchase. The useful question is not just where people leave, but whether the drop is isolated to a device, source, campaign, or page version. Apply a segment or date comparison before changing the product.

Use Journeys when you do not know the sequence yet. Start with a page or event and inspect the common steps before or after it. Use Retention and Cohorts for repeat behaviour: they show whether people who arrived or acted during the same period return and do something meaningful later.

Heatmaps, recordings, and performance

Heatmaps help you see whether attention reaches the elements you expect. Replays help diagnose a specific friction pattern after the aggregate reports show one. Performance reporting provides another explanation for a conversion change: a page can have demand and intent but still lose visitors when the experience is slow or unstable. Use these reports to form a hypothesis, then confirm it against events and conversion data.

Compare the audience that matters

A Segment is a saved audience definition that you can reuse across reports. Make segments for questions you expect to ask again, such as paid campaign traffic, visitors on mobile, readers of documentation, or visitors who reached a pricing page. Name segments after the question they answer, not only the rule used to build them.

Use a segment before assuming that site-wide numbers tell the whole story. A conversion rate can be unchanged overall while a mobile regression is hidden by better desktop traffic. Compare the segment with all traffic or with a previous period, then check whether the same difference appears in the funnel and event reports.

Measure campaigns, revenue, and attribution

Use UTM reports to assess deliberately tagged links. Keep campaign names consistent: pick one format, use lower case, and do not rename the same campaign halfway through. Campaign reporting becomes unreliable when spring-launch, SpringLaunch, and spring_launch all mean the same thing.

Use Revenue when the relevant purchase data is available, then compare it with traffic and events to separate volume from value. Attribution is most useful as a decision aid: it shows the routes that contributed to an outcome, not a perfect claim of credit. Read it alongside direct event and funnel performance before moving budget or changing a channel.

Instrument events deliberately

Track the actions that represent intent or value, not every click. A compact event vocabulary makes reports easier to read and keeps future comparisons valid. Use lowercase snake case, stable names, and small properties that explain meaningful differences.

window.humbleMetrics.track('newsletter_signup', {
  placement: 'blog_footer',
  topic: 'analytics',
});
Event design checklistRecord the outcome first. Add properties only when you expect to break the result down by them. Avoid names, emails, order details, or other personal data. Document an event before reusing it across the product.

Share the answer, not a screenshot

Use boards to keep the reports for a recurring question together—for example, a weekly product health check or a campaign review. Share a report when another person needs the same filtered context. Before you share, set the date range, filters, and breakdown that support the conclusion; then add a short note explaining what changed and what you plan to do next.

For teams with several sites, check that you are in the right website before interpreting a report. Keep each website's goals, segments, and reporting names consistent so a comparison across properties remains meaningful.

Data and privacy

The default setup is cookie-free and focuses on aggregate website activity. Reports use page and session context such as hostname, page URL, title, referrer, language, and screen size, together with the events you choose to send. Keep event properties useful and non-personal, and remove URL parameters from collection when they might contain information you do not need.

A report looks wrong

Check the date range, comparison period, active filters, selected website, and whether a segment is applied. Then look for a release, campaign, seasonality, or tracking change during the same period before treating a difference as product behaviour.

An event is missing or inconsistent

Confirm that the event name and properties match the established vocabulary, then test it with a fresh session. Check that the event fires after the tracker has loaded and that the relevant domain is collecting data.

Need help with an investigation?

Bring the exact question, date range, page or event name, and the comparison you have already tried. That context makes it much easier to turn a report into a useful answer.

Need a second pair of eyes?Contact us with the question you are trying to answer and the report context. Please do not include credentials or private visitor data.