Articles on: Funnel Building

Advanced Node Types

Funnels in FunnelFlux are built from interconnected nodes. While page group nodes handle the bulk of visitor-facing routing, several specialized node types exist for controlling traffic flow, splitting audiences, optimizing performance, and simplifying complex funnel structures.


This document covers every available node type and how they work together through the action link system.


Page Group Nodes

Page group nodes are the primary building blocks of any funnel. Each page group contains one or more pages of the same type and represents a destination where a visitor will actually see content.


Key characteristics:

  • Lander groups hold landers, and offer groups hold offers. You cannot mix landers and offers inside the same page group node.
  • When multiple pages exist in the group, traffic is distributed by rotation weight (percentage-based split testing)
  • Page groups can be local (existing only within a single funnel) or global (shared across multiple funnels, where configuration changes propagate everywhere the group is used)


Local vs global page groups:

  • Local page groups are created directly in the funnel builder via right-click or the node palette. Their configuration is isolated to that funnel.
  • Global page groups are created on the Page Groups page in the app and can be dragged into any funnel from the node palette. Editing a global group in any funnel (or on the page groups page) updates it everywhere.


Global page groups are useful when you want the same set of pages across many funnels -- for example, a rotating list of top-performing offers that you adjust over time without editing each funnel individually.


Condition Nodes

Condition nodes route visitors based on rules you define. When a visitor reaches a condition node, the system evaluates the rules and sends the visitor down the matching route.


What conditions can check:

  • Country / region
  • Device type (mobile, desktop, tablet)
  • Browser
  • Operating system
  • ISP
  • Connection type
  • Any captured URL parameter data (from traffic source tracking fields)


How conditions are structured:


Conditions are built from three components in a hierarchy:

  1. Routes -- the outgoing connections from the condition node. Each route corresponds to a path in the funnel. Routes are evaluated from lowest number to highest (top to bottom). The first matching route wins. If no route matches, the default route is used.
  2. Rule groups -- groups of individual rules within a route. Multiple rule groups are joined by OR or AND operators.
  3. Rules -- individual matching criteria, such as "Country IS US" or "ISP CONTAINS google". Available operators vary by attribute (IS, IS NOT, CONTAINS, DOES NOT CONTAIN, ANY IN, etc.).


Logic example:


To match "US + Android" OR "Canada + iOS", you need two separate rule groups joined by OR -- each group containing two rules joined by AND. Combining all four rules in a single group would produce incorrect matching.


Local vs global conditions:

  • Local conditions are created in the funnel builder and exist only within that funnel.
  • Global conditions are created on the Conditions page. When inserted into a funnel, their configuration is linked -- changes made anywhere (including inside the funnel builder) affect every funnel using that condition.


Global conditions are marked with a (G) indicator on the node in the funnel builder.


Rotator Nodes

Rotator nodes split traffic by percentage weight across multiple outgoing connections. Unlike condition nodes, rotators apply no conditional logic -- distribution is purely percentage-based.


Key characteristics:

  • Each outgoing connection from a rotator has a percentage weight
  • Traffic is distributed according to these weights
  • You can use multiple rotator nodes in a single funnel


Stickiness and anti-affinity:


Rotator nodes support stickiness and anti-affinity settings, which are stored in the visitor's session. These settings control whether a returning visitor sees the same destination they were previously routed to (stickiness) or is deliberately sent somewhere different (anti-affinity).


When to use rotators vs conditions:

  • Use rotators when you want to split traffic by percentage without caring about visitor attributes (e.g., 50/50 split test between two paths)
  • Use conditions when routing should depend on visitor characteristics (e.g., country, device, ISP)


Note: The traffic node (see below) is technically a rotator node.


Traffic Nodes

A traffic node marks the default entrance point of a funnel. It is the node you would typically generate tracking links for when sending traffic into the funnel.


