DEV Community: Muhammad Tayyab

App Store Campaign Links: The Indie Attribution Checklist

Muhammad Tayyab — Wed, 14 Oct 2026 11:47:01 +0000

Originally published at iamtayyab.com.

Early October on Indie Hackers turned into a run of install post-mortems, and they kept landing on the same awkward point.

A solo developer behind a small US stock-and-options app shared 45 days of install data (Oct 3, 2026). The headline: "82% of my iOS installs came from App Store search." Over 90 days, about four out of five iOS downloads started with a typed query, and daily link clicks had a correlation of about -0.1 with new users. In other words, none. When the developer dug into the logs, a crawler was hitting several links in the same millisecond.
A developer relaunching a dead 2020 iOS app tagged every channel link from day one (Oct 6, 2026), because "App Store Connect hides campaign numbers until a source has five downloads." In a follow-up reply: "of the first four downloads App Store Connect attributed, three were Search and one Browse, so the tagged links haven't moved anything yet."
I've already written about the SelfOS install wave, where 2,475 of 2,536 iOS installs over 90 days came from App Store search, so I'll leave that one alone here.

None of these posts prove a universal rule. They're a handful of small apps. Still, the pattern is consistent enough to act on: for a small iOS app, your click counter is probably not measuring what you think it is, and App Store search will often take credit for installs that your posts actually caused.

You can't fix that completely. You can get much closer with a free tool that's already in App Store Connect: campaign links. This post covers setting them up, reading the results honestly, and the traps that quietly break attribution.

What a campaign link actually is

A campaign link is your normal App Store URL with two tokens added. Apple's own example:

https://apps.apple.com/app/apple-store/id123456789?pt=123456&ct=test1234&mt=8

pt (provider token): identifies your developer account. Apple generates it the first time you create a campaign link. It stays the same for every campaign and app, and you can't create one by hand.
ct (campaign token): the campaign name you choose. It can be up to 30 characters (letters, numbers, spaces and a set of punctuation marks) and can't start or end with a space.
mt=8: the media type. Leave it as Apple generates it.

When someone taps the link and makes a first-time download within 24 hours, App Analytics credits that download to the campaign. If they tapped more than one of your campaign links, the most recent one wins.

Everything stays inside Apple's analytics, so there's no SDK, no fingerprinting and no consent banner. The trade-off is that Apple gives you aggregate numbers only, behind privacy thresholds.

Design your token scheme before you make a single link

Most of the value comes from naming things consistently. With 30 characters to work with, a simple channel_placement_date pattern holds up well:

ig_bio_2610: Instagram bio link, started October 2026
x_launch_thread_2610: the launch thread on X
ih_post_2610: an Indie Hackers build story
newsletter_oct26: your own email list
site_footer: the App Store badge on your website
creator_jane_2610: one specific creator or affiliate. Tag the person, not just the platform.

A finished link looks like this:

https://apps.apple.com/app/apple-store/id<YOUR_APP_ID>?pt=<YOUR_PT>&ct=ig_bio_2610&mt=8

Keep a plain list somewhere, in a note or spreadsheet, of every ct value, where it lives and when it went live. Six weeks from now you won't remember what x2_alt meant.

Setup checklist

Make sure your app has analytics data. The Campaigns tab and its + button only appear after the app has been live and generating downloads for at least 24 hours.
Generate your first link in App Store Connect: Apps → your app → Analytics → Acquisition → Campaigns → +. Enter a campaign name and copy the link. This is also how you get your pt value.
Make one link per placement, not one per platform. An Instagram bio link and an Instagram story link are two campaigns.
Link straight to apps.apple.com. Every extra redirect through a shortener or link-in-bio service is another place for blockers, in-app browsers or bot filters to break things.
Don't worry about storefronts. Users get redirected to their local App Store storefront, so a /us/ in the link doesn't limit who can use it.
For cross-promotion from your other apps, present the product page with SKStoreProductViewController and pass SKStoreProductParameterCampaignToken and SKStoreProductParameterProviderToken. Apple attributes those downloads the same way it does a normal campaign link.
For iMessage apps or sticker packs, add &app=messages to send people to the App Store for iMessage.
Test every link on a real iPhone, inside every app it will live in (Instagram, X, Threads, Reddit, Messages, your email client), not just in Safari on your desktop.

