HitKeep Blog

How to Build Better Google Reporting for Stakeholders

Fri, 24 Jul 2026 00:00:00 GMT

Stakeholders rarely need more Google data. They need clearer decisions.

Most teams end up with a dashboard set that is technically rich but hard to act on: one view for SEO, one for marketing, one for executives, and a lot of unannotated changes. Better reporting starts by building one clear decision system, not a bigger set of charts.

Start with the audience, not the dashboard

Each stakeholder asks a different decision question. A single combined view rarely works for everyone.

Stakeholder	Primary question	Best reporting angle	Metric focus
Executive team	Are we moving in the right direction?	Outcomes and risk	Conversions, conversion quality, qualified traffic mix
Marketing leadership	Which channels need more or less focus?	Channel outcomes and quality	Sources, assisted conversions, landing-page performance
SEO team	Is search demand improving in meaningful ways?	Discovery and relevance	Queries, clicks, CTR, indexed pages
Content team	Which pages are helping and which are stalling?	Content-to-outcome paths	Entrances, engagement, conversion steps
Agency or consultant	What changed from this period?	Before/after decision evidence	Baselines, annotations, uplift, recommendations

This mapping should drive every report section. If a chart does not help someone make a decision, move it to an appendix.

Build a reporting narrative before selecting charts

A stakeholder report should follow a consistent order: status, causes, risks, actions.

For example, do not start with traffic and hope the reader infers impact. Start with a simple interpretation:

Traffic mix improved, but growth is driven by informational demand,
conversion contribution stayed flat,
next actions should focus on pages and channels that move qualified outcomes.

Use the same flow every cycle:

What changed in outcomes?
Which source explained the change?
Which decision should happen next?

Use Search Console as discovery context, not a complete story

Search Console is often treated as an SEO utility. It is better used as a demand context layer.

Use it to track:

search demand and click-through changes,
query intent shifts,
and landing-page intent gaps between discovery and conversion.

But do not treat it as the whole report. It does not answer what happens after a click. Pair it with on-site analytics and outcome metrics so your team can connect demand to business results.

Suggested Search Console reporting structure

Demand layer: impressions, clicks, CTR, and query intent.
Bridge layer: landing pages, engagement, campaign context.
Outcome layer: conversions, funnel completion, and business value.

That structure shows whether search visibility is producing outcomes or only activity.

Keep definitions stable across GA and analytics signals

If every team uses a different definition of “users,” “sessions,” or “conversion,” trust decays quickly.

Metric	Recommended definition
Visits or sessions	A bounded interaction path in your chosen measurement model
Engaged sessions	A session meeting the engagement criteria in your platform
Conversion	A named outcome approved by the reporting owner
Channel mix	Source attribution policy, documented per channel

Document definitions in the report before publishing results.

Separate traffic signals that mean different things

In 2026 reporting, one number is no longer enough. Use three streams and keep them separate:

Rendered visits: normal browser sessions that executed your tracker.
AI-referred traffic: visits introduced by AI or assistant referrers.
AI crawler fetches: requests that may not represent human sessions.

A cleaner report does not combine these into one “AI traffic” total. Keep them distinct and explain what each stream can and cannot prove.

HitKeep keeps AI-referred visits and crawler fetches visible as separate signals, so stakeholders do not mistake crawler activity for audience growth.

Use recommendation tables, not only raw tables

A useful report should end with action.

Section	Include	Decision it should support
Executive summary	3 wins, 3 risks, 3 actions	Continue, adjust, escalate
Goal progress	Actual vs target by owner	Are we on pace?
Search visibility	Query mix and click health	Is demand moving correctly?
Traffic quality	Source mix and engagement trend	Are we attracting the right audience?
Conversions	Goals, funnel health, assisted channels	Where should the team improve next?
AI and emerging sources	AI referrals and crawler activity	Is discovery quality changing?
Recommendations	Ranked actions with owners	What should happen this cycle?

The key is restraint. If someone needs deeper detail, provide appendices.

Build a repeatable reporting rhythm

Most teams benefit from two cadences:

Weekly short updates for execution and operations,
Monthly stakeholder summaries for interpretation and decisions.

A simple process is enough:

Review anomalies and tracking changes first.
Confirm definitions and attribution assumptions.
Add the recommendation block and owners.
Publish a short decision summary at the end.

Keep attribution honest

Attribution is useful when its limitations are explicit.

Use first-touch for acquisition understanding, last-touch for closing behavior, and outcome-based context for final recommendations. Do not pretend one metric is “the” truth.

Keep an annotation log

Without annotations, every spike becomes noise and every dip becomes a mystery.

Track campaign changes, tracking config changes, product releases, search updates, consent updates, and major site changes. That log is often the difference between a useful report and a long argument.

Build from one reporting workflow

Teams that switch between GA and privacy-first analytics can still use this framework. The practical requirement is consistency:

one metric dictionary,
one reporting cycle,
explicit source mapping,
and explicit caveats for AI-mediated and crawler-related behavior.

Need a platform that supports clear reporting with Search Console imports, conversion reporting, AI visibility separation, and open exports? Use HitKeep.

HitKeep 2.13.0: Reports, Social Sign-In, and a Typed Tracker SDK

Thu, 23 Jul 2026 00:00:00 GMT

If your team sends analytics to clients or stakeholders, HitKeep 2.13.0 replaces a handful of email-frequency switches with reports you can name, scope, schedule, preview, and audit. Each report has an owner, preset, sites, recipients, local delivery time, next run, and delivery history. External recipients can confirm delivery without receiving dashboard access.

The same release adds Google, GitHub, and Microsoft sign-in, publishes the typed @hitkeep/tracker package for framework applications, and prevents speculative prerenders from sending analytics before activation. Traffic exclusions now span instance, team, and site scopes, while default-tenant analytics move out of the shared control database and into an isolated tenant file.

DuckDB operation also gains serialized checkpoints and narrow, evidence-preserving recovery paths. Country, city, provider, and ASN lookups move to block-addressable embedded assets so the runtime can decode bounded portions on demand. The dashboard moves to the MIT-licensed OptimusUI component stack so HitKeep’s UI foundation remains inspectable, modifiable, and redistributable as open source.

The dashboard also brings AI crawler, AI-referred, and assistant activity into one AI Agents view. The release improves the edges around that experience too: route-critical startup failures now have a reloadable recovery page, and the login screen explains whether access ended because you signed out or because the session expired.

The canonical dashboard view combines AI requests, referrals, crawl depth, pageviews, and assistant activity in one report.

What ships in HitKeep 2.13.0

Configurable scheduled reports: create personal or team reports with a named preset, selected or accessible sites, an IANA timezone, a local delivery time, and daily, weekly, or monthly cadence.
Stakeholder delivery without dashboard access: team owners and admins can add confirmed external recipients. Consent is report-specific, expires, can be withdrawn, and does not create an account or grant site access.
Durable delivery operations: preview content, send a test to yourself, inspect runs and recipient deliveries, retry failures, and distinguish SMTP acceptance from inbox delivery.
Google, GitHub, and Microsoft sign-in: enable only completely configured providers, use them for login or signup, link them to an existing account, and preserve invitations and MFA handoff.
Typed browser SDK: install @hitkeep/tracker from npm to initialize tracking, send custom and ecommerce events, manage component cleanup, and configure browser behavior without injecting a script tag.
Prerender-safe collection: defer pageviews, custom events, attribution, and Web Vitals until a speculative page activates, then use the activated URL and discard work for prerenders that never become visible.
Layered traffic controls: apply CIDR, country, user-agent, or path exclusions at instance, team, or site scope, with inherited rules visible through effective API reads.
Safer DuckDB lifecycle: serialize periodic, migration, backup, and shutdown checkpoints; retain recovery bundles before narrow repairs; and keep application WAL bypass behind explicit operator approval.
Separate default-tenant data plane: migrate default analytics into its own tenant file, keep the control database metadata-only, and run all tenant catalogs through one attached DuckDB data-plane instance.
Lower-overhead IP metadata: decode validated country, city, provider, and ASN blocks on demand under bounded caches instead of inflating every embedded lookup table at startup.
Open-source dashboard foundation: replace PrimeNG and PrimeIcons with OptimusUI, OptimusUI Themes, and OpenNG Icons under the MIT license.
AI Agents dashboard: combine AI requests, AI-referred visits, crawl depth, and pageview context with assistant activity and filterable evidence panels.
Conversion cohorts: selecting a goal or funnel now filters dashboard KPIs, charts, dimensions, raw traffic, and exports; event-based goals can therefore measure a chosen custom event consistently across reports.
Recoverable application states: setup, dashboard bootstrap, and other route-critical failures show a safe error page with reload guidance, while ordinary component API errors remain local to their feature.
Accessible session-end feedback: intentional sign-out and ended sessions return to login with distinct, announced status messages and safe return-URL handling.
Security and dependency maintenance: move Spamhaus refreshes to its JSON feeds, refresh the embedded denylist data, update Go and dashboard dependencies, fix high-severity frontend audit findings, and pin current GitHub Actions revisions.
One contributor workflow: route setup, development sessions, screenshots, builds, smoke tests, and canonical QA through the repository-owned hk platform and its developer MCP surface.
Release metadata that follows the artifact: publish a checksummed configuration catalog with stable releases, then synchronize the public configuration reference and current-version facts only after release binaries and the Helm chart succeed.

Important platform updates

HitKeep 2.13.0 also refreshes the foundations underneath the product features:

OptimusUI 1.0.0-rc.1: the dashboard moves to OptimusUI, OpenNG’s community fork of the final MIT-licensed PrimeNG codebase. HitKeep now consumes the MIT-licensed OptimusUI components, themes, and OpenNG icon packages, keeping the shipped UI code open to inspection, modification, and redistribution.
Angular 22.0.8: Angular framework and build packages move from 22.0.5 to 22.0.8, with Angular CDK moving to 22.0.6 and Angular ESLint to 22.1.0.
duckdb-go v2.10505.0: the embedded DuckDB driver moves from v2.10504.0 to v2.10505.0, with native bindings moving from v0.10504.0 to v0.10505.0. This sits alongside the serialized checkpoints and guarded recovery changes described below; HitKeep still embeds DuckDB in the single application binary.
Frontend runtime updates: Web Vitals moves to 6.0, Tailwind CSS to 4.3.3, Scalar API Reference to 1.63.0, and the dashboard’s Node 24.18.0 and npm 12.0.1 requirements are pinned for reproducible installs.
Backend maintenance: compression, Stripe, mail, AI, cryptography, Google API, AWS SDK, gRPC, and related Go modules receive bounded dependency updates without adding a required external service.

These are implementation upgrades rather than new deployment dependencies. Self-hosted HitKeep remains one Go binary with the Angular dashboard, DuckDB, and NSQ embedded.

A typed tracker for framework applications

@hitkeep/tracker packages the same tracker core as hk.js as a typed JavaScript module. It works with React, Next.js, Vue, Nuxt, Angular, Astro, and other bundler-based applications, with ESM and CommonJS entry points, included TypeScript declarations, and no runtime dependencies.

Install the package and initialize it with the public URL or custom tracking domain that should receive browser ingest:

npm install @hitkeep/tracker

import { init, track } from '@hitkeep/tracker';

init({ host: 'https://analytics.example.com' });

track('signup_clicked', { plan: 'pro' });

Initialization captures the first pageview and history-based SPA navigation by default. The same configuration can enable Web Vitals, disable individual automatic events, respect Do Not Track, or turn off automatic pageviews when an application wants to call trackPageview() itself. Events called before init() are kept in a bounded queue for the first initialization.

Framework integrations can clean up listeners when their owning component unmounts. For React and the Next.js App Router, keep initialization in a client component:

'use client';

import { useEffect } from 'react';
import { cleanup, init } from '@hitkeep/tracker';

export function Analytics() {
  useEffect(() => {
    init({ host: 'https://analytics.example.com' });
    return cleanup;
  }, []);

  return null;
}

Typed ecommerce helpers keep the event name and required purchase fields explicit:

import { trackPurchase } from '@hitkeep/tracker';

trackPurchase({
  transaction_id: 'order-1042',
  value: 49.9,
  currency: 'EUR',
  items: [
    { item_id: 'starter', item_name: 'Starter plan', quantity: 1, price: 49.9 },
  ],
});

The package also exports visitor opt-out controls and typed helpers for view_item, add_to_cart, and begin_checkout. It is versioned with HitKeep, so keep its major version aligned with the receiving instance. Site Settings now offers script-tag and npm installation methods with copyable examples.

The package does not create a separate privacy model. It remains cookie-free by default, follows the same session storage, retry, Do Not Track, and payload behavior as hk.js, and still requires a deployment-specific consent and ePrivacy assessment. See the @hitkeep/tracker package and Tracker Architecture for the current boundary.

Speculative pages wait for activation

Browsers can prerender a likely next page before the visitor actually opens it. HitKeep now recognizes both the current prerendering API and the legacy prerender visibility state. While a page is speculative, the tracker sends no pageview, custom event, or Web Vitals request.

If the page activates, HitKeep sends the pageview first, reads campaign and QR attribution from the activated URL, and rebinds buffered events and Web Vitals to the activated path and page ID. The activation buffer is bounded, and cleanup discards it when a prerender never becomes visible. Because hk.js and @hitkeep/tracker share the same core, the fix applies to both installation methods.

Reports become first-class definitions

The Reporting hub replaces separate digest and per-site switches with saved report definitions. Each row answers the questions an operator needs before trusting scheduled delivery: who owns the report, what it covers, who receives it, when it runs next, and how the last run ended.

Desktop reporting keeps scope, recipients, schedule, next run, recent outcome, and row actions in one searchable, sortable table.

Three presets cover different jobs:

Preset	Cadence	Main content
Site Summary	Daily, weekly, or monthly	Visitors, pageviews, bounce rate, session duration, goals, comparison, trend, top pages, and referrers for one site
Portfolio Digest	Daily, weekly, or monthly	Pageviews, visitors, goals, deltas, and site links across selected sites or every site accessible to a personal report owner
Opportunity Brief	Daily or weekly	Saved, validated Opportunity Recommendations and their cited evidence

Opportunity Brief does not start a model run. It reads already saved recommendations and suppresses an empty report when none passes the deterministic quality rules.

Schedules use the report’s timezone rather than a server-local assumption. New reports default to 08:00 in the browser-detected timezone, allow 15-minute delivery increments, and recalculate the UTC run after schedule changes and daylight-saving transitions. Weekly reports choose a weekday. Monthly reports choose a day from 1 through 28.

Personal reports belong to one user and send only to that user. Team reports use explicitly selected sites and can include members plus up to 25 external addresses. On HitKeep Cloud, external recipients are available with Pro and Business; self-hosted HitKeep does not apply that plan gate.

An external address receives a seven-day, single-use confirmation that names the team, cadence, and selected domains. HitKeep stores a SHA-256 hash of the confirmation token, not the token itself. Changing the preset, sites, or frequency requires renewed consent. Renaming a report or changing only its delivery time does not. External mail contains the report content but omits dashboard and site links.

