HitKeep | Blog

HitKeep 2.5.0: Web Vitals, Opportunities, And Subdirectory Installs

Wed, 13 May 2026 00:00:00 GMT

HitKeep 2.5.0 is in release-candidate review for Web Vitals analytics and Opportunity Recommendations. The release candidate adds opt-in LCP, INP, CLS, FCP, and TTFB reporting beside traffic analytics, plus a saved recommendations inbox for setup gaps, traffic signals, search visibility, AI visibility, ecommerce activity, conversion signals, and performance issues backed by aggregate evidence already in HitKeep.

It also hardens self-hosted deployments that mount HitKeep below an existing domain path, such as https://www.example.net/hitkeep/. Dashboard navigation, static assets, API calls, the API reference, tracker bundles, browser ingest, email links, share links, billing redirects, and OAuth callbacks now derive their public paths from HITKEEP_PUBLIC_URL.

The product promise is deliberately narrow: HitKeep shows privacy-preserving performance signals and evidence-backed recommendations. It does not collect Web Vitals attribution payloads, promise revenue lift, claim financial upside, or infer causal attribution.

Web Vitals cards show p75 values, thresholds, rating mix, and the selected metric trend without enabling Web Vitals by default.

Opportunity cards use stable translation keys and cited aggregate evidence, so the same saved recommendation can render safely in every supported dashboard language.

What Is Prepared

Opt-in Web Vitals collection: the default hk.js snippet stays lean. Sites load the same-origin hk-vitals.js split bundle only when Web Vitals are enabled in tracking settings or data-enable-web-vitals="true" is present.
Web Vitals dashboard: site teams can inspect p75 cards, threshold bars, rating mix, trends, searchable path selection, paginated page breakdowns, and browser, country, language, and device context for LCP, INP, CLS, FCP, and TTFB.
Privacy-preserving samples: HitKeep stores metric, value, server-derived rating, normalized path, navigation type, session/page IDs, tracker source/version, and server receipt time. It strips query strings and hashes and does not store attribution/debug payloads, selectors, text, or resource URLs.
Lifecycle coverage: Web Vitals samples are tenant-local and covered by site deletion, user deletion, archival, retention, takeout exports, and read-only MCP aggregate access.
Opportunity inbox: every site can list saved recommendations, filter by status, open the evidence drawer, dismiss items, mark them done, and regenerate them when the user has site.manage_data.
Evidence-first generation: deterministic detectors decide the candidate type, impact, confidence, score, status, route params, and evidence IDs. Web Vitals detectors can create Performance Opportunities from poor or needs-work metric evidence. AI is optional and can only decorate the detector-approved candidate.
Provider-agnostic AI model configuration: self-hosted operators can configure their chosen provider, model, gateway route, timeout, and local budgets through HITKEEP_AI_* settings without dashboard-secret editing in this first slice.
Local budgets and audit records: HitKeep enforces request and token caps before provider calls, records safe run metadata, stores lifecycle events, and avoids persisting raw prompts or raw provider payloads.
System Status visibility: instance owners can see whether AI is enabled and configured, which provider/model label is active, whether the config is cloud-managed or self-hosted, current usage and cap state, and the last safe success/error category.
Subdirectory install support: operators can set HITKEEP_PUBLIC_URL to a path-prefixed URL. HitKeep serves the dashboard base href, app-owned static assets, API reference iframe, hk.js, hk-vitals.js, ingest routes, and generated public links below that prefix.
Public-safe surfaces: saved Opportunities appear in dashboard APIs, share mode, takeout exports, read-only MCP output, and the regular daily, weekly, or monthly email reports without exposing provider secrets or unrestricted tool execution. Web Vitals dashboard APIs and MCP tools return aggregate reporting data only.
Localization-safe API: customer-facing copy is stored as translation keys plus interpolation params. The API does not persist full English recommendation text as the durable contract.

Guardrails

Web Vitals collection is opt-in. HitKeep derives ratings on the server from standard thresholds, stores samples in the tenant analytics store, and keeps the tracker payload compact. The Web Vitals feature is for aggregate page-performance reporting, not user-level profiling or debugging traces.

