Tag Archives: App Store

Parameters of iTunes, App Store and Mac App Store links


Apple replacing the LinkShare and DGM networks of their Affiliate Program with (the much superior and real-time) Performance Horizon provided an excellent excuse to dig deeper into the components  of iTunes, App Store and Mac App Store links. These are my findings and open questions.

Dissecting a link

This is how a link generated with iTunes Link Maker looks (plus campaign tracking):


The components and parameters of this link are:

  • Country code, optional. E.g., us.
  • Action, mandatory. Indicates which store holds the linked item. E.g., app.
  • Description, optional. For descriptive purposes only. E.g., email-contacts-extractor-lite.
  • Primary ID, mandatory. Uniquely identifies the linked item.E.g., id684303508.
  • uo=4, optional. Meaning unknown.
  • Media type, optional. E.g., mt=12.
  • Affiliate ID, optional. E.g., at=10l6nt.
  • Campaign text, optional. E.g., ct=web.

All these components are shared by iTunes, App Store and Mac App Store links. We’ll talk about some of them in more detail below.

Country code

The country code is optional but Apple recommends to keep it. They say:

If you are dealing with a link that does not have a country code (for example, most EPF links are not tied to a country), you should insert one that is appropriate for your users. The country code serves as a hint to the store. If the specific content is not available in the user’s storefront, iTunes prompts the user to switch storefronts to view the requested content.

The country code also serves as a hint for the default language of the page requested when the user’s preferred language is unknown. If no country code exists on the link, iTunes defaults to the U.S. storefront.

In other words, keep the country code to let Apple know which localized version of the item it should display to the user.

Media type

The infamous mt parameter (mostly known for mt=8) indicates the media type of the linked item, and gives the OS another hint of which store it should open. Over StackOverflow user Ted has compiled its various known values:

1 Music
2 Podcasts
3 Audiobooks
4 TV Shows
5 Music Videos
6 Movies
7 iPod Games
8 Mobile Software Applications
9 Ringtones
10 iTunes U
11 E-Books
12 Desktop Apps

Many developers are tempted to remove this seemingly useless parameter, but it is not recommended. On Mac, it will open the Mac App Store when linking to a Mac app. On iOS, it will reduce the number of redirects when linking apps. And it might have future uses.

Affiliate ID

After signing up for the Performance Horizons affiliate program you will receive your affiliate ID, which is indicated by the at parameter. Including the affiliate ID on your links will not only give you a commission from sales but also provide precious download/sales/conversion rate information.

While Apple statesadd this to the end of any iTunes, App Store or iBooks Store URL to be eligible for commissions“, this is not exactly true. As shown below, not all links work affiliates tracking:

✓ http://itunes.apple.com

Campaign text

The optional ct parameter allows you to differentiate between campaigns. From Apple’s documentation:

The “ct” value is campaign text that you can optionally add to any link in order to track sales from a specific marketing campaign. By using a campaign value, you will see in the reporting dashboard all clicks and sales related to that specific campaign.

For example, the link below has added a campaign tracking parameter for a newsletter link. You can name the campaigns anything you choose, but the “ct” value may not be longer than 45 characters:


To those familiar with Google Analytics campaigns, ct is the equivalent of utm_source (Campaign Source).