The delivery worker records report runs and per-recipient outcomes before mail is attempted. SMTP failures retry after 5 minutes, 30 minutes, and 2 hours with the same Message-ID. A restart catches up at most one missed occurrence inside bounded daily, weekly, or monthly windows. Delivery records retain status, attempt count, timestamps, and safe error codes, but not rendered email bodies, remote tracking images, click tracking, or a snapshot of an external email address.

Migrate report API clients before upgrading

The database migration converts existing enabled report settings into report definitions at 08:00 UTC so their previous delivery time remains unchanged. Disabled settings remain disabled and are not materialized. After that migration, the old handlers and old subscription storage are gone; requests to the removed routes return 404.

Use this mapping when updating a session-authenticated client:

HitKeep 2.12 operation	HitKeep 2.13 replacement
`GET /api/user/report-subscriptions`	`GET /api/reports`
`PUT /api/user/report-subscriptions/digest`	`POST /api/reports` to create, then `PATCH /api/reports/{report_id}` to update a personal Portfolio Digest
`PUT /api/user/report-subscriptions/sites/{site_id}`	`POST /api/reports` to create, then `PATCH /api/reports/{report_id}` to update a personal Site Summary
`DigestSubscription`	`ReportSchedule` inside `ReportDefinitionInput` or `ReportDefinitionUpdate`
`SiteReportSubscription` and `ReportSubscriptions`	`ReportDefinition`, `ReportRecipient`, `ReportRun`, and `ReportDelivery`

The replacement surface also adds operations for preview, test send, run history, failed-run retry, external-recipient confirmation, unsubscribe, and resubscribe. Generated clients should refresh from the 2.13 OpenAPI document because the removed schemas will no longer be present.

Other API changes in this release are additive. Social-authentication paths, team traffic-exclusion paths, database-status operations, and the report-definition paths are new. Existing instance and site exclusion creation payloads remain valid, including the legacy CIDR form that omits type. Exclusion responses retain their existing value fields and add scope, optional owner IDs, and inherited.

Self-hosted operators can configure OAuth client pairs for Google, GitHub, Microsoft, or any subset of the three. HitKeep lists only providers with a complete configuration. On managed Cloud, open social signup has its own switch, so a provider can remain available for existing accounts and invitations without allowing uninvited account creation. On self-hosted HitKeep, configuring HITKEEP_SOCIAL_SIGNUP_ENABLED does not create open public signup.

Each provider appears only after its client ID and client secret are both configured.

The browser flow uses short-lived, one-time state, PKCE S256, and an OIDC nonce where the provider supports OIDC. Return URLs stay inside the application. HitKeep resolves an account through the provider’s immutable identity, discards provider tokens after the exchange, and never treats an editable email address as the long-term identity key.

Google and GitHub verified-email flows can complete a normal signup without another email verification step. Microsoft identities do not provide the same verified-email guarantee, so the first unauthenticated Microsoft link or signup sends a HitKeep confirmation unless an authenticated session or matching invitation already proves the account boundary.

An authenticated user can link or unlink a social provider from security settings. Unlinking is refused when it would remove the last usable primary login method, and password-only fallback requires current-password confirmation. Team OIDC SSO and recovery factors do not count as primary alternatives for that guard.

The Social Sign-In guide provides the exact callback URLs, tabbed Google, GitHub, and Microsoft setup, Docker Compose variables, verified-email rules, invitations, MFA handoff, account linking, rollout checks, and troubleshooting.

Traffic controls follow ownership

Traffic exclusions now use the same ownership structure as the rest of HitKeep. Instance rules apply everywhere. Team rules follow every site currently owned by that team. Site rules stay attached to one site. Effective reads make inherited rules visible, but a team or site route cannot modify a rule owned by a parent scope.

Scope labels explain why a rule applies. The inherited instance rule is visible at team scope and remains read-only there.

Rules are additive and forward-only. HitKeep evaluates instance, current-team, and site rules, then drops a record when any rule matches. There are no allow overrides, and changing a rule does not rewrite historical analytics.

The two new match types cover traffic that network and country rules cannot express cleanly:

User agent: case-insensitive substring matching for monitors, known clients, or other identifiable traffic.
Path: case-sensitive segment-boundary matching after query strings, fragments, duplicate slashes, trailing slashes, and dot segments are normalized. /admin matches /admin/users, but not /administrator.

User-agent and path values are used transiently during filtering and do not add stored visitor fields. Filtering covers browser pageviews and events, Web Vitals, trusted server ingest, AI-fetch records, and dynamic QR opens. Matching ingest keeps its normal accepted response so the API does not reveal which filter matched.

Analytics leaves the shared control plane

Version 2.13.0 completes the database boundary for the original default tenant. The shared hitkeep.db keeps users, sessions, teams, memberships, sites, preferences, API clients, share links, and other ownership metadata. Analytics rows for every tenant, including the default tenant, live in tenant-local DuckDB files under {data-path}/tenants/{tenant-id}/hitkeep.db.

The control plane resolves who can access a site and which tenant owns it. Analytics reads and writes then use the resolved tenant data plane; they do not join analytics tables back into the control database. Tenant catalogs run through the attached DuckDB data-plane layer while the control database remains metadata-only.

On the first 2.13 startup, HitKeep creates the default tenant file, verifies the migrated analytics data, records durable split markers, and rewrites the shared file. Keep the complete data path available throughout the operation. Copying only hitkeep.db after the upgrade produces an incomplete backup because it omits every tenant’s analytics database. The built-in backup and S3 restore paths cover the control snapshot and the tenant files derived from it.

Most upgrades need only the normal process replacement. The extra restart is required only when guarded automatic recovery ran first: HitKeep exits rather than combining recovery and the mandatory split in one process. If a service manager or container policy does not restart it automatically, start the same 2.13 release again, watch the migration logs, and wait for /readyz before returning traffic. Once the split markers are committed, use the complete pre-upgrade backup for rollback instead of starting 2.12 against the new layout.

Recovery preserves evidence before repair

DuckDB is embedded, but it still has a write-ahead log, checkpoint behavior, indexes, and failure modes that need explicit operating rules. Version 2.13.0 serializes periodic checkpoints and requires checkpoints around migrations, before backups, and during clean shutdown. An instance operator can inspect the sanitized database state and request an immediate checkpoint from System Status or the new admin API.

Automatic repair remains intentionally narrow. For the recognized non-unique-index invalidation, HitKeep first creates a permission-restricted, checksummed recovery bundle, then removes only implicated non-unique secondary indexes. Primary-key and unique indexes stay intact. A repair that finds no eligible index fails closed instead of reporting a false success.

The known migration WAL failure has a separate guard. Startup migrations run before the store is published to workers, commit and checkpoint independently, and record a durable checksum for the closed base database while a migration WAL remains authoritative. HitKeep can complete migration-only WAL recovery automatically only when that checksum matches. Bypassing an application WAL remains disabled by default because committed changes may exist only in that WAL; HITKEEP_DB_AUTO_RECOVER_WAL=true is an explicit availability-versus-data-loss decision.

While a shared or open tenant database is recovering, /healthz continues to report process liveness, while /readyz and database-dependent API or ingest routes return 503 with a stable reason and Retry-After: 5. If recovery cannot preserve evidence, verify disk space, or drain open connections, HitKeep stops instead of serving partial data.

Recovery bundles are local incident artifacts, not backup rotation. They can contain the same sensitive data as the live database and are never deleted automatically. Keep backing up the complete data path, including tenant databases, and keep recovery-bundle retention in the operator runbook.

Smaller, bounded IP metadata work

HitKeep still derives country, region, city, provider, ASN, and ASN organization from embedded IP metadata without storing the raw visitor IP. The implementation now stores validated address directories and compressed blocks instead of inflating the full country, city, and network datasets at startup.

Lookup decodes only the block needed for an address, validates length, ordering, metadata references, and checksums, and keeps decoded data under separate bounded country, city, and ASN caches. The result keeps the same analytics dimensions while reducing embedded asset size and putting an upper bound on decoded range-block memory.

The bundled spam filter also moves from legacy Spamhaus feed handling to the provider’s JSON data, with schema validation and a refreshed default snapshot. Production filtering remains embedded and deterministic; a release does not need a runtime download token to start protecting ingest.

Contributor and release workflows become reproducible

For contributors, the new ./hk launcher is the source of truth for toolchain diagnosis, isolated workspace state, container-only development, screenshots, builds, smokes, and QA. A central developer MCP adapter exposes those operations to supported coding clients without giving them arbitrary shell execution or source-rewrite access.

Development is now one workspace session with status and event cursors. Finite setup, QA, build, and smoke operations use durable run IDs and bounded logs. That distinction lets a slow e2e or image gate continue even if one client disconnects, and lets contributors resume the exact run instead of starting a duplicate.

Release preparation receives the same treatment. Release Please owns the version manifest, changelog, dashboard package versions, MCP registry version, and Helm chart version. After a stable release is created, the release workflow builds and uploads binaries, checksums, the Helm chart, and hitkeep-configuration.json. Only after those artifacts succeed does it synchronize the docs repository’s machine-owned current-version and configuration files, validate the site, deploy that exact revision, and trigger the managed-cloud rollout.

Upgrade checklist

Back up the complete HitKeep data path and verify at least one recent restore before changing the running binary.
Update any client that calls the three removed report-subscription routes, then regenerate typed clients from the 2.13 OpenAPI schema.
Ensure the data path has enough free space for one source-database-sized tenant copy plus 512 MiB, and confirm the service manager or container policy can restart the same 2.13 release if recovery exits first.
Upgrade HitKeep and let migrations finish before accepting traffic. If HitKeep reports that automatic recovery completed and a restart is required, start the same 2.13 binary or container again and wait for /readyz; do not downgrade. Existing enabled report subscriptions become reports at 08:00 UTC.
Open Settings → Reporting, verify converted reports, choose a local timezone and time where needed, and send a test through the configured SMTP transport.
If you add external recipients, confirm the consent invitation in a separate browser and verify that the delivery omits dashboard links.
If you enable social sign-in, register the exact callback derived from HITKEEP_PUBLIC_URL, configure only the providers you intend to expose, and test login, invitation, MFA, linking, and last-login-method protection.
Review instance, team, and site traffic filters with effective=true or the dashboard scope labels, especially after site transfers.
Confirm HITKEEP_DB_RECOVERY_PATH has suitable free space, keep application WAL bypass disabled unless incident policy explicitly accepts its loss boundary, and monitor readiness during the first restart.

What does not change

HitKeep 2.13.0 keeps the same product boundary:

one Go binary with the Angular dashboard embedded;
DuckDB for storage and NSQ running in process;
no required PostgreSQL, Redis, Kafka, ClickHouse, or separate report worker;
cookie-free browser tracking by default;
no raw visitor IP stored in analytics;
open exports and complete account takeout; and
the same open-source product foundation for self-hosted and managed cloud.

Scheduled reports add durable outbound mail delivery. Social sign-in adds optional provider connections. Recovery and traffic controls harden operation. None of them add a required external database, queue, cache, or identity service.

Self-hosted HitKeep includes scheduled reports, social sign-in, the typed tracker SDK, isolated tenant analytics, layered traffic controls, and guarded recovery in the same binary. If you want managed email delivery, backups, upgrades, and regional hosting, start a managed HitKeep Cloud deployment.

Follow HitKeep on X, Bluesky, and LinkedIn.

How to Check Site Traffic Without Google Analytics

Thu, 23 Jul 2026 00:00:00 GMT

You can check site traffic without Google Analytics by combining a focused web analytics platform with the sources that answer narrower questions. Use analytics for visitors and on-site behavior, Search Console for Google Search visibility, server or CDN logs for raw requests, campaign tags for attribution, and backend records for confirmed conversions.

The important distinction is ownership. For a site you control, first-party analytics and infrastructure data can provide reliable traffic and conversion trends. For somebody else’s website, no public tool can reveal exact visitor numbers; competitor tools can only estimate them.

The short answer: choose the source that matches the question

“Website traffic” can mean several different things. Start with the decision you need to make, then use the source that can actually support it.

Question	Metric to check	Best source
How many people visited?	Visitors, sessions, pageviews	First-party web analytics
Where did they come from?	Referrers, channels, campaigns	Web analytics plus UTM tracking
Which content attracts Google Search demand?	Clicks, impressions, queries, CTR, average position	Google Search Console
Which pages produce outcomes?	Goals, events, funnels, confirmed conversions	Web analytics plus backend records
Which bots and AI crawlers requested the site?	User agents, paths, status codes, fetch volume	Server, CDN, or edge logs
Did an offline campaign create visits?	QR scans, tagged visits, conversions	Tagged URLs, QR campaigns, and goals
How much traffic does a competitor receive?	Estimated visits and search traffic	Third-party estimates, never exact first-party data

No single source is perfect. Browser analytics can miss blocked or unconsented requests. Logs include bots and asset requests that are not human visits. Search Console covers Google Search rather than total traffic. A CRM or payment system confirms an outcome but may not preserve the acquisition journey.

A useful Google Analytics replacement does not try to force every question into one number. It combines a small set of sources with documented definitions.

First, decide whether you own the website

If you own or operate the website, you can measure it directly. You can install a first-party analytics script, inspect your server or CDN logs, connect Search Console, tag campaigns, and compare recorded goals with your own business systems.

If you do not control the website, you cannot see its exact visitors, sessions, revenue, or conversions unless the owner shares that data. SEO and competitive-intelligence tools can estimate traffic using rankings, clickstream samples, panels, and models. Those estimates can help compare direction or relative scale, but they are not a substitute for first-party analytics.

This guide focuses on accurate measurement for a site you control. The competitor question is covered separately in the FAQ because it requires a different evidence standard.

Use privacy-first web analytics for core visitor data

The closest functional replacement for GA4 is a web analytics platform that records pageviews, visitors, referrers, campaigns, events, and conversions. Modern privacy-first products narrow the collection surface and often avoid analytics cookies or persistent cross-site identifiers by default.

This layer should answer the questions a team checks every day:

How many visitors came today, this week, or this month?
Which pages attracted and retained attention?
Which referrers and campaigns performed best?
Which devices, countries, or browsers changed?
Which calls to action, forms, signups, or purchases converted?

HitKeep provides these reports with cookie-less event tracking by default. It also supports goals, funnels, Search Console imports, open-format data takeout, managed EU or US cloud hosting, and a single-binary self-hosted installation.

Cookie-free does not automatically mean consent-free or compliant. Storage, identifiers, event fields, purposes, retention, deployment, and jurisdiction all matter. Treat the smaller data boundary as an implementation property, not a legal conclusion.

When evaluating an analytics tool, verify how it defines visitors and sessions, how it filters bots, whether referrers and campaigns remain exportable, how goals are confirmed, and whether its hosting model matches your ownership requirements.

Use Google Search Console for organic search traffic

If the question is “How much traffic do we receive from Google Search?”, Search Console is essential. Its Performance report provides clicks, impressions, click-through rate, average position, queries, pages, countries, devices, and dates.

