Analytics Meta Livewire Laravel Package

Technical Evaluation

Architecture fit. This is a presentation adapter — a Livewire UI layer sitting on top of a domain module (liberusoftware/module-analytics-meta) inside Liberu's modular monolith convention. That means it carries almost no business logic of its own; its value is entirely contingent on the parent module being sound. Architecturally it is a poor fit for anything that is not (a) Laravel, (b) Livewire-rendered, and (c) already running the Liberu module loader and its service-provider/view-namespace contracts. In a headless, Inertia/React, or API-first product this package contributes nothing that could not be rebuilt in a day.

Integration feasibility: low. Adoption signals are effectively zero — 0 stars, 0 dependents, single-vendor authorship, composite score 19.78/100. There is no ecosystem evidence of the package working in the wild, no downstream consumers surfacing bugs, and no third-party usage patterns to copy. Integration would be a pathfinding exercise against undocumented assumptions: Livewire major version (v2 vs v3 are materially incompatible), Tailwind build assumptions, PHP/Laravel constraint ranges, and the exact public surface of the parent module. Budget a spike, not an estimate.

Technical risk: high, and concentrated in three areas.

1. Licensing — blocking. NOASSERTION means GitHub could not match the repository to a recognised licence. Until a human reads LICENSE, you cannot ship this in a commercial product. Assume proprietary or bespoke terms until cleared.
2. Metadata integrity. The release date reads 2026-10-26, which is anomalous; combined with zero stars and zero dependents this suggests either a misconfigured release pipeline or an unattended automated publish. Neither inspires confidence in release hygiene. Treat the version as "a commit," not "a release."
3. Security surface. A Meta Conversions API integration touches long-lived access tokens, PII hashing (email/phone normalisation before SHA-256), event deduplication via event_id, and consent state. A presentation adapter that renders token fields and event logs is an attractive target and a likely place for secrets to leak into logs or Livewire payloads.

Key questions to put to the maintainer (or answer by reading source):

• Which Livewire major version, and is the parent module pinned by composer.json or floating?
• Where is the CAPI access token stored — env, encrypted cast, tenant-scoped table — and is it ever serialised to the Livewire component?
• Does the parent module implement event deduplication (event_id shared with the browser Pixel) and retry/backoff against Meta's rate limits?
• Is there any test suite, and does CI run it?
• What is the licence, in writing?
• Is the UI multi-tenant aware, or does it assume a single-account install?

Integration Approach

Stack fit. Narrow. Laravel + Livewire + Tailwind, on the Liberu module system. If you are on that stack, the marginal cost of a trial is low; the marginal cost of dependency is high. If you are not on Livewire, stop here — the capability you actually want (server-side Meta CAPI dispatch) is a queue job and an HTTP client, both of which you already have.

Migration path. Do not composer require this into a production branch. Recommended sequence: clone → licence review → read the parent module's contracts → vendor or fork the code into your own namespace behind a thin internal interface (MetaEventsPresenter). Forking dissolves the abandonment risk at the cost of owning upstream diffs, which for a presentation adapter should be small.

Compatibility. Unverified and unverifiable from metadata alone. Concretely, pin: PHP minor, Laravel major, Livewire major, Tailwind major, and the parent module by commit hash (not by semver — there is no evidence of a disciplined semver cadence). Expect at least one round of fixing view namespaces and published asset paths.

Sequencing.

1. Week 1 — licence and source audit. Blocking gate. No licence, no work.
2. Week 1–2 — technical spike. Stand up the parent module in a throwaway Laravel app; get one server-side Purchase event to appear in Meta Events Manager with dedup verified against the browser Pixel. This validates the domain module, not the UI.
3. Week 3 — decide. If the parent module is solid, fork the adapter and rebuild only the screens you actually need (likely: connection settings, event mapping, delivery log). If the parent module is not solid, build the CAPI client yourself — it is a bounded, well-documented integration.
4. Week 4+ — integrate behind a feature flag, admin-plane only, with the pixel/CAPI dual-send shadow-moded before cutover.

The honest framing for a steering committee: this package is a UI convenience, not a capability. You are evaluating whether to adopt the Liberu analytics module; the Livewire adapter is an incidental artefact of that decision.

Operational Impact

Maintenance. You will become the maintainer. There is no evidence of a maintainer team, release cadence, or issue triage. Bus factor is effectively one organisation, and the anomaly in the release metadata suggests releases may be automated without human review. Forking is not optional; it is the baseline assumption.

Support. GitHub issues with no SLA, no commercial backing surfaced, and no community to answer questions. Internal ramp-up must therefore be self-funded. Plan for one engineer to hold this knowledge, and document the token storage and event-mapping decisions as you go — otherwise you have created a second bus-factor problem.

Scaling. Two distinct planes:

• Admin/UI plane — negligible. Livewire renders a settings screen for a handful of operators. No scaling concern.
• Event plane — this is where the risk lives, and it is not in this package. Meta's Conversions API imposes per-pixel throughput limits and expects timely delivery; a naive synchronous send inside a Livewire request will collapse under checkout volume. The parent module must dispatch to a queue with backoff, idempotency keys, and a dead-letter path. Verify this before you trust it.

Failure modes to design against.

• Silent delivery failure — events dropped without alerting; ad optimisation degrades before anyone notices. Instrument a delivery-success metric and alert on it.
• Deduplication drift — browser Pixel and server CAPI emitting mismatched event_ids, double-counting conversions. Shadow-mode both channels before cutover.
• Token expiry / revocation — Meta system-user tokens expire on rotation; no refresh path means sudden total outage. Add a synthetic canary event.
• Consent and privacy — PII must be hashed pre-transmission and gated on consent state; a UI adapter is a plausible place for this to be missed. Legal review required, not optional.
• Livewire major upgrade — v2→v3 breaks components; an unmaintained adapter will not follow. Budget the rewrite.
• Parent module breaking change — floating constraints will silently break the adapter. Pin hard.

Ramp-up. Call it 1–2 engineer-weeks to reach a trustworthy spike, assuming competent Laravel/Livewire and some Meta CAPI familiarity. Add a week for licence clearance and legal/consent review. If the parent module fails the spike, add 2–3 weeks to build a first-party CAPI client — still a manageable outcome, and one that removes the dependency entirely.

Recommendation. Reject as a dependency; evaluate only as a reference implementation for your own Meta CAPI work. The capability is worth having — post-iOS signal loss makes server-side conversion tracking genuinely valuable — but this specific artefact carries unquantified licence risk, no adoption evidence, and a UI-only value proposition. Score 19.78 is, on this reading, fair.