User

What Analytics Can Not Do

Honest limitations of log-based analytics compared to JavaScript trackers.

Last updated 1775692800

Log-based analytics is the right choice for most hosting customers, but it's not magic — there are real things that JavaScript trackers can do that Opterius cannot. Be honest about the trade-offs.

Time on page

JavaScript trackers measure how long a visitor stayed on a page by firing events on the unload or visibilitychange browser event. Without that JavaScript, the server has no idea when a visitor stopped reading the page — it only sees the request that loaded the page.

Workaround: none. If you really need time-on-page metrics, you'd need a tracking script. For most use cases, the question "are visitors actually engaging?" can be answered by looking at the bounce rate (next item) and the chart of return visits.

True bounce rate

A "bounce" is when a visitor lands on a page and leaves without viewing anything else. JavaScript trackers compute this by checking whether a visitor's session contains exactly one page view.

Server-side, you can approximate it by measuring the ratio of unique IPs that only ever requested one page during the session. But there's no good definition of "session" without cookies — multiple visitors behind the same NAT will look like one IP, and a single visitor revisiting an hour later will look like a new session.

Workaround: none in v1. The aggregated bucket data doesn't preserve the "this IP visited these pages in this order" relationship that you'd need for accurate bounce calculation.

Click tracking

JavaScript trackers can attach click handlers to specific elements (download buttons, outbound links, conversion CTAs) and fire events when they're clicked. Server-side analytics only sees page loads and asset requests — it can't tell you which links visitors clicked.

Workaround: For outbound links, redirect them through a server-side endpoint. Instead of <a href="https://partner.com">, use <a href="/out?u=partner.com"> and have a tiny PHP script log the click then redirect. Those /out requests will then show up as visits in your Top Pages.

Form submission tracking

You can see POST requests in the access log so they show up in the visit counts, but you can't see whether the form succeeded, what fields were filled in, or where the visitor went next.

Workaround: For forms, log success/failure server-side from your application code (e.g., write to a custom log file). Or use a redirect-based pattern: form submission → success page → success page is tracked as a "thank you" URL.

Funnel and conversion tracking

A funnel measures: "of the visitors who saw page A, how many then saw page B, then page C?" This requires tracking individual visitors across pages, which Opterius doesn't do.

Workaround: For simple URL-based funnels, you can compare the visit counts of /landing-page vs /cart vs /checkout vs /thank-you over the same range. The ratios approximate a funnel even though they're not strictly per-visitor.

Custom events

JavaScript trackers let you fire arbitrary events: "user opened the menu", "user scrolled past the fold", "user played the video". Server-side analytics has no visibility into these — they happen entirely client-side.

Workaround: Send a tracking pixel: <img src="/pixel?event=video_played">. The /pixel request will be logged like any other URL and counted.

Visitor session tracking

JavaScript trackers use cookies (or local storage) to track a visitor across multiple sessions. "This is the same person who visited last week." Without cookies, every visit is anonymous.

This is the whole point. Opterius analytics is anonymous by design. If you need to track returning visitors as the same person, you need a JavaScript tracker — but you also need a cookie consent banner and a privacy policy update.

Real-time live visitor count

JavaScript trackers can show "12 visitors right now" because they have a long-lived connection to each visitor's browser. Opterius polls the agent every few seconds via the dashboard, but the underlying data is updated in 1-minute intervals (the log parser polling cadence). So "real-time" is closer to "1-minute lag".

For most use cases this is fine. If you need true real-time (sub-second latency), use SSH and tail -f /home/.../logs/access.log directly.

E-commerce / revenue tracking

JavaScript trackers can integrate with your shopping cart to record per-order revenue and ROI. Server-side analytics has no visibility into your cart contents.

Workaround: Most e-commerce platforms (WooCommerce, Magento, PrestaShop) write order events to their own database and have built-in reports. Use those, not analytics.

Why this list exists

Because the worst thing you can do with a feature like this is oversell it. Opterius analytics is better than AWStats for the basic stats and comparable to Plausible for traffic overview. It is not a replacement for Google Analytics 4 if you need custom events, conversion tracking, or A/B test integration.

Be honest with your customers about the trade-off. Most of them will pick "no consent banner, no JavaScript, no third-party data sharing" over "I can see how long visitors stay on each page."

When to add a JavaScript tracker on top

If you need any of the missing features, install a privacy-friendly JavaScript tracker like Plausible, Simple Analytics, or Umami. They coexist with Opterius — the log parser will keep working regardless. You'll just have two analytics dashboards.

For most hosting customers, Opterius is enough on its own.