Integrating PostHog A/B Tests with Webflow and Marketing Pages

Overview

How It Works

Step-by-Step

1. Step 1: Install the PostHog JavaScript snippet in Webflow

   Open your Webflow project settings, navigate to the Custom Code tab, and paste your PostHog JavaScript snippet into the "Head Code" section. The snippet should call posthog.init() with your project API key and the PostHog host URL. Placing it in the Head Code section ensures it loads on every page of your Webflow project, not just a single page. After pasting, publish your Webflow site so the snippet goes live.

   Verify installation by opening your published site in a browser, opening DevTools, typing posthog in the console, and confirming the object exists with your API key.

   Tip: If you use a reverse proxy or custom domain for PostHog (e.g., `e.yourdomain.com`), update the `api_host` in the snippet to point there. This avoids ad blockers that target `app.posthog.com` and significantly increases the percentage of visitors who get tracked and assigned to experiments.

2. Step 2: Create the experiment and feature flag in PostHog

   In the PostHog app, go to Experiments and create a new experiment. Give it a clear name like landing-page-hero-headline-test. Define your variants: control (current headline) and test (new headline), or use more descriptive names like benefit-led and social-proof-led. Set the feature flag key to something readable like landing-hero-experiment.

   Configure your targeting to match the audience you want to test, such as all visitors, or visitors from a specific UTM campaign. Set the rollout percentage to 100% so all matching visitors enter the experiment. Save the experiment but do not launch it yet. You need to deploy the page-side code first to avoid a state where visitors are assigned variants but see no difference.

   Tip: Use the "test" variant value as a simple string like `test` or `variant-b` rather than a complex JSON payload. On Webflow pages, you will read this value with `posthog.getFeatureFlag('flag-key')`, and simple strings are easier to branch on in vanilla JS than parsed objects.

3. Step 3: Add the anti-flicker inline style

   In Webflow, go to the specific page where the experiment runs (not the project-level settings). Open the page's custom code settings and paste this anti-flicker style into the page Head Code section (Webflow labels it "Inside head tag"):

   <style>.experiment-wrapper { opacity: 0; transition: opacity 0.15s ease; }</style>
   

   Then in the Webflow designer, add a class called experiment-wrapper to the outermost div that contains your testable elements.

   This ensures the content is invisible before PostHog loads. The transition property gives a smooth fade-in rather than a jarring pop when the content reveals. Keep this style inline and in the head so it applies before any external stylesheets or scripts load.

   Tip: Set a fallback timeout that reveals the page after 1500 milliseconds even if PostHog has not responded. This prevents the page from staying blank if PostHog's CDN is slow or blocked. Add this right after the style: `<script>setTimeout(function(){document.querySelector('.experiment-wrapper').style.opacity='1'},1500)</script>`. Users in the timeout path see the control variant, which is the safe default.

4. Step 4: Write the variant rendering code

   In the same page-level custom code section (Webflow labels it "Before body tag"), add a script block that listens for PostHog's feature flags to resolve and then manipulates the DOM:

   posthog.onFeatureFlags(function () {
     var variant = posthog.getFeatureFlag('landing-hero-experiment');
     if (variant === 'test') {
       var headline = document.querySelector('.hero-heading');
       if (headline) headline.innerText = 'Cut your reporting time by 75%';
     }
     var wrapper = document.querySelector('.experiment-wrapper');
     if (wrapper) wrapper.style.opacity = '1';
   });
   

   Use querySelector or querySelectorAll to find the elements you want to change. For a headline test, find the heading by its Webflow class and update innerText.

   For a CTA button test, find the button and update its text and possibly its href. For a section-swap test, hide the control section and show the test section by toggling a CSS class. Each DOM change should be a single, clear operation.

   Tip: If you are swapping entire sections rather than individual text elements, build both the control and test sections in the Webflow designer, give each a distinguishing class like `variant-control` and `variant-test`, and set `variant-test` to `display: none` in Webflow's style panel. Your experiment script then just toggles display between the two. This keeps both variants visually editable in Webflow.

5. Step 5: Add conversion event tracking

   Your experiment needs a goal event that PostHog can count. For landing page tests, the most common conversion events are button clicks, form submissions, or page navigations to a sign-up or checkout page. Add event listeners in the same script block:

   document.querySelector('.hero-cta')?.addEventListener('click', function () {
     posthog.capture('hero_cta_clicked', {
       variant: posthog.getFeatureFlag('landing-hero-experiment')
     });
   });
   

   For a form submission, listen to the form's submit event. For navigation-based conversions, you can configure the goal event as a pageview in PostHog's experiment settings rather than adding client-side code. Include the variant value as a property on the event so you can debug and verify that both variants are firing events correctly.

   Tip: Webflow forms redirect to a thank-you page on submission by default. If your conversion event is form submission, either fire the PostHog event on the submit event before the redirect happens, or configure a pageview-based goal in PostHog that triggers when the thank-you page loads. The pageview approach is more reliable because it does not depend on the event firing before the browser navigates away.