Opportunity Recommendations use aggregate evidence only. Traffic-source recommendations must cite source-specific counts, not total site pageviews. Setup suggestions need a clear page, event, goal, or funnel signal and are suppressed when matching configuration already exists.

The validator rejects provider output that invents evidence IDs, adds trailing prose after JSON, uses removed money/upside params, references unsupported fields, or makes claims outside the detector contract.

Upgrade Guidance

Web Vitals are off by default. Enable them from Site Settings > Tracking for a site, or add data-enable-web-vitals="true" to that site’s tracking snippet. The main tracker only loads hk-vitals.js from the same origin when the opt-in flag is present.

For subdirectory installs, set HITKEEP_PUBLIC_URL to the full external URL, including the path prefix, and keep the reverse proxy route aligned with that prefix:

HITKEEP_PUBLIC_URL=https://www.example.net/hitkeep/

In path-prefix mode, public app and API routes are served below the configured prefix. Root /healthz and /readyz remain available for local probes.

Self-hosted instances can leave AI disabled. With HITKEEP_AI_ENABLED=false, HitKeep still runs deterministic detector logic and stores recommendations that do not need provider enrichment.

To enable provider enrichment on self-hosted instances, configure the HitKeep provider/model route, timeout, request cap, token cap, and budget window through HITKEEP_AI_* variables. Configure provider credentials with the selected goAI provider’s native environment variables.

HITKEEP_AI_ENABLED=true
HITKEEP_AI_PROVIDER=openai
HITKEEP_AI_MODEL=your-json-capable-model
OPENAI_API_KEY=provider_key_from_your_secret_store
HITKEEP_AI_REQUEST_LIMIT=100
HITKEEP_AI_TOKEN_LIMIT=100000
HITKEEP_AI_BUDGET_WINDOW=1440

For OpenAI-compatible gateways, set HITKEEP_AI_PROVIDER=openai-compatible and HITKEEP_AI_BASE_URL for the gateway endpoint. Set HITKEEP_AI_API_KEY only if that gateway requires a bearer token. See AI Model Configuration for model-selection guidance, setup examples, token-budget sizing, and the System Status fields operators should verify before release.

Out Of Scope

This release candidate does not add Web Vitals attribution/debug fields, sampling controls, external performance vendors, share-link Web Vitals reports, dashboard-secret editing for provider keys, customer-defined detectors, write-capable MCP tools, or financial upside predictions. Ecommerce analytics can still report factual revenue metrics, but Opportunity Recommendations do not position themselves around money claims.

HitKeep 2.4.2: Site Export Dropdown Fix

Fri, 08 May 2026 00:00:00 GMT

HitKeep 2.4.2 is a focused patch release for dashboard exports. It fixes the site-specific export format dropdown so choosing CSV, XLSX, Parquet, JSON, or NDJSON starts the matching site takeout download.

The all-sites export dropdown already worked. This patch keeps that behavior unchanged and tightens the site-row path that calls /api/sites/{id}/takeout?format=<format>.

What changed

Site export menu actions: site export dropdown items stay bound to the intended site row while the menu is open.
Alternate formats: CSV, XLSX, Parquet, JSON, and NDJSON remain available for site-specific takeout downloads.
Global exports unchanged: the all-sites export dropdown still calls /api/user/takeout?format=<format>.
Regression coverage: focused unit coverage checks repeated site menu reads, and seeded Playwright coverage verifies all-sites and per-site JSON downloads in the German dashboard at the reported desktop viewport.

Upgrade guidance

Upgrade to 2.4.2 if users rely on site-specific exports from the Import & Export page.

No backend export schema, takeout endpoint, permission model, or supported format changes are included in this patch.

HitKeep 2.4.1: MCP Reliability And Go Security Fixes

Thu, 07 May 2026 00:00:00 GMT

HitKeep 2.4.1 is a focused patch release for operators who enable the optional MCP server behind a reverse proxy. It also updates HitKeep release builds to Go 1.26.3 after govulncheck reported called vulnerabilities in the Go 1.26.2 standard library.

