Enterprise-Level International ASO in iTunes App Store & Google Play (2/3)
November 2, 2017
By: Kathryn Hillis & Cindy Krum
As with all App Search Optimization (ASO), International ASO is an evolving discipline. Neither the Apple App Store or the Goole Play Store have shared the nuances of their internal app store search algorithms, so a lot of what we know is based on experimentation, trial and error, and case studies. The complexity of International ASO is compounded by the fact that an international app can be available in many languages and many countries; they can also be available in ‘Paid’ and ‘Free’ versions and/or in ‘Lite’ and ‘Full’ editions. Each version of the app will need locally-focused ASO assets and a process that must be maintained semi-individually, especially when the content and KPIs for the various versions of the app change.
This is the second article in a four-part series about International ASO. The first article described the strategic elements to consider when determining which countries to target with an ASO strategy. This article will detail the major differences in how the iTunes App Store and the Google Play Store approach the various country and language combinations, and how those differences can impact your ASO strategy and rankings. The next article will explain how to perform international ASO keyword research and then upload and verify the metadata correctly in the stores.
NOTE: If you have not checked it out yet, MobileMoxie has a great international ASO app rank-tracking tool called the App Rankalyzer which is brilliant for comparing international ASO rankings! Sign up for a free trial of our mobile marketing tools to try it out!
Understanding the International Architecture of the App Stores
If you are just getting started, NationsOnline.org is a great resource for finding out which languages are spoken in countries around the world. Some countries have a population that speaks many languages, and some languages are spoken by people, in many countries, which makes the job of organizing app stores quite difficult. That being said, there are a few fundamental things both the iTunes App Store and Google Play have in common:
- First, both iTunes and Google Play allow you to control which countries your app is sold in, and won’t rank apps for countries that they are not intentionally published in. One app can support many languages within the app and one app can be supported by multiple languages of metadata, (though this is more restricted for iTunes than Google Play).
- Second, both stores let you deploy your app metadata in any of the potential metadata languages listed within iTunes Connect or Google Play Console, although the stores distribute and utilize metadata differently, which we’ll discuss in-depth in this article.
- Third, both stores attempt to tailor their search experience to the user based on the device settings. They each try to match the query exactly, and while they may pull in apps from other countries that have metadata that matches your query (as long as the app is permitted to show in the searcher’s country), in the stores will not translate the query to rank other apps in different languages.
- Fourth, though it is not the focus of this article, ASO’s can always submit different app builds to different countries. Different app builds will have different app IDs and will not see any strong benefit from other apps by the same brand (though both stores do offer a small benefit when apps come from strong developer accounts with good reputations.) The ‘separate build’ strategy is especially useful if the app content, design or functionality changes significantly from one place to another. The most common example of this might be a ‘lite’ version of the app that is made available in places where cellular data connectivity is less reliable, and the reliance on web access needs to be minimized.
- Finally, to address the complexity of country and language combinations for users, app stores adapt the store experience on every phone to match the country and language settings of the phone’s operating system (where they can). Most phones require this to be set up in the activation process, so this creates the best and most reliable search experience for the users. If you are hand-testing ASO search results, it is important that you make these changes in your phone settings before you begin testing. Problems only come into play here if the phone OS is set to a language that is not supported by the store, in which case, both stores seem to fall-back to English app results; iOS usually defaults first to UK-English, and Google Play usually defaults to US-English, but we have seen both included when no store-supported OS language is detectable from the phone.
Unfortunately, this is where the similarities end. There are many differences between the two stores. The Apple App Store and Google Play Store handle countries and languages differently from each other, which becomes particularly clear when doing International ASO. One of the most important differences between the two stores is their international architecture and the impact it has in each store. The iTunes App Store is segmented by country or territory, and then by languages within that territory. The metadata languages that can help you in terms of ASO are limited by country/language combinations, due to Apple’s restrictions within this segmentation.
In the Google Play Store, on the other hand, any metadata language can rank in any country your app has been launched in. It is segmented first by language and then sometimes by dialects for particular countries or territories. This granularity is helpful for targeting local markets since different dialects of the same language are common in different regions. Google expects users to self-select through language preferences on their devices. This fundamental difference in segmentation between stores can have a significant impact strategy and prioritization:
Language-First (Google Play): In Google Play, apps are submitted and sorted by language first, then ASO’s can limit which countries the app is sold in. Sometimes specific languages or dialects are associated with specific countries, and the submitter chooses if they wish to publish in those dialects/countries or not in the ‘Pricing & Distribution’ settings. There are specific languages or dialects that are used by most people in particular countries or territories (like English [US] is used by most people in the United States). Therefore, users based in the United States with their phone set to French (for example) will see French metadata in Google Play for apps that have provided French metadata but they will only be shown apps that are published in the US.
Google will automatically translate the app title and short description that you submit to the store into a number of different languages, so that most people read about an app, even if the app itself is not available in the language that they are reading. Android app metadata can be added in any of the languages listed below, and will be auto-translated as indicated below with the ‘hreflang’ tags that Google Play store uses in their rel=alternate tags to link to these variations. Languages that will not be auto-translated are bold and pink, so that they are easy to spot.
 Google Play Language Support |
