It's quite common these days to see multi-offer landing pages that link to 5+ offers.
More often than not these open offer pages (or another pre-lander) in new tabs and its expected that a user will go back to the original page and click other call-to-actions.
Here I'll detail how to set up a funnel for this and important technical considerations to make sure it tracks properly. I'll present the basic approach first and discuss some extra (optional) precautions at the end.
Step 1: Define all your landers/offers
It goes without saying that you'll need to have all your landers and offers created in FunnelFlux. Go and do this now, you'll need them for building the funnel.
If it is a page you control, e.g. the multi-product page, pre-landers, etc. then be sure to set the redirect mode to 301 or 307. Do not use ultimate meta refresh when sending users to pages that are yours anyway.
Step 2: Create your funnel
Let's deal with a situation where you have one mutli-product lander, where each product links out to a pre-lander for that product, that then links to a third-party offer. I.e. traffic > lander > product pre-lander > offer.
Create a funnel like so:
Of course, here you should have the individual pre-lander and offer pages rather than my duplicated ones.
Now, save the funnel.
Step 3: Place FunnelFlux Javascript on all the pages you control
Click on the advanced settings section in your funnel settings then grab the universal tracking code available here:
Place this on each of your lander/pre-lander pages, ideally before </head>.
This code declares your funnel ID. The tracker will see the page URL of your visitor and try to match the visit to a node in your funnel. For this to work, make sure the URLs of the landers match what users will actually visit (mainly the multi-product lander, which is probably going to be the first page they visit).
Step 4: Update call-to-action URLs on your pages
Edit the source code of your multi-product lander to use FunnelFlux action links.
You can get these by right clicking an action in your funnel > get action's URL.
These can just be the generic, universal URLs e.g. https://domain.com/?flux_action=1
Adding the organic params with the toggle button in this prompt can be useful, but will only have an effect if users visit your page and happen to block the FunnelFlux javascript from loading and block cookies. Not that likely.
Important notes
Now, there are a few best practices you must exercise here to ensure you don't waste time with common tracking issues:
Make sure your tracking domain supports SSL -- i.e. https:// links work. Ideally load your landers using https and have all action links use https (you can toggle this as a default in your FunnelFlux system settings). Maintaining secure links throughout will help prevent common https -> http referrer blanking issues.
Do NOT put rel="noreferrer" on any FunnelFlux action links. This blanks refererr and will cause problems. Do not hide information from your own tracker! Note that rel="noopener" is fine... albeit overzealous.
When you update your call to action links, add a
flux_cta
class as well (will need this later). So if your original link looks like this:
a class="blah" href="http://domain/something">Some text</a>
Update it to look more like this:
<a class="blah flux_cta" href="https://domain/?flux_action=1">Some text</a>
It will be fine to have these links opening in new tabs (i.e. target="_blank"
), as long as you avoid the referrer issues I mentioned above.
Now, be sure to update your action links on any secondary landers you have as well -- remember the numbers in the actions need to match what you see visually in your funnel editor.
Step 5: Optional extras to improve reliability
Option 1: Injection session ID into links
With users jumping around pages and being able to come back to a previous open page (and node) to click links again, its possible for things to get a little confused.
Remember that FunnelFlux is trying to keep track of a user jumping around different nodes, so there has to be fallbacks for when a click comes from a node that the user was previously at but moved away from.
To help reduce the likelihood of errors on clickthrough (namely a 404) we can use the FunnelFlux javascript to modify action links and help keep things consistent, which doubles as a defence against cookie blocking.
This is why we added class="flux_cta"
to links earlier.
We can modify the FunnelFlux javascript to inject session IDs into these links. Find the JS code section that looks like this:
fflux.track({
timeOnPage: false,
timeOnPageResolution: 3000,
noCookies: false,
tokenInjection: {
intoUrl: false,
intoForms: { selector: null },
intoLinks: { selector: null },
tokens: {}
}
});
Here, change the code to this:
fflux.track({
timeOnPage: false,
timeOnPageResolution: 3000,
noCookies: false,
tokenInjection: {
intoUrl: false,
intoForms: { selector: null },
intoLinks: { selector: 'a.flux_cta' },
tokens: { flux_sess: '{session-id}' }
}
});
If you make this change then load your page, you should see your action URLs have been modified after the page loads -- your page source code will look the same (if you view source), but if you hover over a link or right-click > inspect, you should see something along the lines of:
<a href="https://domain/?flux_action=1&flux_sess=583495734589343034">
Magic! The JS has injected the user's session ID into the link!
Now, if a user clicks this link, FunnelFlux ignores their cookies as it has direct access to the session ID. This is especially helpful for traffic coming from the FB mobile browser and some Safari situations where third-party cookies are often blocked, which can make a mess of tracking.
Option 2: Injecting hit ID instead
You can do something similar to above but inject hit IDs instead. These are an ID or the specific view of that page from that user. They are as reliable as it can get for forcing coherent tracking.
To do this you would simply modify the code to:
fflux.track({
timeOnPage: false,
timeOnPageResolution: 3000,
noCookies: false,
tokenInjection: {
intoUrl: false,
intoForms: { selector: null },
intoLinks: { selector: 'a.flux_cta' },
tokens: { flux_hid: '{hit-id}' }
}
});
There are some drawbacks though -- note that redirects can be marginally slower to process if you use hit IDs like this, as the tracker has to look up the hit in the database.
Because of that database request, you should also be careful with this approach if you happen to use a remote database or load balanced system with managed FunnelFlux, where you have multiple redirect servers around the world.
In those situations, stick to session ID.