Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.elasticfunnels.io/llms.txt

Use this file to discover all available pages before exploring further.

Learn how to test different component variants within a single funnel step. There are two ways to set up a split test container depending on how your page is built.
Looking to split test entire pages or branches at the funnel level? See Funnel Split Testing.

​
Using the Page Builder

Use this approach if you’re building your page visually in the page builder.

​
Step 1: Create Components

Right-click an element in the page builder and select Create a new component, or build the component from scratch. Repeat for each variant you want to test.

​
Step 2: Add a Split Test Container

Add a Split Test Container to your page and give it a descriptive name. The name is what appears in Page Events when you configure the test.

​
Step 3: Configure in Page Events

Open Page Events for the page and connect a Component Split Test node:
  1. Click Add Node → Component Split Test
  2. Select the container by name
  3. Set the traffic percentage for each variant and assign a component to each

​
Step 4: Connect the Node

Connect the Component Split Test node to the Entry Node or a Script Rule node to activate it.

​
Using Coded Pages

Use this approach if you’re writing page HTML directly (coded pages, custom templates). The <split-test> tag marks a section of the page as a split test zone. The tag itself is just a placeholder — all behavior (which component variant each visitor sees and at what traffic split) is defined entirely in Page Events using the Component Split Test node. The server reads that configuration at render time and replaces the tag with the winning variant.

​
<split-test> tag

Attributes
AttributeRequiredDescription
idYesUnique identifier used by the server to match and replace this container with the winning variant. Must match the container ID configured in the Page Events Component Split Test node.
nameYesHuman-readable label shown in the Page Events UI when selecting which container to target. Without this the container will not appear in the Page Events dropdown.
Syntax 
<split-test id="my-container-id" name="My Container Name">
  <!-- Default content shown if no Component Split Test node is active in Page Events. -->
  @component('my-default-component')
</split-test>
@component('...') embeds a saved Custom Component by its code. See the @component directive reference for full details. How it renders When a matching Component Split Test node is active in Page Events, the server replaces the entire <split-test> block with the resolved component variant: 
<!-- Server output -->
<div
  data-sid="[split_test_id]"
  data-fnid="[funnel_node_id]"
  data-cid="[component_id]"
>
  <!-- HTML of the winning component variant -->
</div>
If no variant is resolved (e.g. no Component Split Test node is configured in Page Events), the tag is left in place and its inner content is shown as-is. Example: A/B testing a headline 
<split-test id="headline-test" name="Headline Test">
  @component('headline-variant-a')
</split-test>
In Page Events:
  1. Add a Component Split Test node
  2. Set Container → Headline Test (matched by name)
  3. Assign variants: 50% → headline-variant-a, 50% → headline-variant-b
The component embedded inside <split-test> acts as the control (variant A) and is also the fallback shown when no Component Split Test node is active. Example: A/B testing a video section 
<split-test id="vsl-test" name="VSL Test">
  @component('vsl-control')
</split-test>

​
Inline Split Testing (Coded Pages)

Use <inline-split-test> when you want to A/B test content directly in the HTML without creating separate components or configuring Page Events. Variants and their content live inside the tag itself.
This is the simplest way to split test on coded pages. For more advanced setups (component-based variants, multi-step funnels), use the <split-test> container with Page Events described above.

​
Syntax

<inline-split-test name="My Test">
    <variant name="variant a" weight="50">
        <!-- HTML for variant A -->
    </variant>
    <variant name="variant b" weight="50">
        <!-- HTML for variant B -->
    </variant>
</inline-split-test>
Attributes
ElementAttributeRequiredDescription
<inline-split-test>nameYesHuman-readable name for the split test. Used as the record name in the database and analytics dashboard. The tag is ignored on save if name is missing.
<inline-split-test>idAuto-generatedDatabase record ID. Injected automatically on save — do not set or edit manually.
<variant>nameYesUnique name for the variant. Used to identify and track the variant across saves.
<variant>weightNoTraffic percentage (0–100). If omitted on all variants, traffic splits evenly.

​
Basic example (equal split)

When no weight attributes are provided, traffic is distributed evenly across all variants: 
<inline-split-test name="Headline Test">
    <variant name="short headline">
        <h1>Buy Now</h1>
    </variant>
    <variant name="long headline">
        <h1>Buy Now and Save 50% Today</h1>
    </variant>
