Quick Answer: Funnelish now offers native pixel apps, including Meta, that handle browser and server-side dedup automatically with no code. Custom code is needed for destinations without a native app, to unify a funnel's tracking with the rest of your Shopify store's data, or to track events outside the native app's standard set. Either way, pick one source of truth per event so nothing double-counts.

Key Takeaways

• Funnelish has a native Meta Pixel app that handles browser and server-side (Conversions API) delivery and deduplication automatically, no custom code required, per Funnelish's own current documentation.
• Custom code, loaded in the page head with lazy load off, is still the right approach for destinations Funnelish doesn't natively support, for unifying a funnel's tracking with your main Shopify store's pipeline, or for tracking events outside the native app's standard set, which Funnelish's own docs discourage forcing through the native app anyway.
• Double-counting happens when more than one system fires the same event for the same funnel: the native app plus a separate custom script, or the native app plus Aimerce or another Shopify-side tool running in parallel.
• If the Funnelish page and Shopify checkout live on different domains, identifiers like fbp, fbc, and click IDs need to carry across that handoff, or attribution breaks even when the event itself fires correctly.
• Verify by pulling Meta Events Manager data scoped to the funnel's specific URL and comparing it to actual Shopify orders for the same window. Confirming a pixel fires isn't the same as confirming it's counting correctly.

Why does Funnelish need its own tracking setup?

Because Funnelish is a separate technical environment from your Shopify theme, and whatever tracking works on your main storefront doesn't automatically extend to a Funnelish funnel.

A lot of brands run Funnelish as the front door: an advertorial-style landing page that reads like an article but is actually the ad, with Shopify behind it handling fulfillment. That's a common setup because advertorials tend to convert better than a standard product page. But Funnelish renders its own pages independently, so any tracking has to be configured on it specifically, either through its native pixel apps or through custom code, not inherited from the main site.

This is exactly the kind of gap that gets missed operationally. A Funnelish funnel usually gets set up by whoever's running that specific campaign, a media buyer or an agency, not necessarily the person who owns tracking on the main site. Nobody's explicitly responsible for checking it, so it doesn't get checked until a campaign's numbers look off.

Should you use Funnelish's native pixel app, or custom code?

Use the native app when one exists for your destination. Use custom code when it doesn't, when you need the funnel's data unified with your broader Shopify tracking setup, or when you need to track something the native app's standard event set doesn't cover.

Funnelish's native Meta Pixel app, configured directly in the funnel's app settings with no code, automatically tracks standard events (Page View, Lead, AddToCart, InitiateCheckout, Purchase, CompleteRegistration), fires critical events through both the browser and Meta's Conversions API, and handles deduplication between the two internally. It also supports up to five pixels running simultaneously, useful if you're tracking across multiple Meta Business Managers. For a destination with this kind of native support, there's no reason to hand-write a script.

Custom code still matters for three real cases. First, a destination Funnelish doesn't have a native app for. Second, situations where you want the funnel's events flowing through the same pipeline as your main Shopify store, so the same identity resolution, deduplication logic, and destination list apply everywhere rather than the funnel being tracked as an island. Third, tracking something specific to your funnel that falls outside the standard event set, a particular upsell step reached, a VSL watched past a certain point, a specific variant selected. Funnelish's own documentation actually discourages pushing custom events through the native app, noting they're subject to iOS 14 limitations and can produce inaccurate tracking data, which makes a purpose-built custom event a case where hand-coding, or having it built correctly for you, is the more reliable path anyway. That second case, unifying with your broader stack, is exactly where reaching out to Aimerce is worth it: the same server-side infrastructure that handles your main site's Meta, Google, TikTok, Pinterest, Snapchat, and Klaviyo tracking can generate a correctly formatted script for a Funnelish funnel too, so the funnel isn't a separate, disconnected tracking setup from the rest of your stack.

Where exactly does a custom tracking script go on Funnelish?

In the page head, with lazy load turned off. Both settings matter, and getting either one wrong is the most common cause of a Funnelish funnel silently underreporting.

In the funnel's settings, under Tracking Codes, creating a new custom code gives you a code placement dropdown, select "Append to page head," not body, and a Lazy Load toggle, make sure it's unchecked. Lazy loading introduces a delay before the script executes, long enough in some cases to miss the event window entirely. Nothing errors out when this happens. It just shows up later as AddToCart or Purchase events attributed to that funnel sitting unusually low, sometimes near zero, in Events Manager, even while real orders are coming in through Shopify.

How do you stop a funnel from double-counting the same purchase?

By making sure only one system is the source of truth for a given event, and that every system reporting on it uses the same event ID.