That information begins before a visitor reaches the site. An impression can show search demand even when nobody clicks, and query data can reveal a page that ranks but needs a clearer title or more relevant answer.

Search Console is useful for:

finding pages with impressions but weak click-through rates;
comparing branded and non-branded discovery;
spotting traffic changes after content or technical updates;
finding queries that deserve a stronger section or a new article; and
measuring Google Search without adding another browser script.

Its limits are equally important. Search Console does not report direct, referral, email, paid, social, or non-Google traffic, and it does not reconstruct the visitor’s full journey after the click. Google also documents why Search Console totals can differ from analytics totals.

Connect the HitKeep Search Console integration when you want search visibility beside landing-page, audience, and conversion reporting.

Search Console adds query, impression, and click context to on-site visitor and conversion reporting.

Read server and CDN logs for raw request evidence

Server, reverse-proxy, edge, and CDN logs show requests made to your infrastructure. They can include human page loads, search crawlers, AI crawlers, uptime monitors, API clients, download requests, and abusive automation.

Logs are especially useful when browser analytics cannot observe the request:

verifying that search engines reach important pages;
separating crawler activity from rendered visits;
finding repeated 404s, redirect loops, or failed requests;
measuring downloads, feeds, or endpoints that do not run browser JavaScript; and
investigating whether a spike came from people or automation.

Raw requests are not the same as visitors. One page load can request HTML, scripts, styles, images, and fonts. Bots can create large volumes, shared networks make IP-based visitor counts unreliable, and privacy protections can change network identifiers. Use logs for infrastructure and crawler truth, then aggregate and classify them before using them in a marketing report.

Track campaigns with UTMs and QR codes

Campaign attribution does not depend on Google Analytics. Add consistent UTM parameters to the destination URL and let your analytics tool record the campaign, source, medium, content, and term.

A newsletter link might use utm_source=newsletter, utm_medium=email, and utm_campaign=summer_launch. The naming convention matters more than the vendor. linkedin, LinkedIn, and li will usually become separate values, so document allowed names before campaigns launch.

Use the same practice for offline campaigns. Point every QR code on event signage, packaging, direct mail, or sales material to its own tagged URL. That makes the offline placement measurable through visits and downstream goals.

HitKeep’s UTM reporting guide covers the parameters and reporting flow, while QR campaigns keep distinct printed placements measurable.

Consistent campaign tags turn email, paid, partner, and QR visits into comparable acquisition reports.

Measure conversions at the source

Traffic becomes useful when it supports an outcome. A SaaS team may care about verified signups or demo requests. A publisher may care about accepted subscriptions. An ecommerce site may care about confirmed orders, revenue, or repeat purchases.

Analytics goals and funnels explain the journey, but the source of truth for the final result is usually the system that accepted it: your backend, CRM, payment processor, form service, or email platform.

For example, analytics may show 120 form-submission events while the CRM contains 112 valid leads. The difference could come from spam, duplicate clicks, rejected submissions, blocked requests, or a tracking mistake. Reconciliation exposes the gap instead of hiding it.

A reliable conversion model has three layers:

Browser events describe low-risk interactions and navigation.
Backend records confirm important outcomes.
Referrer and campaign context explains acquisition.

Use HitKeep goals for named outcomes and funnels for the steps that lead to them, then compare the totals with the system that owns the business record.

Goals connect traffic to outcomes; reconcile them with backend or CRM records for confirmed conversions.

Separate AI crawler fetches from AI-referred visits

Traditional analytics assumes that a person follows a link, renders a page, and triggers a browser tracker. AI discovery breaks that into several observable events.

An AI crawler may fetch a page remotely without running JavaScript. An assistant may later send a person through a recognizable referral. An AI-capable browser may render the page like a normal visit. An answer may also be produced without a new request to your site.

These signals should not share one traffic bucket:

Crawler fetches show that an identified automated client requested a path.
AI-referred visits show that a person arrived from a recognizable assistant or campaign.
Rendered visits show that the page and tracker ran, but not necessarily whether an assistant helped.
Conversions show that a meaningful outcome occurred.

HitKeep’s AI Visibility analytics keeps crawler fetches and AI-referred human visits separate. The guide to AI browsers and web analytics in 2026 explains what browser trackers, logs, referrals, and backend events can each observe.

AI crawler fetches and AI-referred human visits stay separate because they answer different acquisition questions.

Build a simple traffic measurement stack

Most teams do not need ten tools. They need a few sources with clear definitions and an owner for each number.

Need	Recommended approach	Why it works
Daily visitor reporting	Privacy-first web analytics	Clear page, referrer, campaign, and visitor trends
Google organic visibility	Search Console data	Queries, impressions, clicks, CTR, and rankings
Conversion reporting	Goals plus backend records	Connects acquisition to confirmed outcomes
Crawler and bot analysis	Server or edge logs	Captures requests that do not execute browser tracking
Campaign attribution	UTMs and QR tracking	Keeps online and offline placements comparable
Data ownership	Self-hosting or open exports	Supports portability and independent verification

The Google Analytics vs privacy-first analytics comparison covers the broader choice between GA4, a privacy-first platform, and a hybrid stack.

Step by step: check your site traffic without GA4

Install a focused analytics tool. Confirm that pageviews, visitors, landing pages, and referrers appear with the definitions you expect.
Define important outcomes. Create goals for accepted forms, signups, purchases, downloads, or other useful events.
Connect Search Console. Compare Google Search clicks and queries with landing-page engagement and conversions.
Standardize campaign URLs. Define allowed UTM values for email, paid, social, partner, and QR campaigns.
Review server or CDN logs. Look for crawlers, failed paths, redirects, downloads, and unusual request spikes.
Reconcile confirmed conversions. Compare analytics goals with CRM, ecommerce, subscription, or form records.
Create a weekly reporting rhythm. Review visitors, acquisition, top content, search trends, conversions, and anomalies using the same definitions each week.

Do not begin by rebuilding every GA4 report. Start with the recurring decisions your team actually makes, then add a report only when it changes one of those decisions.

Keep your traffic numbers trustworthy

Document how each platform defines visitors, sessions, pageviews, events, and conversions. If the tracker is cookie-free, record how session continuity works. If you self-host, document retention, backups, access controls, updates, and exports.

Separate humans from automation wherever the evidence supports it, but preserve an unknown category instead of forcing certainty. A request is not automatically a visit, and a visit is not automatically a qualified lead.

Finally, use trends for marketing decisions and confirmed systems for billing or finance. Analytics is strongest when it reveals direction: organic traffic fell, email conversions improved, a pricing page gained engagement, or AI referrals increased. Consistent definitions make those changes more useful than false precision.

When should you still use Google Analytics?

GA4 can remain useful when Google Ads optimization, remarketing audiences, Firebase app analytics, BigQuery exports, or existing analyst workflows are central to the organization.

The choice does not have to be permanent or ideological. Many teams run GA4 and a privacy-first platform in parallel while validating coverage, or retain GA4 for advertising workflows while using another system as the primary website-performance dashboard.

The HitKeep vs Google Analytics comparison documents where each product is stronger and outlines a parallel migration path. Keep GA4 where it provides a capability you use; remove it only after the replacement measurement model has been tested against real decisions and confirmed outcomes.

Measure traffic on your own terms

Checking site traffic without Google Analytics is not about finding one magic replacement number. It is about matching each question to reliable evidence: first-party analytics for visits, Search Console for search visibility, logs for requests, tags for campaigns, and backend records for outcomes.

HitKeep brings those website analytics, goals, funnels, Search Console reports, campaign data, AI visibility, and open exports into one product. You can use managed cloud with an EU or US region choice or self-host the same open-source application when direct infrastructure control matters.

Google Analytics vs Privacy-First Analytics in 2026

Wed, 22 Jul 2026 00:00:00 GMT

In 2026, the choice between Google Analytics and privacy-first analytics is no longer just a tooling preference. It determines how consent affects your reporting, where analytics data is processed, how easily you can move it, and whether your measurement stack can distinguish traditional traffic from AI referrals and crawler fetches.

Google Analytics 4 remains powerful, widely understood, and tightly connected to Google Ads. Privacy-first tools have also moved beyond simple pageview counters. Serious products now support goals, funnels, ecommerce events, Search Console data, open exports, AI visibility, and a choice between managed hosting and self-hosting.

The answer does not have to be ideological. For many teams, the practical setup is to use privacy-first analytics as the source of truth for website performance and keep GA4 only where its advertising or advanced analysis workflows add unique value.

If your immediate task is measurement rather than product selection, use the practical guide to checking site traffic without Google Analytics to map visitors, search visibility, server requests, campaigns, and conversions to the right source.

Reviewed July 22, 2026

This article was checked against current Google Analytics, Google Ads, and CNIL guidance. Product behavior and privacy rules change, so re-check the primary sources and obtain advice for your own deployment before making legal or measurement decisions.

The short answer: which approach fits your team?

Choose Google Analytics when Google Ads optimization, remarketing audiences, app analytics, BigQuery workflows, and analyst-grade explorations are central to the job. Choose a privacy-first platform when cookie minimization, a smaller data boundary, operator control, and straightforward website reporting matter more.

Decision factor	Google Analytics 4	Privacy-first analytics
Best fit	Ad-heavy teams, app and web analytics, Google Ads optimization, and established analyst workflows	Privacy-conscious teams, publishers, SaaS companies, agencies, public-sector organizations, and teams focused on first-party website outcomes
Default web tracking	GA4’s JavaScript tag uses first-party cookies to distinguish users and sessions; Consent Mode can alter tag and storage behavior	Varies by product; often designed to avoid analytics cookies or persistent identifiers by default
Data control	Reports live in Google’s product, with raw-event export available through BigQuery	May offer self-hosting, regional hosting, open exports, and direct control over retention and infrastructure
Compliance work	Requires purpose, consent, configuration, data-sharing, and transfer review	Can reduce the data boundary, but still requires review of the complete implementation and jurisdiction
AI traffic	AI referrals can appear through normal acquisition data; crawler fetches require server-side evidence	Some products separate AI referrals, crawler fetches, and completed outcomes as dedicated reports
Ecosystem	Strongest with Google Ads, BigQuery, Looker Studio, Firebase, and Google integrations	Strongest when transparency, portability, and independence are priorities

For a product-by-product feature matrix, use the HitKeep vs Google Analytics comparison. This article stays at the strategy level: what each analytics model is good at, where the evidence differs, and how to choose a source of truth.

What changed by 2026?

Four changes have moved analytics architecture beyond the marketing team.

First, privacy and ePrivacy review now affects tracking design in Europe and many other jurisdictions. The useful question is not whether a vendor uses the word “privacy.” It is what the tracker stores, where the data goes, how it is combined, how long it is retained, and which controls the operator can enforce.

Second, consent choices affect measurement. In basic Consent Mode, Google tags remain blocked until consent and send no data when consent is denied. In advanced Consent Mode, tags can send cookieless pings while storage is denied, and Google may use those signals for modeling when its thresholds are met. Those modes produce different evidence, and modeled outcomes are not interchangeable with directly observed events.

Third, AI has changed discovery. A rendered visit, an AI-referred click, a remote crawler fetch, and a completed signup answer four different questions. A dashboard that combines them into one “AI traffic” number hides the collection boundary.

Finally, more organizations want to know whether analytics can move with them. Data location, export formats, deletion, retention, and self-hosting now appear in procurement and platform reviews, not just analytics implementation tickets.

Where Google Analytics is still strong

GA4 is especially strong when revenue operations depend on Google Ads. Linking a GA4 property to Google Ads supports audience sharing, site statistics in Ads, and advertising reporting inside Analytics. For teams optimizing substantial paid budgets, that integration can justify keeping GA4 even when another platform becomes the primary website dashboard.

Google also has a broad talent and tooling ecosystem. Agencies and analysts understand GA4 concepts, and the surrounding stack includes BigQuery, Looker Studio, Firebase, tag management, and third-party connectors.

GA4’s event model is flexible. Page loads, clicks, scrolls, purchases, and custom interactions can be represented as events with parameters. BigQuery Export adds a raw-event analysis path for teams that need SQL access, and Google states that customers own the data exported into their BigQuery project.

Those strengths come with operational and governance choices. The standard web tag uses the _ga and _ga_<container-id> first-party cookies by default. Consent Mode is a separate integration with a consent banner or platform; it does not provide consent by itself. GA4 also remains a proprietary service rather than infrastructure an operator can run or inspect end to end.

What privacy-first analytics means in 2026

Privacy-first analytics is a category, not one architecture. The useful definition is a measurement system that deliberately minimizes collection and keeps the data boundary proportionate to the business questions being asked.

A privacy-first platform commonly emphasizes some combination of:

cookie-free or minimized tracking by default;
fewer persistent identifiers and less cross-site or cross-product combination;
explicit retention, export, and deletion controls;
regional managed hosting or self-hosting;
transparent collection behavior; and
separate evidence for human visits, bots, AI crawlers, and conversions.

The goal is not to collect nothing. Teams still need to know which campaigns work, which pages generate qualified demand, where funnels lose users, and whether search visibility produces business outcomes. The difference is starting with the minimum evidence needed for those decisions instead of building the largest possible visitor profile.

France’s CNIL describes circumstances in which certain audience-measurement trackers can be exempt from consent, but only under strict conditions such as publisher-only measurement, anonymous statistics, no cross-site tracking, and no combination with other processing. That guidance is France-specific and does not make every cookie-free or privacy-first implementation exempt elsewhere.

HitKeep keeps traffic, engagement, and period comparisons in one first-party website dashboard.

Google Analytics vs privacy-first analytics: the real comparison

A useful comparison starts with the recurring decisions your team needs to make:

Which channels produce qualified visits and conversions?
Which pages support acquisition or activation?
Are technical SEO changes improving clicks and outcomes?
Did a change in consent or tagging alter the report?
Are AI assistants sending visits or only fetching content?
Can we export the evidence and recompute the result ourselves?

Area	Google Analytics	Privacy-first analytics
Traffic measurement	Broad and configurable, with results affected by tag behavior, consent implementation, browser limits, blockers, and reporting configuration	Often narrower and easier to audit, but still affected by blockers, network failures, filtering, and the product’s own session model
Conversion tracking	Strong for Google Ads, app events, cross-channel attribution, and audience workflows	Strong when goals and funnels map directly to first-party business outcomes
User identification	Supports advanced identity, audience, and attribution workflows when configured and permitted	Usually avoids or limits persistent personal identifiers
Compliance posture	Requires careful review of collection, consent signals, Ads linkage, sharing, retention, and transfers	Can reduce exposure through minimization and operator control, but is not automatically compliant
Data portability	BigQuery can export raw GA4 events into a customer-controlled project, subject to setup and limits	Often prioritizes downloadable open formats, APIs, and complete operator-controlled takeout
Operational complexity	Can involve tags, Consent Mode, events, custom definitions, audiences, modeled outcomes, and linked products	Often aims for fewer moving parts, though self-hosting adds backup, security, and upgrade responsibilities
AI-era reporting	Records rendered visits and recognizable referrals; non-rendered crawler fetches need edge or origin evidence	Some platforms make AI referrals and crawler fetches first-class but must still keep them separate

