When someone shares, the friend lands on that thing.
A shared recipe, workout or listing opens on that exact content for everyone who taps it, including people who install first. No reward, just sharing that works.
- Who runs it
- Product, marketers
- Time to set up
- One app release
- Plan
- Growth, for the link API
A link made at share time.
Your share sheet asks your backend for a link with the content's ID in its data and the sharing app as the source. Links are made through the API, so every share gets one automatically.
- The content travels with the link, through the store and install.
- No referrer reward, so nothing to game.
The friend opens the workout that was shared.
With the app, it opens on the workout. Without it, the store, then the same workout after install, with who shared it.
- Works on iPhone and Android.
- No search, no 'what was it called'.
Installs per share, by content type.
Count installs per share and by what was shared. Then compare what share-driven users go on to do, from the events your app sends, with users from other sources.
- Shares, installs and events by content type.
- Which sharing apps carry the most installs.
One-time setup, then it's all yours.
Your developer creates share links through the API and routes on the link's path when the app opens. After that, every shareable screen works the same way.
LinkTrail.onLink(link => {
// link.customData = { contentType: "workout", via: "messages" }
router.navigate(link.path, link.customData);
});The full walkthrough: User-generated share links: when the thing that drives installs is the content, not the channel
Someone shares a recipe from your app to a group chat. Four people tap it. Two have the app and land on the recipe. Two don't, install, and land on the home screen — with no recipe, no idea what their friend sent, and a fair chance of closing the app. The share worked for half the people it reached.
What problem does this solve?
Every piece of shareable content in the app should produce a link that opens on that content whether or not the recipient has the app. And you want to know which content drives installs, which is a different and more useful question than which channel does.
How do you set the links up?
The share sheet generates the link at share time, with the content identifier in the payload and the sharing surface in the source tag. No referrer reward, no incentive — this is organic sharing, and the attribution is about the content, not the sharer.
{
"deepLinkPath": "/recipes/r_51902",
"customData": {"src": "share-sheet", "via": "messages", "contentType": "recipe"}
}How is this different from a referral programme?
| Referral | Sharing | |
|---|---|---|
| Incentive | Yes, both sides | None |
| Who is credited | The sharer | The content |
| Fraud exposure | High — there's a reward to game | Low — nothing to gain |
| Volume | Deliberate, lower | Incidental, much higher |
Sharing is often the larger of the two by volume and the cheaper by far, because nobody is paid. The mistake is treating it as referral-lite and bolting a reward on. A reward invites gaming; plain sharing doesn't, and the numbers stay clean.
Which content should you make shareable?
All of it, and then look at the data. The content that drives installs is rarely what the product team expected. Attribution by content identifier tells you which recipes, workouts or listings are doing the work, and that feeds directly into what to feature.
What makes people actually share?
Three things, all on your side of the link. The share action has to be one tap from the content, using the native share sheet so it goes wherever the person already talks to their friends. The link has to unfurl properly — a preview image and a title in the group chat, generated from the content itself, so the recipient sees a recipe or a listing rather than a bare URL. And the recipient's first screen has to be the content, not a sign-up wall in front of it. Ask for the account after they've seen what their friend sent; a share that lands on a login form is a share that mostly fails.
Which metric should you watch?
Installs per share, by content type, then retention of share-driven installs against other sources. Share-driven users usually retain better — they arrived with a reason and a friend. Confirming that with your own numbers is what justifies investing in the share flow.
Which teams own user-generated content sharing?
- Mobile product teams
- Growth marketers
Which LinkTrail features does user-generated content sharing need?
- Deferred deep linking
- Smart routing
- Per-link source and placement tagging
- Post-install events
Shared content questions.
How do share links work for user-generated content?
The share sheet generates a link at share time with the content identifier in the payload and the sharing surface as the source tag. Recipients with the app open straight to the content; recipients without it install and land on the same content at first open.
How is content sharing different from a referral programme?
Sharing has no incentive and credits the content rather than the sharer, so there's little to game and volume is usually much higher. Bolting a reward onto sharing turns it into referral-lite and invites fraud.
What should you measure for share-driven installs?
Installs per share by content type, then the retention of share-driven installs against other sources. Share-driven users usually retain better because they arrived with a reason and a friend.
If you're doing this, you'll probably want these.
Referral programme
Friend invites a friend. The friend lands inside the invite after installing, the referrer is credited, and suspected fake installs are flagged so you can check them before you hand out a reward.
Group invites
Invite links that put new installs straight inside the group, class or team they were invited to.
Marketplace sellers
When a seller shares a listing and a buyer installs, the seller gets the credit.