[Discussion / RFC] Dedicated monitoring profile for Web Applications (Website vs. Web App mode)

[thiagoalcav]

Hi!

As an enthusiastic user of the project following its development closely, I’ve recently been using HitKeep not only for traditional websites, but also to monitor internal web applications used by my team (management systems, timesheet portals, and day-to-day operational tools).

The tool collects data smoothly and remains rock-solid, but during regular usage I noticed that the dynamics and primary goals of a Web Application differ fundamentally from a standard Website or Landing Page.

I wanted to open this discussion to check if you would consider adding a project setting/flag (e.g., Type: Website | Web Application) to adjust the interface and tailor the dashboard specifically to what provides actionable value for applications.

Here is a summary of what I observed and how this distinction could streamline the interface:

1. Metrics and menus that add noise to Web Apps

For internal systems or authenticated SaaS tools, indicators tailored for marketing and SEO add visual clutter rather than insights:

• Bounce Rate: In a web application, a user who accesses /timesheets directly, submits an entry in 30 seconds, and closes the tab has completed their task successfully. In traditional web analytics, this is flagged as a "bounce".

• Acquisition / Top Sources: Traffic is almost entirely direct, internal bookmarks, or redirects from corporate collaboration tools (e.g., Teams, Slack), making acquisition charts uninformative.

• Marketing Modules: Sections like E-commerce, UTM, Search Console, and AI Agents (external crawler monitoring) rarely apply to authenticated routes.

2. What delivers genuine value for application monitoring

When analyzing software usage, the focus shifts from visitor acquisition to user adoption, workflow completion, and performance:

• Custom Events & Actions: Tracking key button clicks, form submissions, validation errors, and specific module usage.

• Feature Adoption (Screens/Routes): Knowing which system sections are used most frequently to help prioritize refactoring and maintenance.

• Web Vitals (Performance): Critical to ensure that data-heavy screens, large tables, and responsive elements run smoothly without UI lag for operators.

• Process Funnels: Monitoring completion rates for multi-step operational flows (e.g., Start Workflow $\rightarrow$ Fill Inputs $\rightarrow$ Save/Submit).

• Runtime Environment (Browsers/Devices): Helping engineering teams prioritize compatibility testing and layout validation.

3. Suggested implementation approach

The idea is to keep this lightweight without changing the core collection engine:

• Site Settings: A simple profile toggle (Website vs. Web Application).

• UI Adaptation: When set to Web Application, gracefully hide non-relevant sidebar menus (E-commerce, UTM, Search Console, AI Agents).

• Dashboard Card Tweaks: Replace bounce rate on the main overview with app-centric signals, such as actions/events per session or active screen duration.

4. Market differentiator and future observability

I believe this feature would give HitKeep a unique edge. Most web analytics tools remain strictly marketing-oriented; I am not aware of solutions that provide an explicitly adapted view for web application usage out of the box.

HitKeep caught my attention specifically because it stays ahead of the curve with modern capabilities like AI agent tracking. Providing a tailored view for applications feels like a natural step forward that would make a significant difference for teams monitoring internal tooling and SaaS products. Looking ahead, this could even lay the groundwork to bridge product analytics with broader observability workflows (via webhooks/APIs), correlating application usage patterns with system health.

Would this direction align with your vision and roadmap for HitKeep? If you find the concept worthwhile, I would be glad to help detail workflows, brainstorm UI layouts, or assist in any way that adds value.

I’ve been following your efforts in evolving the system and I know firsthand how much work goes into keeping an entire ecosystem of dependencies, languages, and components up to date and secure. As such, this issue is strictly a suggestion and open discussion—feel free to close it without taking any action if you decide that is best. I’ll continue using the application and contributing regardless, as I really like what you’ve built here. ;-)

Thanks for the great work on this project!

[TheBuilderJR]

