Bitter Bundle Laravel Package

Product Decisions This Supports

• Analytics build-vs-buy. Informs the decision to self-host product analytics on Redis bitmaps instead of paying per-seat for Mixpanel/Amplitude/Segment. The Bitter model — one bit per user per event per day — is orders of magnitude cheaper at scale than row-per-event storage, so it directly shapes the vendor line item and the "do we actually need this tool" question.
• Cost model for high-cardinality metrics. Supports infrastructure estimates for DAU/WAU/MAU, unique visitors, feature reach, and retention cohorts. Roughly a megabyte per ten million users per daily metric versus gigabytes in a relational warehouse — the core argument for bitmap-style counting in a roadmap or budget review.
• Feature adoption and rollout gates. Backs per-feature "did this user adopt X" flags and daily/weekly/monthly uniques feeding adoption dashboards, gradual rollout gates, and kill-switch decisions on new features. This is the most common near-term use of the underlying library.
• Retention and cohort analysis. Powers the classic D1/D7/D30 retention charts used to judge whether an onboarding flow, pricing change, or activation nudge actually moved the needle.
• Privacy and data-residency posture. Enables roadmap choices favoring self-hosted, PII-minimizing analytics — user IDs exist only as bit offsets in your own Redis — which matters when legal/compliance pushes back on third-party trackers or cookie-consent overhead.
• Platform standardization. Informs whether to standardize analytics on a PHP-native, in-cluster component versus standing up a data pipeline (Kafka + warehouse). A true build-vs-buy-vs-integrate decision.

Caveat a PM must internalize first: rezzza/bitter-bundle is a Symfony bundle, not a Laravel package. For a Laravel product, the bundle delivers no leverage — what you actually adopt is the underlying rezzza/bitter library (or the bitmap pattern itself) behind a Laravel service provider. Frame every decision below around the pattern and the library, not the bundle.

When to Consider This Package

Adopt — and by "adopt," mean the underlying library or the pattern — only under a fairly narrow set of conditions:

• You are willing to treat it as a reference implementation. 17 stars and zero dependents is a clear abandonment signal. Consider it as a design template and a head start on the Redis-bitmap mechanics, not as a dependency you put on the critical path. Budget to fork it into your monorepo and own it indefinitely.
• Redis is already a first-class, operationally-owned dependency. Replication, persistence, memory limits, and backup are solved problems for your team. If nobody owns Redis ops, stop here.
• Your analytics questions are bounded and known in advance. Unique counts, DAU/WAU/MAU, retention cohorts, feature-adoption flags. Bitmap analytics is excellent at "how many distinct users did X" and poor at arbitrary slicing.
• Your event volume is large enough that per-event row storage genuinely hurts. Below roughly a few hundred thousand users, a simple events table with indexed queries is cheaper in total cost of ownership than the engineering and maintenance overhead here.
• On Symfony: the bundle itself is usable with minimal setup — that is its one real convenience. On Laravel: skip the bundle entirely and integrate rezzza/bitter directly (or reimplement the pattern in ~a day); the Symfony DI/config layer is dead weight.

Look elsewhere when:

• You need arbitrary segmentation ("uniques by plan, country, and acquisition channel, filtered by signup date"). Bitmap intersections don't compose cleanly across many dimensions, and you will end up backfilling into a warehouse anyway.
• You need event-level forensics — funnels with arbitrary step ordering, session reconstruction, per-user timelines. Bitmaps store membership, not events.
• You are pre-product-market-fit or pre-scale. Use a managed tool, buy speed, and revisit self-hosting only when the bill or the privacy requirement actually bites.
• You need compliance-grade or audited reporting (financial, clinical, regulated), where an unmaintained community bundle is not an acceptable control.
• Nobody on the team owns Redis operations or analytics schema design.

How to Pitch It (Stakeholders)

To executives (one paragraph): "There is an open-source technique for product analytics that stores one bit per user per event per day in Redis, so counting ten million monthly actives costs about a megabyte instead of a warehouse table. It would let us answer the questions we actually ask — how many people used this feature, how many came back — without a per-seat analytics contract and without shipping user data to a third party. The catch is that the specific package implementing it is a small, essentially unmaintained community project (and it's built for Symfony, while our product runs on Laravel), so the honest framing is: this is a design we can adopt, not a vendor we can lean on. I'd recommend a timeboxed spike to validate the pattern against our real questions, then either build a small internal service around it or keep paying for the managed tool. I would not put the package itself on our critical path."

To engineering: "This is the Redis-bitmap analytics pattern (Bitter/Bitmapist-style) — one bit per user ID per event per day, with BITCOUNT and BITOP AND/OR doing the counting and cohort intersection. Memory efficiency is the win and no PII leaves our cluster. The concerns are three: it ships as a Symfony bundle so the container/config layer is unusable for us; it has effectively no user base to absorb upgrades; and bitmaps answer 'how many distinct users' well but arbitrary segmentation poorly. My proposal: ignore the bundle, pull the underlying rezzza/bitter library (or reimplement the ~200 lines of bitmap logic), wrap it behind an internal AnalyticsService interface so we're not coupled to its API, and constrain it to unique-count and retention use cases. Anything needing arbitrary segmentation stays in the warehouse — I don't want us discovering mid-quarter that bitmap intersections can't answer a question the exec team already promised. Sequenced as: discovery spike → parity proof of concept against an existing metric → interface + adapter → feature-flag and roll out one low-risk metric first."