3 posts tagged with "Analytics"

When you put product analytics, uptime monitoring, and server health on the same observability surface, you find issues faster, iterate more confidently, and make the right calls within privacy and compliance boundaries. Tianji combines Website Analytics + Uptime Monitor + Server Status into one platform, giving teams end‑to‑end insights with a lightweight setup.

Why an all‑in‑one observability layer​

• Fewer context switches: From traffic to availability without hopping across tools.
• Unified semantics: One set of events and dimensions; metrics connect across layers.
• Privacy‑first: Cookie‑less by default, with IP truncation, minimization, and aggregation.
• Self‑hosting optional: Clear boundaries to meet compliance and data residency needs.

The signals you actually need​

• Product analytics: Pageviews, sessions, referrers/UTM, conversions and drop‑offs on critical paths.
• Uptime monitoring: Reachability, latency, error rates; sliced by region and ISP.
• Server health: CPU/memory/disk/network essentials with threshold‑based alerts.
• Notification & collaboration: Route via Webhook/Slack/Telegram, with noise control.

How Tianji delivers it​

Tianji ships three capabilities in one platform:

1. Website analytics: Lightweight script, cookie‑less collection; default aggregation and retention policies.
2. Uptime monitoring: Passive/active compatible, with built‑in status pages and regional views.
3. Server status: Unified reporting and visualization; open APIs for audits and export.

Privacy by design is on by default: IP truncation, geo mapping, and minimal storage, with options for self‑hosting and region‑pinned deployments.

3‑minute quickstart​

wget https://raw.githubusercontent.com/msgbyte/tianji/master/docker-compose.yml
docker compose up -d

The default account is admin/admin. Change the password promptly and set up your first site and monitors.

Common rollout patterns​

• Small teams/indies: Single‑host self‑deployment with out‑of‑the‑box end‑to‑end signals.
• Mid‑size SaaS: Consolidate funnels, SLAs, and server alerts into a single alerting layer to cut false positives.
• Open‑source self‑host: Public status pages outside, fine‑grained metrics and audit‑friendly exports inside.

Best‑practice checklist​

• Define 3–5 critical funnels and track only decision‑relevant events.
• Enable IP truncation and set retention (e.g., 30 days for raw events, 180 days for aggregates).
• Use referrer/UTM cohorts for growth analysis; avoid individual identification.
• Separate public status pages from internal alerts to reduce exposure.
• Review monthly: decision value vs. data cost — trim aggressively.

Closing​

Seeing product and reliability on the same canvas is a more efficient way to collaborate. With Tianji, teams get fewer‑noise, action‑ready signals — all with privacy and compliance first.

Most teams want trustworthy product signals without shadow‑tracking their users. This post outlines how to run a privacy‑first analytics stack that is cookie‑less, IP‑anonymized, and compliant by default — and how Tianji helps you ship that in minutes.

What “privacy‑first” really means​

• No third‑party cookies or fingerprinting
• IP and geo anonymization at ingestion time
• Minimization and aggregation by default (store only what you act on)
• Short retention windows with configurable TTLs
• Clear data governance: self‑hosted or region‑pinned

Privacy is not the absence of insight. It is the discipline to collect the minimum, aggregate early, and keep identities out of the loop unless users explicitly consent.

What you still get (and need) for product decisions​

• Page views, sessions, referrers, UTM cohorts (sans cookies)
• Conversion funnels and drop‑offs on critical paths
• Lightweight event telemetry for product behaviors
• Country/region trends with differential privacy techniques
• Content insights that help editorial and SEO without tracking people

How Tianji implements privacy by design​

Tianji bundles Website Analytics + Uptime Monitor + Server Status into one platform, so you get product and reliability signals together — without data sprawl.

1. Cookie‑less tracking script with hashing and salt rotation
2. IP truncation and geo mapping via in‑house database
3. Aggregation and TTL policies at the storage layer
4. Self‑host, air‑gapped, or region‑pinned deployments
5. Open APIs and export for audits

See docs: Website Tracking Script, Telemetry Intro, and Server Status Reporter.

Deployment options (pick your trust boundary)​

• Self‑host with Docker Compose for full data control
• Region‑pinned cloud install if you prefer managed ops
• Hybrid: analytics in‑house, public status pages outside

Install in minutes:

wget https://raw.githubusercontent.com/msgbyte/tianji/master/docker-compose.yml
docker compose up -d

Default account is admin/admin — remember to change the password.

Policy templates you can copy​

Use these defaults to start, then tighten as needed:

