Mojito

Mojito is an open-source split testing framework built by Mint Metrics, the digital analytics consultancy, out of their own client experimentation work. Rather than shipping as a single monolithic app, it is deliberately split into three independently versioned modules under the mint-metrics GitHub organization: Mojito JS Delivery (the front-end library that buckets visitors and applies variant JS/CSS), Mojito Snowplow Storage (data models and events for tracking exposures and outcomes through the Snowplow Analytics pipeline), and Mojito R Analytics (templatable RMarkdown reports that turn raw event data into significance-tested experiment readouts).

The core idea is treating experiments as code. Each test is defined in a YAML file (id, name, sample rate, trigger, recipes) alongside plain JS/CSS variant files, then built, linted, minified and published through an npm/Gulp pipeline that can run in any CI system — the README documents both Bitbucket Pipelines and GitHub Actions setups. That means experiments go through the same pull request review, version history, and rollback process as application code, instead of living only inside a third-party WYSIWYG editor.

Because the delivery library is a small, dependency-free IIFE (the project advertises under 5KB minified and gzipped, versus roughly 80KB for Optimizely X’s snippet at the time of writing), it is aimed at teams that care about page performance and want full control over what code actually runs on their site. Storage is not locked to Snowplow either — the delivery layer just needs a storage adapter, so teams can wire exposure/outcome events to Google Tag Manager, Adobe, or a custom backend instead.

Development has been fairly quiet since 2019 (the flagship repo shows a handful of contributors and no recent commits), so this is best understood as a mature, narrowly-scoped toolkit rather than an actively-evolving platform — it solves the git-controlled, self-hosted A/B testing problem well, but teams should expect to own maintenance themselves rather than rely on upstream velocity.

What You Get

• A sub-5KB (minified + gzipped) front-end delivery library for bucketing visitors and injecting variant JS/CSS with no vendor snippet bloat
• YAML-based experiment definitions (id, sample rate, trigger, recipes) that live in source control and go through normal PR review
• A Gulp/npm build pipeline that lints, minifies, and publishes experiment containers, wired for Bitbucket Pipelines or GitHub Actions
• A Snowplow-based storage module with pre-built data models and events for tracking test exposures and downstream outcomes
• An R Analytics module with templatable RMarkdown reports that compute experiment results (e.g. mojitoFullKnit) directly from your metrics
• A pluggable storage adapter interface so exposure/outcome tracking can be pointed at GTM, Adobe, or any custom backend instead of Snowplow

Common Use Cases

• Self-hosting A/B testing infrastructure to avoid per-MTU vendor pricing and keep full ownership of experiment data
• Running experiments through the same Git workflow, code review, and CI/CD pipeline used for the rest of the site
• Testing on privacy-sensitive or regulated sites where sending visitor data to a third-party testing vendor is a compliance concern
• Building a lightweight, high-performance testing setup where a heavier vendor snippet would hurt page speed metrics
• Layering split testing on top of an existing Snowplow Analytics deployment to reuse data pipelines and warehouse infrastructure

Under The Hood

Architecture Mojito is not one codebase but a small constellation of independently versioned repositories under one organization: a browser delivery library, a Snowplow-backed storage/data-modeling layer, and an R-based analytics/reporting layer, tied together by a shared YAML experiment schema rather than by shared code. The delivery library itself is a single dependency-free IIFE that exposes a Test/Recipe object model, a pluggable decision adapter for bucketing, and a pluggable storage adapter for emitting exposure and outcome events — an integration-point style of architecture that keeps the runtime tiny while letting the storage and analytics backends be swapped out independently.

Tech Stack The delivery layer is plain, dependency-free JavaScript built and shipped through an npm/Gulp-style CLI (build, publish, deploy, new, set commands), using js-yaml to parse experiment configuration, terser and clean-css for JS/CSS minification, and the AWS SDK’s S3 client to publish built containers. Continuous integration runs on GitHub Actions across a Node.js 20.x/22.x matrix, executing npm ci, a build step, and a Mocha test suite driven headlessly through puppeteer-core and chrome-launcher. The storage layer integrates with the Snowplow Analytics event pipeline and validates experiment configuration against a self-describing Iglu/JSON-Schema definition, while the analytics layer is R/RMarkdown (knitr), designed to be run against a Redshift-style warehouse populated by Snowplow.

Code Quality The delivery library has an ESLint configuration, a Mocha-based automated test suite that runs headless Chrome via Puppeteer, and a GitHub Actions CI workflow gating builds across two Node versions — a reasonably solid setup for a small front-end library. Configuration correctness is enforced structurally: experiment YAML is validated against a JSON Schema before it can ship, which catches malformed test definitions earlier than a purely convention-based approach would. The trade-off is project activity — commit history is thin and the flagship repo has seen no meaningful updates since 2019, so code quality reflects a project frozen at a mature but no-longer-evolving state rather than one under active hardening.

What Makes It Unique Where mainstream A/B testing platforms like PostHog or GrowthBook ship as a single self-hosted application (or SaaS product) with a built-in dashboard and data store, Mojito’s defining choice is to have no dashboard and no proprietary data store at all — it’s explicitly a set of building blocks that plug into infrastructure a team already runs (Git, CI, and Snowplow or an equivalent event pipeline), with experiment definitions as reviewable YAML rather than UI-configured state. That composability is genuinely distinctive, but it comes at the cost of the batteries-included experience GrowthBook or PostHog provide, and Mojito assumes a team willing to operate CI-based publishing, a Snowplow pipeline, and R-based analysis themselves.

Self-Hosting

Licensing Model BSD-3-Clause licensed — all features available with no restrictions or license keys required.