Skip to content
Start in Cloud
← All posts

HitKeep 2.7.0: Smoother Realtime Analytics

Pascale Beier 6 min read

HitKeep 2.7.0 makes analytics dashboards update faster after new data arrives, without turning every live update into a full visual reload. When HitKeep accepts new traffic, event, ecommerce, Web Vitals, AI visibility, import, goal, funnel, or Opportunity data, the active dashboard can receive a site-scoped realtime signal and refresh the affected reports instead of waiting for the next polling cycle.

That matters most during setup, launches, campaigns, debugging, and demos. You can open the dashboard, trigger a pageview or event, and see the relevant report refresh as soon as the write path publishes the change. Existing KPI cards and charts stay on screen while the dashboard fetches fresh aggregates in the background, then changed metrics get a brief live-update highlight.

This release also moves the dashboard to Angular 22, updates Go release builds to 1.26.4, fixes AI fetch ingest for non-browser forwarders, and marks internal dashboard routes clearly in the OpenAPI output.

What changed

  • Faster dashboard updates: active reports refresh from site-scoped change signals after accepted writes. They no longer have to wait for the next periodic refresh when the realtime stream is open.
  • Smoother live updates: the dashboard keeps existing stats, KPI cards, and charts visible during realtime refreshes. Changed KPI values receive a short visual highlight after the refreshed aggregates arrive.
  • Less unnecessary reloading: each page registers the data types it cares about. Events pages refresh for event and ecommerce changes, Web Vitals pages refresh for Web Vitals changes, and overview pages can listen to the full analytics set. Manual refreshes and filter changes still show the normal loading state.
  • Shared dashboard support: share links use their own site-scoped realtime stream, so read-only shared reports can receive the same refresh signals as authenticated dashboard views.
  • Reconnect and resync behavior: the realtime broker keeps a short per-site event history, supports Last-Event-ID replay, sends heartbeats, and asks the dashboard to resync when a client misses too much history.
  • Polling fallback: dashboard pages still fall back to a periodic refresh when EventSource is unavailable, blocked by a proxy, or not open.
  • Angular 22: the dashboard build, tests, and dependencies are updated for Angular 22.
  • Go 1.26.4: release binaries, Docker images, development containers, and CI now use the Go version declared in go.mod, currently Go 1.26.4.
  • AI fetch ingest fix: server-side AI fetch forwarders that do not send browser fetch metadata can post authenticated crawler records without being rejected by the browser request-isolation fallback.
  • Internal API docs: realtime stream endpoints and the dashboard bootstrap endpoint are marked with x-internal: true in OpenAPI so generated docs can separate dashboard internals from the public API contract.

Where You Will Feel The Speedup

Before this release, dashboard freshness depended on each view’s normal reload behavior. In practice, that meant an operator could send a test hit or event and still wait for a polling cycle before the visible report caught up.

In 2.7.0, HitKeep publishes a realtime change event after the accepted write path completes. When the dashboard has an open stream for that site, it can schedule the relevant report refresh immediately. The refreshed data still comes from the normal aggregate report APIs, so charts, tables, exports, permissions, tenant isolation, and retention behavior stay on the same code paths as before.

The dashboard now treats realtime refreshes differently from manual reloads. A manual refresh, site change, or filter change can still show loading feedback because the visible question changed. A realtime update keeps the current report painted, fetches the latest aggregates in the background, and highlights only KPI cards whose values changed. The result is easier to scan during active traffic because the page does not blink back into skeleton states for every accepted hit.

This is especially useful for:

  • Tracking setup: confirm that a newly installed hk.js snippet sends pageviews without repeatedly pressing refresh.
  • Custom events: fire a test event and watch the Events dashboard update when the ingest consumer writes it.
  • Campaign checks: keep overview, UTM, ecommerce, and goal views open during a launch and see fresh activity sooner.
  • AI visibility: forward AI fetch records from edge or origin logs and let the AI visibility dashboard refresh when new crawler rows arrive.
  • Shared reports: send a read-only dashboard link and let viewers see current aggregate reports without giving them dashboard access.

What Realtime Means Here

Realtime in 2.7.0 means realtime refresh signals, not a separate streaming analytics database. HitKeep still serves normal aggregate reports from the embedded DuckDB stores. The realtime stream only tells the dashboard when data changed and which report families should reload. The dashboard decides whether that refresh should be visible loading or a quiet background update.

That design keeps the single-binary deployment model intact. There is no Redis, Kafka, hosted pub/sub service, browser analytics vendor, or second database to run.

The covered dashboard areas include overview traffic, events, ecommerce, goals, funnels, UTM, Web Vitals, AI visibility, AI chatbot analytics, and Opportunities. Imported historical rows remain separate from native realtime views where the source data does not contain native HitKeep event streams.

Reliability And Fallbacks

The stream is scoped to one site. Authenticated dashboard views use /api/sites/{id}/realtime, and read-only share links use /api/share/{token}/sites/{id}/realtime.

The server sends heartbeats to keep compatible proxy connections open. If a browser reconnects with Last-Event-ID, the broker can replay recent site events. If the browser missed too much history, HitKeep sends a resync event so the dashboard reloads instead of trying to patch around stale state.

If EventSource is unavailable, blocked, or disconnected, the dashboard uses the polling fallback. Realtime improves freshness when available, but it is not required for the dashboard to work.

Compatibility Notes

The realtime stream routes and dashboard bootstrap route are internal HitKeep dashboard routes. They are now visible as internal operations in OpenAPI, but they are not part of the public semver contract:

  • GET /api/sites/{id}/realtime
  • GET /api/share/{token}/sites/{id}/realtime
  • GET /api/user/bootstrap

Public API clients should not depend on those route shapes, EventSource payloads, replay behavior, or bootstrap response fields. They may change in a minor release when the dashboard needs a different internal contract.

The public analytics APIs remain the supported integration surface for site reports, exports, AI visibility, Web Vitals, MCP-read access, takeout, and server-side ingest.

Upgrade Guidance

Upgrade to 2.7.0 if you want dashboard reports to refresh sooner after new analytics writes, Angular 22 runtime maintenance, Go 1.26.4 release artifacts, or the AI fetch ingest fix for server-side log forwarders.

No new external services are required. Realtime refresh runs inside the existing HitKeep binary. If a proxy or browser blocks EventSource, the dashboard keeps using the polling fallback.

For AI fetch forwarders, keep using scoped API client tokens and the documented POST /api/sites/{site_id}/ingest/ai-fetch endpoint. The fix only changes request-isolation handling for non-browser clients. It does not make AI fetch ingest public or unauthenticated.

Read More