Statamic Ab Tester Laravel Package

Getting Started

• Install: composer require thoughtco/statamic-ab-tester, then publish the config with php artisan vendor:publish --tag="ab-tester-config" (confirm the exact tag in the README — vendor tag names have shipped both hyphenated and underscored here). Clear caches afterwards: php artisan optimize:clear && php artisan statamic:stache:clear.
• Look first at: config/ab-tester.php (enable/disable, cookie name + lifetime, tracking behaviour), the new A/B Tests item in the Control Panel nav, and vendor/thoughtco/statamic-ab-tester/src/ for the middleware and Antlers tags — the README covers the happy path but the middleware is where assignment actually happens, and it's where you'll debug 90% of "my test isn't rotating" issues.
• First use case: a two-variant headline/CTA test on a landing page. Create the control entry and a variant entry (duplicate the control, change one thing), create a test in the CP against the control entry, attach the variant, then load the URL in two fresh incognito windows and confirm you get different content and the view counter increments in the CP.
• v1.2.2 note: this is a pure patch release ("Cleanup various bugs and issues" — PR #14). No migratables, no config keys added or removed, no deprecations. Treat it as a routine composer update, but see the Gotchas section for the smoke test to run against live tests.

Implementation Patterns

Control entry + variant entries. Keep variants as real entries rather than templated string swaps. It makes copy review, publishing workflow, and post-test cleanup trivial: when the test ends, the winning variant becomes the control's content and the losing entry is deleted/archived.

Record conversions where the business event happens. Page views are recorded for you by the middleware; conversions are not. Wire the conversion call into your thank-you page, form submission handler, or add-to-cart listener:

// Verify exact facade/tag name against the package source for your version.
app(\Thoughtco\AbTester\AbTester::class)->convert('homepage-hero');

Or in Antlers on the confirmation template, e.g. {{ ab_tester:convert test="homepage-hero" }}. Always fire conversions for both variants — an unevenly instrumented conversion call is the single most common cause of a "winner" that's actually a tracking artefact.

Gate tests by environment. Disable in local and staging in config so you don't burn sample size or confuse editors, and re-enable in production deliberately.

Push the variant into your analytics. Read the assigned variant out of the cookie and emit it as a GA4 custom dimension / dataLayer value alongside the package's own counters. The CP gives you views and conversions; GA gives you revenue, segment, and device breakdowns the package does not model.

Preview without polluting data. Use whatever query-string override the package supports for QA (?ab_variant=… style) and/or temporarily whitelist your IP. Never QA by repeatedly clicking a live test.

Operational lifecycle: create → run for a fixed window with a pre-declared sample size → read results → nominate winner in the CP → apply winning content to the control → archive the test. Run one test per page at a time; overlapping tests on the same template make attribution unresolvable.

Multisite: create a separate test per site. Variant assignment cookies are shared across sites on a common domain, so a test on example.com will not automatically apply to example.fr — and if you force it, you'll get cross-site variant bleed in reporting.

Gotchas and Tips

• Caching is the number one trap. Statamic static caching, responsecache, and any CDN edge cache will freeze the first variant served and show it to everyone. Exclude test URLs from static cache (static_caching.exclude in config/statamic/static_caching.php) and bypass CDN caching for them, or the test silently measures nothing.
• Cookie consent. The assignment cookie is a functional cookie, but regulated-property clients often want it disclosed. Register the cookie name in your consent banner config so an audit doesn't flag it.
• Bots and prefetch inflate views. Crawlers, Slack unfurls, and Chrome prefetch all hit the page. Filter obvious user agents and exclude logged-in CP users from view counting; the package's counters are raw, so dirty traffic shows up as noise not an error.
• Preview mode is not a test. CP previews and live-preview requests can register views. Load the entry through its normal front-end URL when checking counters.
• Statistical significance is your job, not the package's. The results screen reports counts. Decide your minimum sample and runtime before launch, otherwise you will call a winner on a 12-view lead.
• Upgrade smoke test for v1.2.2. Because the release is described only as "cleanup various bugs and issues," check after deploying: (1) existing tests still exist and are still attached to their entries, (2) views/conversions still increment on a known test, (3) the results/CP screens render without errors, (4) the cookie is still being set with its configured name and lifetime. Take a database/stache backup before running it against live test data, since bug-fix cleanups in this kind of package sometimes change how previously recorded results are interpreted or aggregated — historical numbers may shift slightly.
• Debugging assignment: in the browser, inspect cookies for the configured name; if it's absent, the middleware isn't running (check route/middleware ordering and that the addon is registered in config/statamic/addons.php), not the test config.
• Extension points: the config file for cookie name/lifetime/tracking toggles, the package's published views if you need to restyle CP output, and the assignment/conversion layer in src/ — but note it's a small package, so fork-level changes are cheap and you should expect to read the source rather than rely on docs for edge cases like multisite and non-entry URLs.