Limits — what Zippy cannot do

This page exists because this market has been sold unfalsifiable claims for years. One practitioner who pays for a market-leading deep-link tool put it this way about the category's headline promise:

"I have tried to look over stats to see how beneficial it is but honestly, it is really hard to prove if higher conversion is because of deep linking or not. I have heard some people say that they have doubled income with deep linking. I think that is pretty bogus."

— u/gotechgeek, r/Amazon_Influencer, 2025-01-15

He's right to be sceptical, and we'd rather be the vendor who writes its own ceiling down than the one he's describing. Everything below is true of the code as it is shipped today.

---

The technique is not novel, and it is not a moat

Zippy serves a small https page that the in-app browser will happily load, and that page's JavaScript fires the destination app's own URL scheme from inside the webview. That's the whole trick.

It is the same trick URLgenius, Feature.fm and Linkfire already use. We verified it directly: URLgenius's own launch script fires instagram://… straight from the webview, with no Safari punt and no user-agent sniffing. Routing like this is copyable in about a week, and several tools that do it are free.

What we'd actually claim: it's the same escape the paid tools use, it's open source, it's free forever at the redirect layer, and we show you the rate. Not that we invented anything.

A competitor already ships the app-open number

We are not the only tool that reports what percentage of your visitors reached the app. A musician in the same r/musicmarketing thread that documents this whole problem said so unprompted:

"I use URL Genius, which works well and shows what percentage of users made it to the app. iOS is usually around 100%, but unfortunately you won't like the Android number. Typical hovers between 30 and 40%."

— newbathroomtime, r/musicmarketing, 2026-05-10

Two things follow, and we should own both. The number is table stakes, not a differentiator. And those percentages are his, measuring URL Genius's mechanism — not ours. We quote them as what a user reported, never as a Zippy benchmark and never as something we've reproduced.

We do not defeat Meta

There is no reliable, silent, 100% escape from an in-app browser, and anyone promising one is selling you something. This is cat-and-mouse: Meta's browsers change what they allow, without notice, and sometimes suppress a scheme navigation that wasn't triggered by a real tap.

Zippy's mitigation on iOS is that the interstitial renders an "Open in the app" button, so there's a user-gesture path when the automatic one is blocked. That is better than a dead end. It is not a fix, and it costs you a tap. On iOS we also never auto-redirect to the browser when the app doesn't open — a silent redirect a second and a half after a tap reads as a glitch — which does mean some visitors sit on a page that says the app didn't open.

We only help when the link points at a supported host

Zippy matches on hostname. If your Zippy link's destination is a Hypeddit, SubmitHub or HyperFollow landing page, Zippy does a plain redirect and the in-app browser trap is entirely intact.

That means using Zippy for this requires a real change to your funnel: the landing page comes out of the chain and the link points straight at Spotify. You lose the service chooser and whatever that page captured for you. We'd rather say that here than let you find it out from a flat campaign.

Which music services we actually support

Two: Spotify (partially) and Apple Music. Not SoundCloud, Bandcamp, Deezer, Tidal or Amazon Music — those have no entry in the table and get a plain redirect with no app open and no outcome measurement at all.

And two known defects we're not going to bury:

• Spotify episode, show, and spotify.link URLs open the Spotify app's home screen, losing your destination. Because the app already took the navigation, the web fallback is never reached — so for those shapes Zippy is worse than no Zippy.
• music.youtube.com opens the YouTube app, not YouTube Music. The host is currently matched by the YouTube entry. Treat YouTube Music as unsupported.

Full detail: Streaming services.

One Spotify detail we have not verified on a device

Zippy emits spotify://track:<id> for iOS. Spotify's own documented URI form is spotify:track:<id> — one colon, no slashes. Those are not the same string, and no one has yet confirmed on a physical device that our form routes to the specific track rather than to the app generally. The Android intent carries the same shape and the same open question.

Our confidence that a Zippy Spotify link opens the specific track: moderate, unverified. That it opens something in the Spotify app: higher, still unverified. If it doesn't route, the failure is safe — Android follows the web fallback — but "safe" here means "lands on Spotify web, logged out", which is the exact failure you came to fix.

We'll update this section the moment there's a recorded device test rather than before.

Android is worse, and our Android number is currently wrong

Two separate things, both unflattering, and the second is worse than the first.

Android really is worse in the wild. Every practitioner report we have says so — see the iOS ~100% / Android 30–40% quote above. If you see an iOS figure anywhere, do not assume it generalises.

And Zippy's own Android measurement is currently biased toward success. Here is the actual mechanism, because you should be able to check us:

The interstitial registers a visibilitychange listener, then branches on the OS. On Android it fires the intent:// URL and returns immediately — so the copy swap, the pagehide listener and the nine-second long-stop are never registered on Android at all. Consequences:

1. Android has no path to record a "browser" outcome. The only outcome Android can report is opened. Since the app-open rate is opened ÷ (opened + browser + broken), the denominator is structurally missing its failures and the rate trends toward 100%.
2. Worse: Android failures are likely recorded as successes. When the intent fails and the browser navigates to the fallback URL, it fires visibilitychange → hidden on the way out — and that listener is registered. So a failure can be counted as opened. That's a false positive, not just a gap.
3. Android visitors also never see the honest "the app didn't open" copy, and never get the retry button.

So: Zippy does not publish an Android app-open rate, and you should not act on one. Our own instrument is currently incapable of showing that Android is worse; it's biased to show Android as perfect. If your dashboard shows a suspiciously high Android number, that is this bug, not your campaign.

