Filament Pixel Laravel Package

Product Decisions This Supports

• Feature decision — is panel-side conversion tracking worth shipping? This answers a narrow question: "do we want Meta Pixel on our Filament panel?" It is instrumentation, not product surface. Classify it as an enhancement, not a differentiator, and don't let it compete with roadmap items that change user outcomes.
• Build vs buy. The scope is small and legible: a HEAD_START render hook that injects the base pixel + a PageView call, plus a settings page backed by spatie/laravel-settings. Buying costs an hour of integration; building is genuinely ~100–150 lines of Blade + a settings migration. Buy if you want the settings-page pattern and admin-managed Pixel ID for free. Build if you need anything beyond PageView (see below) — you'll be extending this package immediately, at which point you own it anyway.
• Operational autonomy decision. The real value isn't the snippet — it's the settings page. It moves the Pixel ID out of code and into an admin-editable field, so marketing can add/swap IDs, enable/disable, per panel, without a deploy. That's a support-cost reduction argument, and it's the strongest one in the pitch.
• Multi-panel / multi-brand rollout. Registration is per-PanelProvider, so you can turn it on for a customer-facing portal and leave the internal ops panel clean. Combined with settingsPage(false), you get three positions: full plugin, script-only (locked ID, ops can't touch it), or off.
• Governance/consent decision. Because the snippet is injected unconditionally, adopting this package is implicitly a decision that marketing pixels are acceptable in an authenticated panel context. That's a legal/product call, not an engineering one — surface it early.
• Use cases that actually justify it: paid-acquisition funnels that land in a Filament-built customer or partner portal; retargeting-audience building from portal visitors; client-facing SaaS where the client's own marketing team owns the Pixel ID. Use cases that don't: internal employee admin panels, anything where the "traffic" is your own staff.
• Explicit non-goal to state in the decision record: this is write-only to Meta. It gives you nothing back inside the app — no dashboards, no funnels, no retention. If a stakeholder asks "can we see what admins are doing," this is the wrong package; that's a product-analytics or audit-log decision. Don't let those two conversations merge.

When to Consider This Package

Adopt when all of these hold:

• You are on, or committed to, Filament 5 / Laravel 11 / PHP 8.2+ — the documented floor is tight and the plugin's value doesn't justify holding back a framework upgrade or maintaining a fork.
• There is a named business owner for the pixel (marketing) and a concrete campaign or audience it feeds. No owner, no pixel.
• The panel in question is externally facing (customer, partner, tenant portal) rather than internal-staff-only.
• You want the Pixel ID admin-editable and are willing to accept a settings migration and a spatie/laravel-settings dependency.
• Legal/compliance has confirmed pixel use in an authenticated context is acceptable under your consent posture. If you have no CMP and operate under GDPR/ePrivacy, stop here.
• You accept a single-maintainer, 5-star, zero-dependent dependency for a non-core concern, and can pin it (^3.x, never dev-) with a documented removal path.

Look elsewhere, or don't adopt, when:

• You need events beyond PageView. No add-to-cart/lead/signup events, no fbq('track', ...) surface documented, no Conversions API, no server-side events, no event deduplication. Any of those means custom code — so just write the custom code.
• You need real analytics. This does not report back. If the ask is "understand panel engagement," this package cannot answer it; you need product analytics or query-log-based instrumentation.
• You're on Filament 3 or 4. The documented requirement is Filament 5.0. Don't assume graceful degradation.
• You need vendor accountability. No SLA, no security review, no dependents to signal production usage. For anything on the critical render path with an audit requirement, that's disqualifying.
• The docs inconsistency isn't resolved. The release note describes Plugin::make()->navigationGroup(string|Closure) on top of filament-analytics-core 3.1, while the skill doc describes PixelPlugin::make() with settingsPage(bool) and a laravel-pixel + spatie-laravel-settings-plugin dependency set. Those are two different packages' worth of surface area. Until someone reads composer.json and the actual class list, treat the published documentation as unreliable and budget for a spike rather than an estimate.

How to Pitch It (Stakeholders)

For executives (one paragraph): "A small, free (MIT) add-on that lets us put Meta Pixel tracking on our Filament-based portal and manage the Pixel ID from an admin settings screen — no deploys to change it. Integration is roughly an hour, and it can be switched off per panel. The reason to consider it is marketing attribution on acquisition traffic that lands in the portal; the reason to decline is that the underlying package is a single-maintainer, low-adoption dependency and the published docs are internally inconsistent. My recommendation: approve a short spike to verify the dependency chain, adopt only if we have an active paid-acquisition funnel into a customer-facing panel and legal has signed off on pixel use in an authenticated context, and treat it as reversible."

For engineering (the honest version):

• Filament 5 panel plugin. Registers PanelsRenderHook::HEAD_START to inject the base pixel plus PageView, and a ManagePixelSettings page via spatie/laravel-settings.
• Hard requirements: PHP 8.2+, Laravel 11+, Filament 5.0. Pins jeffersongoncalves/laravel-pixel ^2.0 and filament/spatie-laravel-settings-plugin ^5.0. That's two third-party hops below ours for a marketing nicety.
• Signals: 5 stars, 0 dependents, single maintainer, last release dated in the future relative to typical cadence. Blast radius is small (a head script and a settings page), but so is the evidence base.
• Docs are contradictory — PixelPlugin vs Plugin, settingsPage() vs navigationGroup(), laravel-pixel vs filament-analytics-core. First task is reading composer.json and confirming the actual public API, plus which Filament major is genuinely supported. Do not estimate from the README.
• Ship it behind a config flag, smoke-test panel render in staging, and write down the removal steps (unregister plugin, drop the settings migration) before it goes live.
• Position the alternative up front: "40 lines in a Blade render hook with a config value" is a legitimate competing proposal for the PageView-only case, and it removes the dependency entirely. If the only thing the package buys us is the settings UI, say that out loud and let the decision be about the settings UI.