Funnels

Design funnel steps that actually explain drop-off

May 14, 2026 · 8 min read · Product Analytics

Most funnel charts fail for the same reason: the steps do not match how users experience the product. Teams paste every button click into a path, then wonder why conversion looks random week to week. A useful funnel is a hypothesis about a job the user is trying to finish—not a transcript of the UI.

Start from the outcome, not the interface

Before you name events, write the outcome in one sentence: “A new team reaches their first shared project.” Then list the few commitments required to get there—sign up, create workspace, invite a teammate, create a project, invite that teammate into the project. Those commitments become steps. UI chrome, settings pages, and exploratory clicks stay out unless they are truly mandatory.

Keep steps mutually exclusive and ordered

Each step should be something a user can complete once per journey. Overlapping definitions (for example “viewed pricing” and “opened billing”) create artificial drop-off when users take alternate routes. Prefer ordered, required milestones. If your product allows multiple valid paths, model separate funnels per path instead of one messy combined chart.

Segment before you redesign

A 40% drop between invite and first project means little until you split by platform, plan, and acquisition source. Mobile self-serve users often fail different steps than enterprise users guided by CS. Sonicbean cohorts make those slices reusable across funnels and retention so you do not rebuild filters for every question.

Instrument the failure modes

When a step conversion is weak, add events that explain why: permission errors, empty states abandoned, invite emails bounced. Those are not funnel steps—they are diagnostic properties and side events that tell product what to fix. The funnel shows where; diagnostics show why.

Review the catalog quarterly

Event names drift as features ship. Schedule a lightweight review so “project_created” still means the same thing after a redesign. Clean catalogs keep historical funnels comparable and prevent your team from arguing about definitions instead of decisions.

Good funnels are short, outcome-tied, and segmented. Build those first; the chart will finally match the product conversations you are already having.

Retention

Retention without vanity: pick the return action that matters

May 28, 2026 · 9 min read · Product Analytics

“Retention” is not one metric. Returning to open the app is not the same as completing the core job again. Teams that track only sessions inflate numbers and hide whether the product is becoming a habit. The fix is to define a return action that represents real value—then measure cohorts against that action on a schedule that matches your product’s natural rhythm.

Choose a value event, not a pageview

For a project tool, a meaningful return might be “edited a project” or “published a change,” not “opened home.” For analytics products, it might be “ran a report” or “shared a dashboard.” Write the value event down with stakeholders. If growth and product disagree on the definition, your retention curves will never drive a roadmap.

Match the window to product cadence

Daily retention suits messaging apps; weekly or monthly windows fit B2B tools used in planning cycles. Reporting D1 and D7 for a product people use twice a month creates false alarms. Sonicbean retention views let you set the return window explicitly so leadership sees curves that match how customers work.

Cohort by first-week behavior

The most actionable retention work often starts in week one. Users who invite a teammate, connect a data source, or complete onboarding step three frequently retain better. Build cohorts on those early behaviors and compare D7 and D30 curves. That comparison is more useful than a single company-wide average.

Separate resurrection from habit

Email campaigns can spike “retained” users who never establish a habit. Track organic return separately from campaign-driven sessions when you evaluate product changes. Otherwise you may ship activation improvements that only look good because marketing compensated.

Pair retention with feature adoption

When a new feature ships, watch whether adopters retain better than non-adopters in the same acquisition cohort. If adoption is high but retention flat, the feature may be used without changing the core loop. If adoption is low but adopters retain strongly, your problem is discovery—not value.

Pick the return action carefully, set a realistic window, and cohort early behavior. Retention then becomes a decision tool instead of a vanity chart.

Feature adoption

A practical playbook for measuring feature adoption

June 11, 2026 · 10 min read · Product Analytics

Shipping is not adoption. Many teams celebrate release day, then wait months to learn whether anyone uses the feature deeply. A simple measurement playbook closes that gap: define eligible users, first-use, depth, and impact—then instrument those four layers before launch.

1. Eligible users

Not everyone should appear in the denominator. Gate by plan, role, platform, or account configuration. Measuring adoption against all signed-up users will understate success for a feature only available on Growth plan desktop. Document eligibility in the same place you document the event catalog.

2. First-use

Track the first time an eligible user completes the primary action of the feature (not merely seeing a tooltip). Time-to-first-use from exposure or release date tells you if discovery works. If first-use stalls, fix entry points and messaging before optimizing the feature itself.

3. Depth of use

One try is curiosity; repeated use is adoption. Define depth—for example three uses in fourteen days, or completing an advanced path. Depth metrics separate tour-driven spikes from real workflow change. Feature adoption boards in Sonicbean should show both first-use rate and depth rate for the same cohort.

4. Impact on product outcomes

Compare retention, conversion, or expansion between deep adopters and eligible non-adopters. Hold acquisition week constant so you are not confusing better customers with better features. If deep adopters retain more, you have evidence to invest in discovery. If they do not, revisit the value proposition.

Instrumentation checklist before launch

• Exposure or eligibility event (saw entry point / met gate)
• Primary success event with stable properties (mode, source, template)
• Error or abandon events for the critical path
• Dashboard with first-use, depth, and impact panels ready on day one

Close the loop with product reviews

Review adoption weekly for the first month after launch, then monthly. Share the same board with eng, design, and growth so debates stay grounded. Archive or redesign features that never clear a depth threshold after a fair discovery push—capacity is finite.

Measure eligibility, first-use, depth, and impact. That four-layer model turns “how is the feature doing?” into an answer you can act on in the next sprint.