Cursor Rules Template: Node.js Product Analytics with Events, Funnels, Retention, Cohorts

Overview

Cursor rules configuration for building a product analytics tool using Node.js and PostgreSQL, covering events, funnels, retention, cohorts, and user behavior dashboards. This Cursor Rules Template provides concrete instructions that you can paste into a .cursorrules file in your project root. Direct answer: This Cursor Rules Template configures a Node.js + PostgreSQL analytics backend to ingest events, compute funnels and retention, manage cohorts, and expose dashboards via a stable API, with production-ready patterns.

The template targets a traditional analytics stack: a Node.js backend written in TypeScript, PostgreSQL as the data store, and a lean data access layer with explicit SQL rather than heavy ORM coupling. It enforces safe query patterns, modular service boundaries, and Cursor AI assisted guidance for implementation details.

When to Use These Cursor Rules

When designing an event-driven analytics backend in Node.js
When modeling events, funnels, retention, and cohort analysis with SQL
When building dashboards that pull aggregated metrics from PostgreSQL
When you want a copyable .cursorrules configuration to drop into a project
When you need production-ready security, testing, and CI patterns baked in

Copyable .cursorrules Configuration

Framework Role & Context:
  - You are Cursor AI configured to assist Node.js + PostgreSQL product analytics backends.
  - You provide a copyable .cursorrules block that developers can paste into their project root.
  - You enforce strict typing, parameterized SQL, and test-driven development patterns.

Code Style and Style Guides:
  - Use TypeScript with strict mode; ESLint + Prettier; 2-space indentation; explicit types; no any.
  - Prefer named exports; keep modules small; use async/await; avoid callback hell.
  - All SQL must be parameterized; avoid string concatenation for queries.

Architecture & Directory Rules:
  - Separate backend into ingestion, analytics, and API layers.
  - Store events and derived analytics in PostgreSQL with clear schemas and partitioning by day.
  - Use a small data access layer (DAL) with prepared statements and a repository-like pattern.
  - Provide a shared utilities module for time, formatting, and metric calculations.

Authentication & Security Rules:
  - Use JWTs with RS256 or-audience scoped tokens; rotate keys via a secure vault.
  - Never log secrets; store credentials in environment variables; enable TLS for all services.
  - Validate inputs at API boundaries; implement rate limiting and IP allowlists where appropriate.

Database and ORM patterns:
  - PostgreSQL is the primary store; avoid heavy ORMs; use a lightweight DAL with parameterized SQL.
  - Migrations managed via a simple migration script; track schema versions.
  - Use index review on event_time, user_id, and relevant FK columns to optimize analytics queries.

Testing & Linting Workflows:
  - Unit tests for services and data access using a test DB; integration tests for ingestion paths.
  - End-to-end tests for core analytics flows; run via CI on push and PRs.
  - Lint and format on pre-commit; CI runs type-check and test suites; code coverage thresholds enforced.

Prohibited Actions and Anti-patterns for the AI:
  - Do not generate unsafe SQL or string concatenated queries.
  - Do not assume single-row results for multi-row analytics operations.
  - Do not bypass validation or security checks in API handlers.
  - Do not rely on a heavyweight ORM that hides SQL details or hurts query performance.
  - Do not store raw PII beyond what is strictly necessary; avoid insecure key storage.

Recommended Project Structure

Stack-specific directory tree for a Node.js + PostgreSQL product analytics backend.

project-root/
  backend/
    src/
      config/
      ingestion/
      analytics/
      db/
        migrations/
        sql/
      routes/
      services/
      workers/
    tests/
    .eslintrc.js
    .prettierrc
    tsconfig.json
    package.json

Core Engineering Principles

Data modeling focused on analytics queries with deterministic SQL paths
Strong typing and testability across services
Clear separation of ingestion, analytics, and API layers
Idempotent ingestion and replay-safe event processing
Observability: structured logging, metrics, and tracing
Security-by-default: least privilege, secret management, and TLS

Code Construction Rules

Implement services with small, pure functions and explicit interfaces
All database access must use a parameterized DAL; avoid dynamic SQL
Use migrations for schema changes; never alter tables at runtime without a migration
Ingest events via idempotent endpoints; deduplicate using a stable event_id
Query funnels, retention, and cohorts with well-indexed, SQL-native patterns
Write unit tests that mock DB interactions; integration tests hit a test DB
CI should run type-check, lint, test, and a quick build of the backend

Security and Production Rules

Enable TLS everywhere; rotate credentials and use a secret vault
Validate all input; apply rate limiting; monitor for anomalous ingestion patterns
Limit DB user privileges to required actions; use role-based access control
Back up analytics data and maintain restore procedures
Audit logs for API usage and data access

Testing Checklist

Unit tests for services and utilities
Integration tests for database access and ingestion paths
End-to-end tests for core analytics flows (ingest → transform → dashboard)
Performance tests for common funnels and cohort queries
CI checks: type-check, lint, tests, and a quick build

Common Mistakes to Avoid

Overusing ORMs that hide SQL and hurt analytics performance
Neglecting input validation and security in API endpoints
Ignoring indexing needs for event_time, user_id, and funnel keys
Skipping migrations and relying on ad-hoc schema changes
Assuming a single shard or fixed timezone for all data

Related Cursor rules templates

Explore adjacent Cursor rules templates for similar stacks, workflows, and production constraints.

FAQ

What is a Cursor Rules Template?

A Cursor Rules Template is a copyable .cursorrules configuration that guides Cursor AI in providing stack-specific rules, project structure recommendations, and actionable code guidance for a given technology stack. This template targets Node.js + PostgreSQL product analytics with events, funnels, retention, and dashboards.

Which stack does this template target?

This template targets a Node.js + PostgreSQL analytics backend, with TypeScript code, a lightweight data access layer using parameterized SQL, and a focus on events, funnels, retention, cohorts, and dashboards.

Can I paste the .cursorrules into an existing project?

Yes. The included guidelines are designed to be paste-friendly and non-destructive. Integrate the project structure, API contracts, and database patterns into your existing setup while preserving your existing authentication layer and deployment pipelines.

Does this template cover dashboards and cohorts?

Yes. The rules include data modeling, query patterns, and tooling guidance to support dashboards, cohort analysis, and funnel analytics using PostgreSQL.

How do I integrate Cursor AI with my Node.js app?

Install the Cursor AI integration, paste the .cursorrules block, and follow the generated guidance to implement the recommended architecture, queries, and tests. Cursor AI will adapt the rules to your repository layout and CI/CD pipeline.

Is there guidance for security and production readiness?

Yes. The template includes explicit security rules, secret management, TLS guidance, input validation, and production deployment considerations to reduce risk in analytics workloads.

Target User

Use Cases