Google Content Experiments vs Optimizely: What Actually Changed

David SertillangeIndependent experimentation specialist
·6 min read

Google Content Experiments is the testing tool most people searching for it are not actually thinking of anymore, and that confusion is worth clearing up before comparing anything else. It was Google's original multivariate and A/B testing feature, built into classic Google Analytics, and Google deprecated it back in 2017 — years before Google Optimize, its more famous successor, was retired in 2023. If your team's testing history goes back far enough to remember Content Experiments by name, or you've simply found old documentation referencing it while researching a move to Optimizely, this guide covers what it actually was, how it differs from Optimizely, and which of two entirely different migration paths applies to you.

What Google Content Experiments actually was

Content Experiments shipped as a feature of classic Google Analytics, reachable from the Behavior section of the Analytics interface. It let you test up to ten full-page variations against a control, using a simple redirect-based mechanism: visitors were routed to one of several distinct URLs, and Analytics tracked which URL produced better performance against a chosen objective. It replaced an even earlier tool, Google Website Optimizer, and it was itself replaced by Google Optimize in 2017 — Optimize added the visual editor, more targeting options, and eventually a Google Analytics 4 integration that Content Experiments never had.

That lineage matters because it explains why searches for "Content Experiments" and searches for "Google Optimize" turn up overlapping but not identical results, and why some migration guidance written for one does not cleanly apply to the other.

How Content Experiments compares to Optimizely

The comparison is less about feature parity and more about what generation of testing tool each one represents.

Content Experiments was redirect-only: every "variation" was a distinct, separately hosted page, and Analytics split traffic across the URLs and reported which one won on the metric you configured. It had no visual editor, no client-side DOM manipulation, and no concept of audience targeting beyond what you could encode into which visitors received which redirect.

Optimizely Web Experimentation supports that same redirect-based pattern for full-page and URL-based tests, but it is one option among several rather than the only one. It also supports client-side DOM changes through a visual editor without requiring a second hosted page, audience targeting rules that go well beyond a simple traffic split, and integration with Optimizely's Stats Engine for significance testing that accounts for multiple metrics and repeated looks at the data — none of which Content Experiments offered.

Google Content Experiments (2012-2017):  redirect-only, up to 10 variations, basic Analytics objective, no visual editor
Optimizely Web Experimentation (today):  redirect-based OR visual-editor DOM changes, audience targeting, Stats Engine significance

For a team that only ever used Content Experiments for simple landing-page redirect tests, the redirect-based workflow in Optimizely — covered in the landing page A/B testing guide — is the closest like-for-like starting point, even though the platform underneath it is considerably more capable.

Two different migration paths, depending on where you're coming from

If your team's most recent testing tool was Content Experiments itself — meaning you never adopted Google Optimize before it, too, was retired — you are migrating across two deprecations at once, and there is no automated importer for either leg of that journey. Google never published an export format for live Content Experiments configurations, and the platforms differ enough structurally that a mechanical translation would not produce working tests regardless. The realistic path is the same structured rebuild any migration off a legacy Google testing tool requires: inventory what you were testing, decide whether each experiment maps most naturally to a redirect-based test or a visual-editor DOM change in Optimizely, and rebuild from there.

If instead you moved from Content Experiments to Google Optimize at some point before Optimize's 2023 sunset, you are migrating from Optimize, not from Content Experiments — and that is a more common, better-documented path. The Google Optimize to Optimizely migration guide covers that transition in full: mapping Optimize's objectives, audiences, and visual-editor changes to their Optimizely equivalents, and what does not carry over automatically.

Why there's no automated importer for either tool

The absence of a migration tool is not an Optimizely limitation specifically — it reflects a gap upstream. Google never published a machine-readable export format for either Content Experiments or Optimize configurations, so no third-party platform, Optimizely included, has anything to build an importer against. Even if one existed, the underlying models differ enough — Content Experiments' pure-redirect approach versus Optimizely's combination of visual-editor DOM changes and redirects, different audience-targeting concepts, different significance calculations — that a mechanical translation would likely produce broken or subtly wrong tests rather than a clean lift-and-shift.

That makes the rebuild a deliberate, if mechanical, exercise rather than a data-migration problem: most concepts from either legacy tool have a clear Optimizely counterpart, so the work is mapping and recreating rather than inventing a new testing program from scratch.

What actually carries over conceptually

Even without an automated path, the underlying testing logic from a Content Experiments era program is not wasted. A redirect-based page comparison — page A's URL against page B's URL, split by traffic — maps directly onto a URL-redirect test in Optimizely Web Experimentation, and any historical learnings about which page structure won are still valid evidence worth feeding into your next hypothesis, even though the original test predates the platform you're rebuilding in.

What does not carry over is the objective configuration itself — Content Experiments' Analytics-goal-based objectives have no direct equivalent field in Optimizely, since Optimizely defines primary and guardrail metrics natively rather than borrowing them from an Analytics goals configuration. Those need to be redefined as part of the rebuild, not imported.

Common mistakes

  • Assuming "Google Optimize migration" guidance covers Content Experiments too. The two tools have different underlying mechanics — Content Experiments is redirect-only with no visual editor — so guidance written for an Optimize migration will skip steps a Content Experiments migration actually needs.

  • Looking for an export file that does not exist. Neither Content Experiments nor Optimize ever published one; budget time for a structured rebuild rather than searching for an importer.

  • Treating old Content Experiments results as historical noise instead of evidence. A redirect-test result from years ago is still a real finding about what worked on that page — it belongs in your knowledge base, not the trash, even if the tooling that produced it is long gone.

  • Recreating every legacy test exactly as it ran. Some Content Experiments-era tests existed because the tool had no visual-editor option; in Optimizely, several of those may be better redesigned as DOM-change tests rather than reproduced as redirects out of habit.

Key takeaways

  • Google Content Experiments (deprecated 2017) and Google Optimize (deprecated 2023) are two different, sequential Google testing tools — check which one your team actually used before following migration guidance.

  • Content Experiments was redirect-only with no visual editor; Optimizely supports that same pattern plus client-side DOM changes, audience targeting, and Stats Engine significance testing.

  • Neither Google tool ever published an export format, so the migration path for either is a structured rebuild — inventory, map concepts, recreate — not a data import.

  • If your path ran through Google Optimize before Optimizely, the dedicated Google Optimize migration guide is the more specific resource to follow.

Frequently asked questions

Is Google Content Experiments the same thing as Google Optimize?

No. Content Experiments was Google's earlier testing tool, built into classic Google Analytics and deprecated in 2017. Google Optimize was its successor, with a visual editor and GA4 integration, and was itself retired in 2023. They are two different products in the same lineage.

Can I import my old Content Experiments configuration directly into Optimizely?

No automated importer exists, because Google never published an export format for either Content Experiments or Google Optimize. The migration is a structured rebuild: map each concept to its Optimizely equivalent and recreate the experiments you still want to run.

Which Optimizely product replaces what Content Experiments did?

Optimizely Web Experimentation covers the same redirect-based, full-page comparison pattern Content Experiments used, and adds a visual editor, audience targeting, and Stats Engine significance testing on top of it. See the landing page A/B testing guide for the closest equivalent workflow.

David Sertillange

Independent experimentation specialist

David Sertillange is an independent experimentation specialist with 10 years implementing Optimizely across enterprise programs. He specializes in Feature Experimentation, analytics integrations, and helping teams build a culture of data-driven decision making.

Subscribe

Practical Optimizely tips, monthly. No fluff.