Analytics Meta Filament Laravel Package

Product Decisions This Supports

• Build vs. buy for a Meta Conversions API (CAPI) admin surface. Server-side event tracking is now table stakes for paid acquisition — ATT, ad blockers, and cookie deprecation all erode browser-side pixel coverage. The "buy" side of this decision is normally expensive because CAPI work isn't just an HTTP client: it's event deduplication, event_id / fbp / fbc propagation, match-quality tuning, retry and backoff, and an operator UI to inspect, replay, and suppress events. This package is the presentation adapter — the Filament admin layer — which means it removes the least differentiated but most tedious slice of that work (resources, forms, tables, filters, actions) and leaves the interesting decisions to you.
• Roadmap sequencing for a "marketing back office." If your roadmap has a line item like "marketing ops can self-serve tracking config," this is a candidate to compress that item from a multi-sprint build to a wiring exercise — conditional on the underlying analytics-meta module covering your event model, which is the real gate.
• Architecture bet on a modular monolith. The package is one module in the Liberu ecosystem (Laravel modules + Filament). Adopting it is implicitly a decision about whether your team standardizes on that module structure. Treat it as an architecture decision, not a feature decision — the cost isn't the package, it's the convention.
• Use cases it plausibly serves: B2B/SaaS marketing sites with lead-gen forms and signup funnels; e-commerce on Laravel where checkout events need reliable server-side delivery; agencies running many small Filament-backed client apps where a repeatable admin surface has leverage.
• What it should not drive: pricing, packaging, or any customer-facing promise. This is internal tooling on an analytics side-path, not a revenue-critical surface.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Laravel + Filament, and your team is fluent in Filament resources — the adapter's value is entirely the saved UI work.
• You need Meta CAPI specifically, not a multi-vendor event pipeline (Meta + Google + TikTok + GA4). Single-vendor scope is where a single-vendor adapter makes sense.
• License ambiguity is resolved before adoption. NOASSERTION is not a license. For a package that touches ad-spend attribution and customer identifiers, an unresolved license is a procurement and legal blocker, not a footnote. Get written clarification or plan to treat it as read-and-reimplement-only.
• You can vendor or fork it. With 0 stars, 0 dependents, and no observable community, you should assume you are the maintainer. Budget for pinning a specific commit and owning patches.
• The blast radius is small: if this breaks, marketing loses dashboard visibility for a day. It does not break checkout.
• You can run a time-boxed spike (1–2 weeks) against your actual event taxonomy before committing, and you have a fallback — a ~200-line custom Filament resource wrapping Meta's CAPI directly is a realistic alternative and should be priced as your BATNA.

Look elsewhere when:

• You need a vendor-supported, SLA-backed integration. This has none.
• You need multi-platform server-side tracking — you want a proper tag/event layer (or a managed CDP), not a per-network adapter.
• You are not on Filament, or on a Filament major version the package doesn't track.
• Your compliance posture is strict (GDPR/CCPA consent gating, PII hashing policy, data residency). Server-side tracking sends hashed identifiers to Meta; the adapter's consent-handling behavior is undocumented and must be audited, not assumed.
• The release date (2026-10-27) does not reconcile with observable activity — verify the artifact actually exists and installs before it enters a roadmap.

How to Pitch It (Stakeholders)

For executives (one paragraph): Meta's server-side tracking closes a measurable gap in ad attribution caused by browser privacy changes, and we currently have no owned tooling for it. This package is an open-source admin UI that could shortcut the internal tooling portion of that work — it does not replace the attribution logic, and it carries adoption risk: no community, no clear license, no support. Recommendation is a short, cheap evaluation against our own build estimate, with a default of building a thin in-house equivalent if the license or the event model doesn't fit. Low cost to explore, low downside if we walk away.

For engineering (bullets):

• Filament presentation adapter over a separate analytics-meta module — the UI is the deliverable, the tracking logic lives upstream. Read the upstream module first; the adapter is worthless if the event model doesn't match ours.
• Practical dependency risk: 0 stars, 0 dependents, NOASSERTION license. Assume we own maintenance. Pin a commit, vendor it, and isolate behind our own interface so a swap is a day's work, not a quarter's.
• Audit specifically: event_id deduplication against any existing browser pixel, PII hashing, consent gating, retry/queue behavior, and where credentials are stored.
• Success criteria for the spike: installs cleanly on our Filament version, covers our top 5 conversion events end-to-end, and the diff versus a hand-rolled resource is at least 3–4 days saved. If it isn't, we build the thin version and move on.