How does Prelumen Analytics measure, and can it be wired in from our own backend?

You have three ways in and can combine them. The client script is picked per website as a profile: 1.037 KB gzip in minimal mode, 5.971 KB in standard mode with Core Web Vitals and engagement. Server-side, your backend posts pageviews and custom events to /track/{website-uuid}/api, passing the IP address and user agent from the server context; custom events carry an event_id for deduplication between browser and server. Identities have their own identify endpoint. Where no JavaScript can run, the pixel embed remains. Pirsch covers the same range: client script and server integration, there through official SDKs for JavaScript, Go and PHP, and in Prelumen Analytics through a documented HTTP call. So the way in is not what separates the two products.

How do revenue figures come about in the two products?

In Pirsch through custom events that your shop or backend sends itself: custom events and conversion goals are included on every plan, while analysis as custom metrics and e-commerce revenue tracking start with the Plus plan. In Prelumen Analytics the connected payment provider supplies the revenue figures. Revenue then comes out of the payment itself rather than out of a value your code sends along, attributed by source, page and campaign, in realtime, and per visitor only after opt-in per website. Per-step funnel drop-off, custom events and aggregated form friction over explicit form and field aliases round out the picture.

Pirsch shows keywords from Google Search Console. Is that available in Prelumen Analytics?

No. Pirsch connects Search Console via OAuth and shows a keywords panel in the dashboard from it that also works as a filter; that data does not arrive in realtime. Prelumen Analytics has no Search Console connection and no keyword data. The SEO side is covered through recurring checks: on-page quality, structured data, entity signals and machine readability, with findings carrying on as prioritizable issues. If keyword analysis in the analytics dashboard is part of your daily routine, that is a clear point for Pirsch.

Both measure without cookies. Where do the setups differ?

Pirsch describes its recognition as a hash of IP address, user agent, date and a per-website salt, states that it does not store the IP address, positions the measurement as banner-free, and hosts on a server cluster in Germany. Prelumen Analytics runs cookie-free in its default mode, processes and hosts in the EU, respects DNT/GPC by default, and keeps the person-level view off out of the box and enabled per website. How that plays out legally comes down to the implementation and the legal context in either setup.

What happens to our data if we move away from Pirsch?

The reports stay in Pirsch, and you can pull a CSV export there for the last twelve months. Prelumen Analytics counts from the day measurement goes live and builds its own time series from there, so there is no import of Pirsch history. Running both systems side by side for a while is the usual way to reconcile the numbers and keep the switch under control.

Pirsch Alternative

Pirsch pulls revenue from your events. Prelumen from the payment itself.

Both measure cookie-free, in the browser or from your backend. Pirsch also sells a license for your own data center; Prelumen is managed EU SaaS with recurring checks and prioritized issues.

Start where you can stay.

Analytics history rarely moves cleanly between products. Start free with the system that already has the next layer built in: revenue attribution and funnels as well as audits, issues and verifiable proof when you need them.

Free isn’t a trial mode. It’s the product, in small.

Start for free Plans and Pricing

Choose by fit

Cookie-free measurement, a lean script, a tidy dashboard and the choice between collecting in the browser or from your own backend: both products deliver that. The decision therefore comes down to two other things: how the service is procured, and how much carries on inside the same product after measurement.

Prelumen Analytics is a fit when

Revenue should come out of the connected payment rather than out of a value your code attaches to an event.
Accessibility, security, privacy, SEO/GEO, content and carbon should run on fixed check intervals, in the same account that does the measuring.
Findings should carry on as prioritizable issues with incident alerts instead of ending as a report.
A native MCP server should give your agents direct access to traffic, check results and open issues, without a detour through exports.

Pirsch Analytics is a fit when

An installation in your own data center is settled, and it should run under a commercial enterprise license with vendor support rather than as a self-owned open-source project.
SAML single sign-on is mandatory because analytics access is tied to central identity management in your organization.
Contractually guaranteed access to the raw analytics data is a procurement criterion and has to be in the license agreement.

Capability comparison

Cookie-free collection, a lean script and a tidy dashboard are a given in both products, and so is the choice between browser-side and server-side collection. The rows show how the service is procured and which layers sit above it.