The distinction is one of optimization. GA4 is deeply optimized for Google’s advertising, app, and analysis ecosystem. Privacy-first analytics is usually optimized for first-party website measurement, a smaller collection boundary, and operator control.

Compliance: neither label decides the outcome

“Google Analytics is illegal” and “privacy-first analytics is compliant” are both poor decision rules.

GA4 can be deployed with consent management, storage controls, retention settings, and restricted Ads use. Whether that deployment is lawful depends on its purpose, configuration, contracts, transfers, notices, and jurisdiction.

A privacy-first platform can also be deployed badly. Combining analytics with identifiable CRM data, retaining detailed logs indefinitely, or adding fingerprinting defeats the point of minimized tracking. Cookie-free does not mean regulation-free, and browser storage such as sessionStorage may still require ePrivacy or PECR analysis.

Ask concrete questions instead:

Question	Why it matters
What does the tracker read or write on the device?	Cookies, local storage, session storage, and fingerprinting can trigger different technical and legal review.
Which identifiers and event properties leave the browser?	This defines the actual data boundary rather than the marketing label.
Where is the data stored and processed?	Residency and transfers can affect procurement and legal obligations.
Can data be combined with advertising, CRM, or cross-site profiles?	Combination changes both utility and risk.
Can operators configure retention, export, and deletion?	These controls determine portability and lifecycle management.
Which metrics are observed and which are modeled?	Teams need to know what kind of evidence supports a decision.

HitKeep’s privacy-first analytics overview describes its collection boundary and the consent caveats without making a universal compliance claim.

Data ownership and control

“Ownership” is too vague unless it is broken into concrete controls.

GA4 reports live inside Google’s proprietary platform. BigQuery Export creates a copy of raw GA4 event data in a customer-controlled Google Cloud project, where Google says the customer owns the exported data and manages dataset permissions. That is a meaningful portability path, but it still depends on configuring another Google Cloud service and does not make GA4 self-hosted software.

Privacy-first products often compete on a different set of controls: direct file exports, APIs, configurable retention, region selection, or a self-hosted runtime. Open-source software also lets teams inspect how collection and storage work rather than relying only on vendor documentation.

HitKeep supports managed EU or US deployment and self-hosting from the same open-source foundation. The self-hosted product runs as one Go binary with DuckDB and NSQ embedded. Current runtime and collection details belong in Facts and Limits, while the available export surfaces and portability boundaries are documented in data takeout.

Self-hosting is not automatically the better choice. It transfers upgrades, backups, monitoring, access control, TLS, and incident response to your team. Use the self-hosted GA4 alternative guide when infrastructure control is the reason for evaluating a switch; use HitKeep Cloud pricing when the goal is to test the reporting model without owning those operations.

Reporting quality: compare definitions before totals

More sophistication does not guarantee a more useful number. Accuracy depends on the question and on whether both tools define the metric the same way.

GA4 can be the better source for Google Ads optimization, app and web identity, modeled key events, and warehouse analysis. A focused privacy-first dashboard can be easier to trust for pageviews, referrers, goals, and funnels when the team can inspect the collection rules and does not need advertising audiences.

Do not expect two tools to produce identical sessions or users. They can differ because of consent state, blockers, cookie or storage rules, session timeouts, bot filtering, geography enrichment, late events, and attribution models. Validate business outcomes—accepted leads, created accounts, confirmed purchases—before debating small traffic differences.

Search performance belongs beside website analytics but remains a distinct dataset. HitKeep’s Google Search Console integration imports finalized aggregate query, page, country, and device rows; it does not connect a query to an individual session.

Search Console aggregates add search demand and click evidence without pretending that a query identifies an individual visit.

AI traffic changes the comparison

AI search, assistants, and browsers create measurement paths that traditional session reports do not fully explain.

A rendered page can execute browser analytics.
A click from an assistant can arrive with a recognizable referrer.
A remote crawler fetch can appear in edge, CDN, proxy, or origin logs without executing JavaScript.
An answer generated without a new request to your site leaves no direct pageview.
A completed signup or purchase is best confirmed by the backend that accepted it.

GA4 can record rendered visits and some AI referrals when its tag runs and the referrer is available. Non-rendered crawler retrieval requires server-side evidence regardless of the browser analytics product.

HitKeep’s AI Visibility report keeps AI-referred visits and forwarded crawler fetches separate. Neither signal proves that an assistant cited a page or influenced a later direct visit. The AI browser tracking guide explains the boundary in more detail.

AI-referred visits and crawler fetches answer different questions and should remain separate reports.

When to keep Google Analytics

Keep GA4 when it directly supports revenue or analysis workflows that another platform does not replace:

Google Ads attribution and audience activation;
app and web analytics in one property;
BigQuery-first analysis;
Explorations, custom dimensions, and predictive workflows;
agency or stakeholder processes that depend on GA4 output; or
an implementation that has already passed your legal and security review.

Keeping GA4 does not require making it the source of truth for every audience. A hybrid model can reserve GA4 for advertising and advanced analysis while a privacy-first platform handles website performance, SEO, content, and executive reporting.

When to switch to privacy-first analytics

Make privacy-first analytics the primary platform when your organization wants to minimize identifiers, narrow third-party data sharing, choose a hosting region, self-host, or simplify reports around first-party outcomes.

The approach is often a good fit for B2B SaaS companies, publishers, agencies, open-source projects, nonprofits, public-sector organizations, and teams whose website analytics questions do not require advertising-grade user profiles.

Privacy should not mean giving up business measurement. Look for goals, funnels, campaign and UTM reporting, ecommerce events, Search Console data, exports, APIs, retention controls, and a documented distinction between human visits and bot or AI activity.

A practical migration path

Run both systems in parallel before changing the reporting contract.

Audit the current GA4 property. Identify the events, key events, audiences, reports, BigQuery jobs, and Ads links that people actually use.
Separate advertising from business reporting. Mark which workflows exist for Google Ads and which answer broader acquisition, content, conversion, and executive questions.
Map the privacy requirements. Review collection, consent, storage, residency, retention, vendor access, and export needs with the responsible stakeholders.
Install privacy-first analytics beside GA4. Run both for at least one complete business cycle without treating raw session totals as a pass/fail test.
Align outcome definitions. Make sure “lead,” “signup,” “purchase,” and funnel steps mean the same thing, and prefer backend-confirmed events for critical outcomes.
Choose a source of truth per job. Keep GA4 where its Ads, app, or warehouse integrations are unique; use the privacy-first platform where it provides clearer and more controllable website reporting.

Parallel evaluation should compare agreed funnel entries and confirmed completions, not just session totals.

This process prevents the most common migration error: comparing two tools before agreeing on what the business actually needs to measure.

Final verdict

Google Analytics remains a strong choice in 2026 for teams invested in Google Ads, app analytics, BigQuery, and advanced attribution workflows. It is no longer the automatic answer for every website.

Privacy-first analytics is a serious alternative when the primary job is understanding first-party website traffic and outcomes with a smaller data boundary and more operator control. It can also sit beside GA4 rather than replacing it immediately.

Use Google Analytics where its ecosystem is uniquely valuable. Make privacy-first analytics the center of gravity when the reports need to be understandable, portable, and proportionate to the decisions your team is making.

AI Browser Tracking in 2026: What Web Analytics Can See

Thu, 16 Jul 2026 00:00:00 GMT

AI browser tracking is not one new analytics channel. Some AI browsers read a page already open in a person’s browser. Some navigate across tabs and click through a workflow. Others retrieve content remotely without rendering your JavaScript at all.

That distinction matters more than the browser brand. A normal pageview, an AI-referred visit, a server-side crawler fetch, and a completed signup answer four different questions. Combining them into one “AI traffic” number creates a neat chart and a poor measurement system.

This guide explains how AI browsers affect pageviews, attribution, events, bot filtering, and privacy-first analytics. It also gives you a practical measurement plan that works even while the products and their names keep changing.

What AI browser tracking can and cannot see

The short answer depends on how the page or outcome was reached:

AI-mediated activity	Observable evidence
A person opens a rendered page	Browser: usually visible when the tracker runs. Server: visible as a normal request. Backend: visible only if an outcome occurs.
A person clicks an AI assistant referral	Browser: usually visible, sometimes with a recognizable referrer. Server: visible as a normal request. Backend: visible only if an outcome occurs.
A remote agent or crawler fetches a page	Browser: usually invisible because JavaScript does not run. Server: often visible. Backend: usually absent.
An assistant answers without visiting	Browser: invisible. Server: invisible for that answer. Backend: absent.
A person or agent completes a signup or purchase	Browser: supporting events may be visible. Server: partially visible. Backend: the best source of truth.

No single row identifies an “AI browser session” with certainty. Reliable AI browser analytics keeps browser pageviews, AI referrals, server-side crawler records, and confirmed outcomes separate.

Use this guide to:

Separate four kinds of AI-mediated activity

Start by identifying how the content reached the model or the person. The collection path changes with it.

On-page assistance

What happened: A person opened your page, then asked the browser to summarize or explain it.
What analytics can observe: The rendered pageview and any normal browser events. The follow-up questions usually remain inside the browser or assistant.

What happened: An assistant opened pages, clicked controls, or filled fields in a visible browser session.
What analytics can observe: Pageviews and DOM-based events may run. Your site may not have a reliable signal that an agent performed the action.

Remote retrieval

What happened: A crawler or remote service fetched the page without running the browser tracker.
What analytics can observe: Edge, CDN, proxy, or origin logs. Client-side analytics usually sees nothing.

Answer without a visit

What happened: The assistant answered from an index, memory, or previously retrieved content and never opened your site.
What analytics can observe: No direct pageview. Search reporting, later referrals, and business outcomes provide indirect context, not proof of exposure.

These modes can occur within one user task. A browser might summarize an open page, fetch another source remotely, and then navigate to a third site to complete an action. The analytics records will not necessarily share one identifier or attribution chain.

Which AI browsers matter in 2026?

The dedicated alternatives are now familiar. Perplexity describes Comet as a Chromium-based browser with built-in AI capabilities. Dia focuses on working across tabs and connected services to prepare briefs, synthesize information, and answer questions from a user’s wider context.

The established browsers are moving in the same direction:

Gemini in Chrome can summarize pages, use context from multiple tabs, and work with Google services.
Browse with Copilot can select, type, and navigate inside an Edge tab while the user watches or takes control.
Firefox AI controls let people disable all supported AI features or manage them individually.
Brave’s agentic browsing test uses a separate profile and explicit action cues, while Brave also warns that browser agents introduce privacy and security risks.

Product availability can change faster than an analytics implementation. OpenAI launched Atlas in October 2025, but its current support guidance says Atlas will stop working on August 9, 2026 as browser-based agentic work moves into other OpenAI surfaces.

The durable trend is not a particular browser. It is the addition of an assistant that can read page context, combine information across tabs, and sometimes act inside a rendered browsing session.

Compare context, control, and data flow before choosing

Feature lists make AI browsers look more similar than they are. For individuals and teams, the important differences sit underneath the summary button.

Ask five questions before standardizing on one:

What context can the assistant read? Distinguish the current page from other tabs, history, connected email or calendar accounts, cookies, saved credentials, local files, and form input.
What can it do? Summarizing a page has a different risk boundary from selecting, typing, navigating, submitting a form, or approving an irreversible action.
Where is the context processed and retained? Check what stays on the device, what goes to the provider or its model partners, whether content can be used for product improvement, and how deletion works.
What controls exist? Look for opt-in behavior, site blocks, isolated profiles, action previews, interruption, administrator policies, and a way to disable the assistant.
Who can use the feature today? Platform, region, account, rollout cohort, and subscription requirements can matter as much as the product name.

The current products show why this review matters:

Comet’s privacy guidance says browsing history, the full tab list, cookies, passwords, local files, and typed input stay on the device by default. Requests can send the context needed for a summary or task, and some assistant context can be retained for up to 30 days. Users can disable the assistant or block it on specific sites.
Dia’s privacy and security documentation explains that relevant request context can pass through Dia’s servers and model providers. Content sharing for product improvement can be disabled, and write actions require review before they proceed.
Gemini in Chrome can use open-tab context and offers an agentic auto-browse mode, but current availability depends on account, subscription, and region.
Browse with Copilot can select, type, and navigate in a visible Edge tab. Microsoft documents current rollout limits, access to open tabs and signed-in cookies, and warnings for sensitive workflows.
Firefox AI controls let people block all supported generative AI features or manage them individually.
Brave’s agentic browsing test is opt-in and uses an isolated browsing profile so the agent does not inherit the normal profile’s cookies and logged-in state.

For analytics teams, these differences affect test coverage and traffic quality, but they do not create a standard “AI browser” flag that a website can trust. Measure the observable request or outcome instead of inferring the assistant from the browser brand.

Pageviews still work, but they mean less on their own

A pageview remains a useful statement: the page rendered and the tracking code ran. AI browsers do not make that false.

What changes is the relationship between the pageview and the amount of content consumed. One rendered page may support several summaries, comparisons, or questions without another navigation. At the other extreme, an assistant may extract enough information remotely that no pageview occurs.

Use pageviews for reach and navigation analysis, but do not treat them as a complete measure of attention. Pair them with:

landing pages and referrers for acquisition context;
custom events for meaningful interactions;
goals and funnels for business progress;
server-confirmed events for outcomes that must be accurate; and
AI crawler fetch records for non-rendered retrieval.

This is also why a sudden drop in pageviews does not prove that AI browsers took the traffic. Check search impressions, click-through rate, rankings, campaign changes, tracker delivery, consent behavior, and affected landing pages before assigning a cause.

Attribution needs conservative labels

An AI assistant referral is not the same thing as an AI browser session.

If someone clicks a link from ChatGPT, Perplexity, Claude, or another assistant, the destination may receive a recognizable referrer. That belongs in AI referral reporting. If someone types your URL in Comet or opens a bookmark in Dia, the visit may look like any other direct or browser visit. If an assistant opens a page inside a normal tab, the referrer depends on the navigation path and browser policy.

Do not manufacture certainty by labelling every visit from an AI-capable browser as “AI traffic.” Record the evidence you have:

referrer host;
campaign parameters;
landing page;
timestamp;
user agent where your privacy policy and collection design allow it; and
downstream goal or revenue outcome.

Then classify conservatively. HitKeep’s AI Visibility report keeps AI-referred human visits separate from AI crawler fetches for this reason. A fetch shows that an identified crawler requested a path. A referral shows that a person later arrived from an assistant. Neither signal proves that the assistant cited the page or that the fetch caused the visit.

The AI Visibility overview keeps crawler fetches and AI-referred visits as separate metrics before showing assistant filters, fetch volume, and errors.

Can GA4 track AI browser traffic?

