Email Link Tracking & Deep Links

Email link tracking and mobile deep links conflict. When your email service provider (ESP) rewrites links to track clicks, it wraps them in a redirect through its own domain — and that redirect breaks iOS Universal Links in Chrome and in-app browsers, sending users to the App Store or web instead of opening your app.

This guide explains why that happens and how LinkForty fixes it: link to LinkForty directly (no ESP wrapping) and let LinkForty backfill the click analytics your ESP would have recorded.

Cloud Feature

ESP click-sync is a LinkForty Cloud feature, configured under Settings → Integrations. The underlying deep-link fix (linking directly, without ESP wrapping) works on any LinkForty plan and any ESP.

The Problem

A LinkForty link is a Universal Link — tapping it opens your app directly when installed. iOS has one hard rule: a Universal Link does not fire from an HTTP redirect unless the browser decides to honor "user intent."

When ESP click tracking is on, every link in your email is rewritten to the ESP's tracking domain. So the user taps the ESP domain first, which 302-redirects to your LinkForty link. That redirect is exactly what breaks Universal Links — and browsers disagree on how to handle it:

Browser	Behavior on a redirect to a Universal Link
Safari	Lenient — follows the redirect and still opens the app
Chrome on iOS	Only opens the app on a direct tap of the link — a redirect falls through to the web/App Store
In-app browsers (Gmail, Instagram, Facebook, Outlook…)	Same as Chrome — the app does not open

The result: an installed app opens the App Store anyway for a large share of your users. This is a well-known gap that every deep-linking vendor has to engineer around.

Email link (tracking ON)
        │  user taps ESP tracking domain
        ▼
┌──────────────────────┐
│  ESP tracking domain  │  logs the click
└──────────┬───────────┘
           │  302 redirect
           ▼
┌──────────────────────┐
│   LinkForty link      │  ← Universal Link, but reached via redirect
└──────────┬───────────┘
           │
      ┌────┴───────────────┐
      ▼                    ▼
   Safari              Chrome / in-app
  opens app           ❌ App Store / web

The Fix

Stop letting the ESP wrap the link. Put the LinkForty link directly in the email so the user taps it as a direct link — which fires the Universal Link in every browser.

You're not giving up click tracking. LinkForty already records every click in its own analytics, and the ESP click-sync connector pushes each click back into your ESP so its dashboards stay populated.

Email link (tracking OFF)
        │  user taps LinkForty link directly
        ▼
┌──────────────────────┐
│   LinkForty link      │  ← direct tap → Universal Link fires
└──────────┬───────────┘
           │                          ┌─────────────────────┐
           ├── opens app ✅           │  (async, non-blocking) │
           │   in Safari, Chrome,     │   click-sync → ESP     │
           │   and in-app browsers    └─────────────────────┘
           ▼
      records click → LinkForty analytics → ESP

Prerequisite: Turn Off ESP Click Tracking

Required

You must disable your ESP's link/click tracking for the emails that contain LinkForty links. If it stays on, the ESP re-wraps your link and the deep link breaks again — the fix does not work with ESP tracking on.

Disabling click tracking only affects click data on the ESP side — open tracking is unaffected. And LinkForty backfills the click data, so you don't lose it.

What is and isn't preserved

The click-sync sends each click to your ESP as a custom event, which keeps your conversion and engagement reporting populated. It does not repopulate the ESP's native email click-through-rate (CTR/CTOR) widget on the message report — that metric is tied to the ESP's own link wrapping, which you've turned off. Your authoritative click numbers live in the LinkForty analytics dashboard.

Set Up with OneSignal

OneSignal is the first supported ESP click-sync connector. The same two-part pattern — link directly + connect the ESP — applies to any provider.

1. Connect the OneSignal connector

In the dashboard, go to Settings → Integrations, find OneSignal, and click Configure:

Field	Required	Description
OneSignal App ID	Yes	OneSignal → Settings → Keys & IDs → App ID
REST API Key	Yes	OneSignal → Settings → Keys & IDs → REST API Key (server-side secret)
Custom event name	No	Name recorded in OneSignal for each click. Defaults to linkforty_click

Click Test Connection to verify the credentials, then toggle the integration active.

This is your OneSignal app

These credentials connect your OneSignal account so LinkForty can write click events back into it. This is unrelated to any email LinkForty itself sends.

