Php Sdk Laravel Package

Product Decisions This Supports

• Attribution feature roadmap. The deterministic attribution core (12/12 golden fixtures, 57/57 field parity) is the engine behind channel-credit reporting — first-touch, last-touch, and rule-based multi-touch models can be scoped as product features rather than research spikes. Field parity against a reference implementation means the output schema is stable enough to design dashboards and exports against.
• Build vs. buy for measurement. A self-hosted attribution core removes per-event vendor fees and keeps raw conversion data in-house. This is the strongest lever for teams currently paying a SaaS attribution provider on volume-based pricing, or whose finance team objects to black-box credit models.
• Consent-gated analytics as a shippable capability. The inclusion of a consent model at v0.1.0 signals that GDPR/CCPA gating is treated as a first-class concern, not a later patch. This unblocks roadmap items in regulated markets and reduces the risk that attribution data collection is retrofitted into a compliance incident.
• Server-side event delivery. BatchClient transport supports server-to-server event shipping to a warehouse or ad platform, which is the architecture required for cookieless/browser-restricted environments. This supports decisions about whether to invest in first-party collection infrastructure now.
• Buy/build sequencing. Because this is a library rather than a platform, it can be adopted behind a feature flag inside an existing Laravel app — a low-commitment way to validate attribution requirements before committing to a platform vendor or a dedicated data team.

When to Consider This Package

Adopt when most of the following hold:

• The stack is PHP/Laravel and the team wants attribution logic in-process rather than as a separate service.
• Requirements are rule-based and deterministic — auditable, reproducible credit assignment where a stakeholder can ask "why did this conversion get this credit?" and get a stable answer.
• Compliance is a gating requirement: consent state must be checked before events are recorded or transmitted, and the team needs that enforced in code rather than in policy documents.
• There is a warehouse or ad platform endpoint that accepts batched events, and the team is comfortable owning delivery reliability (retries, dead-lettering, backfill).
• The team wants to validate the attribution model before buying a vendor product, or is replacing a vendor on cost or data-residency grounds.

Look elsewhere when:

• The requirement is algorithmic, probabilistic, or ML-driven attribution (data-driven models, Shapley values, cross-device identity graphs). This package does not claim to solve identity resolution, and deterministic rules will not satisfy a marketing org asking for data-driven multi-touch.
• Real-time streaming or sub-second decisioning is needed — batch transport implies latency, and there is no stated streaming path.
• The team is not on PHP, or already runs a consolidated analytics stack (e.g. warehouse-native attribution) where a second engine creates reconciliation work.
• Production SLAs and long-term support are required now. v0.1.0 with an 11-test suite is a foundation, not a hardened dependency; there is no evidence yet of load testing, retry/backoff semantics, or a deprecation policy.

How to Pitch It (Stakeholders)

For executives: This is the attribution engine we would otherwise rent or build from scratch. It gives us an auditable, in-house answer to "which channel gets credit for this conversion" at no per-event cost, and it enforces consent before any data leaves our systems — reducing both vendor spend and regulatory exposure. It is early-stage (v0.1.0), so the ask is a contained pilot behind a feature flag, not a platform migration.

For engineering: The release ships a deterministic attribution core validated against 12/12 golden fixtures with 57/57 field parity, plus a consent model and a batch transport client. Parity with a reference implementation is the important signal: it means output records are schema-stable and behavior is reproducible, which makes migration and regression testing tractable. The stated test suite is 11/11 — thin for the surface area, so treat retry/backoff, batch failure handling, and consent edge cases as unknowns to probe during evaluation rather than as covered ground.

For product: Adopting this converts attribution from a vendor integration into an owned feature area. The practical near-term wins are consent-safe conversion tracking and rule-based channel reporting; the practical constraint is that it will not answer identity-resolution or data-driven-model questions, so those stay on the roadmap as separate decisions.