The release fixes MCP Streamable HTTP initialization when HitKeep listens on loopback, such as 127.0.0.1:8080, and a reverse proxy exposes the public /mcp endpoint. Valid MCP clients should now initialize through the configured public host instead of receiving a plain-text host-header 403 before HitKeep can validate the bearer token.

What changed

Reverse-proxied MCP initialization: HitKeep now validates MCP request hosts against HITKEEP_PUBLIC_URL before handing the request to the MCP Go SDK.
Public host support: deployments that publish /mcp at a public hostname can initialize MCP clients while keeping HitKeep bound to loopback.
Local development preserved: loopback hosts such as localhost, 127.0.0.1, and ::1 continue to work for local MCP clients.
Host validation kept explicit: unexpected hosts still receive 403 Forbidden; missing or invalid bearer tokens on valid hosts receive 401 Unauthorized.
No MCP schema changes: MCP tools, resources, bearer token format, API-client scopes, and dashboard API behavior are unchanged.
Go 1.26.3 release builds: Linux binaries, Docker images, and CI now use Go 1.26.3. This clears the standard-library govulncheck findings that affected Go 1.26.2.

Upgrade guidance

Upgrade to 2.4.1 if you enable MCP and expose HitKeep through a reverse proxy, or if you want release artifacts built with Go 1.26.3.

Make sure HITKEEP_PUBLIC_URL matches the externally visible origin:

HITKEEP_PUBLIC_URL=https://analytics.example.com
HITKEEP_MCP_ENABLED=true
HITKEEP_MCP_PATH=/mcp

The simplest proxy setup preserves the original Host header. If your proxy rewrites the upstream Host to a loopback address, configure explicit HITKEEP_TRUSTED_PROXIES CIDRs and forward the public host with X-Forwarded-Host or the standard Forwarded header.

HitKeep 2.4.0: Imports, Search Console, MCP Reporting, Server-Side Ingest, And Dutch Localization

Wed, 06 May 2026 00:00:00 GMT

HitKeep 2.4.0 was published on May 6, 2026. It ships historical imports for Plausible and Simple Analytics, Google Search Console Search Analytics import, read-only Search Console reporting through MCP, authenticated server-side tracking with original timestamp and visitor IP context, Dutch dashboard and email localization, and focused reliability and UX fixes from the 2.4.0 changelog.

The import system is aggregate-first. Plausible exports and Simple Analytics datapoints are migration history, not full-fidelity native HitKeep sessions. Imported data appears in compatible dashboard and event reports, while realtime, hourly, and relationship-heavy filtered views keep native data separate and explain when imported rows are excluded.

What shipped in 2.4.0

Importables framework: a provider model for future importers, with Plausible and Simple Analytics as the first providers.
Plausible ZIP and CSV input: upload one Plausible export ZIP or loose CSV files whose headers match supported Plausible schemas.
Simple Analytics datapoints input: upload any CSV whose header matches the Simple Analytics All datapoints export.
Mandatory validation: validation scans staged files row by row and returns a manifest before analytics rows are committed.
Historical dashboard coverage: imported traffic, page, source, device, location, and provider-specific dimension aggregates appear in compatible daily and monthly reports.
Imported event coverage: Plausible custom events and URL-style properties appear in compatible Events views.
Google Search Console integration: connect a team to Google Search Console with read-only OAuth, map a site to a Search Console property, and import finalized Search Analytics aggregates.
Search Console drilldown: authenticated site dashboards show clicks, impressions, CTR, average position, trends, top queries, top pages, and country/device breakdowns.
Search Console MCP reporting: approved MCP clients can check Search Console mapping and sync status, then read imported overview, series, query, page, country, and device aggregates for scoped sites.
CLI and REST API: the dashboard flow uses the same chunked upload, validation, start, status, list, and delete lifecycle as the CLI and API.
Import history and deletion: completed imports can be inspected and deleted, including their imported aggregate rows.
Server-side pageview and event ingest: scoped API clients can send trusted pageviews and custom events with an explicit RFC3339 timestamp and transient visitor IP context.
Server-to-server request behavior: the server-side ingest endpoints do not require browser Origin or Referer headers, use the ingest rate limiter, and forward safely from follower nodes to the leader in clustered deployments.
Dutch dashboard and email localization: Dutch (nl) becomes selectable in user preferences, auto-detects from Dutch browser and request languages, and covers the localized transactional and analytics report emails.
Reliability and UX fixes: 2.4.0 also optimizes the healthcheck endpoint, sets the Docker healthcheck interval to 30 seconds, consolidates frontend and auth bootstrap behavior, refreshes the May IP location data, clarifies server-side pageview copy, unifies copy actions for team, site, and user IDs, and consolidates import and export UI behavior.