|||
| Afrikaans – af (hreflang=”af”) Amharic – am Arabic – ar (hreflang="ar") Armenian – hy-AM (hreflang="am") Azerbaijani – az-AZ Basque – eu-ES Belarusian – be (hreflang=”be”) Bengali – bn-BD Bulgarian – bg (hreflang=”bg”) Burmese – my-MM Catalan – ca (hreflang=”ca”) Chinese (Hong Kong) – zh-HK (hreflang="zh_HK") Chinese (Simplified) – zh-CN (hreflang="zh_CN") Chinese (Traditional) – zh-TW (hreflang="zh_TW) Croatian – hr (hreflang="hr") Czech – cs-CZ (hreflang=”cs”) Danish – da-DK (hreflang=”da”) Dutch – nl-NL (hreflang="nl") | English – en-AU English – en-CA English – en-IN English – en-SG English (United Kingdom) – en-GB (hreflang="en_GB") English (United States) – en-US (hreflang=”en”) Estonian – et (hreflang=”et”) Filipino – fil (hreflang=”fil”) Finnish – fi-FI (hreflang="fi") French – fr-FR (hreflang=”fr”) French (Canada) – fr-CA (hreflang="fr_CA") Galician – gl-ES Georgian – ka-GE> German – de-DE (hreflang=”de”) Greek – el-GR (hreflang="el") Hebrew – iw-IL Hindi – hi-IN (hreflang="hi") Hungarian – hu-HU (hreflang="hu") Icelandic – is-IS> Indonesian – id (hreflang="in") | Italian – it-IT (hreflang=”it”) Japanese – ja-JP (hreflang="ja") Kannada – kn-IN Khmer – km-KH Korean (South Korea) – ko-KR (hreflang="ko") Kyrgyz – ky-KG Lao – lo-LA Latvian – lv (hreflang=”lv”) Lithuanian – lt (hreflang="lt") Macedonian – mk-MK Malay – ms (hreflang=”ms”) Malayalam – ml-IN Marathi – mr-IN Mongolian – mn-MN Nepali – ne-NP Norwegian – no-NO (hreflang="no") Persian – fa Polish – pl-PL (hreflang="pl") Portuguese (Brazil) – pt-BR (hreflang="pt_BR") Portuguese (Portugal) – pt-PT (hreflang="pt_PT") | Romanian – ro (hreflang=”ro”) Romansh – rm Russian – ru-RU (hreflang=”ru”) Serbian – sr (hreflang="sr") Sinhala – si-LK> Slovak – sk (hreflang="sk") Slovenian – sl (hreflang="sl") Spanish (Latin America) – es-419 (hreflang="es_419") Spanish (Spain) – es-ES (hreflang="es") Spanish (United States) – es-US Swahili – sw (hreflang="sw") Swedish – sv-SE (hreflang="sv") Tamil – ta-IN Telugu – te-IN Thai – th (hreflang="th") Turkish – tr-TR (hreflang="tr") Ukrainian – uk (hreflang="uk") Vietnamese – vi (hreflang="vi") Zulu – zu (hreflang="zu")  |
Relying on the auto-translation feature is not a strong ASO strategy because it is primarily based on Google Translate results, which may not choose the most optimized or ideal keywords for ASO search and discovery. The auto-translate feature also ignores the Long Description entirely. If you prefer not to use the auto-translate results from Google, app metadata translations can also be submitted, along with translated videos and screenshots for inclusion in the store.
From an ASO perspective, the best option is to do localized keyword research for each metadata language you need, and work with your own translators to incorporate that research when writing your own local versions of the metadata for each language or localization. Then you can add that metadata individually in the Google Play Console, by going to ‘Manage Translation/Add Your Own Translation Text’ to changing the metadata for each specific language. If you are struggling to find translators, Google offers a fee-based service for translation of the Long Descriptions. This fee-based service is just for translation, so you will not get the full benefits of strategic, ASO-focused localization.
You can see Google Play’s Language-First orientation play out in the URLs of the online version of the Google Play Store. The ‘hl=’ designation in the URL shows the app metadata language. These mostly follow standard ISO web language abbreviations, but when there is a specific localization available, they can change, as outlined in the table below. Some languages are designated ‘default’ languages (highlighted in pink), and this means that they are available in multiple locations without further localization. Other languages like Portuguese for Brazil and Portuguese for Portugal, are only a default setting in one country, and have no broader options that could cover other countries.
Google Play Web URL/App URICountry-First (iOS App Store): In iTunes, you can submit one app to multiple countries, with multiple app content and metadata translations. When submitting the app, you can supply any metadata localizations you would like, but Apple restricts which localized metadata will appear in-store listings based App Store country, so only some country and language combinations will actually display the localized metadata in the App Store or help your keyword rankings. (We discuss these limitations in more detail later in this article, in the “Regional & Default Languages” section.)
A full list of countries that are supported in the App Store is available online, and this is a great place to start if you are trying to decide where in the world you would like to launch your iOS app. It is also useful for finding the country abbreviations that the App Store uses in their URL structure if you are trying to get more information about their support, or what to expect for the country or region. iTunes will populate the metadata for each country’s store differently, according to the hierarchy of default languages that is specific to each country’s store, and the available metadata localizations it can use. In countries where more than one language is spoken, a user’s device settings may also impact which metadata localization iTunes will display for them.
This metadata hierarchy plays out in the structure of URLs for the Apple App Store. The country is the first subfolder in the URL (highlighted purple in the grid below). Sometimes there are language parameters at the end of URLs (highlighted pink in the grid below), which display metadata in different languages. URLs with language parameters will only display that language if that metadata is supported in that country’s App Store; if it is not supported, the default metadata language for the country will be shown. This test can be helpful for ASOs to use App Store web URLs when researching potential metadata restrictions for their app. Below is a grid with some examples of URLs structure for the Apple App Store, and the metadata that displays, or doesn’t, in the case of restrictions. Localization and language combinations that do not display matching metadata are highlighted red.
 Examples of Apple App Store Web URLs | Localization + Language |
|---|---|
| https://itunes.apple.com/de/app/facebook/id284882215 | Germany - Default (German) |
| https://itunes.apple.com/de/app/facebook/id284882215?l=en | Germany - English (UK) |
| https://itunes.apple.com/de/app/facebook/id284882215?l=fr | Germany - French [Restricted - Displays German metadata, not French]: NOTE: The Apple App Store in Germany seems to restrict metadata to German and English. We see this restriction at work when we try to view French metadata in the German store by adding a French language parameter (“?l=fr”), and the store listing displays the default metadata language (German) instead. |
| https://itunes.apple.com/us/app/facebook/id284882215 | United States - Default (English [US]) |
| https://itunes.apple.com/us/app/facebook/id284882215?l=es | United States - Spanish (Mexico) |
| https://itunes.apple.com/us/app/facebook/id284882215?l=de | United States - German [Not Supported - Displays UK-English metadata, not German] NOTE: As expected, the Apple App Store in the United States limits the possible metadata to English and Spanish. You can see this restriction at work when you try to view German metadata in the United States store by adding a German language parameter (“?l=ge”), and the store listing displays the default metadata language (UK-English) instead. |
| https://itunes.apple.com/in/app/facebook/id284882215 | India - Default (UK-English) |
| https://itunes.apple.com/in/app/facebook/id284882215?l=hi | India - Hindi [Not Supported - Displays UK-English metadata, not Hindi] NOTE: As expected, this request shows UK-English instead of Hindi, since Hindi is not supported in the App Store. |
| https://itunes.apple.com/ca/app/facebook/id284882215 | Canada - Default (US English) |
| https://itunes.apple.com/ca/app/facebook/id284882215?l=fr | Canada - (Canadian French) |
| https://itunes.apple.com/ca/app/facebook/id284882215?l=fr | Tunisia - Default (UK English) |
| https://itunes.apple.com/tn/app/facebook/id284882215?l=fr | Tunisia - French [Not Supported - Displays UK-English metadata, not French] |
| https://itunes.apple.com/sa/app/facebook/id284882215 | Saudi Arabia -Default (UK-English) |
| https://itunes.apple.com/sa-ar/app/facebook/id284882215 | Saudi Arabia - Arabic[Not Supported Yet - Displays UK-English metadata, but we expect this to change soon!] NOTE: This url is still 404, but it is linked to from the UK English version of the page. We believe this may indicate that the App Store may be about to start supporting Arabic - in Saudi Arabia, but also in many other countries where the primary language is Arabic. This would be a big deal, since many people whose primary language is Arabic are less likely to speak, write or search in secondary languages. * |
Africa | Middle East |
||
|---|---|---|---|
| *Countries Where Arabic is Spoken, & Where We Expect Arabic Might Soon be Supported in the App Store | |||
| Arabic Speaking Countries Already in the App Store | Arabic Speaking Countries NOT Already in the App Store (But Could Now Be Added) | Arabic Speaking Countries Already in the App Store | Arabic Speaking Countries NOT Already in the App Store (But Could Now Be Added) |
| Egypt | Algeria Chad Djibouti Comoros Eritrea Libya Mauritania Morocco Sudan Tunisia Tanzania | Bahrain Israel Jordan Kuwait Qatar Saudi Arabia United Arab Emirates | Iraq Lebanon Oman Palestinian territories Syria |
Conceptualizing Your International ASO Strategy
Knowing the store-specific details will allow you to conceptualize, research, submit, verify, and set KPIs for ASO metadata effectively for multiple countries. To make all the concepts a bit more simple, we have broken the discussion up into the ‘Store-Side Elements of International ASO’ and the ‘User-Side Elements of International ASO.’ The ‘Store-Side’ elements are basically the metadata and category selection for the app. The ‘User-Side’ elements of ASO are simply the app content itself, and the secondary impact that user device setting that can have on the search results users see in the store. Since the ‘User-Side’ parts of ASO are driven by the ‘Store-Side’ elements, we will explain the “Store-Side” elements first, and then talk about how they impact the user.
Country-Specific Dialect Designation | iTunes App Store |  Google Play Store |
|---|---|---|
| India - Hindi | NO | YES |
| India - English | NO | YES |
| Mexico - Spanish | YES | NO |
| Portugal - Portuguese | YES | YES |
| Brazil - Portuguese | YES | YES |
| UK - English | YES | YES |
| Australia - English | YES | YES |
| Canada - English | YES | YES |
Store-Side Elements of International ASO
To help encourage localization, both of the app stores have separate metadata for dialects of the world’s most-used languages. For example, both the iTunes App Store and Google Play Store include language designations like UK-English, Canadian English, and Brazilian Portuguese. The two stores don’t always support the same languages and dialects; For example, Google Play supports separate metadata for Indian English, but iTunes does not, as you can see illustrated in the chart to the right. Conversely, both iTunes and Google Play support separate metadata for the the UK, Australian, and Canadian versions of English, also shown on the right.
In Google Play, historically it has been strategic to have an app and metadata in one common language like English, so your app can theoretically be ready to launch in all countries where a particular language is spoken, even if is not the primary language of the country. Uploading English metadata is a quick way to reach a larger share of the market in Google Play because that store displays metadata based on user’s language preferences on their device, and many devices will have English accounted for in their list of language preferences.
| NOTE: Google Play just announced that they will soon begin allowing apps to launch staged roll-outs that are explicitly targeted to a particular country, which will make testing and launching international app version updates much easier, and less potentially disruptive if the updates are buggy. There is likely an ASO benefit to managing these roll-outs to help make the most of the download volume and velocity. |
Conversely, in iTunes, it is vital to know what languages iTunes associates with each country for both the app content and the app metadata (in the store) because they are not always the same. Occasionally, Apple will support one group of languages for an app’s content and another group of languages for the App Store metadata in that same country. (A good example is India, discussed in the paragraph below.) What is interesting here is that Apple does not seem to be using any editorial review to verify that the app or metadata is in the language that it claims to be. There could be circumstances in which it makes sense to ‘fudge’ the language designations a bit, for instance, labeling ‘US-English,’ ‘UK-English’ until the UK specific metadata is researched and ready to launch, or US-English, even if the metadata includes a significant amount of Spanish too.
These concepts are often easier to understand by way of example:
India has more people than all of the countries that speak German, Italian and French, combined, so if you are marketing an Apple app, it might be strategic to launch in India first. To launch there, you need to make sure that the app content itself is available in Hindi or UK-English. iTunes does not currently support Hindi metadata in the App Store, so the app metadata can only be in UK-English. (And yes, iTunes has been accused of being Anglo-centric before.)
Teams have to be organized enough to build the app in Hindi, but write and submit metadata in UK-English. In that metadata, it will be important to explain (in English) that the app itself supports Hindi, especially if you need to clarify if the app itself does not actually support UK-English. From a strategic perspective, you should always verify that the language you choose to launch with is widely spoken in the country it is launching in, but the good news here is that many people in India do speak some English.
Since Google Play supports both English and Hindi metadata in India, the app and the metadata can be written in either language. The ability to target both languages broadens the appeal of the app so writing the app content and metadata in both languages is the strongest option, but not required. Since Google Play does not require content in both languages, it is easier for companies without translators to launch apps in either language (one or the other), which helps reinforce the idea that Android is the best option for targeting “The Next Billion Users” (discussed in Article 1 of this series).
Regional & Default Languages
As mentioned earlier, both iTunes and Google Play allow you to deploy your app metadata in any language. If needed, both stores also seem to fall back to English metadata for many international localizations. This tends to happen when an app has not uploaded localized metadata for a territory, or if localized metadata is not yet supported for a territory. In iTunes, UK-English is the default version of English, so submitting UK-English metadata can improve your ASO options for many countries around the world. In Google Play, US-English is the default version of English, so submitting US-English metadata can help with the international optimization for your app.
User-Oriented Elements of International ASO
Apple goes a step beyond the normal store adaptations for language and country localization based on the user’s phone settings. They also seem to reference the user’s iCloud language settings – both for determining what should rank, and what languages apps should launch in. We believe this extra effort is in place, just in case a user prefers to access the App Store in a language that is different from the phone OS language. This could be especially important in countries like Switzerland, where there are multiple metadata localizations that can be shown to users. It could also be important in instances where the App Store language does not match the most-likely default device language, like in the Hindi/UK-English example. Many Indian users probably have their phone OS language set to Hindi, but need the App Store to use UK-English, since Hindi is not supported. In this case, the App Store experience will be in UK-English, but the app will launch in Hindi.
It is possible that Google also updates Google Play search results based on language settings in Gmail/Google accounts, but we have not seen evidence of this yet – Remember, it is less needed, since Google Play is organized with language-first (though it is definitely something to watch out for in the future). When a device’s OS language is set to a minor language (like Afrikaans and Icelandic) and nothing else, the Google Play store presented mostly US-English metadata but also includes UK-English metadata for some apps. It appears that they do this only for apps that perhaps have yet to uploaded US English metadata.
It is also important to know that sometimes, submission of metadata in one language will have an additive, beneficial impact on search results in another country where the app is also submitted – even if it is in a different language. Neither store does anything to make these relationships clear, but it can be very strategic. A great example of this additive impact is included below:
Mexican Spanish in the iTunes App Store; companies that submit an app to the US App Store and assign it a ‘Spanish (Mexico)’ localization should expect to see the app ranking in the US Store for keywords included within the “Spanish (Mexico)” localization. This is true, even if the app’s content is not available in Spanish, and if the Mexican Spanish metadata is actually written in English.
If the app’s content is not available in Spanish, ranking well for Spanish-language keywords may not be helpful for your business. Furthermore, if the app is also only available in the US, you will not be concerning yourself with any additional Latin American marketplaces. This means that you can safely use the Spanish (Mexico) localization like an extra keyword field for the US, which can be pretty handy.
Companies that are not actively monitoring ASO search results in different countries might never know, so most of this information related to this relationship is based on our own experiences. To make the most of this relationship, companies should avoid replicating keywords in both US and Mexican metadata elements like the Title and the Subtitle. That being said, it is also important to make the metadata look real, and not overly spam it, to avoid generating undue attention from the Apple Editorial teams.
It is a different story if you have an app that you actively want to market in both the US and Mexico. In that case, companies should do keyword research for both versions of the app store – iOS US and iOS Mexico, and write the Mexican metadata with the understanding that it will have an additive impact on the US rankings as well. The Mexican metadata can still include keywords that help the US app, especially in instances where the keyword research has overlapping positive results, but the main focus of the Mexican metadata should be ranking in the Mexican market.
Below is a grid that should help clarify the major languages, dialects and localizations that are supported and not supported between the two stores. Here’s how to interpret the grid below. The “Language/Region” column on the far left shows the language and region of the language metadata. In the subsequent columns to the right, more detail are provided for each store in the “Language Designation” columns.
| iTunes App Store | Google Play Store |
|||
|---|---|---|---|---|
| Language/Region | iTunes Connect Language Designation: The metadata language in iTunes Connect. | Localizations Available/ Impacted: Localizations where the “Language Designation” (column to the left) can appear in the store and rank in search results. | Google Play Console Language Designation: The metadata language uploaded in Google Play Console. | Top Localizations Impacted: Most common territories where the metadata from the “Language Designation” (column to the left) will be displayed to users & where keywords tend to rank the best, (since translations can technically show anywhere)** |
| English - United Kingdom | UK - English (Most Store Listings Impacted World Wide) | United Kingdom, India, Republic of Ireland, United Arab Emirates, Singapore, Mexico, Germany, Belgium, Kenya, South Africa | UK - English | United Kingdom, United States**, Canada** |
| English - United States | US - English | United States | US - English (Most Impacted Store Listings World Wide) | United States, United Kingdom**, Canada** |
| English - Canada | Canada - English | Canada | Canada - English | Canada |
| Spanish - South America | Mexico - Spanish | Mexico, United States, Argentina, Chile, Colombia, Venezuela | LATAM - Spanish | Mexico, Argentina, Colombia, Chile, Peru |
| Spanish - Europe | Spanish | Spain | Spain - Spanish | Spain |
| French - Europe | French | France, Switzerland, Belgium, Luxembourg | France - French | France, Belgium, Switzerland, Luxembourg, Canada** |
| French - Canada | Canadian French | Canada | Canada - French | Canada |
| French - Africa | French | NONE - iTunes localizations in Africa seem to display English (United Kingdom) metadata | France - French | Algeria, Madagascar |
| Simplified Chinese - East Asia | Simplified Chinese | China (Mainland) | PRC - Chinese (Simplified Chinese is the official script of the People’s Republic of China [PRC].) | China (Mainland) |
| Traditional Chinese - East Asia | Traditional Chinese | Hong Kong, Taiwan, Macau | Hong Kong - Chinese | Hong Kong |
| Taiwan - Chinese | Taiwan | |||
**Sometimes, we observed that certain keywords in metadata for a particular language designation ranked in a country and other keywords (in that same metadata) did not. When we have seen mixed results like this, we added an asterisk (**) to the grid. Since mixed keyword-ranking results are possible, we recommend doing your own research and monitoring for keyword-ranking impact.  |
||||
Below are two examples to help understand the proper interpretation of the information in this chart:
Spanish: If you have authored iOS metadata in Spanish (Mexico) you will be able to target all of the Spanish-speaking countries in Latin America very quickly, but not Spain. But if you are working on an Android app, you can publish metadata in LATAM Spanish and it will cover all the Spanish-speaking countries in LATAM, Mexico, and any users in Spain with “Latin American Spanish” set on their mobile device (but most will have their phone default set to Spain-Spanish). It’s possible but less likely that this metadata will also be displayed to users with “Spain Spanish” set on their device because that preference is a pretty close language match. We believe that Google Play uses a competitiveness threshold to determine when this happens; for high competition queries, with lots of potential apps to rank, Spain-Spanish is less likely to show, but for low competition queries, where there may not be enough apps to generate a good search result, it becomes more likely. We recommend testing metadata on your devices to confirm that this happens, as this isn’t a scenario we’ve tested.
French: If you have French iOS metadata, you could also theoretically use ASO to reach France, Switzerland, Belgium, Luxembourg, but none of the French-speaking countries in Africa. If you have Android metadata written in France-French, you could reach France, Belgium, Switzerland, Luxembourg, Canada, and French-speaking countries in Africa. To target Canadian users more precisely, you can upload French Canadian metadata, but it is not required.
Update (1/24/18): There seems to be a new “App Stores and Localizations” grid that displays as a pop-up in iTunes Connect (screenshot below). You can access that grid by clicking the question mark next to the metadata-language drop-down and then clicking “App Stores and localizations.” (Screenshot of that navigation path below.)
To use the iTunes grid, select one of the five App Store regions from the drop-down at the top. The left column of the grid (“App Store”) lists each App Store country. The right column (“Language”) displays the metadata language localization in iTunes Connect that impact each App Store country. The data in this iTunes grid matches our findings published in our localizations grid (above), including the observation that English (UK) metadata impacts the most App Store countries worldwide.
Other things that can impact ASO search results include the model of the phone (remember, the model is different from the OS), which is much more common in Google Play, since compatibility issues associated with specific handsets are more common. We have also seen that the time and/or time-zone of a search may also impact rankings. This could be related to an app’s download velocity at different times of day, but could also just represent normal fluctuations or simply be a random bug associated with the app store data-centers or their APIs. (More research is in progress here!)
Conclusion:
The complexity between how the two app stores handle country and language relationships can impact your app deployment strategy, and understanding these differences will go a long way to maximizing any international ASO results. It could also save your teams from wasted time and effort caused by a misunderstanding of how the two stores operate. Just because a language, dialect or strategy works or is available in one of the app stores does not mean that it will work or be available in the other. This is critical to understand because it often adds to the overall cost of an international ASO strategy; work for one store may not carry over any shared benefit for the other. Also, in companies where the Android and iOS teams always work in parallel, these complexities could make that more challenging. Here is a quick recap of the differences between the stores:
| iTunes App Store | Google Play Store |
|---|---|
| For iTunes, metadata only helps with ASO rankings if it is in a supported country-language combination. For example, Spanish (Mexico) metadata helps with ASO rankings in Mexico and the United States (both supported country-language combinations), but does not help with ASO rankings in France (not a supported combination). | For Google Play, any metadata language can rank in any country where the app has been launched. Keyword ranking success varies based on language, territory, and the keyword itself. Common metadata and localization combinations (like French metadata in France) will rank better than less-common metadata and localizations combinations (like French metadata in the United States or Spain). |
This article compared and contrasted the international organization of the two app stores and how those differences impact an ASO strategy. The iTunes App Store is organized country-first and Google Play is organized language-first. This subtle difference can impact the details and approach you take with your ASO strategy, as well as larger priorities and goals that a company reasonably be able to achieve. This article also covered the user-focused elements of an international SEO strategy, and how apps may support different languages than the stores that sell them (especially iOS), and how that can impact users’ search queries. Finally, the article clarified how the country and language settings on a phone and in a user account control and change the search results that any particular user might see, and why this is important for your strategy.
The next article in this series will focus on the execution of an ASO strategy, including how to complete international keyword research, as well as how to upload and verify the metadata.
