Product Decisions This Supports
- Build vs. buy for product analytics. Bitter is a credible reference design for an in-house metrics layer: it separates metric definition (counters, gauges, time-series deltas/values), aggregation, and storage adapters. Use it to scope what "good enough" looks like before signing an analytics SaaS contract or committing engineering to a bespoke system.
- Instrumentation scope for early features. Because the API surface is small and self-hosted, it lowers the cost of answering "should we even measure this?" — useful when deciding which roadmap items deserve event tracking versus which can ship with logs alone.
- Data ownership and compliance posture. MIT-licensed and self-hosted means product usage data never leaves the infrastructure. That directly supports decisions in regulated, on-prem, or privacy-sensitive segments where a third-party tag or SaaS pipeline is a non-starter.
- Roadmap inputs for internal dashboards. Lightweight counters and time series are usually enough to power an internal "usage/adoption" view (DAU proxies, feature hit counts, per-tenant activity). This can unblock a PM-led dashboard sprint without waiting on the data platform team.
- Usage-based pricing and quota experiments. Simple counters map cleanly to metered dimensions (API calls, seats, events), which is the cheapest way to prototype usage-based billing logic before investing in a real metering vendor.
- Vendor evaluation baseline. Having a concrete, inspectable implementation in-house makes RFP conversations with analytics vendors sharper — you can specify retention windows, cardinality limits, and aggregation semantics rather than accepting marketing language.
- Architecture decisions on storage. The adapter approach (Redis vs. relational) is a useful forcing function for the "how fresh does this metric need to be, and how long do we keep it?" conversation — the answer usually determines whether you need a columnar store at all.
When to Consider This Package
Consider it when:
- You are on PHP/Laravel, in a single-service monolith, and want metrics recorded in the same transaction boundary as the business event.
- Volume is low to moderate (thousands to low millions of events per month) and dashboards are read by internal staff, not customers at scale.
- You need fast time-to-first-metric — a spike, a hack week, an MVP — and the alternative is a multi-week data platform ticket.
- Self-hosting is a requirement, not a preference, or you want to avoid sending PII/behavioural data to a third party.
- You want a readable blueprint to fork rather than a dependency to trust: the abstraction is simple enough that owning a trimmed copy is realistic.
Look elsewhere when:
- Production dependency risk matters. This package is archived, has ~128 stars and zero dependents, and shows no maintenance signal. There will be no security patches, no Laravel major-version support, and no community to lean on. Treat it as frozen code the day you adopt it.
- You need high cardinality, high write throughput, or real-time dashboards — that is a columnar/streaming problem (ClickHouse, Druid, Snowplow, PostHog, Prometheus/Grafana), not a PHP library problem.
- You need product-analytics primitives — funnels, cohorts, retention curves, sessionisation, segmentation UI. Bitter gives you the raw numbers, not the analysis layer.
- Multiple languages or services must report into one metrics store; a PHP-only collector becomes an accidental silo.
- You have compliance or audit requirements around metric integrity (immutable event logs, replayability). A simple counter library rarely satisfies those controls.
Recommended adoption pattern: vendor a pinned copy or fork it behind an internal Metrics interface, timebox the integration to a sprint, and pre-commit to a replacement trigger (e.g. event volume threshold or the first requirement for cohort analysis).
How to Pitch It (Stakeholders)
For executives: Bitter is a small, MIT-licensed PHP analytics library that lets us record product metrics inside our own application and infrastructure — no third-party tags, no usage data leaving our systems, no per-event SaaS bill. At 128 stars, zero dependents, and archived status, it is not a long-term dependency; it is a low-cost way to stand up first-party metrics now and to pressure-test whether we need a paid analytics platform at all. Proposal: a one-sprint, one-engineer evaluation to validate the pattern against our real questions (adoption, feature usage, quota inputs), with a decision point at the end — adopt a forked copy behind an internal interface, or use the findings to justify a buy decision. Downside is bounded to a sprint; the upside is either a cheap owned capability or a materially better-informed vendor contract.
For engineering: The value is the design, not the package. It cleanly separates metric types, aggregation, and storage adapters, which is exactly the seam we want if we ever swap Redis for a time-series store. It is archived and unmaintained, so we should fork and pin rather than composer require, wrap it behind our own Metrics facade so call sites never touch the library directly, and keep the write path off the critical request path where possible. Concrete asks: (1) confirm the adapter layer fits our current stack; (2) estimate the fork-and-harden cost versus building the same abstraction from scratch; (3) define the volume threshold at which we migrate off relational storage. If (3) is likely to be crossed within two quarters, we should skip the integration and go straight to the buy/columnar path.