Key characteristics:

  • Traffic nodes are optional -- you can generate a tracking link targeting any node in the funnel, not just the traffic node
  • Internally, a traffic node is a rotator, so it supports percentage-based splitting of incoming traffic across multiple outgoing connections
  • Most funnels use a single traffic node at the top, but this is a convention, not a requirement


AI Nodes

AI nodes are intelligent rotators that use Bayesian inference to automatically optimize traffic distribution. Instead of you manually setting and adjusting percentage weights, the AI node learns from conversion data and shifts traffic toward better-performing paths over time.


Key characteristics:

  • AI nodes are a paid add-on feature
  • They can optimize by conversion rate or revenue per view
  • They replace manual rotators in scenarios where you want the system to find the best-performing path automatically
  • The optimization is driven by statistical models, not simple "send everything to the winner" logic -- Bayesian inference balances exploration (testing underperforming paths) with exploitation (favoring known winners)


When to use AI nodes vs rotators:

  • Use rotators when you want fixed, manual percentage splits
  • Use AI nodes when you want the system to automatically discover and favor the best-performing destination based on live conversion data


Action Proxy Nodes

Action proxy nodes are passthrough nodes that take any incoming action and route it out to the same action number. They do not contain pages, evaluate conditions, or split traffic. Their sole purpose is structural -- simplifying complex funnel layouts.


Use case:


Consider a listicle lander with 10+ outgoing action links, each pointing to a different offer. Without an action proxy, you would need to draw 10+ individual connections from that lander to each destination node. With an action proxy node placed between them, the lander connects once to the proxy, and the proxy fans out to each destination -- keeping the funnel visually manageable.


How it works:

  • An action proxy node receives an action (e.g., action 3) and passes it through unchanged
  • The outgoing connections from the proxy are numbered to match the expected actions
  • The visitor experiences no delay or additional redirect -- it is purely a routing consolidation mechanism


Action proxy nodes are especially valuable in funnels with many pages that share the same set of downstream connections, such as listicle-style funnels where every article page links to the same collection of offers.


Webhook Nodes

Webhook nodes are currently in development. They will allow funnels to fire HTTP requests to external systems as part of the routing flow, enabling integration with third-party services, CRMs, and custom backends directly from the funnel logic.


Middleware Nodes

Middleware nodes are currently in development. They will enable custom processing logic to be inserted into the funnel routing pipeline, moving FunnelFlux in the direction of a full orchestration platform.


All navigation between nodes in a funnel is driven by the action link system. Understanding how action numbers work is essential to building funnels correctly.


When a visitor is on a page in a funnel and clicks a call-to-action button or link, that link points to an action URL:

https://track.example.com/action/1

The number after /action/ (1 through 255) tells FunnelFlux which outgoing connection to follow from the visitor's current node. FunnelFlux then:

  1. Identifies the visitor (via VID in URL, referrer, or cookie)
  2. Determines which funnel node the visitor is currently on
  3. Looks up the outgoing connection matching the specified action number
  4. Routes the visitor to the destination node (which may be another page group, a condition, a rotator, or any other node type)
  5. If the destination is not a page, traversal continues automatically until a page node is reached


Action numbers map to connections

In the funnel builder, each outgoing connection from a page node is labeled with an action number (Action 1, Action 2, etc.). Different buttons on the same page can use different action numbers to route visitors to different destinations.


Example: A landing page with two buttons could use:


Action links contain no destination information. They only specify which action number was taken. FunnelFlux resolves the destination at runtime based on the funnel configuration and the visitor's current position.


This means:

  • The same page can be reused in multiple funnels with completely different action destinations
  • Changing where an action routes requires editing the funnel connections, not updating links on the page
  • Action links are generic and portable -- https://track.example.com/action/1 works across any funnel the visitor is currently in


You can retrieve action links in the funnel builder by:

  • Clicking a page node and navigating to the Action Links tab in the settings panel
  • Right-clicking a connection and selecting Get Action Link


Maximum actions

A single page node supports up to 255 action numbers (action 1 through action 255). This is more than sufficient for even the most complex pages.

Updated on: 05/05/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!