Google Search Console Integration

Search Console import is for teams that want organic search query data beside HitKeep’s normal site analytics without exposing that data through public dashboards.

Team owners and admins connect Google Search Console through read-only OAuth. HitKeep stores the team connection, lists available Search Console properties, and lets an admin map one property to a HitKeep site. Viewers can see the mapping state, but they cannot connect, map, unmap, disconnect, or request syncs.

The integration page keeps connection, property mapping, and sync status in the same team-scoped workflow.

The import uses Google’s official generated Search Console client behind HitKeep’s own adapter. It requests the read-only Search Console scope and imports finalized aggregate Search Analytics rows. Tokens, OAuth codes, client secrets, and raw Google payloads stay out of API responses, logs, audits, seed data, exports, and public share surfaces.

Sync is tenant-scoped. A manual sync request should give immediate feedback in the dashboard, while the worker imports rows through the same in-process runtime used by self-hosted and cloud deployments. Recurring syncs recheck recent completed days because Search Console data can settle after initial availability.

Search Console reports stay inside authenticated dashboards and are excluded from share-mode dashboards.

The report surface is aggregate-first: overview metrics, daily series, top queries, top pages, and country/device breakdowns. It does not claim query-to-session attribution because Search Console does not provide that relationship. Use GA4 or another attribution system if your workflow depends on connecting individual search queries to sessions or conversions.

The optional HitKeep MCP server also reads the imported Search Console rows for approved assistants and internal reporting tools. Two read-only tools cover the workflow: hitkeep_get_search_console_status reports mapping state, property URI, safe permission level, sync state, imported date range, and attention reason; hitkeep_get_search_console returns imported overview and daily series by default, with query, page, country, and device sections only when requested.

MCP does not call Google live, refresh OAuth credentials, or trigger Search Console syncs. If the last sync failed or needs attention, MCP can still return older imported rows with warnings such as search_console_sync_failed, search_console_sync_needs_attention, or requested-range warnings. Healthy reports return an empty warnings array.

Server-Side Tracking

2.4.0 makes server-side tracking a first-class ingest path for log replay, edge workers, backend services, and no-JavaScript collection. The API-client-only endpoints accept one pageview or custom event at a time:

POST /api/ingest/server/pageview
POST /api/ingest/server/event

The submitted URL resolves the HitKeep site by hostname. The API client still needs site.manage_data for that site, so a token scoped to one site cannot write records for another domain.

Each record can carry the original RFC3339 timestamp from the log source. HitKeep stores that timestamp as the analytics time, which means replayed records land in the correct daily and monthly buckets instead of using the time the import worker happened to send the request.

The visitor_ip field is trusted transient context. HitKeep uses it for IP exclusions, spam filtering, and pageview geolocation, then stores the derived analytics fields rather than keeping the visitor IP on the hit or event record.

These endpoints are meant for server-to-server clients. They do not require browser Origin or Referer headers, and they use the ingest rate limiter instead of the normal dashboard API limiter because log forwarders and edge workers often send bursts from one IP. In clustered deployments, follower nodes forward these requests to the leader before authentication and persistence.

2.4.0 does not add a public batch request format. The HTTP contract stays one record per request for now, while the existing NSQ and DuckDB write path batches persistence internally.

Imports Page

The Imports page lives with the selected site’s analytics workflow. It is available to users with site.manage_data, which includes site owners, site admins, effective team owners and admins, instance owners, and instance admins.

