Privacy-First Analytics for Dev Tools

Developers are the hardest audience to track and the most likely to block your tracking. They use ad blockers, they read your source code, they notice tracking scripts, and they will call you out publicly if your analytics are invasive. If you are building developer tools, your analytics strategy needs to respect this reality.

Privacy-first analytics is not about collecting less data. It is about collecting the right data without crossing the line into surveillance. You can understand your product, measure your funnel, and improve your UX without knowing who your users are, where they live, or what they had for breakfast.

Key Takeaways

• Aggregate data answers most product questions -- you rarely need individual user tracking to make product decisions
• Cookie-free analytics survive ad blockers because most blockers target cookie-based tracking scripts
• Server-side event collection is more reliable than client-side and avoids the consent banner problem entirely
• Hash-based user identification provides session continuity without storing PII -- you know it is the same visitor, not who the visitor is
• Open-source analytics tools (Plausible, Umami, PostHog) have matured enough to replace Google Analytics for most use cases

Why Google Analytics Fails for Dev Tools

Google Analytics is the default choice for web analytics, and it is the wrong choice for developer tools. Here is why.

Blocked by default. Over 40% of developers use ad blockers that block Google Analytics. Your data is missing nearly half your audience. Every metric is wrong by a significant, unknown margin.

Requires cookie consent. GDPR and similar regulations require consent for tracking cookies. The consent banner irritates users and reduces engagement. Many developers refuse consent, further skewing your data.

Collects PII you do not need. GA collects IP addresses, device fingerprints, and browsing patterns across sites. For a developer tool, you need to know which features are used, not who uses them.

Sends data to Google. Developer-focused companies that send user data to Google face reputational risk. Developers notice and they care.

Architecture: Server-Side Event Collection

The privacy-first approach collects events on your server, not in the user's browser. No client-side script means nothing to block, no cookies to consent to, and no PII to leak.

// lib/analytics/track.ts
interface AnalyticsEvent {
  event: string
  properties: Record<string, string | number | boolean>
  timestamp: string
  sessionHash: string  // Hashed, not identifiable
  pageUrl: string      // Path only, no query params with PII
}

export async function trackEvent(
  event: string,
  properties: Record<string, string | number | boolean>,
  request: Request
): Promise<void> {
  const sessionHash = createSessionHash(request)
  const url = new URL(request.url)
  
  const analyticsEvent: AnalyticsEvent = {
    event,
    properties,
    timestamp: new Date().toISOString(),
    sessionHash,
    pageUrl: url.pathname,  // No query params
  }
  
  await storeEvent(analyticsEvent)
}

function createSessionHash(request: Request): string {
  // Hash of IP + User-Agent + date (rotates daily)
  const date = new Date().toISOString().split('T')[0]
  const raw = `${getClientIP(request)}|${request.headers.get('user-agent')}|${date}`
  return hashSHA256(raw)
}

Why Session Hashing Works

The session hash combines the visitor's IP address, user agent, and current date into a one-way hash. This gives you session continuity (multiple page views from the same visitor in the same day are grouped) without storing the IP address or creating a persistent identifier.

Key properties:

• Not reversible. You cannot reconstruct the IP or user agent from the hash.
• Not persistent. The hash changes daily, so you cannot track users across days.
• Not cross-site. The hash is specific to your application.

This is enough to answer "how many pages did the average visitor view today?" without answering "who is this person and what did they do last week?"

What to Track (And What Not To)

Track: Feature Usage

// In your server action or API route
await trackEvent('skill_installed', {
  skillType: skill.type,
  category: skill.category,
  source: 'browse_page',
})

await trackEvent('search_performed', {
  hasResults: results.length > 0,
  filterCount: activeFilters.length,
  resultCount: results.length,
})

Feature usage data tells you what parts of your product are valuable. You do not need to know who used the feature -- just that it was used, how often, and in what context.

Track: Performance Metrics

await trackEvent('page_load', {
  path: '/browse',
  loadTimeMs: Date.now() - startTime,
  deviceType: isMobile(request) ? 'mobile' : 'desktop',
})

Performance data helps you prioritize optimization work. Again, aggregate data is sufficient. You need "the browse page takes 2.3 seconds on mobile" not "user X on their iPhone 14 waited 2.3 seconds."

Track: Conversion Events

await trackEvent('skill_submitted', {
  step: 'form_completed',
  fieldCount: filledFields.length,
})

Conversion tracking tells you where users drop off in your funnel. Track the steps, not the users.

Do NOT Track

• User identifiers. No email, no username, no account ID in analytics events.
• Content of user input. Do not log what users searched for, typed, or submitted. Log that they searched, not what they searched for.
• External referrers. Knowing someone came from a specific URL can be identifying. Track the referrer domain only.
• Precise location. Country is usually sufficient. City-level geo is unnecessary for product decisions and approaches PII.

