One traceable path, from click to postback.
Adback is a small, debuggable pipeline: a signal link captures the ad click, the SDK matches the install, subscription revenue joins from your billing source, and mapped conversions are sent back to the ad network, with every stage visible as a trace row.
No web funnel required · First-party signals only · Five-line SDK install
The signal path
Six stages. Each one inspectable.
Enterprise MMPs make this loop a black box. Adback keeps it small enough that you can watch a single user's journey move through it.
A paid click hits your signal link
Your ad's destination URL is an Adback signal link on adback.link. One shared resolver serves every link, so there is nothing to deploy per campaign. The link captures the network's macros (campaign, ad group, creative, placement, and click IDs like ttclid) along with coarse geo and language for routing.
adback.link · provider URL templates · macro capture
A fast bridge page redirects to the store
A lightweight bridge fires the advertiser pixel you configured and immediately forwards the visitor to the approved App Store or Play Store destination. Destinations are stored and approved in the console; public query parameters can never turn a link into an open redirect.
approved destinations · country and language routing
The SDK resolves the install
On first open, the SDK loads remote config, creates a first-party install_id, and sends an allowlisted set of app and device signals to Adback. The backend searches recent click candidates and returns an adback_id, attribution parameters, a match score, and a confidence tier, or an honest organic result when nothing matches.
POST /v1/sdk/installs/resolve · match_trace_id · confidence_tier
App events join the same identity
The SDK sends an automatic INSTALL event, and you track funnel events like SIGN_UP or START_TRIAL with stable event IDs so retries never double-count. Revenue is deliberately not an SDK event. Billing truth comes from the server side.
POST /v1/sdk/events · idempotent event_id
Subscription revenue joins server-side
RevenueCat or Superwall webhooks deliver purchases, renewals, refunds, and trial conversions straight to Adback. Each event is joined to the attributed install through the adback_id you handed off, so campaign and creative profitability comes from real billing outcomes.
RevenueCat · Superwall · webhook secret verified first
Mapped conversions post back to the network
Events that pass your mapping rules are sent server-side to the ad network. Today that is the TikTok Events API, using your own Pixel ID and access token, with event_id deduplication, the captured ttclid, and hashed match data. Every attempt records the provider's accepted or rejected response.
TikTok Events API · accepted / rejected visible in the console
Debugging
The trace is the product
Every stage writes a trace row: the click with its captured macros, the install with its match score and confidence tier, the revenue event with its join, and the postback with the provider's actual response. When setup breaks, you see which stage broke, instead of guessing why a network reports zero conversions.
Setup
From zero to first postback
Most teams complete this in an afternoon. Start with one campaign and expand once the trace is clean.
Create an app in the Adback console
Sign in, create your workspace, and add the app you advertise. This gives you the SDK keys and the integrations screen.
Install the iOS SDK
Add the Swift package from github.com/adback-app/ios-sdk and call configure with your publishable SDK key on app startup.
Connect a revenue source
Connect RevenueCat or Superwall and add the webhook URL and secret from the console, so billing events reach Adback.
Create one signal link
Create a link for your app and network, and paste the provider-specific URL template into your ad. The macros are pre-filled.
Verify the trace
Run a small campaign and watch the console: click, install, event, revenue, and postback rows should all appear for the same journey.
Data boundaries
What moves through the pipeline — and what never does
The SDK collects a narrow allowlist needed for install matching and event delivery. It is not a behavior-surveillance SDK.
Used for attribution
- Campaign, ad group, creative, and click IDs captured by your signal link
- First-party install_id and adback_id created by the SDK
- Allowlisted device and app signals such as OS version, locale, timezone, model, and screen size
- Apple AdServices token when you opt in to Apple Ads attribution
- Subscription lifecycle events from your connected billing source
- Hashed email, phone, or external ID, only when your app explicitly supplies them
Never part of the MVP path
- Device advertising identifiers or cross-app IDs
- Precise location, contacts, photos, clipboard, or installed-app lists
- Automatic screen, tap, or session recording
- SDK-side purchase or revenue APIs. Billing truth stays server-side
- Raw match values in logs, dashboards, or error responses
See your first trace
this afternoon.
Self-serve onboarding. Free to start, no credit card, no sales call.