Feedback
Roadmap

Have something to say?

Tell us how we could make the product more useful to you.

In Progress

Feature Request: Per-Variant Custom Code Injection (CSS & JS)

Allow users to attach custom CSS and/or JavaScript to individual A/B test variants, so the code only executes when that variant is served to a visitor. The Problem Optibase's A/B testing is built around element visibility toggling — showing/hiding HTML elements per variant. This works well for swapping headings, images, CTAs, and sections. However, it does not support a common testing scenario: conditionally applying custom CSS or JavaScript per variant without changing the page structure. Real-world examples where this is needed: Testing a CSS animation or transition effect on an existing element (our current use case — a typing animation on the homepage hero heading) Testing a different font treatment, gradient, or visual effect that requires custom CSS Testing a scroll-triggered interaction or micro-interaction that requires custom JS Testing a dynamic content enhancement (e.g., a countdown timer, live counter, or personalized greeting) that runs via JS on an existing element In all these cases, the page structure and HTML elements remain identical between variants. The only difference is CSS and/or JS that either runs or doesn't. Why the Current System Can't Handle This Optibase's display:none toggling mechanism does not prevent CSS or JS from executing. This is a browser-level behavior, not an Optibase limitation per se, but it means users cannot use the existing A/B system to conditionally load code: CSS inside a hidden element still applies globally. Placing variant-specific styles in a hidden embed does not scope them — they affect the entire page regardless of the parent element's visibility. Script tags inside hidden elements still execute. The browser runs JavaScript on page load regardless of whether the containing element is set to display:none. The only workaround currently available is to use a dummy trigger element as an Optibase variant, then write a custom MutationObserver script that detects when Optibase toggles the element's visibility and conditionally injects the CSS/JS. This works, but it's fragile, undocumented, and adds unnecessary complexity for what should be a straightforward test. Proposed Solution Add optional Custom CSS and Custom JS fields to each variant in the Optibase test configuration. When a visitor is assigned to a variant, Optibase's script would: Inject the variant's custom CSS into the document as a tag Execute the variant's custom JS This would happen at the same point in the lifecycle where Optibase currently toggles element visibility — after variant assignment, before the page is visually rendered to the user. UI Suggestion In the variant editor (where users currently set the variant name and connect elements), add two optional code input fields: Custom CSS — a text area for CSS rules (injected as a tag) Custom JS — a text area for JavaScript (executed after variant assignment) Both fields would be optional. Existing element-based A/B tests would continue to work exactly as they do today. The code fields would simply be an additional capability for users who need it. Benefits Unlocks a major category of tests that currently require workarounds or alternative tools (VWO, Optimizely, Webflow Optimize) No breaking changes — purely additive to the existing variant system Keeps testing centralized — users don't need to maintain separate custom scripts alongside Optibase Competitive parity — most enterprise A/B testing platforms (VWO, Optimizely, Google Optimize before deprecation) offered per-variant code injection as a core feature Reduces churn risk — users hitting this limitation today may migrate to more expensive tools that support it natively Current Workaround (For Reference) We are currently using the following approach, which works but demonstrates the demand for a native solution: A dummy div element is added to the page and connected to Optibase as a variant (hidden by default for Variant B) A custom MutationObserver script watches for Optibase's visibility toggle on the dummy element When the observer detects the variant B element becoming visible, it injects the CSS and executes the JS Optibase still handles traffic splitting, cookie persistence, and conversion tracking This is functional but adds ~40-60 lines of custom code, introduces a dependency on Optibase's internal DOM manipulation timing, and is not documented or officially supported.

Stefan Peek 8 days ago

1

Completed

Delete conversions/events

There are times where we setup the test and go through it to see if the connected conversions work correctly and then we reset the test. However, at scale across a site, these conversions may break. It would be great to be able to test and then delete that specific event from the backlog as a workspace owner to not skew data while also not pausing a test. It is also the case that we see some internal views slip through the IP blacklist so being able to delete would be helpful there too.

Jayden Lowe 4 months ago

1

Completed

After the latest update, the Ease and UX of test and conversion creation in the webflow app is even worse than before, After new conversion creation, it does not automatically take you into the settings of that conversion to set it up, But instead redirect you to the Tests tab, same when to click back button inside the conversion to go to the conversion menu, It takes you to the tests tab, After the latest update I was expecting the things to be much better But instead it got worse

Muneeb 6 months ago

1