Your timesheet example suggests that “actions per session” could recreate the bounce-rate problem in another form: a user who completes the same job with fewer clicks may be doing better. For the application profile, I’d make an explicitly confirmed business outcome the primary signal—e.g. the server confirms that the timesheet was saved—and use clicks, validation errors and elapsed time to explain the outcome.

One distinction worth keeping in the event definition is “submit clicked” versus “save accepted.” A click followed by a validation error should not count as a completed workflow, and a webhook/event redelivery should not create a second completion. That also gives the proposed funnel a clearer final step without requiring every app to share the same definition of success. I haven’t used HitKeep; this is feedback on the metric contract in your proposal. Disclosure: I’m JR, creator of Telemetry; AI assisted with this reply.

[PascaleBeier]

@thiagoalcav Would Sessions and Heatmaps benefit one of the two?

Do you have anything in mind how we could implement that in a way making the general user interface and user experience simpler?

I was thinking of how Google Search Console asks you what type of site you want to track. But I have to give it more thought.

[thiagoalcav]

Thanks for the valuable insights, @TheBuilderJR and @PascaleBeier!

Just to provide a bit more context: my initial post was intentionally kept high-level and basic, mainly to introduce the core concept of separating both worlds and gauge whether exploring an MVP around this would align with the maintainer's vision for HitKeep. Seeing this discussion take shape is encouraging, and the points raised help define a much sharper scope.

Regarding @TheBuilderJR's point on outcome vs. raw actions:

You make an excellent observation. High click volume can often signal confusion or poor UI ergonomics rather than productivity. Centering the metric contract around explicitly confirmed business outcomes (e.g., an accepted 200 response or a definitive submission_completed event) rather than an intent trigger like submit_clicked establishes a reliable funnel terminal step. Clicks, validation failures, and elapsed time then naturally serve as secondary diagnostic layers explaining why a workflow succeeded or stalled.

Regarding Sessions and Heatmaps (@PascaleBeier):

• Heatmaps: They bring immense value to both, but solve different problems. On websites, they highlight content engagement, reading depth, and banner visibility. On web applications, heatmaps are essential for spotting UX friction—dead clicks, input fatigue, confusing layouts, or overlooked primary action buttons.
• Sessions: Standard session lengths can be noisy for apps because users routinely leave dashboards open in background tabs throughout the workday. Shifting the lens toward active interaction time or grouping by discrete workflow lifecycles reflects real utility much better than a raw session timer.

UI/UX Implementation & MVP Idea:

The Google Search Console onboarding pattern mentioned is spot on for keeping things intuitive:

1. Setup Step: When creating a project, offer a straightforward profile choice:
   • Website / Content (default): Focus on visitor acquisition, SEO channels, UTM tracking, bounce rates, and organic discovery.
   • Web Application: Focus on workflows, event outcomes, active time, route adoption, and Web Vitals.
2. Context-Aware Sidebar: When configured as a Web Application, gracefully hide marketing-heavy items (UTM, Search Console, E-commerce) to minimize clutter without requiring separate codebases.
3. Overview Card: Replace the default Bounce Rate slot with a configurable primary outcome rate (or completed workflows per active session).

This keeps the data collection contract simple to maintain while giving development and product teams a purpose-built workspace out of the box.

[PascaleBeier]

@gnacho Also interested to get your use case here

[gnacho]

Hi, thanks for the mention, @PascaleBeier

Some context on my use case: we are a small IT consultancy evaluating solutions in order to provide marketing services, as we develop websites and ecommeces, is the next logical step. HitKeep is by far the best tool we tried (and we tried many) For us the context is the opposite of @thiagoalcav s: we need precisely the full "Website" profile - traffic, acquisition, e-commerce, Search Console and, looking ahead, whatever modules come next. For other use cases (infrastructure monitoring, service status) we already run dedicated tools, so our perspective here is that of a team looking to consolidate web analytics for clients.

That said, I think the proposal is solid, and here is my take from this side:

• It validates how important the full Website profile is: for us, the modules the proposal labels as "noise" (e-commerce, UTM, GSC) are exactly the ones that justify migrating. Any sidebar redesign driven by profiles must guarantee that the Website profile still surfaces all of these at the top level, not buried behind a toggle.

