URL Parameter Capture Rules

When a visitor arrives at a FunnelFlux tracking link, the URL typically carries several query parameters -- campaign names, click IDs, zone IDs, and other values populated by the traffic source. This document explains exactly which of those parameters enter the analytics database, which are available only transiently, and how FunnelFlux constructs outgoing redirect URLs through layered data passing.

What Gets Stored in Analytics

Only URL parameters that are explicitly configured as tracking fields in the traffic source definition are stored in the analytics database and available in reporting.

Any parameter in the tracking link URL that does not map to a configured tracking field is ignored for reporting purposes. It will not appear as a filterable attribute, column, or breakdown dimension.

This is an important distinction: configuration determines storage, not the mere presence of a parameter on the URL.

The Session Buffer

Although unconfigured parameters are excluded from the analytics database, they are not discarded entirely. All URL parameters -- configured or not -- are temporarily held in the visitor's session buffer.

This means:

• A parameter like zone=abc123 will be accessible via the {data-zone} token during the visitor's session, even if "zone" is not defined as a tracking field.
• You can use {data-PARAMETERNAME} tokens in data passing to forward these transient values to landers, offers, or postback URLs.
• The values remain available for the lifetime of the session (approximately 24 hours).
• They will not appear in reporting or the analytics database.

This behavior also applies to parameters injected mid-funnel through action links. For example, if a lander form submission passes email=bob@smith.com into an action link, you can reference {data-email} in subsequent data passing even though "email" is not a tracking field.

Tracking Field Configuration

Each traffic source in FunnelFlux has a set of tracking fields that define which URL parameters should be captured and persisted.

Field Structure

Every traffic source includes:

Each field has three components:

When a click arrives, FunnelFlux reads the URL parameter whose key matches the field's name and stores the value. The placeholder is only relevant at click time on the traffic source side; by the time FunnelFlux receives the request, it has already been replaced with the actual value.

Reserved vs Custom Fields

FunnelFlux tracking fields fall into two categories: reserved fields with dedicated reporting columns, and custom fields for capturing additional data.

Reserved Fields

The two reserved fields have special treatment:

These fields use their own tokens ({campaign} and {external}) rather than the {data-...} pattern. They always appear as top-level reporting columns regardless of traffic source configuration.

Custom Fields

Custom fields (slots 1 through 20) are accessible via {data-FIELDNAME} tokens, where FIELDNAME is the name/alias you assigned to the field.

For example, if you name field 1 "country" and field 2 "zone":

• {data-country} resolves to the value captured in field 1
• {data-zone} resolves to the value captured in field 2

Custom fields appear as available attributes in reporting, labeled by whatever name you assigned. They can be used as breakdown dimensions, filters, and column values.

How Offer URLs Are Built

When FunnelFlux redirects a visitor to an offer, the final URL is assembled from multiple layers. Each layer can add or override query parameters. The layers are applied in order of increasing priority:

Layer 1: Base URL

The offer's base URL as configured in the offer settings.

https://network.example.com/offer/123

Layer 2: Offer Source Data Passing (Inherited Template)

If the offer is associated with an offer source (e.g., an affiliate network), the offer source's data passing template is applied. This template defines default query parameters that should be appended to every offer from that source.

A typical offer source template might specify:

sub1={hit}&sub2={campaign}&sub3={data-zone}

This provides consistent data passing across all offers from the same network, so you do not need to configure identical parameters on every offer individually.

Layer 3: Offer-Level Data Passing (Overrides)

The offer itself can define additional parameters or override parameters inherited from the offer source. If a parameter key appears at both the offer source level and the offer level, the offer-level value takes precedence.

For example, if the offer source sets sub3={data-zone} but the offer overrides it with sub3={data-keyword}, the final URL will use the offer-level value.

Layer 4: Node-Level Overrides (Highest Priority)

Individual funnel nodes can append extra URL parameters. In the funnel builder, clicking a page node and navigating to additional settings reveals an "Append Extra URL Parameters" option where you can define a raw query string.

Node-level parameters take highest priority and override all other layers.

Accumulated URL Parameters

Nodes also support a "Receive Accumulated URL Parameters" toggle. When enabled, FunnelFlux dumps all known URL parameters from the visitor's session into the page URL on redirect. This includes every tracking field value, every transient session value, and any parameters injected via action links.

Use this option only when you have a specific need for it, as it can produce very long URLs.

Final Result

After all layers are merged, FunnelFlux resolves any tokens in the URL and performs the redirect. The final URL might look like:

https://network.example.com/offer/123?sub1=h_abc123&sub2=camp_456&sub3=zone_789&custom=value

How Lander URLs Are Built

Landers follow the same general pattern but with a simpler layer structure:

Landers do not inherit from offer sources. There is no equivalent of the offer source template layer for landers. All data passing is configured directly on the lander entity or at the node level in the funnel.

The VID Parameter

The VID (Visitor ID) is a special parameter that FunnelFlux manages automatically. You generally do not need to configure it manually.

Automatic VID Handling

Explicit VID Passing

If you need to pass the VID explicitly (for example, to a third-party system), use the {visitor} FunnelFlux token in your data passing configuration:

click_id={visitor}

VID sessions have an expiry of approximately 24 hours, driven by the underlying session infrastructure. If a session expires, a returning visitor will receive a new VID unless the ff_sr session recovery cookie mechanism is able to rebuild the session.

PII Handling

FunnelFlux supports passing personally identifiable information (PII) such as email addresses and phone numbers to traffic source integrations for conversion optimization (e.g., Facebook CAPI, Google Enhanced Conversions).

How PII Flows Through the System

1. PII values are received via postback parameters (e.g., pii_email, pii_phone) or JavaScript conversion calls.
2. FunnelFlux detects these values and appends them to outgoing postbacks, including those going to traffic source integrations.
3. Integrations automatically detect whether the value is already hashed. If not, FunnelFlux hashes them appropriately for the target platform's API requirements.

What Is NOT Stored

PII data is processed transiently. It is:

• Used in real-time to populate outgoing postback and integration requests
• Hashed as needed for traffic source APIs
• Not stored in the analytics database
• Not available in reporting

PII values may temporarily appear in system logs but are not persisted in any user-facing data store. This design ensures that sensitive personal data passes through the system for optimization purposes without being retained.

Updated on: 05/05/2026