The import flow starts by choosing the site-scoped importer.

After choosing Plausible, HitKeep accepts the normal Plausible export ZIP directly. If a team already unpacked the archive, the same flow accepts loose CSV files whose headers match supported Plausible export schemas. Partial imports are allowed when at least one recognized dataset validates.

After choosing Simple Analytics, HitKeep expects a CSV with the All datapoints header from the Simple Analytics export page. Use the All export rather than a single report export so HitKeep can validate the pageview rows, dates, paths, referrers, devices, countries, and UTM source data together. HitKeep uses the selected site domain, not the filename, to suppress self-referrers from imported source reports.

Validation Before Commit

Validation is mandatory. It does not write final analytics rows. It stages the files, scans each CSV row, checks headers and values, computes the date range, records skipped rows, and produces a compact manifest for review.

The Plausible manifest shows accepted files, ignored files, missing optional files, dataset counts, rows accepted and skipped, estimated pageviews and events, event names, property keys, and warnings when Plausible aggregates cannot prove a relationship.

The Simple Analytics manifest shows the accepted datapoints CSV, the imported date range, accepted and skipped rows, estimated traffic metrics, and unsupported datapoint types. That review step is important because Simple Analytics exports do not contain every native HitKeep dimension.

The validation manifest gives site admins a concrete review step before the import starts.

Compatible Historical Reports

After confirmation, HitKeep imports the rows in small transactions and tags them with the import id, provider, source file, date, dimension or event key, and metrics. The UI updates import history as the job moves through validation, running, completed, failed, and deleted states.

Imported Plausible traffic is daily-grain aggregate data. It is included where the query can use it safely:

visitors, visits, pageviews, bounces, visit duration, pages per session
pages, entry pages, exit pages, sources, devices, browsers, operating systems, and countries
daily and monthly chart buckets

Imported Simple Analytics traffic is built from the All datapoints CSV. It is included in compatible historical reports for:

visitors, visits, pageviews, and visit duration totals
pages, sources, devices, countries, browser names, language codes, and UTM source when those fields exist in the CSV
daily and monthly chart buckets

Imported rows are excluded from realtime and hourly views because the migration exports do not contain native HitKeep event streams. If a filter requires raw session relationships the source export cannot prove, HitKeep returns native data and an imported_excluded reason instead of fabricating precision.

Validation also checks for native HitKeep data already present in the imported date range. The default policy is skip_native_day: overlapping traffic days and matching event/day pairs are reported in the manifest and skipped during import so historical rows do not double count data HitKeep has already tracked.

Events And Source Limits

Plausible custom events are imported into compatible Events reports. Event names, event totals, event visitors, and property breakdowns are available when the CSV data proves the relationship. Plausible system events that match HitKeep automatic events, such as Outbound Link: Click, are normalized to HitKeep names like outbound_click.

Simple Analytics imports focus on pageview history. HitKeep imports browser and language breakdowns when the datapoints CSV includes browser_name and lang_language, but it does not invent bounce counts, native HitKeep events, goals, funnels, ecommerce activity, or conversion relationships from the export. Unsupported datapoint types are reported during validation so the site admin sees the coverage before importing.

Imported Plausible events appear in the Events dashboard, including URL property breakdowns where the export supports them.

For Plausible property files that do not include an event name, HitKeep imports the property aggregate as unattributed coverage and shows a warning in the validation manifest. Those rows no longer inflate queryable event totals. The review step separates queryable custom events from preserved custom property aggregates, and the Events dashboard explains that Plausible exports do not contain event-level source, browser, device, country, or language relationships.

Event goals with matching imported Plausible custom events include imported visitors as historical conversions where aggregate math is safe. Filtered, comparison, hourly, and audience-dimension views continue to show explicit imported-data limitation reasons instead of synthesizing relationships the export cannot prove.

CLI And API

The dashboard uses the same resumable upload protocol as the CLI and REST API. That matters for large exports and repeatable operations, especially self-hosted instances with long-lived historical data. Imports now run through a restart-recoverable in-process runner: queued or interrupted jobs with staged files are picked back up on startup, while jobs whose staged files are missing fail with a clear error.

