Laravel Relational Metrics Laravel Package

Product Decisions This Supports

• Ship "lightweight analytics" without a data platform. This package lets you define metrics (counts, sums, averages) over Eloquent models, including metrics filtered by relationships and by multiple conditions. That maps directly to the most common first analytics ask: "How many X do we have, broken down by Y, where Z?" — e.g., "active customers per plan with at least one completed order," "open tickets per team where priority is high."
• Admin dashboards, KPI widgets, and customer-facing counters. Anywhere you need per-entity aggregates (orders per merchant, members per workspace, invoices per account) without spinning up a warehouse, this shortens the path from "we want a number on a screen" to "the number is on the screen."
• Roadmap prioritization input. Because relational metrics are cheap to define, PMs can commit to "reporting lite" roadmap items early (dashboard v1, exportable counts, operator-facing summary cards) instead of deferring them behind a BI initiative.
• Build vs. buy, made concrete. The realistic alternatives are (a) hand-rolled withCount/selectRaw queries scattered across controllers, (b) a BI tool (Metabase, Looker, Superset) over a replica, or (c) a dedicated metrics layer. This package sits in slot (a): it buys you declarative, reusable, testable metric definitions at the cost of a PHP dependency, versus the maintenance cost of hand-rolled aggregates that diverge across screens.
• Definition hygiene. Its real product value is not speed but single source of truth — one named metric definition rather than five slightly different COUNT queries that produce five slightly different numbers in a board deck.

When to Consider This Package

Consider it when:

• You run a Laravel monolith with MySQL/Postgres and moderate data volumes, where a relational aggregate query returns in well under a second.
• Metrics are relational and categorical (counts/sums filtered by relations and conditions), not time-series, cohort, or funnel analysis.
• Your team is already fluent in Eloquent and would otherwise be writing ad-hoc aggregate queries.
• The metrics will be displayed in-app (admin panels, dashboards, widgets) rather than consumed by external analysts.
• You want the metric definitions to live in code, versioned and reviewable, alongside the models they describe.

Look elsewhere when:

• Maintenance risk matters. Last release was March 2022 with 26 stars and a single-small-community footprint. Verify Laravel/PHP compatibility against your target version before committing roadmap items to it; pin it, and budget for a fork or in-house replacement.
• Scale. If the source tables are in the tens of millions of rows or the metrics are requested on every page load, you need caching, queued pre-aggregation, materialized views, or a columnar store — not on-request Eloquent aggregates.
• Analytical depth. Time-series, retention cohorts, funnels, and ad-hoc slicing belong in a warehouse/BI stack (Metabase, Superset, dbt + ClickHouse/BigQuery), not here.
• Governance/compliance. No formal security review or vendor support; if metrics touch regulated data or feed external reporting, the audit surface is yours.
• You need a supported SLA — this is community open source with no backing organization.

Adoption gate: treat it as an internal utility, wrap it behind your own MetricsService boundary so replacement is a one-file change, and pin the version.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost enabler for in-app reporting. It lets engineering define business metrics once — "active accounts with a completed order," "revenue per merchant" — and reuse them across dashboards and admin screens, instead of rebuilding each number ad hoc. Expect faster delivery of "reporting lite" roadmap items and fewer incidents where two screens disagree on the same figure. The trade-off is a small, aging open-source dependency: we contain it behind an internal interface so it can be swapped out without touching product code.

To engineering: It gives you declarative, testable metric definitions over Eloquent — aggregates scoped by relations and by multiple conditions — rather than duplicated withCount/selectRaw in controllers. That means one place to change a definition and one place to test it. Caveats to size up in a spike: last release 2022, small maintainer base, so confirm Laravel/PHP compatibility and wrap it in an adapter. If query latency is a problem at our data volumes, the same interface lets us move to cached or pre-aggregated implementations later.

Recommendation: Run a one-day spike to validate compatibility and latency on production-shaped data. If it passes, adopt behind an internal metrics interface for internal/admin reporting only; route anything analytical, external-facing, or high-volume to the data platform track.