Ever encountered a situation where your stats, in tree or flat view, don't seem to match up the way you would expect?

There can be a few reasons for this. Keep in mind at all times that FunnelFlux is non-linear in the tracking configuration it allows, so unlike most trackers, you can get situations that are quite complex (and sometimes impossible) to show in a table.

It's for this very reason we have the heatmap system in your funnel builder, which lets you view traffic (node visits) and conversions/revenue, in a heatmap overlay of the funnel schematic. Try to use this in complex situations as it is a much better way of presenting the basic traffic flow data than a table.

Now, on to situations where data doesn't match up. Let me outline a few common causes confusion:

​

Ever wondered what the "Show N/A" option is for?

Well, it's very important.

Because hits can enter from any part of your funnel and get to any destination without strict linear limits like traffic > offer or traffic > lander > offer, it's very easy to create groupings that make hits become invalid within the current grouping/view.

For example, you group by funnel > country > landers.

Your funnel level will contain all hits for the funnel within your other restrictions like traffic source, time range, and whether you are showing filtered traffic.

Your country level will contain all hits described by their detected country, and likely some N/A grouping for any hits where the country was unknown (i.e. there was no result in the database for some reason - it happens).

Your lander level will contain all hits that visited a lander node.

But, what if a visitor went through a rotator that sent them to an offer directly? What about a condition that sent them to an external URL?

There are plenty of scenarios for where there is X visitors but <X hits to lander nodes.

In this situation, N/A captures those that fall outside that criteria, and all children + N/A should then add to the parent row.

Well, that's in a perfect world - but you'll need to also keep in mind the next issue.

​

FunnelFlux processes stats in the background using free resources so that reporting is faster. These processes created cached "aggregates" of data, which are continuously updated.

When you run reports, especially if you are running a lot of traffic, chances are not all the data you will see is real-time and completely up to date. It could be another second or few minutes before other data appears, depending on various factors.

It's hard to make reporting real-time and prioritise redirects being as fast as possible, hence our approach here.

Here is a list of all the background reports we run. Each of these is done in buckets by date, as well as filtered/unfiltered status:

As you can see, there are a lot of background jobs that go on to ensure fast reporting for broad data aggregates. This is why drilling down by to show a single attribute within a funnel > traffic source combo is generally fast.

Now, consider a situation where you do a drilldown of some funnel and traffic source, then look at countries > landers.

In this situation, you will be pulling cached data for the parent country component since funnel > traffic source > country is a cached report.

However, the child country > lander combination is not a cached report, thus this data has to be pulled from the database directly.

In this scenario any hits that have happened but have not yet been added to the cached country report will be absent from the country parent level, and the landers below it may then sum to more than the parent.

Make sense?

So, any small discrepancies like this can  be ignored and they will usually go away over time. They are more frequent if you are pushing a lot of traffic through the system as there is a) less resources available for background jobs and b) more divergence of the raw hit data from the cached reports.

​

Another scenario that can cause configuration is changes to your funnel design.

If you alter the funnel configuration, the past data does not go away. So, you can create situations where a lander for example used to get 100% of incoming traffic.

You then add a rotator and other landers, now the traffic share goes down. If you looked at stats over the lifetime of the campaign, the original lander would of course have higher stats.

This may not see very disruptive, but if you were looking at the "coversion path" reporting, changing the lander/offer flow can have effects than cause confusion later (only if you aren't sure why the stats are like that).

Another situation: you have many landers rotating but at one point also direct linked to the offer. This resulted in a lot of direct offer views. You then change the funnel to be only via landers.

Now, if you break down your data by funnel > country > landers, as an example, the parent country row may have a lot more offer views than the sum of the landers, because a lot of direct views of the offer happened without going via the landers.

This situation of X > landers breakdown can happen quite often since you have no requirement to send traffic via a lander to get to an offer, or on the contrary could have many landers prior to multiple offers!

It's for this reason that we highly recommend using the heatmap view where possible, and to use conversion path reporting in complex situations to display the data more appropriately in a table format.

​

Finally, you may notice times where a single value is present in a column for every item in a drilldown level.

For example, you drill down by funnel > country > lander. On your landers you then have the same entrance value listed for each of them, even though the number of hits that went to them may be different.

This is because entrances are related to a funnel and can be broken down by properties of that entering visitor like country, ISP, etc.

However, an entrance can't be specifically allocated to a certain lander. 

Why? Because when a user enters, there is no guarantee that they will go to a certain lander or hit any specific node type at all -- it entirely depends on your funnel design.

The only way you could relate a funnel entrance to a lander view is when the user gets there. In that case, funnel entrances on that lander would be the same as node views, making the entrance a pointless metric to display.

Thus, the entrances are displayed relative to the next parent grouping that actually has sensible entrance splitting, based on the attributes of the visitor.

This makes it easier to compare "overall funnel visitors" to the amount of "node views" to a lander, giving you the percentage of people who ended up hitting that lander.

This type of inheritance mainly happens with the funnel entrance column and its useful to understand why it happens to avoid confusion when reading your data.