GA4 can record an AI browser visit when the page renders, the Google tag runs, and the request is not blocked. It can also attribute some visits from ChatGPT, Perplexity, Claude, and similar services when the destination receives a recognizable referrer or campaign parameter.

That does not make every visit in Comet, Dia, Chrome, Edge, Firefox, or Brave identifiable as AI-mediated traffic. A direct visit can still look direct, an agent action inside a rendered tab can resemble an ordinary interaction, and remote retrieval usually does not execute the Google tag.

Use GA4 or another client-side analytics tool for rendered sessions and visible referrals. Use edge or origin records for crawler fetches, and use backend events for confirmed outcomes. The AI traffic analytics alternative to GA4 comparison shows where HitKeep adds server-side AI crawler reporting and fetch-to-visit correlation without replacing GA4’s Google Ads, app analytics, or exploration workflows.

Critical events should be confirmed on the server

Browser agents can click buttons, fill forms, and move through checkout steps. Automatic browser events may record those interactions if the page and tracker run normally. They are useful for understanding the path.

The final business outcome should come from the system that accepted it:

emit a signup-complete event after the account exists;
emit a purchase event after the order or payment is confirmed;
record a subscription change after the billing system accepts it;
record a lead after the backend accepts the form, not only when the submit button is clicked; and
use idempotent event handling where retries could create duplicates.

Server-side tracking gives these events a collection path that does not depend on the agent, browser extension, content blocker, page lifecycle, or client connection finishing a beacon request.

This does not mean moving every interaction to the backend. Keep low-risk navigation and engagement events in the browser. Move the outcomes used for revenue, activation, provisioning, or operational decisions to the server.

Funnels connect tracked steps to completions and period comparisons. Critical completion events should still come from the system that accepted the outcome.

Do not turn every assisted session into a bot

An AI-capable browser may still represent a person making decisions. Blocking or discarding the session because an assistant helped with the workflow can remove valid visits and conversions.

Known crawler requests are different. They usually arrive through identifiable user-agent families, do not execute your browser tracker, and should be measured at the edge or origin. HitKeep’s AI fetch ingest accepts matching crawler records separately from normal pageviews.

Use a narrow classification policy:

Treat a rendered visit as a visit unless you have strong evidence that it is invalid traffic.
Keep known AI crawler fetches in a separate server-side dataset.
Apply spam filtering to known abusive networks and impossible behavior.
Avoid browser fingerprinting added only to guess whether an assistant was involved.
Preserve an “unknown” category when the evidence does not support a stronger label.

That approach produces less certainty on individual sessions and more trustworthy totals.

A privacy-first measurement plan for AI browsers

You do not need a larger tracking surface. You need a clearer mapping from business questions to evidence.

Did a page render for a visitor? Use a pageview from the cookie-less browser tracker.
Did an assistant send a person to the site? Use the referrer and landing page from browser tracking and AI referral reporting.
Did an AI crawler request the content? Record the path, crawler family, status, and timestamp from edge, CDN, proxy, or origin logs.
Did the person or agent complete an important outcome? Emit a confirmed conversion event from the application or commerce backend.
Did the workflow progress before completion? Use custom events and funnel steps, with server events for critical stages.
Can we recheck the classification later? Keep portable event records through open exports and takeout.

Collect the minimum fields needed for those questions. A privacy-first setup should resist the temptation to add persistent identifiers or fingerprinting because browser behavior became harder to classify.

HitKeep uses cookie-less event tracking by default, supports browser and server-side events, and keeps AI referrals and crawler fetches as separate reports. Consent and legal requirements still depend on your full deployment, purpose, configuration, and jurisdiction.

Managed cloud or self-hosted analytics?

The browser measurement model does not change with the deployment model. Both managed and self-hosted analytics still need browser tracking for rendered visits, server-confirmed events for critical outcomes, and edge or origin records for non-rendered crawler fetches.

The choice changes which operating and governance responsibilities your team owns.

Choose HitKeep Cloud when you want:

a faster pilot without operating the analytics runtime;
managed upgrades, backups, SMTP, and day-two operations;
a region-pinned deployment in Frankfurt or Virginia; and
the same self-service export paths without managing the storage and backup infrastructure yourself.

Choose self-hosted HitKeep when you want:

direct control over the runtime, data directory, network boundary, backup targets, and upgrade schedule;
analytics data to remain inside infrastructure you operate;
a single Go binary with DuckDB and NSQ embedded instead of separate database and queue services; and
the responsibility to configure retention, backups, email, TLS, monitoring, and recovery.

Neither option recovers an interaction that never reached your site. Deployment is an operating decision; the collection paths described in this article are the measurement decision.

Test the browsers instead of assuming

Run a small repeatable test whenever a browser or assistant becomes important to your audience.

Open a tagged test landing page manually.
Ask the assistant to summarize the page without navigating away.
Ask it to open a second tagged page.
Let it complete a harmless test workflow, such as a sandbox signup.
Check the browser pageviews, custom events, backend confirmation, referrer, and server logs.
Repeat with privacy protections or content blocking enabled.

Record the result in a dated worksheet:

Test field	What to record
Product and version	Browser, assistant feature, build, platform, account type, and region
Page rendered	Whether the tagged page visibly opened
Browser tracker	Whether the pageview and expected browser events arrived
Referrer and campaign	The referrer value, campaign parameters, or absence of both
Server request	Whether the edge, proxy, CDN, or origin recorded a request
Backend outcome	Whether the application confirmed the test signup, lead, or purchase
Controls	Content blocking, privacy mode, isolated profile, and assistant permissions

Document what you observed, including the browser version and date. Do not turn one result into a permanent product assumption. AI browser features are frequently gated by platform, region, account type, rollout cohort, and user settings. This article therefore describes durable measurement boundaries instead of claiming one permanent result for every Comet, Dia, or incumbent-browser release.

For crawler tests, use server logs instead of the visible browser. The AI crawler logs versus AI referral traffic guide explains why those datasets answer different questions.

What to watch over the next 6 to 12 months

Treat these as instrumentation watchpoints, not predictions:

The gap between discovery and visits. Compare search impressions, AI crawler fetches, AI referrals, pageviews, and conversions separately. A growing gap can justify investigation, but no single series proves that an assistant summarized the page.
Agent identification standards. Watch for stable, documented request headers, crawler identities, or opt-in browser signals. Do not build production classification around an experiment until its semantics and privacy boundary are clear.
Feature availability. Record browser version, platform, region, account type, and test date. Agentic modes frequently move between experiments, subscriptions, and general availability.
Security and privacy controls. Isolated profiles, per-site blocks, administrator policies, and model-context choices can change which events or authenticated states appear in a test.
Your ability to re-run the analysis. Preserve baselines and export samples so a new classification rule can be tested against historical records instead of only future traffic.

Small, repeatable checks are more useful than a large one-time instrumentation rewrite.

A practical 30-day checklist

If AI-mediated browsing is relevant to your acquisition or product flow, use this sequence:

List the metrics that drive decisions. Remove events that nobody uses.
Record a baseline by referrer, landing page, goal, and funnel before changing the tracking setup.
Move signup, purchase, and other critical outcomes to server-confirmed events.
Forward known AI crawler requests from the edge or origin if content discovery matters.
Test the AI browsers and incumbent AI features your audience actually uses.
Review false bot classifications and keep ambiguous rendered visits out of crawler totals.
Export a sample dataset and confirm that the team can re-run the analysis outside the dashboard.

The aim is not to identify every model interaction. It is to preserve reliable answers about reach, acquisition, conversion, and content retrieval while the browser layer changes.

Where HitKeep fits

HitKeep provides the measurement paths covered in this article:

cookie-less browser pageviews and automatic outbound, download, and form events;
custom browser and server-side events;
goals, funnels, ecommerce, and UTM reporting;
AI-referred visit reporting;
server-side AI crawler fetch ingest and correlation views; and
exports through takeout in CSV, Parquet, JSON, NDJSON, and XLSX where supported.

You can self-host the same open-source foundation as one Go binary with embedded DuckDB and NSQ, or use HitKeep Cloud in the EU or US when managed upgrades, backups, and day-two operations are the better fit.

HitKeep 2.12.0: Team OIDC SSO, Invite-Aware Sign-In, And Routed Site Settings

Tue, 14 Jul 2026 00:00:00 GMT

HitKeep 2.12.0 added team-scoped OpenID Connect single sign-on, carried invitations safely through the provider flow, and gave owners a controlled path from connection testing to rollout without turning analytics access into another disconnected account lifecycle.

The release also gives site settings real routes, brings password, passkey, and SSO choices into one consistent sign-in surface, and fixes two less visible but important boundaries: QR campaign data now survives site changes correctly, and cross-origin request checks use the standard browser security contract.

What Shipped

Team OIDC SSO: connect one OpenID Connect provider to a team, route allowed email domains to it, and keep the configuration within the team’s administration area.
Invite-aware access: carry a pending team invitation through the provider redirect, verify the returned email, preserve the invited role, and consume only that invitation after successful authentication.
Optional trusted-domain provisioning: owners and admins can let a verified user from an allowed domain join as a Member without an invitation; the option is off by default.
Stronger OIDC verification: use Authorization Code flow with PKCE S256, exact issuer and audience checks, nonce validation, one-time state, and a required boolean email_verified: true claim.
One authentication surface: password, passkey, and SSO entry points now share the same card, feedback, loading, and error patterns across login, signup, setup, password recovery, and invitation acceptance.
Routed site settings: general, tracking, filtering, retention, access, and danger-zone settings have stable URLs and route-level permission checks.
Addressable invitations: team administrators can link directly to the invite flow instead of relying on page-local dialog state.
Data and request-boundary fixes: site changes preserve QR campaign data, while state-changing cross-origin requests are checked with a standard origin policy.

Configure SSO Per Team

Owners and admins configure SSO under Administration → Team → SSO. The page keeps the callback URL, issuer, client credentials, allowed domains, claim mapping, connection test, and enable switch together. One team connects to one OIDC provider, and one email domain can belong to only one SSO configuration in a HitKeep instance, keeping email-based provider discovery unambiguous.

The team SSO page presents provider configuration, domain routing, security checks, testing, and rollout controls in one place.

HitKeep stores the client secret encrypted and never returns it to the dashboard. Leaving the field blank keeps the current secret; entering another value rotates it. The callback URL comes from the configured public URL, including any deployment path prefix, so the identity-provider registration can match the real installation exactly.

The connection test validates discovery metadata before rollout. It checks that the issuer is reachable and advertises usable authorization, token, and key endpoints. A real browser sign-in is still required before announcing the integration because provider assignment, the client secret, callback matching, and ID-token claims can only be proven end to end.

On HitKeep Cloud, SSO is included with the Business plan. Self-hosted HitKeep includes the feature without a plan gate. Password and passkey sign-in remain available: this release adds OIDC as an authentication method; it does not force a domain to use SSO or replace the existing recovery path.

Verified Identity Is Not Automatic Access

An allowed email domain tells HitKeep which identity provider to use. It does not grant membership by itself. After the provider returns a verified identity, one of these authorization paths must apply:

the person is already a member of the routed team;
the person has a live invitation for that team; or
an owner or admin has explicitly enabled trusted-domain auto-provisioning.

Invitation acceptance stays scoped to the invitation that started the flow. HitKeep carries the one-time token through OIDC state, requires the provider to return the same verified email address, preserves the requested team role, and does not accept other pending invitations for that address.

Automatic provisioning is deliberately off by default. When enabled, a verified trusted-domain user joins as a Member. Managed-cloud seat and team limits still apply, and team membership does not silently create site permissions; those remain a separate assignment.

This keeps identity verification and product authorization distinct. The identity provider proves who signed in. HitKeep still decides which team and sites that identity can access.

The normal login page now presents password, passkey, and SSO methods through the same interaction pattern. Choosing SSO asks for a work email first, then routes the user to the configured provider for that domain. The page can also open directly in SSO mode with a prefilled email, which makes invitation and organization-managed entry points less repetitive.

Password, passkey, and SSO remain visible choices on one sign-in surface; enabling team SSO does not remove the existing login methods.

The same auth components now appear across invitation acceptance, setup, signup, forgotten-password, and reset-password pages. Loading belongs to the action that is running, provider failures return to the right surface, and an access-denied result is distinct from a discovery or token-exchange failure.

Invited users do not need to leave the invitation page to discover whether SSO is available. If the invited team has an enabled and entitled connection, the page offers Continue with SSO and carries the invitation through the redirect. Existing password-based invitation acceptance continues to work.

OIDC Security Boundaries

HitKeep’s OIDC relying party validates more than a successful redirect. The flow uses:

Authorization Code flow with PKCE S256;
exact issuer and audience validation on the ID token;
nonce validation and short-lived, one-time state;
a required native boolean email_verified: true claim;
encrypted storage for the provider client secret;
no storage of provider access or ID tokens; and
team audit events for configuration changes, tests, and login outcomes.

Managed HitKeep Cloud also requires HTTPS provider endpoints, rejects private and other non-public network targets, and checks redirects before following them. Self-hosted installations can reach an internal identity provider when the HitKeep host can resolve it and trusts its TLS certificate.

The boundary is intentionally narrower than a full identity-governance product. Version 2.12.0 does not add SAML, SCIM, identity-provider-initiated login, group-to-role mapping, forced SSO, or continuous provider-to-HitKeep account synchronization. Removing a user at the provider prevents future SSO authentication, but operators must still remove the HitKeep membership and review any other enabled login methods.

Site Settings Become Addressable Pages

Site settings are no longer a drawer whose state disappears when the page closes. Each section now has a stable route under the selected site:

general
tracking
filtering
retention
access
danger zone

Deep links open the requested section, browser titles describe the active page, and route guards apply the same site capabilities that control which tabs are visible. Someone without permission to manage exclusions, retention, team access, or deletion cannot bypass that boundary by typing a URL.

This also removes a layer of layout state from the analytics dashboard. Settings use the same page frame, breadcrumbs, and routed-tab pattern as team administration, making the interface more predictable on reload and easier to link from support or operational documentation.

The team members area received the same treatment for invitations: Administration → Team → Members → Invite is now an addressable state, so an owner can return directly to the task without reopening a local dialog.

Reliability And Security Fixes

Two fixes sit below the visible product changes.

Changing a site’s domain or moving site data relies on a careful shadow-row sequence because DuckDB rewrites indexed rows and does not provide cascading or deferred foreign-key behavior. Version 2.12.0 relaxes the QR parent constraints involved in that workflow and preserves QR campaigns, codes, visits, and related analytics during supported site changes.

The server also replaces a custom fetch-metadata implementation with a standard cross-origin protection policy for state-changing requests. Same-origin dashboard requests keep working, approved cross-origin API behavior remains explicit, and requests that do not satisfy the browser-origin contract are rejected before reaching protected handlers.

What Is Not Changing

HitKeep 2.12.0 keeps the same operating model:

one Go binary
embedded DuckDB data stores
embedded NSQ queueing
no required PostgreSQL, Redis, Kafka, ClickHouse, or separate identity service
cookie-free browser tracking by default
open export paths
self-hosted and managed cloud built from the same product foundation

