Insights

The built-in pages answer the common questions. Insights is where you answer your own. It is a report builder: you pick what to measure, how to group it, and how to show it, and leadmaps draws the chart from your events. When you build something useful, you save it so you and your team can come back to it without rebuilding it each time.

Think of it like a kitchen. The other pages are dishes already on the menu. Insights is the kitchen itself, where you cook the exact thing you are hungry for.

Insights are part of the Pro and Business plans.

What you see

• A page title that reads “Insights”, with your saved insights listed so you can reopen them.
• A builder where you choose what to measure and how to see it. You can build several shapes of report from the same events:
  • Trends, how a number moves over time.
  • Funnels, how many people get through a set of steps in order.
  • Retention, whether people come back after a first visit.
  • Breakdowns, one number split by a detail like page, source, or device.
• A save action, so a report you built once becomes a saved insight you can reopen and share with your team.
• A SQL sandbox for the deepest questions, where you write a query against your data directly. The SQL sandbox is part of the Business plan.

How to read it

An insight is a question you shaped, so read it the way you would read the answer to that question. If you built a trend of signups per week, read it as “are signups growing?”. If you built a funnel of your checkout steps, read it as “where do people drop out?”.

Here is the flow. You decide the question, for example “how many people who read the blog go on to sign up?”. You build it: pick the event for reading the blog, then the event for signing up, arrange them as a funnel, and read the drop between the two steps. If it is worth watching over time, you save it, and it joins your list of saved insights so you never rebuild it.

Customize it

• Choose the report shape. Pick trend, funnel, retention, or breakdown to match the question you are asking. The same events can answer very different questions depending on the shape you choose.
• Pick the events and the grouping. Choose which events to measure and how to split them, for example by source or by device, so the report shows exactly the cut you care about.
• Set the date range. As on every page, the range decides the window your insight covers.
• Save what is worth keeping. Save the insights you will return to, and give each a clear name so your team knows what it answers at a glance.
• Drop to SQL for the hard questions. When the builder cannot express what you need, use the SQL sandbox to query your data directly. This is for the deepest, most specific questions and is available on the Business plan.

Use cases

• Answer a question no built-in page covers. When leadership asks something specific, build it here rather than exporting and doing it by hand. Action: build the exact report, save it, and reopen it next time the question comes up.
• Watch a metric that matters to your business. Build a trend for the one number your team cares about and save it. Action: check the saved insight regularly so you notice a change early.
• Investigate a drop. Build a funnel of the steps leading to a goal and read where people fall away. Action: fix the worst step, then rebuild or reopen the insight to confirm the drop improved.

Tips

• Start from the question, not the tool. Decide what you want to know in plain words first, then pick the report shape that answers it. It is faster than clicking around.
• Save and name well. A saved insight is only useful if you and your team can tell what it answers. A clear name is half the value.
• Use the SQL sandbox only when the builder cannot. The builder covers most questions faster and with less room for error. Reach for SQL for the genuinely custom ones.
• An insight is only as good as the events behind it. If a report looks wrong, check that the events it relies on are actually being sent correctly, using the Events feed.