Experimentation Tooling Installed to Survive an Audit

What a finished install has to prove: Four numbers decide whether a test tool is installed correctly. The variant renders before the browser paints the control, not after. The sample ratio mismatch check on every running experiment stays above p = 0.001. At least 99 percent of exposure events join to a session row in your warehouse. And a visitor who moves from Safari on a phone to Chrome on a laptop stays in the same variant. Most stacks handed to me fail the last two, silently, and have been failing them for months. This engagement fixes them and leaves the checks running daily, so the next break surfaces within a day rather than at the end of a quarter when a result looks strange and nobody can say why. Tools: VWO, Optimizely Web and Feature Experimentation, GrowthBook self-hosted and cloud, Statsig. I have no vendor preference I will defend for free. The tool follows the decision about where assignment happens, and that follows your rendering architecture. If your site is server-rendered and your tests change prices, limits or logic, a visual editor is the wrong purchase and I will say so before you sign anything. What the work touches: Snippet placement and the anti-flicker path, including the case where a consent banner blocks the tool until acceptance. Consent handling under TCF v2.2 and Consent Mode v2, which for Spanish and EU traffic decides how much of your population you are allowed to bucket at all. That is the largest and least discussed source of missing data in European stacks. The event taxonomy: exposure events, the metric events they join to, and a naming convention your analysts will still understand in a year. Assignment logging into BigQuery, Snowflake or ClickHouse, because a result you cannot recompute outside the vendor dashboard is not a result. Bucketing keys and sticky assignment across device and login state. A Playwright suite that forces each variant and asserts it rendered, so a deploy that breaks a running test fails CI instead of quietly halving your sample. Migrations: Moving from a client-side tool to a flag-based one is the most common request here, and it is not a port. The tests that made sense in a visual editor are usually not the tests worth rebuilding. I will tell you which to abandon rather than carry. Not included: I do not write hypotheses or set the test roadmap in this engagement. That is separate work and it is the more valuable half. No analytics rebuild, no tag manager cleanup beyond what the install requires, no CMP selection, no CDP migration. I do not sit in your vendor negotiation, though I will tell you privately what the contract is worth. Who this is not for: Teams whose highest-traffic template sees fewer than about 25,000 sessions a week. At that volume the tool is not the constraint. You will run four tests a year and none of them will resolve, and a better installation will not change that arithmetic. I say this on the first call and do not invoice for the privilege. Also not for teams who want a tool in place so a board slide can say experimentation exists. That install is already available to you at no cost: it is called a dormant snippet. How it runs: I work inside your repository and your tracker, in English or Spanish. Your engineers merge and deploy; I write the code, the checks and the runbook, and I review the pull requests. What you keep is a working stack, a monitoring job that alerts when SRM or join rate degrades, and a document your next hire can read without me.