Meta Conversions Api Bundle Laravel Package

Product Decisions This Supports

• Server-side conversion tracking: build vs. buy. This package is the "build-light" option — it wires Meta's Conversions API (CAPI) into Symfony's DI container, config, and HTTP client so engineering isn't hand-rolling payload signing, hashing, and retry logic. The decision it informs: do we pay a CDP/tag-manager vendor (Segment, GTM server-side, Elevar, Littledata) per event, or own a thin in-app integration?
• Measurement roadmap / ROAS reliability. CAPI is the mitigation for signal loss (ATT, ad blockers, cookie deprecation). Adopting it is a roadmap line item under "marketing attribution accuracy," with an owner (eng), a dependency (Meta Events Manager access), and a measurable outcome (Event Match Quality score, deduplicated event coverage).
• Event taxonomy ownership. Shipping this forces the product org to define and version a canonical event schema (Purchase, AddToCart, Lead, ViewContent), stable event_id values, and which PII gets hashed and sent. That's a product decision, not a marketing one — it needs a PM-level owner because it touches checkout flows and data governance.
• Consent and privacy posture. Sending hashed email/phone/external_id server-side is a data-processing decision under GDPR/CCPA and, in practice, a legal-review gate. This bundle makes the capability cheap to enable, which raises the risk of enabling it without the consent gate — a decision worth pre-empting.
• Martech vendor consolidation. If marketing already has a tag manager or CDP, this package may be redundant or actively harmful (duplicate events, split ownership). If they don't, it's a low-cost way to avoid a new SaaS line item on the P&L.
• Platform/architecture investment. Whether the commerce platform exposes a stable, first-class "conversion event" abstraction that any destination (Meta, TikTok, Google, GA4) can consume — this package is one implementation behind that interface, not the interface itself.

When to Consider This Package

Adopt when:

• The application is Symfony (5/6/7) with a conventional bundle + autoconfigure setup. This is not a Laravel package: there is no service provider, no config publish stub, no facade. In a Laravel codebase you'd be adopting the underlying HTTP/SDK logic manually or writing your own client — budget for that, or evaluate Meta's official PHP Business SDK directly.
• You have PHP engineering capacity and a Symfony-native codebase; the marginal cost of integrating is measured in days, not sprints.
• You're running paid Meta acquisition at a volume where attribution accuracy visibly moves ROAS — typically meaningful spend, not a test budget.
• You already have (or will build) a consent gate and a deduplication strategy (shared event_id between Pixel and CAPI; fbc/fbp cookie propagation).
• Your marketers can operate Events Manager (test events, match quality) — otherwise you've built a pipe with no one watching the output.

Look elsewhere when:

• Not Symfony. Laravel/Slim/WordPress teams should not adopt this; the integration cost erases the benefit.
• You need multi-destination tracking (Meta + Google + TikTok + GA4). One bundle per network is a maintenance tax; a CDP or an internal event bus pays for itself.
• You require vendor SLAs, security review, or a support contract. One star, zero dependents, and a single agency maintainer is a bus-factor of one. Fine for a pilot; not fine as a critical-path dependency in an enterprise commerce stack.
• High event volume where you need batching queues, backpressure, circuit breakers, and dead-letter handling as first-class features — verify what the bundle delegates to Symfony Messenger vs. what you must build.
• Your catalog/order data lives behind an ERP or offline channel (offline conversions, in-store) — this bundle is web-event shaped.

Risk note for the decision record: low adoption is the dominant risk. Mitigate by wrapping it behind an internal ConversionTracker interface so a swap to another implementation is a contained change.

How to Pitch It (Stakeholders)

To executives: Meta's browser pixel is losing signal — ad blockers, iOS ATT, cookie restrictions — which means we're increasingly bidding on incomplete conversion data and likely overpaying for purchases we can't see. Server-side conversion tracking recovers that signal. This package is a free, MIT-licensed Symfony integration that lets our own engineers send purchase and funnel events directly to Meta instead of buying a per-event SaaS tool. Expected outcome: better-attributed ad spend and defensible ROAS numbers, at near-zero licensing cost. The catch is maturity — it's a small open-source project with one maintainer and almost no adoption. Recommendation: fund a scoped spike (≈1–2 engineering weeks including consent gating and event dedup), wrap it behind our own interface, measure Event Match Quality and dedup rate, and only then decide whether to keep it or swap in a vendor.

To engineering: It's a Symfony bundle using the standard DI/config/HttpClient stack — integration surface is small and idiomatic. We will not call it from controllers directly; it sits behind a ConversionTracker interface with our own DTOs so we can test it, stub it, and replace it. Work items: event schema + versioning, stable event_id generation shared with the client-side pixel, PII hashing, fbc/fbp capture at landing, consent gating, Messenger queueing, and failure observability. Known risk: single-maintainer, one star, zero dependents — treat as a vendored dependency we may fork.

To marketing: You get server-side Purchase/Lead/ViewContent events with deduplication against the pixel, and a test-event code path for validation in Events Manager. You own the acceptance criteria: match quality score, event coverage vs. actual orders, and no duplicate conversions. You also own the taxonomy sign-off — if event names drift, the data is worthless.

To legal/privacy: The package makes it trivial to transmit hashed identifiers (email, phone, external_id) to Meta server-side. We will not enable it in production without a documented lawful basis, a consent gate at the point of capture, and confirmation that hashing-as-pseudonymization meets our DPIA position.