Self-Hosted Options

Three self-hosted analytics tools are mature enough for production use.

Plausible Analytics

Lightweight, cookie-free, GDPR-compliant out of the box. The dashboard is simple and focused. Self-hosting costs about $5/month on a small VPS.

# Docker deployment
docker run -d \
  --name plausible \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://... \
  -e SECRET_KEY_BASE=$(openssl rand -hex 32) \
  plausible/analytics

Best for: Simple websites and landing pages where you need page views, referrers, and basic event tracking.

Umami

Open-source, privacy-focused, with a more detailed feature set than Plausible. Supports custom events, funnels, and retention analysis.

Best for: Applications where you need event tracking and funnel analysis beyond basic page views.

PostHog

The most feature-rich option. Includes analytics, session replay (privacy settings needed), feature flags, and A/B testing. Self-hosted version is free for reasonable usage.

Best for: Teams that want a full product analytics suite without sending data to third parties.

Implementation: Next.js Server-Side Analytics

Here is a complete implementation for a Next.js application using server-side event collection with Supabase as the storage backend.

// lib/analytics/server.ts
import { createServerClient } from '@/lib/supabase/server'

interface Event {
  name: string
  properties: Record<string, unknown>
  path: string
  session_hash: string
  created_at: string
}

export async function track(
  name: string, 
  properties: Record<string, unknown> = {},
  request?: Request
) {
  const supabase = createServerClient()
  
  const event: Event = {
    name,
    properties,
    path: request ? new URL(request.url).pathname : 'unknown',
    session_hash: request ? hashSession(request) : 'server',
    created_at: new Date().toISOString(),
  }
  
  // Fire and forget -- analytics should never block the response
  supabase.from('analytics_events').insert(event).then()
}

// Usage in a Server Component
import { track } from '@/lib/analytics/server'
import { headers } from 'next/headers'

export default async function BrowsePage() {
  const headersList = await headers()
  await track('page_view', { page: 'browse' })
  
  // ... rest of the page
}

// Usage in a Server Action
'use server'
import { track } from '@/lib/analytics/server'

export async function installSkill(skillId: string) {
  await track('skill_installed', { skillId })
  // ... installation logic
}

For more on building privacy-aware AI applications, see our guide on privacy-first logging.

Querying Your Analytics

With events stored in Supabase, you can query them directly with SQL.

-- Daily active sessions (not users, sessions)
SELECT 
  DATE(created_at) as day,
  COUNT(DISTINCT session_hash) as sessions
FROM analytics_events
WHERE created_at > NOW() - INTERVAL '30 days'
GROUP BY day
ORDER BY day;

-- Most used features
SELECT 
  name,
  COUNT(*) as event_count
FROM analytics_events
WHERE created_at > NOW() - INTERVAL '7 days'
GROUP BY name
ORDER BY event_count DESC;

-- Conversion funnel
SELECT 
  name,
  COUNT(DISTINCT session_hash) as sessions
FROM analytics_events
WHERE name IN ('browse_page_view', 'skill_detail_view', 'install_clicked', 'install_completed')
AND created_at > NOW() - INTERVAL '7 days'
GROUP BY name;

FAQ

Will privacy-first analytics give me enough data to make product decisions?

Yes. Most product decisions require aggregate trends, not individual user behavior. "Feature X is used 3x more than Feature Y" and "30% of visitors leave after the search page" are actionable insights that do not require user-level tracking.

How do I handle attribution without cookies?

First-touch attribution based on referrer domain is possible without cookies. For multi-touch attribution, accept that you will have less precision. In practice, developer tools grow through word of mouth and content marketing, where precise attribution is less important than overall trend tracking.

Is this approach GDPR compliant?

Server-side, cookie-free analytics with no PII collection is GDPR-compliant without requiring consent banners. However, consult a legal professional for your specific situation. The legal landscape varies by jurisdiction.

Can I use this alongside Google Analytics?

Yes, but it defeats the purpose. If you are running GA alongside privacy-first analytics, GA is still tracking your users. The point is to replace GA, not supplement it.

What about tracking retention and cohorts?

Hash-based session IDs rotate daily, so you cannot track individual user retention. You can track aggregate retention through other signals: returning IP ranges (hashed), feature usage patterns over time, and login-based metrics for authenticated users who have consented.

Explore production-ready AI skills at aiskill.market/browse or submit your own skill to the marketplace.

Sources

• Plausible Analytics - Privacy-focused, cookie-free web analytics
• Umami - Open-source self-hosted analytics
• GDPR and Analytics - Legal basis for data processing
• PostHog Open Source - Self-hosted product analytics suite