Experiment Laravel Package

Product Decisions This Supports

• Testing roadmap bets on live traffic instead of in a meeting. The package supplies the delivery half of an in-app A/B test: declarative experiments with weighted variants, deterministic hash-based assignment (sticky per visitor, no database round-trip), variant resolution through a facade and Blade helpers, and goal/conversion counters per variant. A PM can put a CTA, pricing page, onboarding step, or checkout flow in front of a slice of traffic and let observed behavior — not opinion — settle the question. It is the mechanism for the test, not proof the test was conclusive.
• Making the build-vs-buy call on experimentation itself. Adopting this is a decision to own the assignment layer (which the package provides) while retaining full responsibility for the measurement layer: exposure logging, goal deduplication, bot filtering, reporting SQL, and statistical inference. That split is often right for a small Laravel-native team and clearly wrong for one that expects rigor out of the box — so evaluating the package forces the useful, explicit conversation you want to have before signing a vendor contract.
• De-risking releases with progressive exposure. The same primitives back feature gates: a 0/100 experiment is a rollout flag, a 10/90 split is progressive exposure. One adoption could serve a growth team running tests and a platform team reducing launch risk — provided the API and persistence model survive a bounded spike first. Keep gates and tests in separate namespaces, since gates should not be counted as exposures.
• Keeping experiment data in-house. For privacy-sensitive, data-residency-constrained, or high-volume freemium products where per-MTU vendor pricing scales badly, in-app assignment and goal logging into your own tables removes a vendor surface and a procurement cycle. The trade is explicit: the analytical rigor a vendor would have supplied becomes a roadmap item you must staff.
• Turning experiments into code-reviewed artifacts. Experiments declared in config are reviewable in PRs, testable with forced variants, and cheap to retire — a real governance improvement over hand-configured campaign tools, if the team centralizes experiment names in an enum and funnels every goal through one service/event seam.
• Lowering the activation energy for "let's just test it." The PM-facing value is not the bucketing math; it's that shipping a test becomes a two-hour engineering task rather than a procurement cycle. That only pays off if a review-and-decide ritual already exists — otherwise you generate data nobody acts on.
• Enforcing sample-size discipline as a product habit. The package splits traffic and reports nothing about whether a result is real. Agreeing a minimum runtime and sample size before launch, and resisting daily peeking, is a PM process decision this adoption surfaces rather than solves.

Evidence caveat. Public signals are weak: zero dependents, overall score 0.3, opportunity score ~20, and a latest release (2.4) whose only change is Laravel 9 support from a first-time contributor. Treat capability as plausible and maintenance as unproven — the decision is whether a thin, swappable integration is worth the optionality.

When to Consider This Package

Consider it when:

• You are on Laravel 8/9 (verify the require block in composer.json first — release notes only confirm Laravel 9), and the app is a monolith where server-rendered or server-resolved variants are natural.
• You need simple, sticky, percentage-based splits and rollout flags, not multi-variate optimization, sequential testing, or a stats engine. This is the "three variants, one primary metric" tool.
• You have — or will staff — an engineering owner for the measurement layer: a single TrackConversion seam, deduplication policy per goal, bot/user-agent filtering, and a reporting query (exposures per variant, conversions per variant, conversion rate, date range).
• Data residency, privacy, or vendor cost pushes you toward keeping exposure and conversion data in your own schema.
• You can commit to the hygiene rules up front: experiment names in an enum, variant resolved once per request at the edge (never client-side), weights frozen after launch, and an explicit experiment lifecycle (running → stopped → shipped, with the losing branch deleted).
• You are willing to wrap it behind an internal interface — resolve(experiment, identity): string and converge(experiment, goal, identity): void — so a hosted service or a fork is one class, not a refactor.

Look elsewhere when:

• You are on Laravel 10+. Budget for a fork before you budget for features; the last release only widened support to Laravel 9, itself past security support.
• You need statistical rigor out of the box — significance testing, guardrails, sequential analysis, sample-ratio-mismatch alerts. There are no dashboards here; reporting is SQL you write.
• You need client-side or cross-service experimentation (mobile apps, SPAs resolving variants locally, edge/CDN bucketing). Client-side selection destroys stickiness and causes render flicker.
• You require guaranteed support, SLAs, or a security review trail. Zero dependents and sparse release notes mean you are the maintainer in practice.
• Your experiments need audience targeting, mutual exclusion across overlapping tests, or holdout groups at scale — that is vendor territory.
• Nobody owns the analysis and decision ritual. Without it, this is a cheap way to accumulate inconclusive data.

Before committing, verify in a spike: supported PHP/Laravel matrix; whether assignment is derived from identity each request or persisted in session/cache (cache flush must not reassign visitors); whether conversions dedupe and what the published schema actually contains (if there's no unique constraint on (experiment, goal, identity), your SQL must DISTINCT); behavior under config:cache and route:cache; and whether you can add columns to the tracking tables without patching the package.

How to Pitch It (Stakeholders)

To executives: This is a small, free Laravel library that lets us run A/B tests and gradual rollouts inside our own app, with data staying in our database — no vendor contract, no per-MTU pricing, no procurement cycle. It makes "let's test it" a two-day engineering task instead of a quarter of vendor onboarding. The honest framing: it gives us the plumbing to split traffic, not the analytics to conclude anything — we own the reporting and the statistics. Given the project's public signals are thin (no downstream users, a single maintainer-of-record, last release only added Laravel 9 support), I recommend a bounded spike, not a platform commitment: cap the integration behind a thin internal interface so switching to a vendor or a fork later is a one-file change.

To engineering: The ask is roughly a week: one experiment end-to-end (a landing-page CTA test, 50/50) to validate three things we can't learn from the docs — stickiness, conversion deduplication, and behavior under config:cache. Then a ExperimentResolver interface with a fake()/force() implementation so every variant is testable deterministically, an enum of experiment names, a single TrackConversion seam where deduplication and bot filtering live, and one artisan command that prints exposures and conversion rates per variant. If the spike shows the package persists assignments in session/cache rather than deriving them from identity, we stop and reassess — cache flushes silently reassigning visitors would invalidate every readout.

To the growth/product team: What changes for you is turnaround. Today a test is a vendor conversation; after this, a test is a config change plus a controller branch you can ship in an afternoon. What does not change: you still have to name the hypothesis, agree the minimum runtime and sample size before launch, and resist checking the dashboard daily. The package will happily produce a confident-looking conversion-rate table on an underpowered test — deciding when a result is real remains our job, and it's the part most likely to go wrong.

The one-line recommendation: Worth a scoped spike in a Laravel 9 monolith where we're prepared to own the measurement layer; not worth it on Laravel 10+, and not a substitute for an experimentation vendor if rigor is the requirement.