Open questions

  • What does the uo parameter mean? What is the effect of removing it?
  • Is it possible to add affiliate and campaign tracking to appstore.com short URLs (e.g., http://appstore.com/mac/emailcontactsextractor)?

App Store keywords checklist: 21 tips to work around Apple’s horrible search

App Store icon

Don’t you hate those articles about App Store marketing who basically tell you you need to build a great app*? Me too.

Here are 21 practical and actionable tips to get the most from your App Store keywords, with real examples from my Mac app Email Contacts Extractor, references and further resources.

Let’s see how many of these you know already.

Basic tips

All of these tips can be found in the documentation provided by Apple.

  1. You can only use up to 100 characters for keywords.[1]
  2. Each word in your app title and company name counts as a separate keyword.[2]
  3. The description does not count as keywords.[3]
  4. Separate keywords with commas.[1]
  5. Keyword changes require an update of the app binary.[1]
  6. Prefer specific keywords.[4] E.g., extractor is better than tool.
  7. Each keyword must be more than 2 characters.[1]
  8. Keywords that use offensive language or are trademarked or that reference another app’s name or company name, might cause your app to be rejected.[1] However, many product or brand names are accepted based on the context of the app, so try them if appropriate. E.g., gmail.

Intermediate tips

Improve your chances with these tips learned by trial and error.

  1. Separate keywords with “,” but not “, ” (no extra space) to save characters.
  2. Use single words keywords but not phrases (even if the iTunes Connect Guide says otherwise). Searches that are a combination of your keywords will display your app too. E.g., “extract,contacts” instead of “extract contacts“.
  3. Consider including plurals if the App Store does not recognise them. To test this, first submit your app without plurals and search your desired plurals. Then upload a new version with the plurals that are not recognised by the App Store.[5] E.g., addresses.
  4. Category names no longer count as keywords. In any case, only use a category name as keyword if your app is very popular within that category or if the category is not too crowded.[6]
  5. While it’s not possible to know which keywords are more frequent, it is possible to scrap the App Store for common words in app titles. The last list I found was compiled by AppsFire. You might want to avoid adding any of these as additional keywords.
  6. If your app is free, you don’t need to include free as a keyword, although you might still want to include it in the app title for marketing purposes.[7]

Advanced tips

You should follow these tips if you plan to make a living from your app.

  1. Different countries produce different search results. You can localize both your app title and keywords. You can also change the App Store country to test the results. On iPhone: open the App Store, select the Featured tab, scroll down to your account and tap, change country region. On Mac: open the App Store, selected the Featured tab, scroll down, tap on the country flag.
  2. While it’s not possible to know which search terms are related in the App Store, we can consider Google searches as an approximation. Use Google Keywords Tool (limited to mobile traffic and each desired country) and Google Trends (limited by country) for ideas. E.g., using this I found that “export“, “backup” and more frequently used than extract in the context of email contacts export.
  3. iTunes and the iOS App Store sometimes produce different results. Try both.
  4. Consider including common misspellings as keywords. E.g., adress.
  5. Consider using services that track your keywords ranking, such as AppCod.esMobileDevHQ and AppStoreRankings. Unfortunately I can’t endorse any as I haven’t used them yet.
  6. In-app purchase titles do not count as keywords anymore.[7]
  7. Keywords might be deactivated by the App Review team without letting you know (unverified).[8] Make sure you test them all after releasing the app.

Bear in mind that the above change every so often. If you found that any of the tips doesn’t work anymore, please leave a comment below.

This post was all about keywords. For a more generic introduction to App Store Optimisation (ASO), you might want to read apptamin’s checklist.

* (BTW, they’re right)

1. ^ a b c d e App Store Resource Center – Marketing Resources.
2. ^ iTunes Connect – Frequently Asked Questions > App Store.
3. ^ iTunes Connect – Frequently Asked Questions > Manage Your Applications.
4. ^ iTunes Connect Developer Guide – Best Practices.
5. ^ App Store Optimization (ASO): App Name And Keywords.
6. ^ Category names no longer work in App Store search on the device.
7. ^ a b New rules in App Store Search.
8. ^ “SEO Optimizing” Your App for iTunes – Part 4 (Additional Findings).

Rejected from the Mac App Store for checking for updates

The first personal app that I submitted to the Mac App Store was recently rejected. Was it the subject matter? A bug? Too ugly? Not at all: the app displays an alert when an update is available, and according to an Apple employee “update checks” are forbidden.


This post is sponsored by WTF, the World Taekwondo Federation.

Notifying the user that a new version is available is a very common feature in apps: you want your users to be using the latest version. It’s so common that there are many open-source libraries that do this automatically, such as iVersion, the one I used. Unfortunately, It appears that the Apple employee who reviewed my app has a misconception about iVersion. Quoting the rejection message:

The app updates itself outside of the Mac App Store, the app uses iVersion to update the app,

The Mac App Store provides customers with notifications of updates pending for all apps delivered through the App Store, and allows the user to update applications through the Mac App Store app. You should not provide additional update checks or updates through your app.

The Mac App Store Review Guidelines (developer account needed) do, in fact, forbid apps that “use update mechanisms outside of the App Store” (rule 2.21). This is not the case with iVersion, as I explained to the Apple review team:

The app does not update itself outside of the Mac App Store.

When opened, the app consults the App Store API (provided by Apple) and checks if a new version is available. If it is, it shows an alert to the user, offering the choice of opening the App Store.

No update is provided within the app, and the update check is done via the App Store API.

Unsurprisingly, I received no reply. Given that I didn’t consider this issue important enough to delay the release any further, I removed iVersion from the app and resubmitted.

How did Apple find out that I was using iVersion? Quite simply, I told them. Unlike iOS apps, Mac apps require entitlements to use key OS features, such as network access. iVersion uses network access to check for the latest version in the App Store, and Apple requests you to explain how each entitlement is used when submitting the app.

You could argue that iVersion is not necessary. After all, the Mac App Store provides notifications for updates. As an user -and as the number of apps that I install from the Mac App Store grow-, I tend to postpone dealing with these notifications as many are from apps that I’m not currently using. Thus, I believe there is value in opening an app and being told that an update for that app is available.

What’s worse is that there’s plenty of apps in the Mac App Store that use iVersion, or have a similar feature. Lesson learned: the more you tell Apple about your app the most likely it will get rejected.

Update: iVersion’s author agrees with the conclusion.