• Module customization via admin settings: rather than a fixed toggle at project creation (Website vs. Web App), I believe the more flexible solution is to let administrators enable or hide modules per project from the settings. This is consistent with the customization that already exists when sharing the dashboard with other users, and it covers the proposal's case without forcing a rigid taxonomy: a SaaS with a customer area could have e-commerce visible and Search Console hidden, for example.

• Hybrid websites: in practice, many client sites are a mix - a public marketing side plus an authenticated customer area or tool. The ideal configuration would be reversible at any time and act on the view (which cards and menus get priority), never on the collected data.

• Sidebar structure: on a FullHD desktop the sidebar already overflows the viewport and requires vertical scrolling, which is unnecessary friction for primary navigation. The last three sections - "Account", "Resources" and "Administration" - are the least frequently used and do not apply to every user (Administration is admin-only, for example). Grouping them as collapsible sections (or nesting them under a single group) would free up enough room for the whole main menu to fit without scrolling. In fact, the root cause here is not the Website vs. Web App profile, but that the sidebar in general needs restructuring into fewer top-level areas; the profiles proposal would only pile more items onto it if this is not addressed first.

• I agree with @TheBuilderJR's point: measuring server-confirmed outcomes instead of click intent. This is a principle I would like to see applied to e-commerce funnels in the Website profile as well (confirmed purchase vs. "pay" clicked), not just to the application profile.

• Heatmaps and sessions: useful in both profiles. In e-commerce, heatmaps on the product page and checkout are extremely valuable; and the forgotten-background-tab problem thiagoalcav mentions also exists on websites with registered users.

From our position, if HitKeep covers the full Website profile well and matures the e-commerce and GSC modules, it has become our choice to consolidate all of our clients' analytics into a single self-hostable tool.

[thiagoalcav]

Thanks for the thoughtful feedback, @gnacho.

I completely agree with your points. My goal was never to undermine or shift the focus away from websites and e-commerce. I actually consider HitKeep the best tool available today precisely because it excels at that.

The idea was simply to explore a leaner, purpose-tailored view when tracking web applications (strictly keeping it focused on usage/product analytics, not infrastructure monitoring, which belongs to dedicated tools).

Your suggestion of allowing administrators to toggle modules on/off per project in the settings addresses this perfectly without creating rigid project types. It preserves HitKeep's core strengths for marketing/e-commerce while adding a solid competitive edge for tracking web applications.

[PascaleBeier]

What do you guys think on how Claude does it?

[gnacho]

In my opinion, PR #391 (reorganize navigation and declutter the sidebar) could solve most of the menu-related problems. It addresses what I see as the root cause: too many top-level areas, with the least used ones (Account, Resources, Administration) grouped out of the way. Full disclosure: I authored it, so take this with a grain of salt, but if it lands, primary navigation fits a FullHD viewport without scrolling.

The Claude pattern is nice, but it solves a different problem. "Edit sidebar" is per-user personalization: everyone curates their own menu. That is a great fit for a product where every user has wildly different habits, but it adds a whole personalization layer (storage, defaults, first-run decisions) on top of navigation. From my side, I would rather see the effort go into the data side: e-commerce depth, GSC, events. That is where the tool wins or loses users like me.

One related point that neither reorganization nor personalization covers, at least from my point of view: visibility by context. A menu entry that leads somewhere the user cannot or will not use is noise no matter how the menu is structured:

• Sections that require setup that has not happened yet (Search Console before OAuth is connected, AI Agents before anything is configured) could be hidden, or carry a "connect" affordance only for users who can actually connect them.
• Reference material and admin-only areas do not need to be visible to every role, and the same applies to shared/public dashboards.

That would deliver most of the value of a customizable sidebar with almost no UI: sane defaults, progressively revealed as things get configured. I would treat Claude-style per-user customization as a later step, if at all, not the next thing to build.