[CI] (362fa9c) django/django3-saas

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: 362fa9c
App: django/django3-saas
App directory: apps/django/django3-saas
Workbench branch: wizard-ci-362fa9c-django-django3-saas
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-02-11T17:25:10.539Z
Duration: 402.0s

[wizard-ci-bot]

Now I have all the information I need to complete the evaluation. Let me produce the PR evaluation report:

---

PR Evaluation Report

Summary

This PR adds comprehensive PostHog analytics integration to a Django SaaS application. It implements server-side event tracking for authentication flows, subscription/billing events, and project CRUD operations using PostHog's Python SDK v7+ context-based API. The integration follows Django best practices with AppConfig initialization.

Files changed	Lines added	Lines removed
7	+363	-6

Confidence score: 4/5 👍

• Missing environment variable documentation: The .env.example file was not updated to include POSTHOG_API_KEY, POSTHOG_HOST, and POSTHOG_DISABLED variables. This will cause confusion for developers setting up the project. [MEDIUM]
• No reverse proxy configured: Events are sent directly to us.i.posthog.com without an adblock-circumventing reverse proxy, which may result in lost events from users with ad blockers. [MEDIUM]
• PII in person properties: Email addresses are being stored as person properties via tag(). While this is intentional for identification, teams should verify this aligns with their data privacy policies. [LOW]

---

File changes

Filename	Score	Description
accounts/apps.py	5/5	New file - correctly initializes PostHog in Django's AppConfig.ready() method with proper configuration from Django settings, including disable flag support and debug mode
accounts/views.py	5/5	Adds PostHog tracking to login, logout, registration, profile update, and password reset flows with proper user identification and person properties
billing/views.py	5/5	Comprehensive subscription lifecycle tracking including checkout, subscription start, plan changes, cancellation, and payment failures. Includes exception capture for Stripe errors
config/settings.py	4/5	Adds PostHog middleware and configuration settings. Updated app reference to use AccountsConfig. Environment variables properly read from env
dashboard/views.py	5/5	Adds project CRUD event tracking with relevant properties like project counts and field changes
requirements.txt	5/5	Adds posthog dependency
posthog-setup-report.md	4/5	Comprehensive documentation of the integration, though claims .env was modified which is not in the committed diff

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Standard Django patterns, no syntax errors, valid imports
Preserves existing env vars & configs	Yes	All existing settings preserved, PostHog config added alongside existing Stripe config
No syntax or type errors	Yes	Clean Python syntax throughout
Correct imports/exports	Yes	PostHog SDK imports are correct for v7+ context API
Minimal, focused changes	Yes	Changes are surgical - only adding PostHog tracking without modifying existing business logic

Issues

• Missing .env.example update: The .env.example file does not include POSTHOG_API_KEY, POSTHOG_HOST, or POSTHOG_DISABLED variables. Developers following standard setup would miss these required configurations. Update .env.example to include the new PostHog environment variables with placeholder values. [MEDIUM]

Other completed criteria

• Clear, readable code with helpful comments
• Consistent with existing Django patterns in the codebase
• Appropriate error handling with exception capture
• Environment variables used for configuration (not hardcoded)
• Build configuration is valid

---

PostHog implementation: 4/5 ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog package added to requirements.txt
PostHog client initialized	Yes	Initialized in AccountsConfig.ready() with API key and host from Django settings; PosthogContextMiddleware added to middleware stack
capture()	Yes	13 distinct events captured across authentication, billing, and project modules
identify()	Yes	identify_context() called with str(user.id) as distinct_id; person properties set via tag()
Error tracking	Yes	posthog.capture_exception(e) called for all Stripe API errors (6 locations)
Reverse proxy	No	Events sent directly to us.i.posthog.com; no reverse proxy configured

Issues

• No reverse proxy: Events are sent directly to PostHog without a reverse proxy to circumvent ad blockers. While this is less critical for server-side Python SDK than client-side JS, the Django app may have mixed client/server needs. Consider documenting this limitation or adding reverse proxy guidance. [MEDIUM]

Other completed criteria

• API key sourced from environment variable (POSTHOG_API_KEY)
• Host correctly configurable via POSTHOG_HOST env var with sensible default
• Disable flag available via POSTHOG_DISABLED for testing
• Debug mode enabled in development (when DEBUG=True)
• Proper use of new_context() blocks for the Python SDK v7+ context API
• Person properties set correctly using tag() function
• No hardcoded API keys or secrets

---

PostHog insights and events: 5/5 ✅

Filename	PostHog events	Description
accounts/views.py	user_signed_up, user_logged_in, user_logged_out, profile_updated, password_reset_requested	Full authentication lifecycle tracking with signup method, login method, and field change tracking
billing/views.py	checkout_started, subscription_started, subscription_plan_changed, subscription_canceled, payment_failed, capturedException	Complete subscription funnel tracking with plan details, pricing, upgrade/downgrade classification, and payment mode (Stripe vs demo). Exception capture on Stripe errors
dashboard/views.py	project_created, project_updated, project_deleted	Project CRUD tracking with relevant properties like total project count and changed fields

Issues

None. The event schema is well-designed for product analytics.

Other completed criteria

• Events represent real user actions (signup, login, subscribe, create project)
• Events capture key product flows (signup → checkout → subscription funnel)
• Events capture friction points (payment failures, cancellations)
• Properties enable segmentation (plan name, plan price, payment mode)
• Properties enable funnel analysis (upgrade vs downgrade, subscription duration)
• No PII in event properties (PII correctly placed in person properties via tag())
• Properties have appropriate types (strings, booleans, numbers)

---

Reviewed by wizard workbench PR evaluator