[CI] (e08800d) django/django3-saas

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: e08800d
App: django/django3-saas
App directory: apps/django/django3-saas
Workbench branch: wizard-ci-e08800d-django-django3-saas
Wizard branch: main
Examples branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-22T20:17:53.376Z
Duration: 324.3s

[wizard-ci-bot]

Now I have all the information needed. Let me write the evaluation report.

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Django SaaS application. It adds SDK initialization via AppConfig.ready(), configures middleware for context tracking, implements user identification and event tracking across authentication, billing, and project management flows, and captures exceptions for error tracking.

Files changed	Lines added	Lines removed
7 (committed)	+340	-5

Confidence score: 4/5 👍

• API key exposed in setup report: The posthog-setup-report.md file contains a hardcoded API key (phc_sBGFIjin7AfcLwLJ4yc79wY84KHkvrTw5SnUeKD0SWE). While project API keys are not secret, including them in committed documentation is poor practice. [MEDIUM]
• No reverse proxy configured: No reverse proxy setup to circumvent ad-blockers when sending events to PostHog. This reduces data quality for users with ad-blockers. [MEDIUM]
• .env.example not updated: The .env.example file was not updated to include POSTHOG_API_KEY and POSTHOG_HOST environment variables, making it harder for other developers to know what's required. [LOW]

---

File changes

Filename	Score	Description
accounts/apps.py	5/5	New file implementing PostHog initialization via Django's AppConfig.ready() pattern. Correctly imports inside the method, configures API key/host from settings, and handles disabled/debug modes.
accounts/views.py	5/5	Adds PostHog tracking for login, logout, signup, password reset, and profile update. Uses correct context-based v7+ API with new_context(), identify_context(), tag(), and capture(). PII properly placed in tag() not event properties.
billing/views.py	5/5	Comprehensive billing event tracking including subscription creation, plan changes, cancellation, checkout completion, and payment failures. Exception capture via posthog.capture_exception() for all error paths. Both demo mode and Stripe mode covered.
config/settings.py	5/5	Correctly adds PostHog middleware (PosthogContextMiddleware), updates INSTALLED_APPS to use AccountsConfig, and adds environment variable configuration for API key, host, and disabled flag.
dashboard/views.py	5/5	Adds event tracking for project CRUD operations with relevant properties (project_id, name, total_projects count).
requirements.txt	5/5	Adds posthog dependency.
posthog-setup-report.md	3/5	Comprehensive documentation but contains hardcoded API key which should not be committed.

---

App sanity check: 5/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Django system check passes with no issues. All Python files pass syntax validation.
Preserves existing env vars & configs	Yes	Existing settings preserved; only additions made for PostHog configuration.
No syntax or type errors	Yes	All modified Python files compile successfully.
Correct imports/exports	Yes	All imports are valid; uses correct Python SDK v7+ context-based API.
Minimal, focused changes	Yes	Changes are targeted to PostHog integration only. No unnecessary modifications.

Issues

• .env.example not updated: The example environment file lacks PostHog variables, which could cause confusion for new developers. [LOW]

Other completed criteria

• Clear, readable code with helpful docstrings
• Consistent with existing Django patterns (class-based views, decorators)
• Appropriate error handling (try/except blocks with capture_exception)
• Build configuration (requirements.txt) is valid

---

PostHog implementation: 4/5 ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog added to requirements.txt
PostHog client initialized	Yes	Initialized in AccountsConfig.ready() with API key and host from settings. Also includes PosthogContextMiddleware in middleware stack.
capture()	Yes	13 distinct events captured across authentication, billing, and project management flows
identify()	Yes	Uses identify_context(str(user.id)) within new_context() blocks - correct v7+ pattern
Error tracking	Yes	posthog.capture_exception(e) used for all payment/webhook errors
Reverse proxy	No	No reverse proxy configured to circumvent ad-blocker issues

Issues

• No reverse proxy: Events sent directly to us.i.posthog.com will be blocked by ad-blockers, reducing data quality. Consider adding a Django reverse proxy view or using a separate proxy service. [MEDIUM]
• API key in setup report: The posthog-setup-report.md contains a hardcoded API key. Should reference environment variable only. [MEDIUM]

Other completed criteria

• API key correctly loaded from environment variable (not hardcoded in code)
• Correct API host configuration (POSTHOG_HOST with sensible default)
• No PII in event properties (email/name correctly placed in tag() calls)
• Middleware setup for automatic context tracking
• Disable flag available for testing (POSTHOG_DISABLED)
• Debug mode enabled in development

---

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 funnel coverage with signup method, login method, and profile update field tracking
billing/views.py	subscription_created, subscription_plan_changed, subscription_canceled, checkout_completed, payment_failed, capture_exception	Complete subscription lifecycle tracking with plan names, prices, upgrade/downgrade detection, and payment failure alerts
dashboard/views.py	project_created, project_updated, project_deleted	Feature usage tracking with project counts and field change details

Issues

None - excellent event coverage.

Other completed criteria

• Events represent real user actions (signup, login, subscription, project CRUD)
• Events enable key product analytics (funnel analysis, churn tracking, revenue metrics)
• Rich properties on events (plan_name, plan_price, is_upgrade, is_demo_mode, fields_updated)
• Server-side events for webhook-driven flows (checkout_completed, payment_failed)
• Person properties set via tag() for user segmentation

---

Reviewed by wizard workbench PR evaluator