Posthog Php Laravel Package

Product Decisions This Supports

• Server-authoritative funnel instrumentation. Most product analytics defaults to the browser, which means the events that matter commercially — subscription_created, invoice_paid, seat_provisioned, report_exported — are invisible or duplicated. This SDK lets the Laravel backend emit those events with the same distinct_id the frontend uses, so the funnel actually closes.
• Feature flags and experiments evaluated in PHP. Gating an API response, a queued job, or a CLI command cannot depend on a JS flag. This package supports progressive rollout, kill switches, and server-side A/B assignment — the difference between "we can ship behind a flag" and "we can ship behind a flag for everything except the parts that matter."
• Build vs. buy on analytics plumbing. The alternative is a hand-rolled HTTP client with retry, batching, identity merge, and shutdown-flush logic. This is a cheap way to price that build: if the SDK covers 80% of the wrapper you were about to write, don't write it.
• B2B / group analytics. Account-level tracking (group_identify, company properties) underpins seat-expansion, account-health, and churn-risk reporting. Backend systems know the account hierarchy; the frontend usually doesn't.
• Roadmap fork in the road: standardize on PostHog across web + backend, or keep a split stack (posthog-js on the client, bespoke backend pipeline). Adopting this package is the commitment point for the former — worth an explicit decision rather than a drift.
• Concrete use cases: onboarding experiments, paywall/entitlement gating, internal admin-tool telemetry, worker-side job outcome tracking, and revenue event reconciliation against billing.

When to Consider This Package

Consider it when:

• You are already on PostHog (cloud or self-hosted) and want backend events in the same project, with the same identity model.
• You need flags or experiments evaluated in PHP — API middleware, queue workers, scheduled commands — with no browser in the loop.
• Your team is Laravel/PHP-first and the alternative is a bespoke analytics client nobody wants to own.
• You want the vendor-maintained semantics (batching, flush() on shutdown, distinct_id handling) rather than reimplementing them.

Look elsewhere when:

• You only need client-side product analytics. posthog-js is the right tool; this package adds nothing there.
• You are not on PostHog and have no near-term plan to be. An SDK should never drive the analytics-vendor decision — pick the vendor first, then the client.
• You want deep Laravel-native ergonomics (publishable config, facade, middleware, queued dispatch). Evaluate the Laravel-specific wrapper instead, or budget half a day for a thin adapter.
• You run long-lived workers where flush-on-shutdown semantics and per-process memory growth need explicit design.
• You have data-residency or PII constraints that forbid events leaving your boundary — evaluate self-hosted PostHog before adopting the client.
• You are screening on community signal alone. 31 stars looks alarming, but official vendor SDKs are routinely low-star because they are a means to a vendor's end, not a community project. Judge on release cadence and issue responsiveness instead — and note the release metadata here is unusual (a 2026-10-26 date), so verify the actual changelog before pinning.

How to Pitch It (Stakeholders)

Executives: PostHog's official PHP SDK lets our backend emit the events that actually drive revenue — payments, subscriptions, provisioning — under the same identity model as our frontend analytics. That closes the gap between "someone clicked" and "someone paid," and gives us server-side feature flags so we can ship behind a switch without a redeploy. MIT-licensed, officially maintained, no new vendor and no procurement.

Engineering: It's a thin, vendor-maintained client, not a framework. Two real costs: (1) it introduces batching and flush-on-shutdown behavior you have to reason about in long-running processes, and (2) it is infrastructure we do not own. Mitigate both by wrapping it behind our own Analytics interface — that keeps the vendor swappable and gives us one chokepoint for PII scrubbing and event-schema validation. Rough effort: 1–2 days for the adapter plus 5–8 key events; another day for flags including caching.

State the caveats plainly: low star count and thin community surface; feature parity with the JS SDK typically lags; the release date in the metadata warrants verification. None of these are blockers for a wrapped dependency — but they are reasons to pin the version, keep it out of domain code, and avoid betting an entire analytics migration on it in one quarter.