Creator & Affiliate Deep Links with Post-Install Attribution

Overview

Affiliate and creator programs live or die by reliable attribution. Links must survive tracking layers, previews, and the App Store / Play Store redirect while keeping campaign context intact. SDDL issues a unique key per link and stores metadata such as UTM, partner_id, campaign, offer, or any JSON you define. When the app launches, SDDL returns that payload so you can route to the correct screen and tie conversions to the right partner.

How it works

1. Create a link per creator/affiliate with your custom metadata and UTM parameters.
2. User taps the link from social, video description, newsletter, or ad platform.
3. If the app is not installed, SDDL sends them to the store and safely stores the context for later.
4. On first app launch, the client fetches payload (SDK or GET /api/{key}/details), then routes to the right screen (e.g., promo, product, paywall) and attributes the user to the correct partner.
5. Optionally, webhooks notify your backend about clicks and app starts so you can reconcile payouts.

Setup & requirements

SDDL supports iOS Universal Links and Android App Links out of the box. We auto-publish the association files (apple-app-site-association and assetlinks.json) based on your app configuration, so you don’t need extra hosting. Follow these guides to verify your platform setup: iOS Universal Links · Android App Links · Deferred deep links explained.

You can use your own custom domain for brand trust and smoother deliverability. SDDL also offers an optional interstitial step before store redirect for more reliable deferred linking and messaging.

Implementation: SDK or REST

Implementation is intentionally simple. Many teams start with a pure REST flow and adopt the SDK when they want automatic cold-start handling.

• REST only: On app launch, call /api/{key}/details to obtain metadata and UTM for routing. If the key is unknown, call /api/try/details.
• With SDK: The iOS, Android, and Flutter SDKs handle both direct open-URL events and cold starts, and include helpful headers for attribution.

See API documentation for request/response formats and recommended headers.

Webhooks & reporting

Webhooks allow you to stream events into your CRM or BI: click received, payload resolved, optional app-start confirmation. The payload contains your link metadata (including UTM and partner_id) so you can reconcile conversions against contracts and handle tiered payouts. In the SDDL dashboard you can also review link performance, top sources, and geo/device breakdowns for quality monitoring.

Basic anti-fraud

Creator traffic often passes through preview bots, email scanners, and link shorteners. SDDL applies practical safeguards: bot-UA filtering for known previews, time-window validation between click and resolve, per-IP rate heuristics, and a one-time “used” flag on payload details to prevent replay. These signals are designed to reduce noise, not to replace a dedicated fraud vendor — you can combine SDDL data with your own rules or a third-party service.

Best practices

• One link per partner (or per campaign/flight) so attribution stays clean.
• Govern your UTM: align source/medium naming and keep partner_id consistent across all channels.
• Use interstitial when buying paid traffic to stabilize deferred flows and communicate offers or consent.
• Plan fallbacks: set iOS/Android/Web URL plus a generic fallback for unsupported contexts.
• Limit-time coupons: expire codes or validate server-side to reduce abuse.
• Test end-to-end with our QA Playbook before scaling spend.

Use cases

FAQ