OIDC adds an optional outbound connection to a team’s chosen identity provider. It does not change tracking, analytics retention, or the data collected from website visitors.

Upgrade Guidance

Upgrade to 2.12.0 when a team wants to use its existing OpenID Connect provider or when operators need stable links to site settings and invitation workflows.

For an SSO rollout:

upgrade HitKeep and keep at least two owner login paths available;
open Administration → Team → SSO and copy the exact callback URL;
create a confidential OIDC web application using Authorization Code flow;
enter the issuer, client ID, client secret, domains, and claim mappings;
save with SSO disabled, run the connection test, then enable it;
test a real invited or existing member in a private browser window; and
review the team activity log before expanding access or enabling automatic provisioning.

If a self-hosted installation changes HITKEEP_PUBLIC_URL, update the provider callback registration. If HITKEEP_JWT_SECRET changes, enter and save the OIDC client secret again because the previous encrypted value was derived from the old secret.

Self-hosted HitKeep includes team OIDC SSO in the same binary as the dashboard, queue, and database. If you want managed upgrades, backups, and regional hosting alongside SSO, start a managed HitKeep Cloud deployment.

Follow HitKeep on X, Bluesky, and LinkedIn.

HitKeep 2.11.0: Signed Webhooks, Bounded Retries, And Delivery History

Sat, 11 Jul 2026 00:00:00 GMT

Operational changes are useful outside an analytics dashboard. A goal conversion may need to notify billing, a completed import may unblock a migration, and a team membership change may need to update an internal system. Polling the REST API adds delay and repeated work.

HitKeep 2.11.0 adds signed outbound webhooks for those workflows. Site and instance administrators can subscribe an HTTPS endpoint to the events they need, send a test delivery, rotate its signing secret, and inspect delivery attempts without adding a separate integration service to HitKeep.

What Shipped

Site and instance webhooks: subscribe one endpoint to a site’s events or use instance scope for cross-site and administrative events.
HMAC-SHA256 signatures: every request signs its timestamp and exact JSON body with a secret shown only after creation or rotation.
Bounded retries: unsuccessful deliveries use exponential backoff, with six attempts by default and a six-hour maximum delay.
Test delivery: queue a webhook.test event before connecting a production workflow.
Delivery history: inspect event type, status, attempts, response code, and creation time in a paginated, sortable table.
Focused administration: search and sort configured endpoints, scan subscribed events, and open delivery, test, edit, rotate, or delete actions from the row menu.
Destination protection: production endpoints require HTTPS and cannot resolve to loopback, private, link-local, multicast, documentation, or other reserved addresses.
Single-binary operation: the dispatcher, retry worker, recovery sweep, and retention cleanup run inside the existing HitKeep process.

Configured endpoints reuse HitKeep’s searchable table and row-action patterns; the event-count popover keeps larger subscriptions scannable.

Verify The Exact Request Body

Each delivery includes a Unix timestamp and a v1 HMAC-SHA256 signature. Verify the original bytes before decoding JSON; parsing and re-serializing the body can change whitespace or key ordering and invalidate the signature.

body, err := io.ReadAll(io.LimitReader(r.Body, 1<<20))
if err != nil {
  http.Error(w, "invalid body", http.StatusBadRequest)
  return
}

timestamp := r.Header.Get("X-HitKeep-Timestamp")
signature := strings.TrimPrefix(
  r.Header.Get("X-HitKeep-Signature"),
  "v1=",
)
provided, err := hex.DecodeString(signature)
if err != nil {
  http.Error(w, "invalid signature", http.StatusUnauthorized)
  return
}

mac := hmac.New(sha256.New, []byte(signingSecret))
mac.Write([]byte(timestamp + "."))
mac.Write(body)
if !hmac.Equal(mac.Sum(nil), provided) {
  http.Error(w, "invalid signature", http.StatusUnauthorized)
  return
}

Receivers should also reject stale timestamps and persist X-HitKeep-Event-ID or X-HitKeep-Delivery-ID before returning success. Delivery is at least once, and events may arrive out of order, so downstream processing must be idempotent.

The signed webhook guide includes a complete Go receiver with timestamp validation and the full request-header contract.

Events At The Right Scope

Site webhooks cover lifecycle, goal, import, and test events for one site:

site.updated and site.deleted
goal.created, goal.updated, goal.deleted, and goal.converted
import.completed and import.failed
webhook.test

Instance webhooks can subscribe to every site event plus site.created, user lifecycle events, team lifecycle events, and team membership changes. The dashboard loads the valid event catalog for the selected scope, and the API rejects invalid combinations.

This is deliberately an operational event surface, not a raw analytics stream. Webhook payloads do not export pageview histories, visitor records, form contents, or Ask AI conversations. Use open exports and takeout when another system needs analytics data rather than a notification that an operational change happened.

One-Time Secrets And Rotation

Creating a webhook returns its signing secret once. The dashboard presents it through the same one-time credential pattern used for API client tokens: copy it into the receiver’s secret store before leaving the page.

Rotation replaces the configured secret and re-signs pending, retrying, and processing delivery records with the new value. A request already in flight may still carry the previous signature, so receivers that rotate during active delivery should allow a short overlap window.

Webhook administration remains a human dashboard workflow. Instance owners and administrators can manage instance webhooks. Site owners and administrators can manage a site’s webhooks. Editors, viewers, instance users, and delegated API clients cannot create endpoints or rotate secrets. The roles and permissions guide documents the complete boundary.

Retries Without An Unbounded Queue

Any 2xx response marks a delivery successful. Timeouts, connection failures, and non-2xx responses retry with exponential backoff. The defaults keep failure bounded:

Behavior	Default
Request timeout	10 seconds
Maximum attempts	6 total attempts
Initial retry delay	30 seconds
Maximum retry delay	6 hours
Global delivery concurrency	8
Per-endpoint concurrency	1
Delivery-history retention	30 days
Recovery sweep	Every 30 seconds

Operators can tune these limits through the outbound webhook configuration. The default per-endpoint concurrency of one prevents one slow receiver from being flooded, while the global limit keeps outbound work predictable inside the single process.

Delivery history stores outcomes and attempt metadata, not saved response bodies or secrets. The dashboard exposes that history in a paginated and sortable table, so a failed endpoint can be diagnosed without turning the UI into a raw payload archive.

A successful test delivery records the event, terminal status, attempt count, response code, and creation time without retaining the response body or signing secret.

Safer Outbound Destinations

An outbound webhook feature creates a server-side request boundary, so endpoint validation happens both when an administrator saves the URL and immediately before delivery. Production destinations must use HTTPS. HitKeep does not follow redirects, does not inherit proxy settings for webhook delivery, and blocks hostnames that resolve to non-public address space.

Self-hosted developers can explicitly enable HTTP and private targets with HITKEEP_WEBHOOK_ALLOW_DEVELOPMENT_TARGETS=true. That flag removes the destination protections intended to prevent server-side request forgery and should never be enabled in production. The security reference covers webhook delivery alongside HitKeep’s other optional outbound connections.

What Is Not Changing

HitKeep 2.11.0 keeps the same operating model:

one Go binary
embedded DuckDB data stores
embedded NSQ queueing
no required PostgreSQL, Redis, Kafka, ClickHouse, or separate integration service
cookie-free browser tracking by default
open export paths
self-hosted and managed cloud built from the same product foundation

Webhooks add outbound operational delivery; they do not change browser tracking or broaden the stored analytics data model.

Upgrade Guidance

Upgrade to 2.11.0 when another system needs to react to HitKeep goal, import, site, team, or user changes without polling.

After upgrading:

Open Integration → Webhooks and choose site or instance scope.
Create an HTTPS endpoint and subscribe only to the events the receiver needs.
Store the one-time signing secret outside HitKeep.
Send a test event and verify the timestamp, signature, and delivery ID.
Confirm the delivery appears as successful in delivery history.
Review retry, concurrency, and retention defaults before enabling a high-volume workflow.

Self-hosted HitKeep includes webhook delivery in the same binary as the dashboard, queue, and database. If you want signed operational delivery without managing upgrades, backups, and worker operations, start a managed HitKeep Cloud deployment.

Follow HitKeep on X, Bluesky, and LinkedIn.

HitKeep 2.10.0: Custom Tracking Domains, Team Admin Pages, And Chart Preferences

Tue, 07 Jul 2026 00:00:00 GMT

HitKeep 2.10.0 lets teams serve the tracker and ingest endpoints from their own verified hostnames, turns the team administration area into real addressable pages, remembers your chart style and report preferences, and tightens the cloud plan surface.

What Shipped

Custom tracking domains: team admins verify their own tracker hostnames with a DNS TXT record; active domains serve hk.js, hk-vitals.js, and browser ingest for every site in the team.
Managed TLS for tracking domains: HitKeep Cloud issues on-demand certificates after DNS verification; self-hosted setups get documented Caddy, nginx, and Traefik examples.
Team admin pages: overview, members, API clients, custom domains, branding, activity, and danger zone are now routed subpages with their own URLs and browser titles.
Tables with dialogs: custom domains and API clients use the same table-plus-dialog management pattern, with validity shown as per-check icons.
Chart style toggle: switch charts between area, line, and bars with an icon control; the choice applies to every chart and is remembered, alongside the report range and overview sort order.
Cloud plan polish: a clearer plan comparison with locale-aware prices, usage-aware free plan notices, and a focused upgrade path from banner, sidebar, and lifecycle emails.
Fixes: search field icons align with the theme again, the multi-site overview gets proper hover feedback, and the free plan notice no longer competes with itself.

Custom Tracking Domains

Serving analytics from a third-party hostname is a common reason measurement quietly degrades. HitKeep 2.10.0 lets a team register its own tracker hostnames, prove ownership with a DNS TXT record, and then serve the tracker scripts and ingest endpoints from that first-party domain.

Custom domains are managed in a table: per-check validity icons for ownership, DNS target, and TLS, with verify, DNS setup, and delete as row actions.

Adding a domain opens a DNS setup dialog with the exact records to copy: the _hitkeep-tracking TXT record for ownership and the CNAME, A, or AAAA target for routing. Verification checks all three concerns separately, so a half-finished DNS change is visible as exactly that.

The DNS setup dialog shows copyable records and the current verification state for each check.

Once a domain is active, site tracking snippets can be generated against it, and browser ingest accepts traffic through it for every site in the owning team. Cross-team use is rejected at the API: a domain verified by one team never ingests for another team’s sites.

On HitKeep Cloud, TLS is part of the feature: after DNS verification, certificates are issued on demand for the custom hostname. Custom tracking domains are available on the Pro plan and higher in the cloud; self-hosted deployments get the feature without restriction, with Caddy, nginx, and Traefik examples in the repository.

# Self-hosted configuration
HITKEEP_CUSTOM_TRACKING_DNS_TARGET=analytics.example.com   # host or IP your domains must point at
HITKEEP_CUSTOM_TRACKING_TLS_MODE=external                  # or caddy-on-demand
HITKEEP_CADDY_TLS_ASK_TOKEN=...                            # protects the Caddy on-demand TLS ask endpoint

Team Administration Gets Real Pages

The team area used to be one page with query-parameter tabs. In 2.10.0 every section is a routed subpage: /admin/team/members, /admin/team/custom-domains, /admin/team/branding, and so on. Deep links work, browser titles are descriptive, and the activity page enforces its audit permission on the route itself.

Members, invites, API clients, and custom domains share the same searchable table pattern with row actions.

The pages also share one design language now. API clients and custom domains use the same table-plus-dialog pattern, status is a color-coded icon rather than prose, and the danger zone matches its site-level counterpart card for card.

Chart Style And Remembered Preferences

Analytics charts get a three-way style toggle — area, line, bars — rendered as an icon control above the plot instead of a dropdown over it. The selection applies to every chart in the dashboard at once and is remembered per browser.

The chart style toggle sits above the plot and applies to all charts, including comparisons and trend lines.

The same preference layer now covers the report range and the multi-site overview sort order, so the dashboard reopens the way you left it. The overview cards also picked up proper hover feedback: the card lifts, the sparkline deepens, and keyboard focus receives the same treatment.

The overview remembers your sort order and search stays a keystroke away.

Cloud Plans And Upgrade Flow

For HitKeep Cloud, the plan comparison inside the team overview was rebuilt: a section header, a highlighted recommended plan, a custom-domains feature line, and locale-aware prices — €15 in English locales renders as 15 € in German. The free plan notice became usage-aware: when a team fills 80% or more of its site or member allowance, the banner switches to the exhausted limit and resurfaces even if the time-based notice was dismissed. A matching lifecycle email reaches owners who are not in the dashboard.

Every upgrade surface — banner, sidebar chip, plan page, lifecycle emails — now leads to the same plan comparison instead of jumping straight into a checkout. The comparison page states plainly that HitKeep is fully open source, including every paid feature, with sponsoring and self-hosting as first-class alternatives.

None of this appears on self-hosted deployments: plan gating, notices, upsell emails, and the sidebar chip are managed-cloud surfaces only.

Bug Fixes And UI Polish

search field icons across all tables align with the OptimusUI theme again
the signup page states the essentials up front: no credit card, region-pinned data, export or self-host anytime
the free plan retention notice consolidated three competing actions into one
the seeded demo covers custom domains, so screenshots and e2e tests exercise the real flow

What Is Not Changing

HitKeep keeps the same operating model:

one Go binary
embedded DuckDB data stores
embedded NSQ queueing
no required PostgreSQL, Redis, Kafka, ClickHouse, or hosted analytics dependency
cookie-free browser tracking by default
open export paths
self-hosted and managed cloud built from the same product foundation

Custom tracking domains do not change the tracking model. The tracker still sets no analytics cookies, respects Do Not Track, and serves the same hk.js — only the hostname it loads from becomes yours.

Upgrade Guidance

Upgrade to 2.10.0 if you want first-party tracking hostnames, the reworked team administration area, or remembered chart and report preferences.

After upgrading, check:

the new custom_tracking_domains table is created by the automatic migration
HITKEEP_CUSTOM_TRACKING_DNS_TARGET if your deployment serves custom tracking domains
HITKEEP_CUSTOM_TRACKING_TLS_MODE and the reverse-proxy examples if you terminate TLS yourself
deep links into /admin/team/... used in internal runbooks or bookmarks (legacy tab URLs redirect)
the chart style toggle and remembered report range on your most-used dashboards

Follow HitKeep on X, Bluesky, and LinkedIn.

HitKeep 2.9.0: Ask AI, Site Overview, And Better Analytics Charts

Sat, 04 Jul 2026 00:00:00 GMT

HitKeep 2.9.0 adds the experimental Ask AI dashboard assistant, a new multi-site overview, ECharts-based charts, more time range presets, and a round of dashboard fixes.

What Shipped