Focus area	Prelumen Analytics	Pirsch Analytics
Operating model	Analytics, revenue attribution, diagnostics and issue workflow as one managed operations layer in the EU	Cookie-free web analytics focused on traffic, campaigns and conversion goals
Integration path	Client script with a measurement profile you pick per website, server-side API tracking through POST /track/{website-uuid}/api with ip and user_agent passed in, plus pixel embedding	Client script, WordPress plugin or server integration through the API and SDKs, officially for JavaScript, Go and PHP
Revenue and conversion	Revenue by source, page and campaign in realtime once your payment provider is connected; funnels, custom events, form friction	Conversion goals and custom events on every plan; e-commerce revenue through events you send yourself and custom metrics from the Plus plan up
Privacy baseline	Cookie-free default, EU processing and hosting, DNT/GPC respected by default	Cookie-free measurement with a server cluster in Germany
Daily simplicity	A tidy analytics dashboard as the default view, set up in a few minutes; check results and issues have their own navigation entries	A tidy analytics dashboard with filters, saved views and rollup views
Diagnostics scope	Built-in checks for quality, security, accessibility, privacy, SEO/GEO, content and carbon, as subscriptions on fixed intervals	Web analytics as the product focus; audits for accessibility, security, privacy or carbon are not listed
Action after insight	Every finding becomes an issue with incident alerts: weighted by page hits from the last 30 days and resolved or ignored across every affected URL in one step	Analysis in the dashboard, plus email reports, traffic spike and traffic drop notifications and webhooks; follow-through in your own process
AI agent access	Native MCP server across traffic, check, compliance, carbon and issue data, on selected plans	Agent access through the REST API; the docs mark the MCP integration as a community project without vendor support
API surface	REST API + MCP on selected plans	REST API in versions 1 and 2, plus native webhooks and script proxies
Procurement model	Managed EU SaaS: operation, updates and scaling stay with the vendor; you pick the measurement profile per website	SaaS plans plus a commercial enterprise license for on-premise or managed-cloud installation with SAML SSO, raw data access, personal onboarding and dedicated support
Entry cost	Free plan to start; upgrade when you need more	Paid product with a 30-day trial to start
Best-fit profile	Teams running traffic, revenue, check results and follow-up work off the same signals	Teams whose procurement calls for a licensed installation in their own data center with vendor support

Decision guide

There is little to decide about measurement itself: cookie-free, in realtime, in the browser or from the backend, both can do it. What tips the decision is how the service is procured, and whether revenue, checks and follow-up work belong in the same product.

Choose Prelumen

when cookie-free measurement should also bring revenue from the connected payment, fixed check intervals, prioritized issues and a native MCP server.

Choose Pirsch

when procurement calls for an on-premise installation under a commercial enterprise license with vendor support, SAML SSO and contractual raw data access.

Settle the procurement frame first

when cookie-free measurement is settled but it is still open whether analytics is bought as SaaS or has to be installed in your own data center.

Frequently Asked Questions

How does Prelumen Analytics measure, and can it be wired in from our own backend?: You have three ways in and can combine them. The client script is picked per website as a profile: 1.037 KB gzip in minimal mode, 5.971 KB in standard mode with Core Web Vitals and engagement. Server-side, your backend posts pageviews and custom events to /track/{website-uuid}/api, passing the IP address and user agent from the server context; custom events carry an event_id for deduplication between browser and server. Identities have their own identify endpoint. Where no JavaScript can run, the pixel embed remains. Pirsch covers the same range: client script and server integration, there through official SDKs for JavaScript, Go and PHP, and in Prelumen Analytics through a documented HTTP call. So the way in is not what separates the two products.
How do revenue figures come about in the two products?: In Pirsch through custom events that your shop or backend sends itself: custom events and conversion goals are included on every plan, while analysis as custom metrics and e-commerce revenue tracking start with the Plus plan. In Prelumen Analytics the connected payment provider supplies the revenue figures. Revenue then comes out of the payment itself rather than out of a value your code sends along, attributed by source, page and campaign, in realtime, and per visitor only after opt-in per website. Per-step funnel drop-off, custom events and aggregated form friction over explicit form and field aliases round out the picture.
Pirsch shows keywords from Google Search Console. Is that available in Prelumen Analytics?: No. Pirsch connects Search Console via OAuth and shows a keywords panel in the dashboard from it that also works as a filter; that data does not arrive in realtime. Prelumen Analytics has no Search Console connection and no keyword data. The SEO side is covered through recurring checks: on-page quality, structured data, entity signals and machine readability, with findings carrying on as prioritizable issues. If keyword analysis in the analytics dashboard is part of your daily routine, that is a clear point for Pirsch.
Both measure without cookies. Where do the setups differ?: Pirsch describes its recognition as a hash of IP address, user agent, date and a per-website salt, states that it does not store the IP address, positions the measurement as banner-free, and hosts on a server cluster in Germany. Prelumen Analytics runs cookie-free in its default mode, processes and hosts in the EU, respects DNT/GPC by default, and keeps the person-level view off out of the box and enabled per website. How that plays out legally comes down to the implementation and the legal context in either setup.
What happens to our data if we move away from Pirsch?: The reports stay in Pirsch, and you can pull a CSV export there for the last twelve months. Prelumen Analytics counts from the day measurement goes live and builds its own time series from there, so there is no import of Pirsch history. Running both systems side by side for a while is the usual way to reconcile the numbers and keep the switch under control.

Revenue Analytics

Traffic is just a metric. Revenue is what matters.

To Revenue Analytics

Customer Journeys

Understand behavior before conversion.

To Customer Journeys

Privacy Analytics

Privacy-first analytics without flying blind.

To Privacy Analytics

Measuring cookie-free is the start, not the result.

Use Prelumen Analytics when the same cookie-free measurement, in the browser, from the backend or through a pixel, should also produce revenue attribution, recurring checks and prioritized issues.