There is a second, smaller unverified claim in the same area: intent:// handling is a Chrome feature, not a generic Android WebView feature, and Meta's Android in-app browser is WebView-based. Whether Meta's WebView parses intent:// at all is not verified in our code today.

The app-open number is a heuristic, not a fact

Zippy does not observe the Spotify app launching. It cannot — no web page can. What it actually does is fire the scheme and then watch its own page's visibility:

So the known false readings are:

• A phone lock, an incoming call, or a notification tap inside that window hides the page and reads as opened.
• A Spotify cold start slower than nine seconds reads as browser, even though the app opened.
• On Android, the branch above means most of this never runs at all.

On top of that, the counts come from Cloudflare Analytics Engine and are sampled.

Read every app-open figure as a rate or a trend, never as per-click truth. Compare two links with a clear gap between them; do not act on a decimal point, and do not reconcile these counts against anything financial.

What the number cannot tell you

The sharpest objection to this whole category came from a musician, not a competitor:

"Just because it doesn't track, does not necessarily mean that they didn't go through to the app, or find you manually on the app, and listen!"

— PaulNichollsMusic, r/musicmarketing, 2026-05-10

He's right, and the inverse is the part we can't answer either. Zippy cannot distinguish a visitor whose Spotify app we launched from one who backgrounded Instagram and opened Spotify themselves. We are measuring "our page went hidden", which correlates with "we caused an app open" but is not identical to it.

Concretely, the number cannot tell you:

• Whether Zippy caused any particular app open.
• Whether the listener played, saved, or followed anything once they arrived.
• What your conversion rate would have been without Zippy.
• Anything reliable about Android today.

The only honest way to answer "is this worth it" is a controlled comparison — same creative, same audience, two ad sets, one on a Zippy link and one on your old link — judged on Spotify for Artists numbers rather than on any dashboard, ours included.

Escaping the webview makes your pixel worse

This is the finding that cuts against us hardest, and it is the one you'll hit within a week of buying.

Your Meta pixel runs inside the webview. A listener who successfully reaches the native Spotify app has left the webview — so the person who converted is precisely the person your pixel can no longer see. Fixing the app-open can make your Ads Manager reporting worse even as your real outcomes improve.

That's not theory. The musician whose thread documents this whole problem reported exactly it after fixing her funnel:

"now it seems to work. The link opens the app!!! But although I added my metapixel to the submithub landing page i get no conversions in my meta add manager but the followers of my playlist are increasing. All in all it's an improvement"

— EmilyVibezNextDoor, r/musicmarketing, 2026-05-13

And the counter-position deserves airtime too. A merchant in a parallel thread argued the whole tracking gap might be a measurement artifact rather than lost revenue — "I would hazard a guess it's an incorrectly setup pixel?" We can't rule that out for your account.

What this means practically:

• Zippy trades pixel-measurable conversions for real, unmeasurable ones. That is the actual deal. If your business depends on Meta's optimiser learning from conversion events, this tradeoff may not be in your favour, and you should test it rather than assume.
• We cannot restore the pixel signal on the other side of an app launch. Nobody can — the app is not a web page.
• Your best instrument is Spotify for Artists, which attributes independently of the pixel.

What you get on the free plan

The escape itself — the interstitial, the scheme launch, the Android intent, all 22 apps — is free-forever infrastructure at the redirect layer, on every tier including Sidekick.

The app-open receipt, the single headline percentage, is available on every tier too.

What's gated to Hero and up is the diagnosis: the opened / browser / broken split, the per-tap feed, the per-variant A/B comparison, and the device and country breakdowns. On the free plan the API returns appOpenRate: null with zeroed outcomes rather than pretending.

So the honest framing of the free tier is: you get the fix and one number, not the analytics. And per the Android section above, the device split you'd unlock is not currently trustworthy on Android anyway.

FAQ

Is Zippy's in-app browser escape different from URLgenius or Feature.fm?

Mechanically, no. Zippy serves a page that fires the destination app's URL scheme from inside the webview, which is the same technique those tools use. What differs is that Zippy is open source, free at the redirect layer, and documents its own failure modes — not the routing itself.

Can Zippy guarantee my link opens the Spotify app?

No. Meta's in-app browsers change what they permit without notice and can suppress the launch; Spotify may not be installed; some URL shapes aren't supported. On iOS Zippy renders a manual "Open in the spotify app" button as the user-gesture fallback. On Android there is no button and no page — the intent:// URL is fired immediately and its browser_fallback_url takes the visitor to your web URL by itself.

Why doesn't Zippy show an Android app-open rate?

Because it would be wrong. The interstitial returns early on Android, so the pagehide and nine-second listeners that record a "browser" outcome are never registered — meaning Android can effectively only report success, and failures may be miscounted as app opens. We're not publishing a number our own bug inflates.

Will using Zippy improve my Meta Ads Manager conversions?

Probably the opposite. A listener who reaches the native app leaves the webview your pixel runs in, so successful conversions become invisible to Meta. Real outcomes can rise while reported conversions fall — judge these campaigns on Spotify for Artists and keep a control ad set.

How accurate is Zippy's app-open percentage?

It's an inferred rate, not a count. Zippy fires the app's scheme and infers the outcome from whether its own page goes hidden, so a phone lock reads as an app open and a cold start slower than nine seconds reads as a browser. The data is also sampled. Read it as a trend and compare clear gaps, never decimals.

Read more

• Streaming services — the supported table, defects included.
• Meta ads to a Spotify release — the workflow these limits apply to.
• Troubleshooting — symptom-first.
• App-open receipt — the number itself, and its 90-day window.
• Deep Link Debugger — check any URL against the real table.