• Retention: 30 days for raw events, 180 days for aggregates
• IP handling: drop last 2 octets (IPv4) or /64 (IPv6)
• PII: deny‑list at ingestion; allow only hashed user IDs under consent
• Geography: pin storage to your primary user region
• Access: least privilege with audit logging enabled

Implementation checklist​

• Map your product’s critical funnels and decide what to measure
• Deploy Tianji with cookie‑less website tracking and telemetry events
• Turn on IP truncation, geo anonymization, and retention TTLs
• Build cohorts by campaign and page groups, not people
• Review monthly: decision value vs. data cost — trim aggressively

Closing​

Privacy‑first analytics is not just possible — it’s the default you should expect. With Tianji, you get actionable product and reliability signals without surveilling users. Less creepiness, more clarity.

When you just need to confirm real visitor volume without heavy SDKs, cookies, or complex pipelines, a 1x1 pixel or a minimal request is enough. Tianji supports this lightweight telemetry pattern to help you validate traffic safely and reliably.

What This Telemetry Is (and Is Not)​

• It is a simple “signal” that a human likely visited a page or executed an action.
• It is not OpenTelemetry, tracing, or deep behavioral analytics.
• It favors privacy and performance over granularity.

Common use cases:

• Confirming documentation traffic and marketing landing page reach
• Basic pageview counting for self-hosted sites
• Minimal conversion confirmation (e.g., signup success page)

Option 1: Image Pixel (No JavaScript)​

Embed a 1x1 pixel that calls your collector endpoint. The server increments counters based on request metadata.

<!-- Simple pixel beacon: uses GET and works without JS -->
<img
  src="https://your-domain.example/api/telemetry/pixel?site=docs&path=/getting-started&ts=1690000000000"
  width="1"
  height="1"
  alt=""
  referrerpolicy="strict-origin-when-cross-origin"
  loading="eager"
/>

Server recommendations:

• Count unique visits by a rolling fingerprint from IP range + User-Agent + truncated time bucket
• Return Cache-Control: no-store to avoid CDN/browser caching
• Use 204 No Content and a tiny transparent GIF/PNG if needed

Option 2: Minimal Request (sendBeacon/fetch)​

When JavaScript is available, a tiny request provides more control and better delivery on page unload.

<script>
  // Use sendBeacon when available to improve delivery on unload
  (function () {
    var url = 'https://your-domain.example/api/telemetry/hit';
    var payload = JSON.stringify({ site: 'docs', path: location.pathname });
    if (navigator.sendBeacon) {
      navigator.sendBeacon(url, payload);
    } else {
      // Fallback: fire-and-forget fetch
      fetch(url, {
        method: 'POST',
        body: payload,
        headers: { 'Content-Type': 'application/json' },
        keepalive: true
      });
    }
  })();
  // Note: No cookies, no localStorage. Keep it privacy-friendly.
</script>

Server recommendations:

• Accept both POST (JSON) and GET (query) to handle blockers
• Normalize UA strings and drop high-cardinality parameters
• Apply bot heuristics and basic rate limits

Avoiding Caching Pitfalls​

• Add Cache-Control: no-store and Pragma: no-cache on responses
• For pixel GETs, include a timestamp ts=<epoch> to bust intermediary caches
• On CDNs, bypass cache for /api/telemetry/* paths

What You Can Measure Reliably​

• Pageviews and unique visitors (coarse, privacy-preserving)
• Per-path popularity (docs, blog posts, landing pages)
• Simple conversions (e.g., reached thank-you page)

What you should not infer:

• Precise user identity or cross-device journeys
• Detailed event streams or UI heatmaps

How This Works with Tianji​

• Use the pixel or minimal request to send pageview signals into Tianji
• Correlate traffic with uptime, response time, and incidents in a single view
• Keep data ownership: self-hosted, lightweight, and privacy-aware

Useful docs:

• Telemetry intro: https://tianji.msgbyte.com/docs/telemetry/intro
• Website tracking script: https://tianji.msgbyte.com/docs/website/track-script
• Feed concepts: /docs/feed/intro, /docs/feed/state, /docs/feed/channels

Key Takeaways​

1. A 1x1 pixel or a tiny request is enough to confirm real visitor volume.
2. Prefer privacy-friendly defaults: no cookies, no local storage, no PII.
3. Control caching aggressively to avoid undercounting.
4. Use sendBeacon/fetch for reliability; fall back to pixel when JS is blocked.
5. Pipe signals into Tianji to see traffic alongside uptime and performance.

Lightweight telemetry gives you the truth you need—no more, no less—while keeping users fast and private.