2. Turn off OneSignal click tracking

When composing the email (or in the template settings), uncheck click tracking. With it on, OneSignal rewrites your links to its own tracking domain, which breaks deep links in Chrome and in-app browsers — the exact problem this connector fixes.

3. Add the recipient's ID to each LinkForty link

So LinkForty can attribute the click back to the right OneSignal user, append the subscriber's OneSignal ID to each LinkForty link as an os_id query parameter, using OneSignal's Liquid syntax:

https://go.yourdomain.com/your-link?os_id={{ user.onesignal_id }}

Use &os_id=... instead of ?os_id=... if the link already has query parameters.

{{ user.onesignal_id }} is rendered by OneSignal per recipient at send time and is present for every user — no external_id setup required. LinkForty reads os_id from the click and maps it to OneSignal's onesignal_id.

That's it. When a subscriber taps the link:

1. The app opens directly (Safari, Chrome, and in-app browsers).
2. LinkForty records the click in its own analytics.
3. LinkForty sends a linkforty_click custom event to OneSignal, attributed to that user.

Don't Run Both at Once

Leaving ESP click tracking on and enabling the connector is self-defeating:

• The deep link breaks — the ESP re-wraps the link, so you're back to the original problem in non-Safari browsers.
• Redundant reporting — every click is recorded twice: once by the ESP's native tracking and once by the connector's custom event. They live in different reports (so the native click count isn't directly inflated), but if you mark the custom event as a conversion alongside native clicks, your conversion numbers will double-count.

Treat the connector as a replacement for the ESP's disabled click tracking, not an addition.

How It Works

1. A subscriber taps the LinkForty link (no ESP wrapping). The app opens via the Universal Link.
2. LinkForty records the click and serves the redirect immediately — the backfill never slows it down.
3. LinkForty reads the identity from the link (os_id) and sends a custom event to your ESP, attributed to that subscriber, with automatic retries. Delivery failures are surfaced on the integration and never affect the redirect.

Links without an identity, and workspaces with no connector configured, do no extra work.

Other Email Providers

The deep-link fix is ESP-agnostic: any provider that wraps links in a tracking redirect breaks iOS Universal Links the same way, and the cure is always the same — disable that provider's click tracking and link to LinkForty directly. That works today regardless of which ESP you use.

The analytics backfill is per-provider — each one connects in Settings → Integrations and reads a different identity parameter that you add to your LinkForty links. Supported connectors:

Provider	Identity parameter to add	Merge tag
OneSignal	?os_id=	{{ user.onesignal_id }}
Braze	?braze_id=	{{${braze_id}}}
Iterable	?iterable_id=	{{userId}}
MoEngage	?moe_id=	your user-id personalization token
CleverTap	?ct_id=	your CleverTap Identity

Each backfills a custom event (default name linkforty_click) into that provider, attributed to the subscriber. The setup is identical to OneSignal above — only the credentials and identity parameter differ; the in-dashboard connector spells out exactly what to add.

CleverTap does both

CleverTap is also an analytics integration. One CleverTap connection can forward analytics events and do email click-sync — pick the events you want (including Email click sync) when you configure it.

If your provider isn't listed yet, you still get working deep links plus full click analytics in LinkForty — you just won't see the clicks mirrored back into that provider until a connector exists.

Troubleshooting

App still opens the App Store on Chrome / Gmail

• ESP click tracking is still on. This is the most common cause — the link is being re-wrapped. Disable click tracking for that email.
• Confirm the email contains the raw LinkForty link, not an ESP-shortened or wrapped URL.
• Verify Universal Links are configured for your app and link domain — see Universal Links vs App Links.

Clicks aren't appearing in your ESP

1. Check the link carries the identity parameter for your provider (e.g. ?os_id=... for OneSignal, ?braze_id=... for Braze — see the table above). Without an identity there's nothing to attribute, and the event is skipped.
2. Check the integration is active and Test Connection passes.
3. Check the integration's error message in the dashboard — an invalid API key or account/endpoint surfaces here.
4. Some clicks are from users the ESP doesn't recognize; those are expected and don't disable the integration.

Connection test fails

• 401 / 403 — the REST API key is wrong for this app.
• 404 — the App ID is incorrect.

Next Steps

• Review all event-forwarding integrations
• See your authoritative click data in the analytics dashboard
• Learn how Universal Links and App Links decide when your app opens