Add custom product pages for the channels that matter

Campaign tokens tell you who sent someone. Custom product pages let you change what they see when they arrive, and Apple measures each page separately.

You can create up to 70 custom product pages per app, each with its own screenshots, previews, promotional text and optional keywords.
Each page gets a unique URL that adds a ppid= (product page ID) parameter to your normal App Store link.
App Analytics shows impressions, downloads and conversion rate per page once a page has at least five first-time downloads.
Pages need App Review approval, work on iOS 15 and later, and can include an app deep link for users on iOS 18 and later.

A commenter on the finance-app thread suggested exactly this pairing: one custom product page per main channel, with screenshots and opening line matched to the post that sent the visitor. That gives you per-channel conversion even while a channel's campaign numbers are still too small to show.

Apple's docs show campaign tokens and ppid separately and don't document a URL that combines both. Many developers append pt/ct to a custom product page URL. If you try that, confirm in App Analytics that both the page and the campaign are recording before you rely on it.

(If your screenshots themselves need work, that's a separate job. Fix the page before you blame the channel.)

How to read the results

Where to look:

Acquisition → Campaigns: per-campaign impressions, product page views, first-time downloads and more.
Metrics → Add Filter → Campaign: lets you break any metric down by campaign.
Acquisition → Sources: App Store Search, App Store Browse, App Referrer, Web Referrer and others. This is where untagged traffic ends up.
The App Store Analytics API detailed reports, if you want raw exports. Apple notes that small groups of users may be withheld or combined there too.

The threshold, stated precisely. The pitch for this post said "a 5-download reporting threshold". Apple's wording is a bit different, and the difference matters:

Each campaign metric shows up only if it reaches at least 5 in the date range you've selected.
A campaign's data appears once it has generated first-time downloads from at least five individual users.
New campaigns appear in the dashboard after at least 24 hours.

In practice, a link that brought in three installs this week can look identical to a link that brought in zero. Widen the date range before deciding a channel is dead. Apple suggests this directly, and it's the single most useful habit here.

What the sources really mean:

App Store Search covers taps in App Store search results, including Apple Ads in search. It also absorbs everyone who saw your app name in a video or post, didn't click, and typed it in later. Both the finance-app and SelfOS developers concluded their posts were working through search. The finance-app developer found that posts per day correlated with next-day new users at roughly r = 0.5 over about 18 days, and called it a hypothesis from a small sample.
App Referrer means someone tapped a link inside another app, including apps that use StoreKit and Apple apps like Messages. Safari is excluded.
Web Referrer means a link on a website opened in Safari. If a chain of redirects led to the App Store, the last URL in the chain gets the credit.
Downloads that can't be attributed, such as promo codes and gift cards, show up as Unavailable.

A practical reading routine:

Compare first-time downloads by campaign over 30 or more days, not day by day.
Check product page views per impression and conversion rate for search traffic. If people see you in search but don't open the page, the problem is your icon, name or subtitle, not your posting schedule.
Look for search lifts that line up with posting days. A creator on X suggested comparing "first-time downloads in app store connect the 48h after posting vs a normal day" alongside a tagged bio link. That's crude, but honest.
Add a one-question "Where did you hear about us?" screen in onboarding. It's the only way to name the source behind a "search" install.

Pitfalls that quietly break attribution

In-app browsers. On iOS, a tap from a non-Safari browser such as Chrome is credited to that browser app under App Referrer, not to Web Referrer. Links opened in social apps have the same problem. The campaign token still works, which is exactly why you need it. Also check your own redirect code: the finance-app developer found their router treated KakaoTalk's in-app browser as a link-preview bot, so real taps got a preview card instead of a redirect. A commenter added that Facebook and Instagram in-app browsers include "FBAN/FBAV" or "Instagram" in a real person's user agent, while the preview fetcher is facebookexternalhit. Match exact bot names, never app names.
Bots inflating click counts. If you run your own click counter, audit it for same-millisecond hits and spikes at the same hour every day. After cleaning up, the finance-app developer counts only likely-human navigations and excludes known collectors, prefetches and requests without normal browser headers.
Ad and content blockers. Shorteners, link-in-bio services and third-party click trackers are exactly the kind of domains blockers and privacy tools interfere with. Apple's campaign link doesn't need any of them, so keep the redirect chain as short as you can, ideally zero hops.
Web-to-app hops. For sites opened in Safari, only the last URL before the App Store gets credit. If your landing page sends people through a tracker domain, the tracker gets the Web Referrer credit, not your page. Put the ct link directly on the button.
Last click overwrites earlier clicks. Someone who taps your newsletter link and later your Instagram link gets credited to Instagram. Don't treat campaigns as cleanly separate audiences.
The 24-hour window. If someone taps today and installs three days later after searching your name, that's a search download, not a campaign download.
Smart App Banners. Apple says you can add your ct and pt tokens to a Smart App Banner, but its banner docs only spell out app-id and app-argument. The syntax developers commonly pass around (affiliate-data=pt=…&ct=…) isn't in Apple's current banner documentation, and forum reports are mixed. Treat it as unverified until you see it in your own campaign data. Banners also don't appear inside frames or in the Simulator.
Tiny numbers. Below the threshold, a dead channel and a slow one look the same. Don't kill a channel because of one empty week.

What to do this week

Monday: generate your first campaign link, write down your pt, and draft a token list for every place you currently link to your app.
Tuesday: replace every App Store link you control (website badge, bios, email footer, pinned posts) with its own tagged link that goes straight to apps.apple.com.
Wednesday: test each link on a real iPhone inside the apps it lives in, and check your own redirect or bot rules for in-app browser user agents.
Thursday: pick your highest-intent channel and draft a custom product page whose screenshots and first line match what that audience saw.
Friday: add a "Where did you hear about us?" question to onboarding, with "a video", "a post" and "searched the App Store" as options.
In 30 days: open Campaigns with a 30-day range, compare first-time downloads and conversion rate, and only then decide where your posting time goes.

Soft close

Campaign links won't show you the person who heard your app's name in a video and typed it into search. Nothing will. What they do is turn "I think Instagram works" into a number you can check, and they stop you from crediting a channel because of clicks that were mostly bots. For a solo developer, a few hours of setup pays off every time you decide where to spend your time.

If you're setting up attribution for an iOS app and want a second pair of eyes on the link structure or the analytics, get in touch.

About the author

Muhammad Tayyab is a full-stack and mobile developer based in Lahore. He builds DripScore, an AI outfit rating app live on the App Store, under dawnapps.co. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

Need help building or shipping your app or internal tool? Let's talk.

[Boost]

Muhammad Tayyab — Mon, 05 May 2025 09:10:53 +0000

Muhammad Tayyab

May 4 '25

Your Browser Dev Tools Are Killing Your Productivity (And How to Fix It)

3 min read

Your Browser Dev Tools Are Killing Your Productivity (And How to Fix It)

Muhammad Tayyab — Sun, 04 May 2025 15:27:27 +0000

Have you ever found yourself constantly switching between your code editor and browser dev tools, trying to track down that elusive bug? Or perhaps you've spent hours analyzing network requests or console logs, only to miss the forest for the trees?

What if I told you there's a way to bring all that browser debugging power directly into your coding environment?

Enter Browser Tools MCP - a game-changing tool that transforms how developers debug and optimize web applications from within Cursor IDE.

Why Browser Debugging is Broken (And How to Fix It)

The traditional debugging workflow creates a cognitive drain on developers:

Write code in your editor
Switch to browser to test
Open dev tools to check errors
Try to remember what you saw while switching back to your editor
Repeat endlessly

This context-switching tax is draining your productivity without you even realizing it. Browser Tools MCP eliminates this by bringing browser analytics directly into your coding environment.

The Magic Moment: Debugging Without Leaving Your Editor

Imagine instantly accessing:

Console logs and errors - Track down JavaScript issues without tab switching
Network requests - Analyze API calls, responses, and performance bottlenecks
DOM inspection - Examine selected elements and their properties
Screenshots - Capture and analyze visual state automatically
Comprehensive audits - Performance, accessibility, SEO, and best practices analysis

All from within your Cursor IDE, powered by Claude AI's assistance.

Beyond Basic Debugging: Unlock Web Development Superpowers

Browser Tools MCP isn't just about catching errors - it's about transforming your entire web development workflow:

🚀 Performance Optimization Made Effortless

Identify render-blocking resources, excessive DOM size, unoptimized images and more - with AI-powered suggestions for fixes.

🔍 SEO Enhancement at Your Fingertips

Analyze metadata, headings, link structures and get recommendations to improve search visibility, helping your projects reach wider audiences.

♿ Accessibility Without the Learning Curve

Catch WCAG compliance issues like color contrast problems, missing alt text, and keyboard navigation traps automatically - making your applications more inclusive without becoming an accessibility expert overnight.

🛠️ Best Practices Enforcement

Ensure your code follows web development best practices with automated checks and AI-guided improvements.

⚡ NextJS-Specific Intelligence

Special audit capabilities for NextJS applications to optimize your React projects with framework-specific insights.

From Frustration to Flow: A Real Developer Story

When I first discovered Browser Tools MCP, I was skeptical. Could it really replace my browser debugging workflow?

Then I encountered a particularly nasty bug - an intermittent network error that only appeared sometimes. Instead of constantly refreshing and hoping to catch it, I simply asked Claude (through Cursor) to monitor the network logs.

Within seconds, I could see the pattern - a race condition in my API calls was causing occasional failures. What might have taken hours of manual debugging was solved in minutes.

Get Started in 3 Simple Steps

Ready to transform your debugging workflow? Here's how to set up Browser Tools MCP:

Step 1: Install the Chrome Extension

Download the Browser Tools MCP Chrome Extension and enable it in your browser.

Step 2: Configure Cursor

Open Cursor Settings → MCP → Add new
Paste the following configuration into your mcp.json file:

{
  "mcpServers": {
    "Browser Tools MCP": {
      "command": "npx",
      "args": [
        "-y",
        "@agentdeskai/browser-tools-mcp",
        "--stdio"
      ]
    }
  }
}

Step 3: Run the Node Server

Open a new terminal and run:

npx @agentdeskai/browser-tools-server@latest

That's it! After these steps, open Chrome DevTools and navigate to the BrowserToolsMCP panel to ensure everything is connected.

The Future of Web Development is Here

Browser Tools MCP represents a fundamental shift in how we approach web development. By bringing browser intelligence directly into your coding environment and enhancing it with AI capabilities, it eliminates the context-switching tax that has plagued developers for decades.

Whether you're building a simple website or complex web application, this tool will help you:

Debug faster with direct access to browser logs
Build more accessible applications through automated WCAG checks
Optimize performance with AI-assisted insights
Improve SEO with targeted recommendations
Follow best practices without memorizing them all

For more detailed installation instructions and the latest updates, visit the official Browser Tools MCP GitHub repository.

Give it a try - your future self (and your users) will thank you.

What's Your Debugging Horror Story?

Have you battled with a particularly challenging bug that took forever to track down? Share your debugging horror stories in the comments below - and how a tool like Browser Tools MCP might have helped!

Are you using any browser debugging tools that integrate with your IDE? What's your current debugging workflow? Let me know in the comments!

🚀 Why Strings Are Immutable (And How to Fix Inefficient String Operations!)

Muhammad Tayyab — Thu, 03 Apr 2025 19:08:46 +0000

🔥Stop Wasting Memory! The Truth About Strings That No One Told You

Imagine this: You're building a high-performance Python application, and your code runs 10x slower than expected. You debug for hours—only to find out your string operations are the culprit.😨

Sounds familiar? Well, here’s the catch:

Strings are immutable in most modern programming languages. That means every time you modify a string, you're creating a new one. Wasting memory. Slowing down execution. Killing performance.

Let’s break it down with some mind-blowing examples and the best fixes you need to know!🔥

🚀 The Problem: Why Are Strings Immutable?

Many languages (Python, Java, JavaScript, Swift, Rust, Go) treat strings as immutable objects. Once created, they cannot be changed.

** 📌Example:**

s = "Hello"
s += " World"
print(s)  # "Hello World"

❌ Looks simple? Under the hood, Python allocates new memory every time you modify s!

Why does this happen?

Memory Efficiency: Immutable strings can be shared across multiple parts of a program.
Security: Prevents unintentional modifications.
Thread Safety: Multiple threads can read the same string safely.

⚡ How to Fix Slow String Operations

🛑Bad Approach: Using `+=` in Loops

s = ""
for i in range(10_000):
    s += "abc"  # Creates a new string every time (O(n²) complexity!)

🚨 Never do this! It’s like hiring new employees every second instead of reusing your existing team. 🏢

✅Best Fix: Use `''.join(list)`

s = []  # List is mutable and efficient
for i in range(10_000):
    s.append("abc")

result = "".join(s)  # Fast O(n) operation
print(result)

💡 Boom! Memory-efficient and blazing fast! 🚀

💡 The Takeaway

✅ Immutable strings are great for security, memory optimization, and thread safety—but they can slow down performance if used incorrectly.

⚡ Use efficient alternatives like lists (.join()), StringIO, or StringBuilder when you need heavy string manipulation.

💬 What’s the worst string performance issue you’ve ever faced? Drop a comment below and let’s discuss! 👇

🚀 If this helped you, give it a ❤️ and share it with your fellow developers!

DEV Community: Muhammad Tayyab

App Store Campaign Links: The Indie Attribution Checklist

What a campaign link actually is

Design your token scheme before you make a single link

Setup checklist

Add custom product pages for the channels that matter

How to read the results

Pitfalls that quietly break attribution

What to do this week

Soft close

About the author

Sources

[Boost]

Your Browser Dev Tools Are Killing Your Productivity (And How to Fix It)

Your Browser Dev Tools Are Killing Your Productivity (And How to Fix It)

Why Browser Debugging is Broken (And How to Fix It)

The Magic Moment: Debugging Without Leaving Your Editor

Beyond Basic Debugging: Unlock Web Development Superpowers

🚀 Performance Optimization Made Effortless

🔍 SEO Enhancement at Your Fingertips

♿ Accessibility Without the Learning Curve

🛠️ Best Practices Enforcement

⚡ NextJS-Specific Intelligence

From Frustration to Flow: A Real Developer Story

Get Started in 3 Simple Steps

Step 1: Install the Chrome Extension

Step 2: Configure Cursor

Step 3: Run the Node Server

The Future of Web Development is Here

What's Your Debugging Horror Story?

🚀 Why Strings Are Immutable (And How to Fix Inefficient String Operations!)

🔥Stop Wasting Memory! The Truth About Strings That No One Told You

🚀 The Problem: Why Are Strings Immutable?

⚡ How to Fix Slow String Operations

🛑Bad Approach: Using += in Loops

✅Best Fix: Use ''.join(list)

💡 The Takeaway

🛑Bad Approach: Using `+=` in Loops

✅Best Fix: Use `''.join(list)`