[CI] (bd1f803) django/django3-saas

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: bd1f803
App: django/django3-saas
App directory: apps/django/django3-saas
Workbench branch: wizard-ci-bd1f803-django-django3-saas
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-03-03T17:16:23.941Z
Duration: 408.1s

[wizard-ci-bot]

The files don't exist locally as I'm running in an environment where the repository isn't cloned. However, I have the complete diff information from the PR, which provides all the changes made. Let me evaluate based on the comprehensive diff provided.

---

PR Evaluation Report

Summary

This PR adds PostHog analytics integration to a Django 3 SaaS application. It initializes the PostHog Python SDK via Django's AppConfig.ready() pattern, adds middleware for context management and exception autocapture, and instruments 12 custom events across authentication, billing, and project management flows.

Files changed	Lines added	Lines removed
7	+158	-1

Confidence score: 4/5 👍

• No reverse proxy configured: Events will be blocked by ad blockers for any client-side tracking extension. However, since this is a server-side Python SDK integration, this is less critical than for JavaScript implementations. [MEDIUM]
• No page view tracking: The integration captures custom events but doesn't track page views. For a Django app this would typically require additional middleware or manual calls. [LOW]
• Duplicate plan_changed event code: The same capture block is repeated for both Stripe and demo mode in change_plan(). Consider extracting to avoid duplication. [LOW]

---

File changes

Filename	Score	Description
accounts/apps.py	5/5	New file correctly initializes PostHog SDK in Django's AppConfig.ready() pattern with API key and host from settings
accounts/views.py	4/5	Properly adds user authentication events (user_logged_in, user_logged_out, user_registered, profile_updated) with correct context-based API usage
billing/views.py	4/5	Comprehensive billing event tracking including checkout, subscription lifecycle, plan changes, and payment failures. Minor code duplication in plan_changed events
config/settings.py	5/5	Correctly updates INSTALLED_APPS to use AccountsConfig, adds PosthogContextMiddleware, and defines environment-based settings
dashboard/views.py	4/5	Adds project lifecycle events (project_created, project_deleted) with appropriate properties
posthog-setup-report.md	5/5	Well-documented report of changes, events table, and actionable next steps for creating insights
requirements.txt	5/5	Correctly adds posthog dependency

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	All imports and configuration appear valid for Django 3.x
Preserves existing env vars & configs	Yes	Existing settings preserved; POSTHOG_API_KEY and POSTHOG_HOST added with sensible defaults
No syntax or type errors	Yes	Python syntax is correct throughout
Correct imports/exports	Yes	import posthog added correctly to all modified files
Minimal, focused changes	Yes	Changes are focused solely on PostHog integration

Issues

• Code duplication in billing/views.py: The plan_changed event capture block is duplicated for Stripe and demo mode paths. Consider extracting to a helper function after the conditional branches merge. [LOW]

Other completed criteria

• Environment variables documented in settings.py with sensible defaults
• Build configuration unchanged (requirements.txt only adds posthog)
• Error handling preserved in existing try/except blocks
• Consistent with existing Django patterns (class-based views, function views, decorators)
• Clear, readable code with proper indentation

---

PostHog implementation: 4/5 ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog added to requirements.txt
PostHog client initialized	Yes	Initialized in AccountsConfig.ready() using posthog.api_key and posthog.host from Django settings
capture()	Yes	12 events captured using posthog.capture() within new_context() blocks
identify()	Yes	posthog.identify_context() called with user ID in all capture blocks; posthog.tag() used for person properties on login/registration
Error tracking	Yes	PosthogContextMiddleware added to MIDDLEWARE enables automatic exception capture
Reverse proxy	No	No reverse proxy configuration for ad-blocker circumvention

Issues

• No reverse proxy configured: The integration doesn't include a reverse proxy setup to circumvent ad blockers. For server-side Python SDK this is less critical since events are sent from the backend, but any future client-side extension would benefit from this. [MEDIUM]
• No page view tracking: Custom events are tracked but standard page views are not. For a Django server-rendered app, this could be added via middleware or template tags. [LOW]

Other completed criteria

• API key sourced from environment variable (not hardcoded)
• Correct API host configuration with default to https://us.i.posthog.com
• No PII in event properties (only user IDs, plan slugs, boolean flags)
• Proper use of Python SDK v7+ context-based API (new_context(), identify_context(), tag(), capture())
• Middleware correctly placed in MIDDLEWARE list
• AccountsConfig properly registered in INSTALLED_APPS

---

PostHog insights and events: 5/5 ✅

Filename	PostHog events	Description
accounts/views.py	user_logged_in, user_logged_out, user_registered, profile_updated	Complete user authentication lifecycle with person properties (username, date_joined) on registration/login
billing/views.py	checkout_initiated, subscription_started, subscription_activated, plan_changed, subscription_canceled, payment_failed	Comprehensive billing funnel tracking including Stripe webhook events; properties include plan_slug, plan_interval, old_plan_slug
dashboard/views.py	project_created, project_deleted	Core product engagement events with has_description property on creation
Middleware	capturedException	Automatic exception capture via PosthogContextMiddleware

Issues

None - the event instrumentation is comprehensive and well-designed.

Other completed criteria

• Events represent real user actions and product flows
• Signup → checkout → subscription funnel fully instrumented
• Churn signals captured (cancellation, payment failure)
• Events enriched with relevant properties (plan details, intervals, boolean flags)
• Setup report includes 5 actionable insight recommendations
• Events enable cohort analysis, funnel analysis, and retention tracking

---

Reviewed by wizard workbench PR evaluator