Advanced Traffic Source Settings

This article covers the advanced configuration options available within traffic source settings. These go beyond the basics of tracking fields and simple postback URLs, covering cost attribution, modifiers, custom conversion scenarios, and HTML-based tracking.

For an introduction to creating and configuring traffic sources, see Add Your First Traffic Source.

Cost Settings and Attribution

FunnelFlux provides several mechanisms for tracking and attributing costs to your traffic.

Cost Per Entrance (CPE)

FunnelFlux attributes cost to visitors using the cost per entrance (CPE) field on each traffic source. When a visitor enters a funnel, the system reads the cost value from the URL and records it against that visitor.

The CPE field accepts a token from the traffic source that dynamically passes the cost for each click. For example, PropellerAds can pass real-time cost using its {cost} token:

However, most traffic sources -- particularly those billing on a CPM (cost per thousand impressions) basis like Facebook, Google Ads, and native platforms -- cannot pass real-time cost per click. This is because CPM pricing means the cost is calculated per impression batch, not per individual click, making it mathematically impossible to assign an exact cost at click time.

Handling CPM-Based Cost Values

Some traffic sources pass a CPM bid value rather than a per-click cost. For these sources, prepend cpm_ before the cost token in the CPE field:

In a live URL, this produces something like ...&c=cpm_12.34. The FunnelFlux edge server detects the cpm_ prefix and automatically divides by 1000 to calculate the per-click cost. For example, cpm_12.34 becomes 12.34 / 1000 = 0.01234 per click.

This is useful for pop, redirect, and push traffic sources that pass CPM bid values through dynamic tokens.

Retrospective Cost Updates

When a traffic source cannot pass real-time cost, you must update costs after the fact. FunnelFlux provides three methods in the Update Costs section of the UI:

1. Simple update -- Apply a total cost to all visitors matching a funnel, traffic source, and date range. FunnelFlux divides the total by visitor count to calculate an average cost per visitor.
2. Segmented update -- Paste a table of cost data segmented by one or more tracking fields (e.g. ad ID, zone ID). FunnelFlux applies the cost proportionally within each segment for greater accuracy.
3. CSV upload -- Upload a CSV file containing cost data broken down by tracking field values. Limited to 5000 rows per upload.

For the most accurate data, segment cost updates by the most granular dimension available from your traffic source reporting -- such as ad ID for Google Ads, or site/zone ID for push and native networks.

See Updating Cost Data for Campaigns for full instructions.

Incoming Cost Overrides

As an alternative, you can set a cost override at the funnel level under the funnel's advanced settings. This applies a fixed cost per entrance to all visitors from a specific traffic source, regardless of what cost value (if any) appears in the URL.

This is useful for applying an approximate average cost in real time before doing a proper retrospective update at the end of the day.

See Using Incoming Cost Overrides for details.

Automated Cost Syncing with Argosync

For automated cost updates, FunnelFlux integrates with a separate partner platform called Argosync. Argosync connects directly to traffic source reporting APIs and automatically pushes cost data into FunnelFlux, eliminating the need for manual updates.

This is particularly valuable for high-volume advertisers running across many campaigns and traffic sources where daily manual cost updates would be impractical.

Revenue and Cost Modifiers

Traffic sources include two modifier settings under Advanced Settings that adjust financial values in real time:

Incoming Cost Modifier

When enabled, this multiplies all incoming cost values by the specified percentage. Use this to account for click loss between the traffic source and your tracker.

• A value of 110 multiplies costs by 110%, adding 10% to compensate for visitors that the traffic source charged for but never reached FunnelFlux.
• A value of 100 leaves costs unchanged (no effect).
• A value of 90 would reduce incoming costs by 10%.

This modifier applies at the point of entrance, before the cost is written to the analytics database.

Outgoing Revenue Modifier

When enabled, this multiplies the value of the {payout} token used in postback URLs sent to the traffic source.

• A value of 75 sends 75% of the actual revenue back to the traffic source.
• A value of 100 sends the full revenue (no effect).
• A value of 120 would inflate the reported revenue by 20%.

This is useful when you do not want to disclose your full conversion value to the traffic source, or when you need to adjust the optimization signal for the platform's bidding algorithm.

The modifier only affects the {payout} value in outgoing postbacks and custom scenarios. It does not change the revenue recorded in FunnelFlux reporting.

Disable Zero-Revenue Postbacks

Under advanced settings, the Disable zero revenue postbacks toggle controls whether FunnelFlux fires postback URLs (or custom scenario integrations) for conversions or custom events that have a payout value of zero.