Double-counting happens when more than one tracking path is active for the same funnel and the same event: Funnelish's native pixel app alongside a separately added custom script for the same destination, or the native app alongside a Shopify-side tool like Aimerce also sending events for that funnel's traffic. Either combination means the destination platform sees two conversions where there was one, and reported ROAS inflates in a way that eventually shows up as declining ad account data quality. The fix: decide one source of truth per event and destination, and if more than one system genuinely needs to be active, make sure they share consistent event IDs so the destination's own deduplication logic can actually match them. If the funnel and your Shopify checkout live on different domains, also make sure identifiers like fbp, fbc, and any click ID get forwarded across that handoff, since cookies don't cross domains on their own, and losing that identifier mid-funnel breaks attribution even when the event itself fires correctly.

Funnelish vs. Checkout Champ vs. Lightfunnels: do they need the same setup?

The underlying principle is identical, each is a separate environment needing its own tracking setup, checked independently, but the specific mechanics differ by platform.

A setup that works on Funnelish won't necessarily behave the same way on Checkout Champ or Lightfunnels, since each platform has its own rendering behavior and app ecosystem. If you're running more than one landing page builder across different campaigns, check each one on its own. A working Funnelish setup says nothing about whether Checkout Champ or Lightfunnels are configured correctly.

Should you build this yourself?

If a native app covers your destination, configuring it yourself in Funnelish's settings is a short task with no code involved. Custom code is where it's worth being more careful.

If you're comfortable pasting custom code into Funnelish's Tracking Codes settings and you already have a correctly formatted script, dropping it in is a 10-minute job. Where it gets harder is knowing exactly which fields the script needs for a server-side payload to work properly, order ID, value, currency, hashed email, event_source_url, and keeping event IDs consistent if you're running several funnels or unifying the funnel with your main site's tracking. That's worth reaching out to Aimerce for before launching real spend behind it. A misconfigured custom script doesn't throw an error, it just quietly under-reports, and it's usually not noticed until ad spend and actual revenue stop lining up.

How do you verify the setup is actually working?

By confirming events are counted correctly against real orders, not just confirming that a pixel fires at all.

• Pull events attributed specifically to the funnel's URL, not the domain as a whole.
• Compare Purchase (or Lead, if that's the funnel's goal) events from that URL against actual Shopify orders for the same window.
• If using custom code, confirm it's placed in the head, not the body, and that lazy load is off, the single setting responsible for most silent failures.
• If running more than one landing page builder, check each one separately. A working Funnelish setup tells you nothing about Checkout Champ or Lightfunnels.
• Use a pixel-testing tool (like Meta's own Pixel Helper extension, or Test Events in Events Manager) with ad blockers disabled while testing, since ad blockers can make a correctly working setup look broken during a test.

FAQ

Does a Funnelish funnel need its own Meta Pixel setup? Yes, but it's easier than it used to be. Funnelish now has a native Meta Pixel app configurable with no code, handling both browser and server-side delivery with automatic deduplication. Custom code is only needed for destinations without a native app, or to unify the funnel with your broader Shopify tracking.

Why would Funnelish tracking fail without throwing any errors? Usually a custom script lazy-loading instead of loading immediately in the page head. The delay can cause it to miss the event window entirely, and none of this throws a visible error, it just shows up later as lower event counts than actual orders.

Can Funnelish and a Shopify-side tool both send the same Purchase event? Yes, if both are active for the same funnel without coordination. Pick one source of truth per event, and if more than one system is genuinely active, use consistent event IDs so deduplication works.

Do Checkout Champ and Lightfunnels have the same tracking rules as Funnelish? The general principle is the same, each is a separate environment needing its own setup, checked independently, but the specific placement rules and available native apps differ by platform.

Do I need a developer to set up Funnelish tracking? Not for destinations with a native app, that's configured in settings with no code. For custom code, dropping in an already-correct script is quick; getting the payload fields and event IDs right across multiple funnels is where it's worth reaching out to Aimerce.

Does Funnelish's native pixel app handle deduplication automatically? Yes, for events sent through that app specifically. Funnelish sends critical events from both the browser and server with matching deduplication data built in. The double-counting risk comes from adding a second, separate tracking source for the same destination and funnel, not from the native app itself.

What fields does a custom Funnelish tracking script need for server-side delivery? At minimum, order ID, value, currency, a hashed customer identifier like email, and the event_source_url. Missing or inconsistent fields here are a common cause of a script that fires but reports inaccurately.

Can I track a custom event, like reaching a specific upsell step, through Funnelish's native pixel app? Not reliably. Funnelish's own documentation discourages pushing custom events through the native app, citing iOS 14 limitations and a risk of inaccurate tracking data. Custom events are one of the clearer cases where custom code, built correctly, is the more dependable path.

Sources

[1] Funnelish, "Facebook Pixel"

[2] Funnelish Community, "Meta Pixel (Facebook Pixel) - Documentation"

Related reading

• Top 5 Headless Shopify Tracking Solutions in 2026
• One Pixel, 16+ Destinations: How Aimerce Moves Your Data
• What Is Server-Side Tracking and How Is It Different From Client-Side Tracking?