Everyone Can Branch on a Tag. Only We Can Branch on Whether the App Opened.
DM automation conditions that act on what actually happened when someone tapped your link — the real app, or Instagram's in-app browser. Plus why we refused to build the follow-gate every other tool ships.


⚡ Zippy: same DM to everyone is fine. knowing who it failed on is better.
Every DM automation tool has conditions. Tag, no tag, subscribed, not subscribed. It's a solved problem and it's been solved since about 2019.
Here's the one no other DM tool has:

If they tapped your last link but got stuck in Instagram's in-app browser, send them something different.
Not "if they have a tag". Not "if they clicked". If the native app actually launched.
Why no other DM tool can offer this
Because the link it sent doesn't report back.
(To be clear about the market: we are not the only tool that measures app opens. URL Genius reports an app-arrival percentage, and has for a while. We're the one that lets a DM rule act on the outcome, per person.)
When a link goes out in a DM from any other tool, it's a raw URL. The follower taps it, it opens Instagram's in-app browser, and the tool's job is finished. It knows a message was delivered. It does not know what happened next, because nothing reports back — that webview is logged out, has no app session, and fires none of your pixels.
Every link Zippy sends is a Zippy link, so the tap runs through our redirect engine, which records one of four things: the app opened, it stayed in the browser, the app link was broken, or we haven't seen anything yet. That's been powering your link stats for a while. As of today it's also something a rule can branch on, per person.
What that outcome actually is — read this before you build a rule
It is an inference from our own page's visibility, not a report from Instagram or the
store. Our interstitial fires the app and then watches itself: page goes hidden → opened;
page still sitting there after nine seconds, or the visitor leaves it → browser. Nothing
ever reports back to us. So:
- A phone lock or a notification tap mid-launch reads as
opened. False positive. - A cold start slower than nine seconds reads as
browser. False negative. - The counts come from Cloudflare Analytics Engine and are sampled.
- On Android, none of the failure listeners run at all. The interstitial fires the
intent://URL and returns immediately, so thepagehidelistener and the nine-second stop that recordbrowserare never registered. An Android tap can only ever come back asopened— including when it failed.
That last one is load-bearing for this feature. The "stuck in the in-app browser" line below will not match Android users, because we cannot currently record that outcome for them. They fall through to your main message. And Android is the platform where the in-app browser trap is worst — practitioner reports put Android app arrival at 30–40% against roughly 100% on iOS. So build these rules knowing the rescue branch is an iOS rescue branch until we fix the Android path. The whole mechanism, written up by us: Limits.
Read every per-branch rate as a rate and a trend, never as per-person truth.
What that looks like in practice
One rule. Comment LINK on the reel. Everyone gets the DM.
But under Say it differently to some people, one line:
- If last tap: stayed in Instagram's browser
- Send "looks like that one got stuck 😅 here's one that opens properly"
- With your store's web checkout link instead of the app deep link
Three fields. Top to bottom, first match wins, everyone else gets your main message.
Then open Results and there's a row per condition with that line's own app-open rate next to it. So the question "did sending those people a different link actually help?" has a number, not a vibe.
What we deliberately didn't build
A flow builder. No canvas, no nodes, no dragging a line from one box to another. You get up to three condition lines on one rule, read like a list, and that's the cap. If you have opened ManyChat's flow editor and quietly closed the tab, that reaction is the entire reason this is a form. A rule you can't read at a glance is a rule you can't debug at 11pm before a launch.
The follow-gate. This is the one you came looking for, so here it is straight.
"Follow me and I'll DM you the link" is against Instagram's own Community Standards — specifically the Spam policy, which prohibits requiring users to engage (likes, shares, follows) to gain access to specific content. Other tools ship it as a checkbox anyway.
The problem isn't that it's cheeky. The problem is whose account gets actioned, and it isn't ours. If Instagram decides to enforce, they enforce on the creator running the automation. We cannot give you your account back. So we didn't build a lever we'd have to warn you not to pull.
What we built instead is follow-awareness: the rule can read whether someone follows you and change what it says — warmer for a regular, a friendly "no follow needed, but I'd love to have you around" for someone new. The link you promised goes out either way. There is no setting anywhere in the product that sends someone a DM withholding the thing your caption promised them, and there's a test in our codebase whose entire job is to fail if somebody ever adds one.
Also, and less nobly: the friendly version converts better. People who feel gated leave.
The honest bit
Native Instagram automations are built and switched off. Meta hasn't approved our app, App Review hasn't been submitted, and nothing sends to your real followers until that changes. We'll say so the day it does.
If you want the app-open escape today, with no approval from anyone: keep your existing ManyChat flow and swap the raw URL for a Zippy link. Same webview escape, same app-open numbers, works on any plan, right now — here's the recipe.
Related
- Instagram DM automations — the full setup, including the conditions section.
- ManyChat + Zippy — the version that works today.
- ManyChat tells you who commented. Zippy tells you who opened the app.
- Changelog: conditions that branch on app-open