When enabled, any conversion or custom event with $0.00 revenue will be recorded in FunnelFlux but will not trigger a postback or API call to the traffic source.

This is useful in scenarios where:

• You track non-revenue custom events (e.g. "page view", "form start") that should not be sent to the traffic source
• An affiliate network occasionally fires postbacks with zero revenue that would pollute your traffic source's conversion data
• You only want the traffic source to optimize on revenue-generating events

When disabled (the default), all conversion and custom events trigger outgoing postbacks regardless of their revenue value.

Custom Conversion Scenarios

For platforms that support Conversions API (CAPI) or similar server-to-server integrations, FunnelFlux offers custom scenario options as an alternative to manual postback URLs.

These are configured in the traffic source's conversion tracking section:

After selecting a scenario, you will need to provide the required credentials and, in most cases, authorize FunnelFlux to access your advertising account.

Available Integrations

The following platform integrations are available as custom scenarios:

• Facebook Conversions API (CAPI) -- Sends conversion events directly to Meta's server-side API, bypassing browser-based pixel limitations. This is the recommended approach for Facebook and Instagram campaigns.
• Google Ads Offline Conversions -- Uploads conversion data to Google Ads. Note that Google enforces a minimum 6-hour delay between the click and the conversion upload. Conversions sent before this window may be rejected.
• TikTok Events API -- Server-side conversion tracking for TikTok campaigns.
• Microsoft Ads -- Server-to-server conversion reporting for Microsoft Advertising (Bing Ads).
• Snapchat -- Server-side conversion tracking for Snapchat Ads.
• Reddit -- Conversion reporting via Reddit's server-to-server integration.
• Twitter/X -- Server-side conversion tracking for X (formerly Twitter) ad campaigns.

How Custom Scenarios Work

Custom scenarios fire automatically when a conversion is recorded for traffic originating from that traffic source. They behave similarly to postback URLs but handle the API authentication, formatting, and delivery requirements specific to each platform.

Behind the scenes, these integrations are implemented as postback URLs to custom cloud functions that translate the conversion data into each platform's required API format and handle the delivery. In the future, more of these will be handled natively on FunnelFlux's backend.

Triggering Events

Each custom scenario (and postback URL) has a triggering event selector. By default, scenarios fire on standard conversion events, but you can configure separate entries for different custom event types. This is particularly useful for platforms like Meta, TikTok, and Google where you may want to send multiple event types (e.g. "Purchase", "Lead", "Add to Cart") as distinct conversion actions.

Tracking Field Limits

Each traffic source supports up to 22 tracking fields total:

• 2 reserved fields:
• campaign -- for passing the traffic source's campaign identifier
• external -- for passing the traffic source's unique click ID, used for conversion attribution
• 20 custom fields -- for capturing any additional data the traffic source provides (publisher ID, zone ID, creative ID, country, etc.)

Custom fields are configured with a parameter name and a default value (typically a dynamic token from the traffic source). Only data captured in configured tracking fields enters the analytics database and appears in reporting. URL parameters that are not mapped to a tracking field are stored in the session temporarily but do not persist to analytics.

HTML Pixel Tracking

In addition to postback URLs and custom scenarios, traffic sources support HTML-based conversion tracking. This covers any client-side content that must load in the user's browser on a conversion page:

• Image pixels
• iFrames
• JavaScript tags and script blocks

HTML tracking content is configured in the traffic source's conversion tracking section alongside (or instead of) postback URLs. You can use both simultaneously -- for example, firing a server-side postback and loading a client-side pixel on the same conversion event.

Requirements

For HTML tracking to work, you must install the FunnelFlux conversion JavaScript on the page where conversions occur (typically a thank-you or confirmation page). The conversion JS triggers the loading of any HTML content configured on the traffic source.

HTML content is loaded by the user's browser, which means:

• It cannot be triggered by a server-side postback from an external system like an affiliate network
• It depends on the user reaching the conversion page and the page fully loading
• It is subject to ad blockers and browser privacy restrictions

When to Use HTML Tracking

HTML tracking is appropriate when:

• A traffic source requires a client-side pixel or JavaScript tag for conversion tracking and does not support server-to-server postbacks or API integrations
• You need to fire a retargeting pixel on conversion pages
• The traffic source's tracking documentation specifically calls for placing a script tag or image pixel

In general, prefer server-side methods (postback URLs or custom scenarios) over HTML tracking wherever possible. Server-side tracking is more reliable since it does not depend on the user's browser behavior, page load completion, or ad blocker settings.

Updated on: 05/05/2026