The CLI reuses HITKEEP_PUBLIC_URL when it is already set, and otherwise talks to http://localhost:8080. Use --url only when importing into a remote instance from another machine.

For Plausible, validate and import the export ZIP:

export HITKEEP_API_TOKEN="hk_api_..."

hitkeep import validate plausible \
  --site <site-id> \
  --file plausible-export.zip

hitkeep import plausible \
  --site <site-id> \
  --file plausible-export.zip \
  --wait

Loose Plausible CSV files and export directories work from the CLI too:

hitkeep import validate plausible \
  --site <site-id> \
  --file imported_visitors.csv \
  --file imported_custom_events.csv

hitkeep import plausible \
  --site <site-id> \
  --dir ./plausible-export \
  --yes \
  --wait

For Simple Analytics, validate and import the All datapoints CSV:

hitkeep import validate simpleanalytics \
  --site <site-id> \
  --file simple-analytics-export.csv

hitkeep import simpleanalytics \
  --site <site-id> \
  --file simple-analytics-export.csv \
  --wait

The lifecycle commands are:

hitkeep import start --site <site-id> --import-id <import-id> --wait
hitkeep import status --site <site-id> --import-id <import-id>
hitkeep import list --site <site-id>
hitkeep import delete --site <site-id> --import-id <import-id>

The REST API exposes the same flow: list importers, create upload, upload file chunks, validate, start, fetch status, list history, and delete. See the Imports API reference for the endpoint list.

Built For Large Sources

The Plausible and Simple Analytics importers stream work row by row. They do not call ParseMultipartForm, do not hold full CSV files in memory, and do not build an in-memory manifest of every row. Plausible ZIP files are staged on disk, recognized entries are scanned sequentially, and loose CSV files are scanned sequentially.

The default staged import limit is 100 GiB and can be changed with HITKEEP_IMPORT_MAX_STAGE_BYTES. Import upload requests use the normal API rate limiter, so operators only have one authenticated API budget to tune.

HitKeep 2.3.1: Clearer System Status For Backups, Workers, And Rejected Traffic

Thu, 30 Apr 2026 00:00:00 GMT

HitKeep 2.3.1 tightens the operational visibility added in 2.3.0. It is a small patch release for instance owners and cloud operators who rely on System Status to answer a simple question: is the instance healthy right now?

The release does not add a new analytics surface. It makes existing status data clearer for backups, worker connectivity, spam filtering, rejected ingest requests, and managed cloud operations.

What changed

Backup worker status: System Status now reports backup success, failures, recent failure count, last error, and next run time from the live backup worker.
Worker health: leader instances now surface degraded NSQ worker connectivity instead of looking healthy when the producer is unavailable or failing.
Spam and rejection counters: dropped spam hits, dropped spam events, rejected pageview ingest requests, rejected event ingest requests, and rejected AI fetch requests now increment system counters.
Managed cloud status link: managed cloud admin settings now link directly to status.hitkeep.com for hosted incident status.
Maintenance refreshes: the release also includes Go dependency updates and refreshed dashboard screenshots.

HitKeep 2.3.1 makes the System Status data behind this view more complete for operational checks.

Upgrade guidance

All 2.3.0 operators should upgrade to 2.3.1. The update is especially useful for:

managed cloud deployments
instances using automatic S3 or filesystem backups
high-traffic self-hosted instances where rejected or spam traffic should be visible
clustered deployments where worker health needs to be explicit

Use the normal release artifacts from GitHub. There are no extra migration steps for this patch.

HitKeep 2.3.0: MCP, WordPress, More Events, Installation & Activation Center

Sat, 25 Apr 2026 00:00:00 GMT

HitKeep 2.3.0 is built around the Installation & Activation Center: HitKeep now tells you whether tracking is actually live, guides new users to their first value, and lets instance owners see which teams and sites are active.

