Weave Code
Experiment Laravel Package
orchid/experiment
A Laravel package for running experiments and A/B tests. Define variants, assign visitors, track conversions, and review results through a straightforward API, making it easy to add controlled feature and UI tests to your application.
AB tests for Laravel
Frequently asked questions about Experiment
- How do I install orchid/experiment in a Laravel application?
- Install it with composer require orchid/experiment, then publish the package config and any migrations with the vendor:publish command. Declare your experiment with weighted variants, resolve the variant once at the edge of the request in middleware or a controller, and branch on that value in your view. The footprint is small and the facade is the main contract, so a single experiment is roughly a two-hour integration. Verify the service provider and migration diff before upgrading between releases.
- Which Laravel and PHP versions does orchid/experiment support?
- The public release signal is thin: the latest release, 2.4, is described mainly as adding Laravel 9 support, and the full Laravel and PHP support matrix is not clearly documented. You should read composer.json and diff the recent pull requests to confirm the exact constraints before committing to a roadmap. If you are on Laravel 10 or newer, plan for a fork rather than assuming upstream compatibility.
- How does orchid/experiment assign visitors to variants?
- Assignment uses deterministic hash-based bucketing over weighted variant definitions, resolved in-process through the facade with no external service involved. Because configuration lives in code, experiments are reviewable, testable, and cheap to retire. The key rule is that the variant is resolved server-side and passed down as a value, so the client never picks a variant, which keeps stickiness and avoids render flicker.
- Can I use orchid/experiment with Blade, Inertia, or Livewire?
- Yes. The package ships Blade helpers, and the recommended pattern is to resolve the variant once in middleware or a controller and pass it to the view or Inertia props as a plain value. Livewire and JSON APIs work the same way as long as the server decides the variant. Wrap the package behind a thin internal interface such as resolve(experiment, identity) and converge(experiment, goal, identity) so controllers never learn the package API directly.
- Does orchid/experiment track conversions and report experiment results?
- It provides goal and conversion counters, but it stops at assignment plus counting. Exposure logging, goal deduplication, bot filtering, attribution windows, reporting, and statistical inference are not included and remain your responsibility to build. That split is fine for a small team that wants the mechanism in-house, but it is the wrong choice if you expect experimentation rigor out of the box.
- Is variant assignment sticky if I clear the cache or change variant weights?
- This depends on whether the package derives the variant from the visitor identity on every request or remembers it in the session or cache. Identity-derived assignment is cache-flush-proof by construction, while session- or cache-based assignment can silently flip when caches are cleared. Changing weights mid-flight can also reshuffle hash buckets for existing visitors. Determine which mode the package runs in before your experiment count grows.
- Can I add columns to the exposure and goal tables or enforce deduplication?
- The shipped schema needs to be checked for a unique constraint on experiment, goal, and identity, because without one your reporting SQL must dedupe itself. If the tables lack useful fields such as context, dedupe key, or user-agent, verify whether you can extend them through published migrations without patching the package. If not, plan a small fork or a post-processing step in your own measurement layer.
- How do I test experiments with orchid/experiment in PHPUnit?
- Because experiment definitions are plain code, you can assert that a given identity consistently resolves to an expected variant and that conversions register against the correct goal. Stub or bind your internal resolver interface in the test container so feature tests do not depend on the package facade. Also test the cache-cleared path to confirm assignment stays sticky for the same identity.
- Is orchid/experiment actively maintained and safe to build on?
- The signals are weak: zero dependents, a low overall score, sparse release notes, and a latest release that only widened support to Laravel 9, which is itself past security support. The dominant risk is maintenance rather than functionality, so assume a low probability of tracking future Laravel majors. If you adopt it, fork the repository, pin to a commit, and treat the fork as the artifact you actually support.
- What are the alternatives to orchid/experiment for A/B testing in Laravel?
- Hosted experimentation and feature flag services handle assignment plus the measurement layer, including exposure logging, deduplication, bot filtering, and statistical readouts, at the cost of a subscription and an external dependency. Building around orchid/experiment keeps the mechanism in-house and cheap to retire but leaves reporting and inference to you. Compare the cost of that measurement layer against a hosted service before committing, especially if you need rigorous results rather than simple flags.
Weaver
How can I help you explore Laravel packages today?