Conversion Studio

SKAN Conversion Studio lets you define what your SKAdNetwork conversion values measure — revenue, in-app events, or a funnel — without changing your app code. Configure, validate, and publish a schema for each iOS app.

SKAN Conversion Studio is where you decide what your SKAdNetwork (SKAN) conversion values measure. A conversion value (CV) is a small number iOS reports in each postback; on its own it means nothing until you map it to user activity. Conversion Studio lets you build that mapping — measuring revenue, in-app events, or a funnel — without touching your app code. The AdShift SDK reads your published schema and sets the right CV automatically.

Go to Settings → SKAN Conversion Studio to open it.

Conversion Studio applies to iOS apps only. The app selector is filtered to iOS apps. For a conceptual introduction to SKAN and the dashboard that reads these values, see SKAN: Overview.

Before you begin

Enable SKAN for the project using the toggle at the top of the page. When you enable SKAN for the first time, AdShift creates a default published configuration for each iOS app so measurement starts immediately.
Select an iOS app — each app has its own configuration.
You need the skan.configs.manage permission to create, edit, or publish. Users with only skan.configs.read can view configurations but not change them.

SKAN 4 windows

A configuration defines measurement across the three SKAN 4 windows. Each window is configured separately:

Window	Period	What you can configure
Window 1	Days 1–2	A fine value (0–63) and a coarse value (low / medium / high)
Window 2	Days 3–7	A coarse value only
Window 3	Days 8–35	A coarse value only

Only Window 1 supports the precise fine value, because Apple only sends fine values when there is enough install volume. Windows 2 and 3 use coarse buckets.

Measurement components

You build a window's fine value out of one or more components. AdShift combines them and encodes the result into the available conversion value range.

Component	Measures	Example
Revenue	Total revenue, split into ranges	`$0–$2`, `$2–$4`, …
Event	How many times an in-app event fired, split into ranges	`level_complete` fired 0–1, 1–3, …
Funnel	Which step of an ordered funnel the user reached	`product_view → add_to_cart → purchase`

Coarse values

For the coarse value, you assign one component condition to each of low, medium, and high. By convention the low bucket should always include a baseline signal such as session_start, so that even minimally active installs report a coarse value.

Single Source of Truth bit

Window 1's fine value can reserve one bit for SSOT (Single Source of Truth). When enabled, this bit flags whether the install was also attributed device-level, which is what lets the SKAN Overview dashboard deduplicate installs in SSOT mode. Reserving this bit halves the fine value range (0–31 instead of 0–63).

Capacity

The Window 1 fine value is only 6 bits, so it can encode at most 64 distinct combinations (or 32 with the SSOT bit enabled). The total number of combinations across all your components must fit. The editor shows a live capacity indicator as you add ranges and components; if you exceed the limit, validation will fail. Reduce the number of revenue ranges or event ranges, or move some measurement to the coarse value, to fit.

Industry templates

Rather than building a schema from scratch, you can start from a pre-built template. Templates cover six verticals, each with sub-strategies:

Vertical	Example strategies
Gaming	Strategy, RPG, Casino, Hypercasual, Sports, Action, Tabletop
Shopping	Revenue focused, Revenue + events
Travel	Booking focused, Search & engagement
Finance	Transaction focused, Account activation
Subscription	Trial to paid, Content engagement
Utilities	Feature adoption, Session focused

Open the Industry templates modal, pick a vertical and strategy, preview the window setup, and apply it as a new draft you can customise.

Configuration lifecycle

A configuration moves through three states: draft → published → archived.

Draft — editable. You can keep up to 5 drafts per app.
Published — compiled, signed, and pushed live to the SDK. There is exactly one active published config per app.
Archived — a previously published config kept for history. Publishing a new config automatically archives the old one.

You never edit a published config in place. Editing or duplicating a published config creates a new draft, so the live configuration is never disturbed while you work.

How to publish

Open or create a draft and configure your windows.
Click Publish. AdShift first validates the draft:
- Revenue ranges must start at 0 and be continuous with no gaps.
- Event ranges must be whole numbers and continuous.
- A funnel needs at least 2 steps with unique event names.
- Total combinations must fit within capacity.
- Window 1's low coarse bucket must include session_start.
If validation passes, AdShift compiles the draft into a compact SDK payload, signs it, and pushes it live. The new config's version increments automatically and the previous published config is archived.

If validation fails, the editor lists each problem so you can fix it before publishing again.

Simulate before you publish

Use the simulator to test a draft against a hypothetical user. Enter a stream of events and revenue per window, and the simulator returns the exact fine value, coarse value, and lock status the SDK would produce. This mirrors the SDK rule engine, so you can confirm a schema behaves as intended before going live.