Experimental Ask AI: a dashboard drawer can answer site-scoped analytics questions, show tool-call progress, cite aggregate results, render small charts or tables, and offer safe dashboard actions.
New overview page: the dashboard gets a lighter place to compare sites before opening a specific analytics report.
ECharts charts: analytics charts move from Chart.js to ECharts for clearer rendering, better accessibility hooks, and a shared chart option layer.
More time ranges: the range toolbar now supports Today, Yesterday, 24h, 7d, 30d, additional presets, and custom ranges.
Searchable selectors: range and language selectors are easier to scan when the list grows.
Cloud setup polish: hosted cloud signup now carries region choice into the signup flow and exposes hosted integration discovery.
Team and site workflow fixes: invite links survive the login flow, site owners can reset stats from the dashboard, QR share mode exposes QR navigation, and seeded demo data better matches the current day.
UI maintenance: the favicon and primary logo were replaced with optimized SVGs, dashboard screenshots were refreshed, mail footer social badges were simplified, and frontend dependencies were updated.

Experimental Ask AI

Ask AI is the first dashboard-session assistant in HitKeep. It appears as a drawer inside the authenticated dashboard and uses the active site as its scope. A user can ask a question such as “How many hits did I get from ChatGPT in the last 14 days?”, then see which aggregate analytics tools were read before the answer appears.

Ask AI opens from the dashboard sidebar and starts with suggested prompts for the active site.

Tool-call chips, citations, table output, and safe dashboard actions make the answer auditable from the UI.

Ask AI is experimental, optional, and disabled by default. Self-hosted operators must enable both the shared AI route and the Ask AI feature flag:

HITKEEP_AI_ENABLED=true
HITKEEP_ASK_AI_ENABLED=true
HITKEEP_AI_PROVIDER=openai-compatible
HITKEEP_AI_MODEL=your-model-or-gateway-route

Ask AI is dashboard-session only. It does not add a public MCP tool, does not accept API client bearer tokens, and does not expose a saved history tab. MCP remains a separate read-only aggregate API client surface.

The assistant is also intentionally narrow about stored data. Public docs and user-facing exports do not expose raw prompts, provider secrets, full model responses, provider headers, raw external error bodies, or unrestricted tool payloads. Saved audit metadata uses safe fields such as hashes, tool names, status, counts, usage, and error categories.

New Overview Page

HitKeep 2.9.0 adds a new overview surface for operators who manage more than one site. It gives the dashboard a light entry point before the user drills into a specific report. The overview uses lightweight site metrics and compact chart visualizations so teams can spot which site needs attention first.

The new Overview page lists every accessible site with filter and sort controls, 30-day metrics, sparklines, and direct links into each site dashboard.

The site reset workflow also became more explicit. Site owners can reset stats from the dashboard, while API clients cannot use that destructive dashboard-session path. That keeps cleanup available to operators without turning reset into a machine-token workflow.

Better Charts And More Time Ranges

Analytics charts now use ECharts through a shared HitKeep chart option layer. The dashboard keeps the same product questions: pageviews, visitors, comparison overlays, goal and funnel movement, ecommerce trends, AI visibility, and Web Vitals. The charting library change is about rendering, readability, and maintainability rather than changing the analytics model.

ECharts renders the main traffic series, trend line, and previous-period overlays while KPI cards keep the selected range comparison visible.

The range toolbar now covers short windows, calendar-style presets, and longer report windows in one control set. Today is useful during setup and launches. Yesterday, 24h, 7d, 30d, and the expanded preset list cover recurring reporting. Custom still handles exact campaign or incident windows.

Cloud, Teams, And Setup Polish

The hosted cloud signup flow now carries region choice into signup instead of making the user pick it later. Hosted integration discovery also gives cloud deployments a clearer way to expose available hosted integration paths.

Team invite handling is less fragile. Invite links now survive the login flow, so existing users can sign in and land back on the pending invite. New invited users can set a password for the invited email address and start in the team that invited them.

The setup path also picked up smaller fixes: brand clicks return to the app root, QR share mode exposes QR navigation, and demo seed data now keeps AI visibility, UTM, and QR examples visible for the current day.

Bug Fixes And UI Polish

This release includes a wide dashboard asset refresh and several focused fixes:

the language selector overlay stays above the settings card
the favicon and primary logo now use optimized SVG assets
the mail footer keeps legal and social links without heavy badge styling
seeded dashboard end-to-end tests are more stable
Go modules and frontend packages were refreshed
Helm chart release metadata now follows HitKeep Release Cadence
the MCP registry and README point readers toward the analytics MCP use-case page

These are maintenance changes, but they matter for the daily experience: fewer overlay surprises, better current-day demo states, cleaner branding, and less screenshot drift between the product and docs.

What Is Not Changing

HitKeep keeps the same operating model:

one Go binary
embedded DuckDB data stores
embedded NSQ queueing
no required PostgreSQL, Redis, Kafka, ClickHouse, or hosted analytics dependency
cookie-free browser tracking by default
open export paths
self-hosted and managed cloud built from the same product foundation

Ask AI does not turn HitKeep into a write-capable automation layer. It is a human dashboard assistant for aggregate analytics questions. MCP remains read-only, aggregate-only, and separate from the dashboard-session Ask AI drawer.

Upgrade Guidance

Upgrade to 2.9.0 if you want to try the experimental Ask AI drawer, use the new overview surface, get the ECharts chart migration, or use the expanded report ranges.

After upgrading, check:

Ask AI visibility and disabled states on self-hosted instances
AI provider configuration and budget limits if you enable Ask AI
the new overview page with multiple sites
better chart rendering on dashboard, goals, funnels, ecommerce, Web Vitals, AI visibility, and UTM reports
Today, Yesterday, 24h, 7d, 30d, More ranges, and Custom range behavior
invite acceptance after login
owner-only site stats reset
QR share navigation

For production Ask AI use, route provider traffic through an AI gateway or provider policy layer that can enforce detailed quotas, model allowlists, key isolation, audit logging, redaction, and network controls. HitKeep’s built-in request and token caps are a local process-level safeguard, not a complete provider policy system.

Follow HitKeep on X, Bluesky, and LinkedIn.

HitKeep 2.8.0: QR Campaigns, Portuguese, And Agent-Ready Analytics

Wed, 24 Jun 2026 00:00:00 GMT

HitKeep 2.8.0 adds dynamic QR campaigns for offline attribution, Portuguese dashboard localization, and clearer AI assistant enablement through the optional MCP server, the official MCP Registry entry, HitKeep Agent Skills, and public contributor guidance.

What Shipped

QR campaigns: create dynamic QR codes under UTM -> QR codes, attach UTM and custom query parameters, export print artwork, share QR-only analytics, and export QR-scoped data.
Portuguese dashboard localization: the dashboard language set now includes English, German, Spanish, French, Italian, Dutch, and Portuguese.
Agent-ready analytics: the optional MCP server remains read-only and aggregate-only, with official Agent Skills that teach assistants how to use HitKeep analytics safely.
MCP Registry metadata: the HitKeep MCP server is listed as io.github.PascaleBeier/hitkeep, so compatible clients and directory tooling can identify the official endpoint shape.
Public AI contributor guidance: AGENTS.md, CLAUDE.md, the pull request template, and the public hitkeep-i18n skill now explain the safe paths for AI-assisted contributions.
GoAI validation coverage: the AI output storage boundary has focused regression coverage for structured output, raw provider payload rejection, and cited evidence validation.

QR Campaigns

QR campaigns are for offline links that still need campaign attribution. A saved QR campaign gets a dynamic HitKeep redirect URL under /q/{token}. That redirect records a QR open when allowed, then sends the visitor to the configured destination URL with UTM fields, custom parameters, and the reserved hk_qr attribution parameter.

The QR campaigns table lives under UTM, alongside the existing campaign workflow.

The editor keeps the dynamic redirect URL, final tracked URL, UTM fields, custom parameters, and QR styling visible before the artwork goes to print.

The dashboard separates redirect opens from tracked pageviews. Opens answer “how often was the QR token used?” Pageviews and visitors answer “how much tracked traffic arrived after the redirect?” That distinction matters because a scan can fail to become a tracked pageview when the destination page has no tracker, the visitor leaves early, the tracker is blocked, or privacy and traffic filters suppress the request.

Each QR campaign has its own analytics view with the artwork, redirect URL, tracked destination URL, open count, downstream pageviews, visitors, and export controls.

Each saved QR campaign can be exported as SVG or PNG artwork. PNG exports are available at 1024, 2048, and 4096 px. Optional center images can be PNG, JPEG, or WebP up to 2 MiB.

QR-only share links expose a read-only view for one QR campaign and its exports, without opening the rest of the dashboard.

Portuguese Localization

Portuguese joins the built-in dashboard languages. Users can select it from the same profile language setting as the other supported languages, and the selected locale follows the user across sessions and devices.

The supported dashboard languages are now:

English
German
Spanish
French
Italian
Dutch
Portuguese

AI Enablement

The AI-facing work in this release is about governed access, better assistant instructions, and safer contribution paths, not a new write-capable automation layer.

HitKeep MCP stays optional, leader-only, and disabled by default. When enabled, it accepts scoped API client bearer tokens and exposes read-only aggregate analytics, docs lookup, and help resources. It does not accept dashboard cookies and does not expose raw hit exports, billing, site administration, goal mutation, funnel mutation, or write workflows.

The official HitKeep Agent Skills complement MCP. They teach compatible assistants how to ask useful analytics questions, which HitKeep MCP tools to call, and where the privacy boundary is. That makes assistant answers easier to audit because the skill layer is public while the analytics token remains private and revocable.

For contributors, the new public agent guidance documents the MCP read-only boundary, skill maintenance rules, dashboard localization workflow, and GoAI structured-output expectations. GoAI-backed Opportunity output must stay key-based and deterministic: saved model output should contain localization keys, interpolation params, cited evidence IDs, detector metadata, status, and safe audit metadata rather than raw prompts, raw provider responses, external error bodies, provider headers, or secrets.

The release also adds direct storage-boundary regression coverage for AI run output. That test keeps the public rule honest: stored AI output must be a JSON object, must reject raw provider payload shapes, and must cite evidence that was actually supplied to the run.

What Is Not Changing

HitKeep still keeps the same operating model:

one Go binary
embedded DuckDB data stores
embedded NSQ queueing
no required PostgreSQL, Redis, Kafka, ClickHouse, or hosted analytics dependency
cookie-free browser tracking by default
open export paths
self-hosted and managed cloud built from the same product foundation

QR campaigns do not turn HitKeep into an ad platform. MCP and Agent Skills do not give assistants write access to analytics or admin actions.

Upgrade Guidance

Upgrade to 2.8.0 if you want QR campaign creation and analytics, Portuguese dashboard localization, or the new public AI contributor guidance and skill pack updates.

After upgrading, check QR campaign creation, scan redirects, destination tracking, QR-only share links, Portuguese dashboard copy, and MCP client setup with a scoped API client token.

How to Measure AI Overviews Traffic Loss

Wed, 10 Jun 2026 00:00:00 GMT

Your search traffic chart changed shape this spring, and the usual explanations do not cover it. Google is rolling out an AI-first search experience, a visible share of users is protesting by moving to no-AI alternatives, and AI Overviews answer queries before anyone clicks a result. All three shifts land in the same place: the referral data reaching your site.

This post covers what is actually happening, with the numbers from the reporting, and shows how to detect the shift in your own analytics instead of guessing.

Users are moving to DuckDuckGo and no-AI search

The pattern is consistent across multiple outlets. TechCrunch reported that “DuckDuckGo noted a 30% increase in web visits to its no-AI search page week-over-week,” alongside new Chrome and Firefox extensions that make the no-AI experience a default. The Independent reported that DuckDuckGo app installs rose by nearly a third after Google’s AI updates, quoting CEO Gabriel Weinberg: “Google is force-feeding AI with no way to opt out.”

Gizmodo tied the growth to user frustration with AI-generated answers and declining result quality. Wide Open Country cited Pubity data putting DuckDuckGo’s traffic increase at 300% since Google’s changes, and noted a parallel rise in the Vivaldi browser.

Keep the scale honest: per Statcounter, DuckDuckGo holds roughly 0.7% global market share against Google’s 90%+. Nobody is dethroning Google this quarter. Acquisition analysis cares about your referral mix rather than global market share, though, and a few percentage points moving between engines is enough to break attribution assumptions and weekly dashboards.

AI Overviews reduce clicks to source sites

The second shift is structural. When Google answers a query inline with an AI Overview, the click to the source page often never happens. ExtremeTech called the AI-first model potentially “disastrous for both the company and the broader internet ecosystem” precisely because it starves source sites of visits.

The trust dimension makes it worse. A BBC investigation showed how easily AI answers can be manipulated, quoting SEO expert Lily Ray: “You should assume that you’re being manipulated until they have better systems in place.” The same reporting notes that 2.5 billion people see Google’s AI Overviews each month. Broad exposure plus visible skepticism drives users to test alternatives, and it should drive publishers to recheck their numbers.

Check your own referral mix first

Before changing strategy, measure. If you have raw analytics data, the first check takes minutes. With a HitKeep Parquet export, it is one DuckDB query:

-- Referral mix by search engine, week over week
SELECT
  date_trunc('week', timestamp) AS week,
  CASE
    WHEN referrer ILIKE '%google%'     THEN 'google'
    WHEN referrer ILIKE '%duckduckgo%' THEN 'duckduckgo'
    WHEN referrer ILIKE '%bing%'       THEN 'bing'
    WHEN referrer = ''                 THEN 'direct'
    ELSE 'other'
  END AS source,
  count(*) AS pageviews
FROM 'pageviews.parquet'
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

You are looking for three symptoms:

Google share falling while direct or other engines rise. That is a signal of a possible channel shift, not proof that users migrated. Investigate campaign changes, tracking gaps, and affected landing pages before attributing the cause.
Search Console impressions flat or rising while clicks fall. That is consistent with more zero-click results, including AI Overviews, but it does not identify the cause by itself. Check affected queries and the search-result layout before attributing the change.
Stable sessions but worse downstream conversion from organic. That points to a change in channel quality rather than lost acquisition, and the two problems need different fixes.

In the dashboard, period-over-period comparison against the weeks before Google’s rollout gives you the same answer without exporting anything.

Instrument funnels and events

A total-sessions chart hides structural change. To tell an acquisition drop apart from a channel-mix shift, you need event-level visibility:

Custom events for signup steps, key outbound clicks, and downloads, so conversion is measured independently of pageviews.
Funnels segmented by referrer, so you can see whether DuckDuckGo arrivals reach step two of onboarding at a different rate than Google arrivals.
UTM reporting for the channels you control, so paid and owned traffic does not blur the organic picture.
Bot and spam filtering at collection time. Bot traffic masquerades as referral shifts, and a small real change in channel mix can look much bigger than it is when bots skew the data.

None of this requires analytics cookies. HitKeep records referrers and events with cookie-less tracking by default. Your consent and legal-basis analysis still depends on the full site configuration and jurisdiction. That matters here because the same backlash pushing users toward DuckDuckGo is privacy sentiment. Collecting more data than the analysis needs would be the wrong response.