The activation work ships with the rest of the 2.3.0 release: read-only MCP analytics access, a first-party WordPress plugin, automatic outbound click, file download, and form submit events, a dedicated System Status area for operations and audit visibility, and a warning before dashboard sessions expire. The release keeps to HitKeep’s existing shape: one tracker, one event pipeline, one permission model, and the same single-binary runtime for cloud and self-hosted deployments.

What shipped

Live Tracking Verifier: Site Settings now shows whether tracking is waiting, live, dormant, or receiving traffic from a mismatched hostname.
Cloud onboarding checklist: the dashboard computes setup progress from real product state instead of asking users to tick fake boxes.
Instance owner Activation view: System Status now shows which teams and sites are live, waiting, dormant, or missing recent automatic events.
Tracker metadata hooks: hk.js reports itself as the source by default, with snippet attributes for WordPress and future SDK versions.
Read-only MCP analytics access: approved assistants and internal tools can query scoped aggregate analytics without dashboard cookies.
First-party WordPress plugin: WordPress sites can install the normal HitKeep tracker without editing theme templates or adding a tag manager.
Automatic tracker events: hk.js records outbound clicks, file downloads, and form submissions through the existing event pipeline.
System Status operations: instance owners and admins get health, storage, tenant footprint, backup, spam filter, mail test, and audit visibility in one area.
Session expiry warning: dashboard users get a clear warning and stay-signed-in action before their session expires.

Installation & Activation Center

The new verifier card lives in Site Settings → Tracking. It shows first and last hit timestamps, last event, detected hostname, last automatic event, tracker source, tracker version, and a refresh action. New installs poll briefly while waiting for the first accepted hit, then flip to live when data arrives.

The Live Tracking Verifier gives site owners a direct answer to the first install question: is tracking actually live?

The dashboard checklist uses the same operational state. Creating a site, receiving the first hit, seeing automatic events, inviting a teammate, and scheduling reports complete automatically when the underlying product state exists.

The onboarding checklist is compact and dismissible, so new users know the next useful action without a wizard.

For operators, System Status now includes an Activation tab. Instance owners can see team, owner email, site domain, activation status, first and last hit, last event, and 24-hour/7-day aggregate counts. The table is intentionally operational: no IPs, user agents, paths, session IDs, raw referrers, or visitor journeys.

Instance owners can spot live, waiting, and dormant users without opening tenant databases or impersonating users.

MCP for governed analytics access

HitKeep now includes an optional MCP server on the main HTTP server. It is built for teams that want approved assistants or internal tools to answer analytics questions through HitKeep’s permission model.

It is disabled by default. When enabled, it mounts at /mcp and accepts existing API client bearer tokens. It does not accept dashboard cookies.

The v1 MCP surface is intentionally read-only. Assistants and internal reporting tools can list visible sites, fetch aggregate overview metrics, inspect event breakdowns, query ecommerce summaries, read AI visibility analytics, and fetch HitKeep docs as Markdown.

It does not expose raw hit exports, write tools, billing operations, site creation, or instance administration.

MCP lets approved assistants answer analytics questions from aggregate HitKeep data while staying inside scoped, read-only API client access.

hitkeep \
  -mcp-enabled \
  -mcp-path /mcp

This keeps MCP aligned with the same access model as the REST API: scoped API clients, site permissions, API rate limits, and tenant-aware analytics stores. Cloud and self-hosted deployments use the same contract.

A first-party WordPress plugin

The new WordPress integration installs the normal HitKeep tracker without editing a theme template or adding a tag manager.

The plugin stays thin on purpose. WordPress is only the installation point:

WordPress page -> hk.js -> HitKeep /ingest and /ingest/event -> DuckDB

It does not create WordPress analytics tables, set analytics cookies, or send traffic to a third-party analytics backend. Site owners choose EU Cloud, US Cloud, or a self-hosted HitKeep URL, and the plugin loads hk.js from that instance.

The defaults are conservative. Logged-in WordPress users are not tracked, Do Not Track is respected, and pageviews plus automatic events are enabled for public visitors. Site owners can inspect the generated snippet before saving.

The WordPress settings screen keeps the instance connection, privacy defaults, automatic event controls, and generated snippet preview in one place.

