Everyone Who Opened the App. Now Email Them.

ManyChat can tell you who commented. Every link tool can tell you who clicked. Nobody else can tell you who opened the real app — because nobody else is doing the handoff that makes the app open in the first place.

Zippy has been reporting that number for a while. Broadcasts, live now on Hero and up, is the other half: you can send that group a message.

The segment nobody else has

Here's the thing about a click. Someone taps your link inside Instagram, lands in Instagram's in-app browser, sees a logged-out web page with no Apple Pay and no saved cart, and leaves. Your dashboard records a click. You learned nothing.

Zippy's whole reason to exist is springing that tap out into the real native app — and then telling you whether it worked. That means your analytics contain a category no competitor's do: the taps that ended in an app actually opening.

Save that as a segment ("app-opened, my last drop"). Then broadcast to it.

That's an audience built out of a behaviour that only exists because of the product. You can't export it from Mailchimp. You can't rebuild it in ConvertKit. The data isn't there.

What sending looks like

Write a subject. Write a body. Pick one of your links for the button. Pick your segment.

Then, before you commit to anything, you get the real number:

Not "your list is 486." The number that's actually going to receive it, after consent and unsubscribes are applied — computed with exactly the same rule the send uses, so the preview can't flatter you.

Hit send and it returns straight away. The sending happens in the background, in batches, resumably. If it dies halfway through, you retry, and the people who already got it don't get it again — that's a database constraint, not a hopeful retry counter.

Consent isn't a checkbox in our UI. It's the shape of the API.

Most tools have an unsubscribe list and a "please only mail people who opted in" line in the terms. That's a policy. Policies get worked around by whoever's in a hurry.

We did it differently: there is no way to name a recipient. The broadcast API has no to field, no recipients array, no emails parameter — not on any endpoint. You can't craft a request that specifies an address, because there's no parameter to put one in. Recipients are derived on our side from your own contacts, filtered by the consent record we stored when each person signed up.

And it's checked again — per person, immediately before their individual email goes out — against their current status. So somebody who unsubscribes while your broadcast is still going out gets skipped, even though their row was already queued. "Effective immediately" means immediately, not "on your next campaign."

The unsubscribe you can't sell

Every broadcast carries a one-click unsubscribe. Not just a footer link (though it has one, sitting right next to the exact consent wording that person originally agreed to) — the proper List-Unsubscribe headers too, so Gmail and Apple Mail show their own native Unsubscribe button and the recipient never has to open anything.

It works on every plan. It works with no account. It works instantly, forever, on every future send.

We took the same position on deleting a contact: some things are not features we're willing to put behind an upgrade. Someone's ability to get out of your inbox is one of them.

The number at the end

Here's the part that makes this worth having in Zippy rather than in a real email tool.

Every link in a broadcast is a Zippy link. You literally cannot type a raw URL into one — paste mybrand.com/sale and it gets refused, by name, before you can send it. That's not us being precious; a raw link opens in whatever browser the mail client hands it to, springs no native app, and reports nothing back.

A Zippy link opens the real app and says so. So your broadcast report has a row that no Mailchimp campaign summary will ever have:

Two honest notes, because we'd rather be trusted than impressive. We don't show "delivered" — we don't consume delivery webhooks from the mail provider, so we genuinely can't see it, and labelling accepted as delivered would be a small lie we'd have to keep telling. And the app-open figures are sampled, like the rest of your app-open analytics: a real rate and a real trend, not a per-tap tally. It says so on the screen.

Why there's no Instagram DM blast

You'll notice broadcasts are email. There's no "DM my segment" button, and there isn't going to be one.

Meta's 24-hour messaging window covers an ongoing conversation — which is exactly what your DM automations do today, legitimately, when someone comments or messages you. Re-engaging people outside that window needs message tags, one-time notifications, or paid messaging. We went and checked whether we could do that correctly for the Instagram connection your account uses, and we couldn't verify it. So we fail closed.

Blasting DMs at a list is the single fastest way for a creator to get their Instagram account restricted, and that's not a mistake we can undo for you. If a tool offers you that button, that's worth thinking about.

Email the same segment instead. Same people. Plus a number the DM was never going to give you.

FAQ

How do I email everyone who opened my app from a link?

Save a segment filtered to the app-open outcome on that link, then compose a broadcast and pick it. The preview shows the real consented recipient count before you send. One thing we'll be straight about: the join is by link — "the people who joined your list from the links this segment matched" — not a per-individual guarantee that each recipient personally app-opened. Person-level click identity is something we deliberately don't store.

Can I email people who didn't give me consent?

No. There's no plan, no setting and no API parameter that allows it. Consent is checked when the recipient list is built and again right before each individual send.

Do I still need Mailchimp or ConvertKit?

For a segment of your Zippy audience with an app-open number on the end, no — that's this. For a full newsletter operation with automations, templates and a visual builder, they're still better at being that, and you can keep piping contacts to them with the contact.captured webhook.

What happens if a broadcast fails halfway?

Retry it. Recipients who already received it aren't queued any more, so they don't get a second copy — enforced by a uniqueness constraint in the database, not by a counter that could drift. The ones who never went out get picked up and sent.

What plan do I need for broadcasts?

Hero ($19/mo) and up. Unsubscribing works on every plan, including Free, forever — as does deleting a contact.

Followers are rented. A list is owned. A list of people who opened the real app is something else entirely. It shipped here in the changelog, the full mechanics are in the docs — start zipping →