Track AI assistants as their own channel

Search engines are only half of the new referral landscape. ChatGPT, Perplexity, and Claude cite and link sources, and their crawlers fetch your pages before any human visit shows up. The BBC’s reporting notes more than a billion people use AI chatbots regularly. That audience never appears in a classic search report.

HitKeep treats this as its own reporting surface: AI visibility analytics separates AI referral traffic from search referrals, and AI fetch ingest records GPTBot, ClaudeBot, and PerplexityBot fetches from your edge or origin logs.

HitKeep’s AI visibility report separates assistant referrals and AI crawler fetches from regular search traffic.

If Google’s AI answers may be taking clicks, seeing which systems fetch your content and which assistants later send referred visits adds useful context. Those are separate signals; neither one proves that a page was cited in an AI answer.

Run the measurement stack you can trust

When the search layer changes overnight, the analytics layer has to be something you can inspect and rely on. HitKeep is built for that case: a single Go binary with embedded DuckDB and NSQ, so there is no external database, cache, or queue to operate. Retention is configurable to your compliance constraints, and open exports in JSON, CSV, and Parquet support ad-hoc analysis like the query above. The self-hosted GA4 alternative guide covers the setup. One fair caveat from it: if your business depends on Google Ads attribution or BigQuery exports, a Google-native stack may remain essential.

If you want the same measurement without running infrastructure, HitKeep Cloud uses HitKeep’s shared open-source analytics foundation in region-pinned EU (Frankfurt) or US (Virginia) infrastructure with managed updates and backups. That helps when the team that needs these answers this week has no time to operate another service.

HitKeep 2.7.0: Smoother Realtime Analytics

Sat, 06 Jun 2026 00:00:00 GMT

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.

HitKeep 2.6.1: Web Vitals Dedup And Maintenance

Mon, 01 Jun 2026 00:00:00 GMT

HitKeep 2.6.1 was published on June 1, 2026. It is a maintenance patch on top of HitKeep 2.6.0 and keeps the city, provider, ASN, Web Vitals, MCP, and export surfaces compatible.

The main product fix is Web Vitals metric identity. The tracker now sends the metric ID emitted by the Web Vitals library, and the ingest path stores it with the Web Vitals sample. This gives HitKeep a stable metric identity for duplicate handling when a browser reports metric updates for the same page session.

What changed

Web Vitals metric IDs: hk-vitals.js sends the metric ID, ingest accepts it, and Web Vitals rows can store it as optional metric_id data.
Dashboard site selectors: API-client, settings, and UTM builder site selectors share the same site option component, favicon treatment, and domain sorting.
Dependency maintenance: Go modules, dashboard dependencies, and GitHub Actions were refreshed.
IP metadata refresh: embedded IP metadata assets were refreshed for release builds.
MCP registry metadata: server.json advertises the 2.6.1 MCP package version.

Upgrade guidance

Upgrade to 2.6.1 if you use Web Vitals reporting, want the latest dependency refresh, or publish HitKeep MCP metadata to tooling catalogs.

The Web Vitals schema change is additive. Existing Web Vitals rows do not need backfill. Older samples may have no metric ID, while new samples can preserve the metric ID sent by the tracker.

HitKeep 2.6.0: City And Network Analytics

Mon, 18 May 2026 00:00:00 GMT

HitKeep 2.6.0 adds city, provider, ASN, and ASN organization reporting to accepted hits. The new dimensions appear in dashboards, filters, Opportunities, shared reports, MCP responses, takeouts, and the public API.

The privacy boundary stays the same. HitKeep resolves visitor IP addresses transiently, stores derived analytics metadata, and still does not store raw visitor IP addresses on hit records.

This release also replaces the old country-only iploc dependency with embedded lookup data generated from IP2Location LITE country, city, and ASN datasets. Runtime lookup does not download data.

HitKeep uses the IP2Location LITE database for IP geolocation. See IP2Location and IP2Location LITE.

What Changed

City and network metadata: accepted browser and server-side hits can store region, city, provider, ASN, and ASN organization fields beside country.
Dashboard filters: country and city live under Location. Provider and ASN live under Network. Clicking a row applies the same reversible filter behavior as other metric cards.
More report context: dashboard, events, goals, funnels, ecommerce, Web Vitals, AI visibility, and chatbot analytics can show the new dimensions where the report has matching data.
Opportunities: traffic quality, ecommerce, Web Vitals, and AI visibility Opportunities can cite aggregate city, provider, and ASN evidence without storing raw IP addresses, user agents, or visitor rows.
MCP and shared dashboards: governed read-only surfaces can expose aggregate city/provider/ASN context without visitor-level data.
Lifecycle coverage: takeout, hit exports, retention archives, deletion/reset, and backup/restore include the new hit metadata consistently.
Country traffic exclusions: site and instance exclusions support country rules beside IP/CIDR rules. Country exclusions affect new incoming traffic only.

2.6.0 also extends traffic exclusions with country rules at the site and instance level, while keeping exclusions ingest-time and non-retroactive.

Dashboard Groups

Metric-card reports now use the same information architecture:

Group	Typical cards
Content	Pages, landing pages, exit pages, paths, event names, chatbot surfaces, AI resource types
Acquisition	Sources, referrers, campaigns, UTM source, medium, campaign, content, and term
Audience	Devices, browsers, and languages
Location	Countries and cities
Network	Providers and ASNs

City stays with country because both answer “where.” Provider and ASN stay together because both answer “which network.” Empty groups are hidden.

Data And Attribution

HitKeep’s embedded lookup assets are generated from IP2Location LITE data. They keep country lookup quality aligned with the previous iploc source and add city, provider, and ASN lookup for IPv4 and IPv6 addresses.

Maintainers refresh the embedded assets before public release:

IP2LOCATION_DOWNLOAD_TOKEN=... go run ./cmd/ipmeta-generate

The generator downloads upstream data, writes compressed runtime lookup assets, and discards the raw ZIP/BIN payloads. Production binaries embed only the runtime assets.

Privacy And Lifecycle

City, provider, and ASN fields are derived analytics data. They follow the same lifecycle as hits:

site takeout and user takeout include the fields
filtered hit exports include the fields
retention archives keep the fields in archived hit rows
site deletion, site reset, and analytics cleanup remove the fields with the hit rows
backup and restore preserve the fields because they are normal database columns

HitKeep still does not add raw visitor IP storage.

Compatibility Notes

API compatibility

Most JSON analytics response changes in 2.6.0 are additive. API clients with strict schemas should still review these compatibility-impacting changes before upgrading:

Exclusion rule responses are now typed. GET /api/admin/exclusions and GET /api/sites/{id}/exclusions can return CIDR rules with type: "cidr" and cidr, or country rules with type: "country" and country_code. Existing POST requests that send only cidr still work and are treated as CIDR rules, but list clients should stop assuming every row has a cidr value.
Hit exports and takeouts add geo/network fields. Hit rows can now include region, city, provider, asn, and asn_org. JSON clients that ignore unknown fields should keep working. Fixed-column CSV/XLSX readers and strict Parquet, JSON, or NDJSON schema consumers should update their mappings.
AI chatbot export now recognizes audience filters. /api/sites/{id}/ai-chatbots/export accepts repeatable filter=type:value hit-dimension filters. Clients that previously sent unrelated filter, filter_type, or filter_value query parameters should rename or remove them because invalid filter input can now return 400.

Hit metadata migration

There is also a schema migration for hits. Historical rows are not backfilled, so old rows may have country-only or empty city/network metadata. New accepted hits receive derived metadata when the resolved IP has a matching lookup row.

Trusted proxy accuracy

If you self-host behind a reverse proxy, review Trusted Proxies. Correct trusted-proxy configuration affects rate limiting, IP exclusions, spam checks, and derived country, region, city, provider, and ASN accuracy.

Release metadata refresh

Operators who mirror release workflows should set the IP2LOCATION_DOWNLOAD_TOKEN secret before running the metadata refresh workflow. Runtime deployments do not need the token.

HitKeep 2.5.1: Dashboard Refresh And Clearer API-Client Grants

Sat, 16 May 2026 00:00:00 GMT

HitKeep 2.5.1 is prepared as a dashboard and API-client clarity patch. The release keeps the 2.5.0 analytics surface intact while making navigation, table actions, dialogs, API-client grants, token rotation, and dark-mode Opportunity Recommendations easier to understand. It also exposes aggregate Web Vitals reports in read-only share mode and fixes stale AI provider warnings in system status.

Under the hood, it contains a few permission audit bugfixes.

The important API-client wording change is site grants. A client without a site grant can still be useful for permitted instance or admin APIs, but site analytics, MCP tools, and ingest access require an explicit site grant. That was the intended API-client model before this patch. The UI now says it plainly.

The API-client settings page now leads with a table. Creation and editing happen in dialogs, and row actions use the same menu pattern as other settings tables.

API-client creation now says what the grant does: site analytics, MCP, and ingest access require an explicit site grant.

Team-owned clients use the same grant language and table actions as personal clients, but the owner is the active team.

The Opportunities page was cleaned up in dark mode so cards, filters, badges, and evidence text stay readable.

On small screens, the API-client page keeps the team-management link visible above the table instead of burying it below scrolled content.

What changed

Sidebar navigation: related destinations are grouped as collapsible items. UTM can reveal UTM Builder, and API Clients can reveal API Reference, while the parent labels remain normal navigation links.
Reusable row actions: settings and admin tables now use a shared OptimusUI popup menu for row actions instead of inline button stacks.
Consistent dialogs: create and edit flows use the same dialog shell, footer order, close behavior, Escape behavior, and submit/cancel treatment.
API-client settings: the page is table-first. Add and edit flows open in dialogs, site grants are labelled as grants, active/revoked/expired state is shown beside the client name, and team API clients are reachable when the user has permission.
Explicit site-grant wording: empty site grants are shown as no site access. The form says that site analytics, MCP, and ingest access require a site grant.
Token rotation: personal and team API clients can roll tokens. Rotation returns the new token once and invalidates the previous token immediately.
Audit coverage: API-client create, update, revoke, reactivate, delete, and rotate actions are recorded without token material or token hashes.
Shared Web Vitals: share links now include the Web Vitals report, with the same aggregate p75 cards, trends, page rows, and visitor-context breakdowns available to authenticated viewers.
Mobile settings flow: page actions move above the table on narrow screens, so users do not need to scroll past rows before finding the main action.
Dark-mode Opportunity Recommendations: the filter rail, opportunity cards, evidence rows, status badges, and action buttons were tuned so the page no longer mixes light card styling into dark mode.
Settings polish: inline CRUD feedback was moved closer to the changed resource, so users see save, rotate, revoke, and delete outcomes where they acted.

API-client grants

API clients now use grant language consistently to address some feedback:

site_roles are grants, not optional restrictions.
A client with no site grants has no site-data access.
Site analytics, site-scoped MCP tools, and ingest require an explicit site grant.
Instance/admin-only API clients can still have no site grants.
Personal clients are capped to the creating user’s access.
Team clients are owned by the team and appear in the team API-client section.

This is a clarity and hardening patch for the existing model. If an integration already had site grants, no change is needed.

Compatibility note

Review API clients that call site analytics, MCP tools, or server-side ingest. Add the required site grants before or during the upgrade.

Most clients used for site data already needed grants to be useful. The hardening also closes paths where delegated owner/admin API clients could satisfy site-scoped checks through instance role alone. Treat those as over-broad tokens and add the intended site grants explicitly.

That has always worked like this and is not breaking

Token rotation is optional. Adding a grant does not reveal an existing token and does not require rolling it.

Upgrade guidance

Upgrade to 2.5.1 for the dashboard refresh, API-client grant wording, token rotation, audit coverage, share-mode Web Vitals reports, and stale AI provider warning cleanup.

Before upgrading integrations that use API clients for site data, check that each client has a grant for every site it should access. Clients used only for instance/admin APIs can remain without site grants.

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>.

Release pipeline note

This patch is intentionally small and follows 2.4.1 quickly. It fixes the site export menu bug and exercises the release pipeline with a narrow change.

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 for derived country, region, city, provider, and ASN metadata, 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 for derived IP metadata.
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 country, region, city, provider, and ASN lookup. It stores the derived analytics fields and does not store the raw visitor IP.

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, optional redirect tracking, 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

How to Build Better Google Reporting for Stakeholders

Start with the audience, not the dashboard

Build a reporting narrative before selecting charts

Use Search Console as discovery context, not a complete story

Suggested Search Console reporting structure

Keep definitions stable across GA and analytics signals

Separate traffic signals that mean different things

Use recommendation tables, not only raw tables

Build a repeatable reporting rhythm

Keep attribution honest

Keep an annotation log

Build from one reporting workflow

HitKeep 2.13.0: Reports, Social Sign-In, and a Typed Tracker SDK

What ships in HitKeep 2.13.0

Important platform updates

A typed tracker for framework applications

Speculative pages wait for activation

Reports become first-class definitions

Migrate report API clients before upgrading

Social sign-in without replacing existing login methods

Traffic controls follow ownership

Analytics leaves the shared control plane

Recovery preserves evidence before repair

Smaller, bounded IP metadata work

Contributor and release workflows become reproducible

Upgrade checklist

What does not change

Read more

How to Check Site Traffic Without Google Analytics

The short answer: choose the source that matches the question

First, decide whether you own the website

Use privacy-first web analytics for core visitor data

Use Google Search Console for organic search traffic

Read server and CDN logs for raw request evidence

Track campaigns with UTMs and QR codes

Measure conversions at the source

Separate AI crawler fetches from AI-referred visits

Build a simple traffic measurement stack

Step by step: check your site traffic without GA4

Keep your traffic numbers trustworthy

When should you still use Google Analytics?

Measure traffic on your own terms

Google Analytics vs Privacy-First Analytics in 2026

The short answer: which approach fits your team?

What changed by 2026?

Where Google Analytics is still strong

What privacy-first analytics means in 2026

Google Analytics vs privacy-first analytics: the real comparison

Compliance: neither label decides the outcome

Data ownership and control

Reporting quality: compare definitions before totals

AI traffic changes the comparison

When to keep Google Analytics

When to switch to privacy-first analytics

A practical migration path

Final verdict

AI Browser Tracking in 2026: What Web Analytics Can See

What AI browser tracking can and cannot see

Separate four kinds of AI-mediated activity

On-page assistance

Agent navigation

Remote retrieval

Answer without a visit

Which AI browsers matter in 2026?

Compare context, control, and data flow before choosing

Pageviews still work, but they mean less on their own

Attribution needs conservative labels

Can GA4 track AI browser traffic?

Critical events should be confirmed on the server

Do not turn every assisted session into a bot

A privacy-first measurement plan for AI browsers

Managed cloud or self-hosted analytics?

Test the browsers instead of assuming

What to watch over the next 6 to 12 months

A practical 30-day checklist

Where HitKeep fits

Read more

HitKeep 2.12.0: Team OIDC SSO, Invite-Aware Sign-In, And Routed Site Settings

What Shipped