Launch day: turn the waitlist into users.
Your waitlist gave you emails. The launch email carries where each person signed up and what they wanted, through the install, so the first screen picks up where they left off.
- Who runs it
- Marketers, product
- Time to set up
- Minutes, after the SDK
- Plan
- Free
One launch link, personal per person.
Store where each person signed up when they join the waitlist. At launch, each person's link carries that source and anything they told you about their interest. One template, filled per recipient by your email tool.
- The signup source travels with the link, through the store and install.
- Send in waves if you can; it's easier on your servers and your support.
A first screen that remembers them.
Skip the introduction they already read months ago. Lead with what they said they wanted, and honour any early-signup promise without being asked.
- Works on iPhone and Android, after a fresh install.
- Store-organic installs get the normal onboarding.
Which signup source found real users.
Installs by source tell you which channel was loud. Track an activation event by source, from the events your app sends, to see which channel found people who wanted the product.
- Installs and activations per signup source.
- The list of channels worth repeating next time.
One-time setup, then it's all yours.
Your developer adds the LinkTrail SDK before launch and reads the signup details on first open. Test the whole journey before the email goes out.
LinkTrail.onLink(link => {
// link.customData = { src: "product-hunt", interest: "marathon" }
startOnboarding(link.customData.interest);
});The full walkthrough: Launch day: turning a waitlist into installs that land in the right onboarding
A waitlist is a list of people who said they were interested once. Launch day is a single email to all of them, and then a store listing. What you learn from the default version of this is how many installed. What you don't learn is which of the pre-launch channels — the product-hunt post, the founder's thread, the newsletter mention — produced the people who actually stuck.
What problem does this solve?
Each waitlist signup came from somewhere. If the launch link remembers where, the install attributes back to the channel that produced the signup months earlier, and onboarding can reflect what they signed up for. That turns launch day from one number into a ranked list of the channels worth repeating.
How do you set the links up?
Store the acquisition source against each waitlist entry at signup. At launch, each person's link carries that source and, if they told you anything about their interest, that too. One template, personalised per recipient by your email tool.
{
"deepLinkPath": "/onboarding",
"customData": {"src": "{{signup_source}}", "wl": "true", "interest": "{{interest}}"}
}What about the people who install from the store listing directly?
They'll show up as organic, and that's correct — they are. The waitlist link is what separates 'organic because of launch buzz' from 'came back because we emailed them'. If the two numbers are similar, the waitlist did little. If the waitlist dominates, the pre-launch work is where growth came from.
- Send the launch email in waves if you can. It makes the server load survivable, and it lets you compare open-to-install by wave.
- The store listing will get traffic you can't attribute. Don't try to; use the waitlist cohort as the controlled comparison.
- Keep the waitlist link live for weeks. Launch-day installs are the minority; the long tail from people who saw the email late is often bigger.
What should the first screen show a waitlist user?
That you remember them. The payload says this person signed up months ago and told you what they were interested in; the first screen should say so back — skip the 'what is this app' introduction they already read, lead with the thing they said they wanted, and if there was a promise made to early signups, honour it here without being asked. A waitlist user who gets the same onboarding as a store-organic install has just been told the wait meant nothing. The point of carrying the source and the interest across the install is to make the opposite true.
Which metric should you watch?
Day-7 retention by signup source, measured with a return event your app sends. Installs by source tells you which channel was loud. Return events by source tell you which channel found people who wanted the product — and that is the only list worth spending on next time.
Which teams own a waitlist launch?
- Growth marketers
- Mobile product teams
Which LinkTrail features does a waitlist launch need?
- Deferred deep linking
- Per-link channel tagging
- Post-install events
- Smart routing
Launch day questions.
How do you track which channel your waitlist signups came from?
Store the acquisition source against each waitlist entry at signup. At launch, each person's link carries that source in its payload, so the install attributes back to the channel that produced the signup months earlier.
What should the first screen show a waitlist user?
That you remember them: skip the introduction they already read, lead with what they said they wanted, and honour any promise made to early signups. A waitlist user who gets the same onboarding as a store install has been told the wait meant nothing.
Which metric should you focus on after launch?
Day-7 retention by signup source, measured with a return event your app sends. Installs by source shows which channel was loudest; return events by source show which channel found people who wanted the product.
If you're doing this, you'll probably want these.
Email links
Opens the app if it's installed, the store if not. No more newsletter links opening in Safari on phones that have the app.
Onboarding that matches the ad
If the ad promised 20% off, the first screen shows 20% off. Nobody has to find the code again.
Test the whole journey first
Click, install, open, right screen. Run it on a test device before a penny goes on ads.
Make your launch link.
Free for your first 5,000 users. No card, no sales call.