The plugin installs through the normal WordPress plugin workflow and can be opened from the standard admin screen.

Automatic events from the tracker

HitKeep’s browser tracker now records three built-in automatic events with the default snippet:

outbound_click
file_download
form_submit

These events use the existing event pipeline and dashboard. There is no separate schema, second ingestion route, or extra reporting product. The same Events page handles manual product events and automatic tracker events.

Automatic events land in the existing Events dashboard, so outbound clicks, downloads, and form submissions can be analyzed next to manual events.

The payloads are deliberately narrow. HitKeep strips query strings and hashes and does not capture link text, form field values, or request bodies.

<script async src="https://your-hitkeep.example/hk.js"></script>

If a site needs a narrower tracking surface, you can disable event classes from the dashboard tracking settings or with snippet attributes:

Tracking settings make automatic event coverage explicit and adjustable per site.

<script
  async
  src="https://your-hitkeep.example/hk.js"
  data-disable-outbound-tracking="true"
  data-disable-download-tracking="true"
  data-disable-form-tracking="true"
></script>

A system status page for real operators

HitKeep now has a dedicated System Status and Settings area for instance owners and admins. System Status is its own sidebar item. System Settings stays focused on users, sites, teams, and global filters.

System Status shows what the instance is doing: version, health checks, storage paths, tenant database sizes, recent hit volume, enabled features such as MCP and backups, LRU cache pressure, automatic backup state, spam database freshness, mail delivery configuration, and instance audit activity.

System Status gives operators a direct view of runtime health, storage, tenant database footprint, ingestion volume, and cache state.

The Operations tab separates passive refreshes from real maintenance actions. Refreshing a status card reloads that card. Refreshing the spam database downloads and rebuilds the configured spam lists. Sending a test email uses the configured mail transport and sends an actual message to the specified recipient.

The Operations tab makes backups, spam filter freshness, and mail delivery testable without asking operators to inspect logs first.

Sensitive actions are written to the instance audit log with actor, action, target, outcome, IP address, user agent, request ID, and details where available.

The instance audit log records maintenance actions such as spam database refreshes and mail tests.

The result is less guesswork during operations. Admins can check whether automatic backups are configured, whether the spam database is stale, whether the mail transport works, and which maintenance actions were attempted.

A clearer timeout warning

Dashboard sessions now warn users before they expire.

When the session enters the configured warning window, HitKeep shows the remaining time, the instance session policy, and two clear actions: stay signed in or sign out.

The goal is to support teams that review dashboard behavior against timed-session accessibility expectations, including WCAG 2.1 Success Criterion 2.2.1 (Timing Adjustable) and EN 301 549, the standard used with the EU Web Accessibility Directive. The warning gives users a simple way to extend the session before timeout while still respecting the instance’s configured session policy.

The session expiry dialog gives users a clear choice before the dashboard signs them out.

HitKeep | Blog

HitKeep 2.5.0: Web Vitals, Opportunities, And Subdirectory Installs

What Is Prepared

Guardrails

Upgrade Guidance

Out Of Scope

Read More

HitKeep 2.4.2: Site Export Dropdown Fix

What changed

Upgrade guidance

Read more

HitKeep 2.4.1: MCP Reliability And Go Security Fixes

What changed

Upgrade guidance

Read more

HitKeep 2.4.0: Imports, Search Console, MCP Reporting, Server-Side Ingest, And Dutch Localization

What shipped in 2.4.0

Google Search Console Integration

Server-Side Tracking

Imports Page

Validation Before Commit

Compatible Historical Reports

Events And Source Limits

CLI And API

Built For Large Sources

Read More

HitKeep 2.3.1: Clearer System Status For Backups, Workers, And Rejected Traffic

What changed

Upgrade guidance

Read more

HitKeep 2.3.0: MCP, WordPress, More Events, Installation & Activation Center

What shipped

Installation & Activation Center

MCP for governed analytics access

A first-party WordPress plugin

Automatic events from the tracker

A system status page for real operators

A clearer timeout warning

Read more