Glossary

Plain definitions for the terms that come up when you ship deep links, attribute installs, and read link analytics. Each entry stands on its own and points at the page that goes deeper.

deep link

A deep link is a URL that opens a specific screen inside a mobile app instead of a web page. On iOS and Android the same HTTPS address can open the app when it is installed and verified, and load the web page in a browser when it is not.

See: Deep linking

Universal Link

A Universal Link is Apple's verified deep link. iOS checks the apple-app-site-association file on the link domain against the app's Associated Domains entitlement, then hands a matching URL to the installed app rather than Safari. iOS fetches that file at install and on app update, so edits do not reach devices immediately.

See: Universal Links not opening

Android App Link

An Android App Link is a verified HTTPS deep link. Android fetches assetlinks.json from the link domain and compares its SHA-256 certificate fingerprints with the installed app's signature. A verified host opens the app directly. An unverified host falls back to the browser or to a chooser dialog.

See: Android App Links autoVerify failed

custom URL scheme

A custom URL scheme is an app-private address such as myapp://product/42. It is not verified against any domain and nothing on the web answers it, so a device without the app gets an error or silence. Useful as a fallback inside embedded browsers, never as the address you publish.

See: Deep links in in-app browsers

apple-app-site-association (AASA)

The apple-app-site-association file is the JSON document iOS reads to decide which app may open a domain's links. It is served at /.well-known/apple-app-site-association over HTTPS, with a 200 status, an application/json content type, and no redirects. Each appIDs entry is the Team ID joined to the bundle identifier.

See: The AASA debug checklist

assetlinks.json

assetlinks.json is the Digital Asset Links file Android reads to verify App Links. It lives at /.well-known/assetlinks.json and holds a JSON array of statements, each naming a package and the SHA-256 fingerprints of the certificates that sign it. With Play App Signing, list the app signing key, not the upload key.

See: The assetlinks.json verification checklist

associated domains

Associated Domains is the iOS capability that lists the hosts an app may claim, written as applinks:example.com in the entitlement. The bare host is required, with no scheme, path, or port, and it does not cover subdomains. The provisioning profile that signs the build must carry the capability too.

See: Universal Links not opening

intent filter and autoVerify

An intent filter declares the URLs an Android activity can handle. Adding android:autoVerify="true" to a filter that uses the https scheme, the VIEW action, and the BROWSABLE and DEFAULT categories asks the system to verify the host against assetlinks.json. Without it, Android never verifies and shows the browser or a chooser instead.

See: Android App Links autoVerify failed

deferred deep link

A deferred deep link preserves a link's destination through an app install. The tap is recorded before the visitor reaches the store, and on first launch the app asks the server which recent click it belongs to. The original destination and its parameters come back, so a new user lands on the shared content.

See: Deferred deep links

install attribution

Install attribution connects a new app install back to the click that produced it, and to the link, campaign, or share behind that click. Mobile makes the join hard because the store sits between the tap and the launch, so the connection is rebuilt from whatever signals survived the install.

See: Install attribution

Play Install Referrer

The Play Install Referrer is a string the Google Play Store carries through an install and hands to the app afterwards. The app reads it on first launch through the Play Install Referrer library, which gives an exact, deterministic attribution match. It is attached only when the visitor is sent to a play.google.com address.

See: Deferred deep linking on Android

IDFV

The IDFV, or Identifier for Vendor, is an iOS identifier shared by every app from the same vendor on one device. It cannot follow a user into another company's apps, it is readable without a permission prompt, and it is exempt from App Tracking Transparency, which makes it a deterministic re-engagement signal.

See: Deferred deep linking on iOS

fingerprint matching

Fingerprint matching is the probabilistic fallback used when no deterministic signal exists. The server hashes coarse signals available at both ends, the request IP plus the device language and IANA timezone, and looks for a recent click whose hash agrees. It identifies a network rather than a device, so confidence decays quickly.

See: Deferred deep links

deterministic and probabilistic matching

A deterministic match reads an exact identifier, so it is certain. An install referrer is carried from the click through the store to the install. A vendor identifier matches a device already on record, which is re-engagement. A probabilistic match compares coarse signals and returns a scored guess. Gate sensitive work, like automatic sign-in, on a deterministic match only.

See: Install attribution