</inline-split-test>
This creates a 50/50 split. For three variants it would be 33/33/34, and so on.

​
Weighted example

Send 70% of traffic to the control and 30% to the challenger: 
<inline-split-test name="Headline Test">
    <variant name="control" weight="70">
        <h1>Original Headline</h1>
    </variant>
    <variant name="challenger" weight="30">
        <h1>New Headline</h1>
    </variant>
</inline-split-test>
Weights must sum to 100.

​
Saving pages through the API

When you create or update a coded page through the public Pages API:
  • Send the full <inline-split-test>...</inline-split-test> block inside the html field.
  • The Pages API stores that source HTML as provided.
  • The create/update response does not replace the tag with the winning variant’s runtime HTML.
  • The public Pages API also does not inject the auto-managed id attribute as part of POST /api/brands/{brand}/pages or PUT /api/brands/{brand}/pages/{page}.
Example source HTML sent to the API: 
<inline-split-test name="Headline Test">
    <variant name="control" weight="70">
        <h1>Original Headline</h1>
    </variant>
    <variant name="challenger" weight="30">
        <h1>New Headline</h1>
    </variant>
</inline-split-test>
That block is the page source. It is not replaced in the API response with rendered output. At runtime, when a visitor loads the page, the server renders only the chosen variant and replaces the entire block with: 
<div data-sid="[split_test_id]" data-cid="[variant_code]">
    <!-- Full HTML of the chosen variant -->
</div>
If the page is saved through the editor save flow instead of the public Pages API, the server can normalize the tag, inject the generated id, and return the updated HTML.
If an API or editor save response returns normalized inline split test HTML with an injected id, persist that returned HTML and use it for future updates. This matters only when you send html again on a later save or update. If html is omitted because nothing changed, the existing stored HTML remains unchanged. If you do send html again and keep using the original <inline-split-test> block without the server-generated id, the server can treat it as a new inline split test and create a new split test record on every save.

​
How it works

  1. On editor save, the system validates the tag structure (the <inline-split-test> must have a name, and there must be at least 2 <variant> tags each with a name). It creates a split test database record and injects an id attribute into the tag. The name attribute on the tag is used as the split test record name. The editor updates automatically to show the assigned ID.
  2. At runtime, when a visitor loads the page the server:
    • Checks for an existing cookie (st_res_{id}) to maintain consistency for returning visitors
    • If no cookie exists, selects a variant using deterministic weighted rotation (Redis-backed for consistency across servers)
    • Sets a 7-day cookie with the selection
    • Replaces the entire <inline-split-test> block with just the chosen variant’s HTML
  3. Tracking is automatic. The rendered output includes data-sid and data-cid attributes, which the built-in tracking script picks up to fire split-test-view events. These appear in your analytics dashboard alongside regular split tests.
  4. Conversion attribution works out of the box. The split test cookie is included in conversion and click payloads, so you can see which variant drove each purchase.

​
Server output

At runtime the tag is replaced with: 
<div data-sid="[split_test_id]" data-cid="[variant_code]">
    <!-- HTML of the chosen variant -->
</div>
The variant_code is an internal identifier (e.g. v0, v1) that maps back to the variant name in the analytics dashboard.

​
Rules

  • The <inline-split-test> tag must have a name attribute. Tags without a name are ignored on save (no split test record is created or updated).
  • Minimum 2 variants required, each with a unique name.
  • Weights must be positive numbers that sum to 100. If no weights are set on any variant, traffic splits evenly.
  • Do not manually set or edit the id attribute — it is managed by the system.
  • Removing the tag from the page does not delete or deactivate the split test record. The record stays active in the database. To deactivate a split test, use the split test management UI.
  • Variant identity is tracked by name. Existing variants keep their internal tracking code (v0, v1, etc.) across saves. Renaming a variant in the HTML creates a new variant with a new code — the original variant and its analytics data remain in the record. Removing a variant from the HTML does not delete it from the split test record.

​
Tips for Effective Split Testing

  • Test one element at a time for clear results
  • Run tests long enough to get statistical significance
  • Monitor performance metrics closely
  • Document your test results for future reference