How smart app links choose a destination

A smart link sends each visitor to a destination you configure. In AppRoute, you set an App Store URL for iPhone visitors, a Google Play URL for Android visitors and a website fallback for other devices or missing store destinations. Active targeting rules can take precedence over those defaults when a visitor matches them. This routing requires no mobile SDK. Opening a specific screen inside your app is called deep linking. It requires integration with the mobile platform; Android’s deep-link documentation explains that distinction.

01 What should each visitor open?

Plan your iPhone, Android and fallback paths before adding custom rules. Start with the page each visitor needs, then copy its URL into the corresponding destination field.

The fallback deserves the same attention as your store URLs. Someone opening a link on a laptop still needs to understand what your app does. Use a page that explains it and helps them continue, such as a product page with links to the available stores.

For example, suppose your app is available only on iPhone. You would configure its App Store URL and a website fallback. With no Android store destination configured and no matching target group, Android visitors would reach that fallback too. Choose its content with those visitors in mind; don’t send them looking for a Google Play listing that doesn’t exist.

Once you’ve chosen these destinations, enter them in your smart routing setup. Open each destination URL directly to check the page before testing the shared link’s routing.

02 Why did this visitor reach that page?

Active matching rules take precedence over default store routes. If a visitor reaches an unexpected page, inspect the target groups before changing the device destinations.

1. Check which groups are active. Only active target groups take part in the decision. Start with those that could apply to the visitor whose route you’re checking.
2. Check every condition in each group. All conditions you set, such as operating system, device type or country, must match for a group to apply. A group that matches one condition but fails another does not qualify.
3. Read the groups in priority order. A lower priority number runs first. If two groups have the same priority, the earlier-created group runs first. The first matching group wins, so a later group won’t override it just because its conditions are more specific.
4. Inspect the winning group’s destinations. When a group contains weighted destinations, AppRoute selects one randomly according to the weights. The weights don’t guarantee exact totals across a small set of visits or the same destination for a returning visitor.

Write down the visitor conditions, the first group you expect to match and its possible destinations. Then open the link and record where it lands. If you’re checking a weighted group, compare the result with all of that group’s destinations; one visit can’t establish whether the split follows the configured proportions.

03 How do I know the link is ready?

Test the link from the places you’ll share it and record the expected and actual destinations. A click record shows a request to the link; it doesn’t prove an install or purchase.

Use this blank example worksheet to record your checks.

Replace these example placements with yours, then check each relevant device in each placement. If a result differs, inspect the destination settings and active target groups before sharing more widely.

You can edit destinations while keeping the shared URL. Keep the same slug and domain, and leave the link and domain active. Repeat the checks after an edit.

Once the routing checks pass, use click analytics to review traffic from the placements you share.