App Store campaign tokens, ct and pt

Two query parameters, no SDK, free. Campaign attribution on iOS starts here, and most people never turn it on.

6 August 2026 by PAD team

The parameters

Apple reads two values from an App Store URL and reports installs against them in App Store Connect:

https://apps.apple.com/app/id123456789?pt=PROVIDER_ID&ct=summer_reels&mt=8

Where the numbers appear

App Store Connect, under App Analytics, in the campaign section. Data appears with a delay of roughly a day and is aggregated, so small campaigns may be suppressed for privacy.

This is not the same as the Sources report, which covers organic and browse traffic. Campaign tokens live in their own view and only populate when links carry them.

What breaks it

• The parameters dropped by a redirect somewhere in the chain, which is the most common cause
• ct values that vary per user, which fragments the report into noise
• Parameters attached to the first URL in a chain rather than the last one
• Links opened in an in-app browser, where the tap never reaches the store at all

The third one deserves emphasis. If your funnel is ad → landing page → store, the tokens have to be on the store URL at the end, not on the ad's destination. Anything earlier is thrown away by the time Apple sees the request.

Naming conventions that survive

Keep ct values short, lowercase, and stable across a campaign's life. Something like ig_stories_aug is readable in a report six months later. Encoding a timestamp or a user identifier there produces thousands of one-install campaigns and no insight.

The catch

None of this matters if the tap never arrives. Campaign tokens measure installs, and an install requires the store to open, which is exactly what fails inside social app browsers. The tokens survive an escape from the WebView, so the two solve different halves of the same problem.