6. Step 6: Test both variants locally before publishing

   Before publishing to production, verify both variants render correctly. PostHog lets you override feature flag values for testing. Run posthog.featureFlags.override({'landing-hero-experiment': 'test'}) to force the test variant, then reload the page. Confirm the correct elements change, the anti-flicker behavior works (no flash of control content), and the conversion event fires in the PostHog Live Events view.

   Then run posthog.featureFlags.override({'landing-hero-experiment': 'control'}) and reload to confirm the control variant displays correctly and its events also fire. Check the live events stream in PostHog to verify that the events arrive with the correct variant property attached.

   Tip: Test on mobile viewport sizes too. Webflow pages often have different element visibility and layout at mobile breakpoints, and your experiment script may need to target different elements or handle responsive behavior. An experiment that works perfectly on desktop but breaks on mobile will produce uninterpretable results because your mobile visitors see a broken experience.

7. Step 7: Publish the Webflow page and launch the experiment

   Once both variants are verified, publish your Webflow site to push the experiment code to production. Launch the experiment in PostHog. PostHog will start assigning visitors to variants based on a hash of their distinct ID and the flag key, ensuring each visitor sees the same variant on repeat visits. Monitor the experiment dashboard over the first few hours to confirm that both variants are receiving roughly equal traffic (the split should be close to 50/50 unless you configured otherwise). Check the Live Events stream filtered to your goal event to verify conversions are recording for both variants.

   If one variant shows zero events after several hundred visitors, there is likely a bug in the DOM manipulation or event tracking code for that variant.

   Tip: Do not edit the experiment elements in the Webflow designer after launch unless you intend to change the control variant. Webflow publishes overwrite any custom code changes to the DOM, and a designer edit that changes a class name will break your querySelector selectors. If you need to update the control variant's design, update the experiment code simultaneously.

8. Step 8: Monitor for implementation integrity during the experiment

   Over the first 24-48 hours, check three things. First, verify the traffic split in PostHog's experiment view matches your configured ratio. A skewed split suggests the feature flag is not evaluating correctly, possibly because of a targeting rule mismatch. Second, check that the bounce rate and time-on-page for both variants are within a reasonable range of each other.

   A massive bounce rate increase in one variant could indicate a rendering bug that visitors see but you missed in testing. Third, check the browser console on the live page for JavaScript errors. Load the page in an incognito window (so you get a fresh session), open DevTools, and watch for errors in the console during the first few seconds of page load. Any error in your experiment script could prevent variant rendering or event tracking from working.

   Tip: Set up a PostHog insight that shows daily unique visitors split by the feature flag variant. This gives you an ongoing visual check that both arms are receiving traffic. If the line for one variant drops to zero on a specific day, investigate immediately because something likely broke in a Webflow publish.

Examples

Best Practices

• Always use the page-level custom code section for experiment scripts rather than the project-level section. Project-level code runs on every page and will execute unnecessary feature flag evaluations on pages that are not part of the experiment. Page-level code keeps the experiment scoped to exactly the pages involved, reduces JavaScript execution overhead, and makes cleanup straightforward when the experiment ends.

• Keep the anti-flicker timeout between 1200 and 2000 milliseconds. Below 1200ms, you risk showing the default content to visitors on slow connections before PostHog flags resolve, which contaminates your control group with visitors who briefly saw the wrong variant. Above 2000ms, the blank screen feels like a broken page and increases bounce rate, which hurts both variants equally and wastes traffic. Test the timeout on a throttled connection (use Chrome DevTools Network tab set to "Slow 3G") to find the right balance.

• Include the variant value as an event property on every conversion event you fire, not just in PostHog's automatic flag tracking. This lets you build custom funnels, filter session recordings by variant, and debug discrepancies between PostHog's experiment view and your own analysis. The property costs nothing to include and saves significant debugging time when results look unexpected.

• Build both variants in the Webflow designer as distinct sections or elements rather than relying on JavaScript to rewrite content. When the variant logic is limited to toggling visibility of pre-built elements, you eliminate the risk of JavaScript-generated content looking different from the design intent. Designers can review and iterate on both variants in the Webflow canvas, and you avoid complex innerHTML manipulation that can introduce XSS risks or broken markup.

• Run an A/A test on your first Webflow experiment integration before committing to a real hypothesis. Set up the experiment with identical content in both variants and let it collect data for 48 hours. If the conversion rates diverge significantly, your implementation has a bug, likely in how the anti-flicker code interacts with Webflow's rendering or in how events are tracked. This costs you two days but can save you from running a multi-week experiment on broken infrastructure.

• Document the Webflow class names and element IDs your experiment code depends on in a comment block at the top of the script. Webflow does not enforce stable class names across redesigns, and a team member editing the page in the designer may inadvertently rename a class. A clear comment listing the dependencies makes this failure mode obvious and recoverable.

• Use PostHog's $feature_flag_called autocaptured event as a sanity check that flag evaluation is actually happening on the page. Filter your PostHog events by this event name and the specific flag key. If this event is not firing for the experiment's flag, the onFeatureFlags callback is not running, which means none of your variant rendering or event tracking is working.

Common Mistakes

Frequently Asked Questions