match confidence

Match confidence is the score WarpLink returns with an attributed install, from 0.0 to 1.0. A deterministic match is always 1.0. A probabilistic match starts from the age of the click and the signals available, then drops when the click IP was shared or several links could have matched.

See: Install attribution

short link

A short link is a compact HTTPS URL that redirects to a longer destination. The short path, called the slug, is either generated or chosen. Because the destination lives on the server, a printed or shared short link can be repointed later, and every request through it can be recorded as a click.

See: Deep linking

custom domain

A custom domain serves short links on a host you own, such as go.yourapp.com, instead of a shared shortener domain. Setup is a CNAME for routing plus a second CNAME that lets the certificate be issued and renewed. Association files are generated for the host, so the links still open your app.

See: Custom domains

WarpLink domain

A WarpLink domain is any host the SDKs will resolve a link on: the shared aplnk.to domain plus every custom domain you have verified and declared. It is broader than a custom domain, which means only a domain you own and have configured, and does not include aplnk.to.

See: Custom domains

click deduplication

Click deduplication decides which repeated clicks count once. A link can be tapped many times by one person, so a raw count overstates reach. The rule on this service treats a click as unique per combination of link, visitor address, and a twenty-four hour window, computed in the database at write time rather than at a cache layer.

See: Install attribution

UTM parameters

UTM parameters are query string fields that label the source of a visit: utm_source, utm_medium, utm_campaign, utm_term, and utm_content. They ride on the destination URL, so any analytics that reads the landing page can group traffic by campaign. A link can append them at redirect time instead of each share carrying them.

See: Pass UTM parameters through deep links

social preview (Open Graph)

A social preview is the card a chat app or social network renders for a shared URL, built from Open Graph and Twitter Card meta tags. A link service detects the crawler by user agent and returns HTML with those tags, while a real visitor gets the redirect. Images want at least 1200 by 630 pixels.

See: Social previews

in-app browser

An in-app browser is a web view an app embeds so links open inside it rather than in the system browser. Some embeds behave like the real browser and route verified deep links normally. Others intercept navigation, so the operating system never sees a tap and the app is never opened.

See: Deep links in in-app browsers

QR deep link

A QR deep link is an HTTPS URL printed as a scannable pattern that routes a scan into an app. Neither the iOS nor the Android camera opens an app on its own: each decodes the URL, shows it, and waits for a tap. That tap is what lets a verified link hand off.

See: QR code deep linking

mobile measurement partner (MMP)

A mobile measurement partner is a service that attributes paid app installs across ad networks. It maintains network integrations, decodes Apple's privacy-preserving ad attribution postbacks, joins spend to installs for cost and return figures, and detects install fraud. Teams whose installs come from their own links rarely need that stack.

See: Install attribution without an MMP

SKAdNetwork

SKAdNetwork is Apple's privacy-preserving attribution framework for paid campaigns. A registered ad network receives a signed postback per install, delivered on a deliberate delay, with identifying fields such as the conversion value withheld unless crowd anonymity thresholds are met. The network learns that a campaign produced installs, and you do not learn which install.

See: Install attribution without an MMP

App Tracking Transparency (ATT)

App Tracking Transparency is the iOS framework that requires an app to ask permission before tracking a user across other companies' apps and websites. It gates the advertising identifier, the IDFA. Link-based attribution that uses only the vendor identifier and coarse request signals falls outside it, so no prompt is needed.

See: Install attribution without an MMP

MCP server

An MCP server exposes a service to AI clients over the Model Context Protocol. WarpLink runs one at api.warplink.app/mcp, so an assistant can create links, register apps, read click analytics, manage keys and domains, and report usage. It is free on every plan and shares the REST API rate limit.

See: AI access

SDK key

An SDK key is the credential the mobile SDKs use to call WarpLink, created in the dashboard under API Keys as an SDK key. It is pre-scoped to link resolution and install attribution and never expires. It looks identical to an API key, so deep links can keep resolving while every attribution call silently fails.

See: Authentication

API key

An API key is the credential for backend scripts, CI, and AI agents such as the MCP server, created in the dashboard under API Keys as an API key with scopes you choose. Unlike an SDK key, it can never record install attribution, even when placed inside a mobile app by mistake.

See: Authentication