What to watch for in 2018: Mobile SEO predictions

As we wrap up 2017 and look forward to 2018, many SEOs will speculate about what to expect in the year to come. Since my focus is mobile, I wanted to share my unique expectations for 2018 by outlining what we know and what we suspect on the mobile SEO front.

This past year brought a lot of changes to the mobile ecosystem, though we are still waiting expectantly for the launch of Google’s mobile-first index. We have been assured that it will launch sometime in 2018, and we hope this is true.

For this article, I plan to focus on a few of my key predictions for 2018: the blurring of the lines between app and web, cross-device convergence and the increased reliance on schema markup in HTML, JSON and databases. I will then tie all the trends together with unique speculation about what mobile-first indexing will actually be and what strategies you can start incorporating now to create an immediate SEO benefit.

This background information about mobile trends and the long-term expectations about mobile-first indexing should help you prioritize and plan for a more successful 2018.

Blurring of the app/web lines

The biggest trend in 2017 that will continue to grow in 2018 is a movement toward Progressive Web Apps, or PWAs. You can expect them to be an even bigger focus in 2018.

Just as a refresher, Progressive Web Apps are websites that enable an app shell and configuration file to be downloaded to a phone, which allows it to take on all the best characteristics of a native app while living on the web. Remember, “web apps” are basically just JavaScript-heavy websites that look like native apps, so making them function as a PWA just entails adding a couple of extra files and a little more functionality.

The great thing about PWAs is that they allow for an app icon, full-screen display without an address bar, speedy on- and offline functionality and push notifications. They are a good way to help companies build a bridge between the discoverability of the web and the engagement and satisfaction that users experience with apps, all while minimizing overhead. They can be used directly on the web or installed like a native app on Android devices (and iOS devices soon, too). That means there is a lot less to maintain, optimize and promote, so they are incredibly attractive to savvy companies of all sizes.

The app development trends will start to shift away from native apps and toward PWAs as more companies begin to understand the value that PWAs can provide. The Android OS now treats PWAs almost exactly like native apps, showing their resource consumption and specs in the exact same places, displaying them in the app tray, and soon, adding them to the Google Play Store. Google has also begun to transition many of their specific-interest web resources into PWAs, including Traffic, Sports, Restaurants, Weather, Google Contribute, Maps-Go and Weather PWA.

You can see this trend in action below. The first screen shows a web search result for the local weather. The next screen shows the same search result with a different presentation and the option to add it to the home screen. The third screen shows the dialogue where you accept addition of the PWA icon to your home screen. The final image shows Google’s native weather app and its weather PWA app icons side by side. The two apps do the exact same thing and have the exact same interface.

[Click to enlarge.]

PWAs are also important because they remove the need for companies to set up deep links from their websites into their apps and vice versa — a process that has proven complicated and sometimes impossible for large companies that don’t have exact parity between their app and website content. Google always prefers to recommend and reward the least error-prone options, and in our experience, deep linking the old fashioned way is very error-prone. Every time something changes in the app or content moves on the website (individual 301 redirects or a full migration), app indexing and deep linking is at risk of failing or completely breaking down.

And even when your deep links are working correctly, referral touch points and attribution can be nearly impossible to track without the assistance of third-party services. This is a stark contrast to the simplicity of linking on the web. PWAs are self-contained apps that are already indexed on the web, eliminating all that complexity.

If everything that happens in your company’s app can be achieved in a PWA, it makes sense to focus efforts on the PWA — especially if the company is struggling with deep linking. As long as your PWA is well indexed and delivering a great user experience, Android deep links will be irrelevant.

Since PWAs will be in Google Play with native apps, Android users likely won’t be able to tell the difference between a native app and a PWA. On Android, it is important to note that Google may eventually change how they treat deep links when a PWA is available. Google may begin to prefer PWA content over deep links (especially if the app is not installed), just as they have done for AMP content.

This is less of a concern for iOS, especially if deep linking is happening through iOS Universal links rather than any Firebase implementation. Since Universal Links are executed with the iOS operating system rather than the browser, it seems likely that iOS will continue to honor Universal Links into apps, even if a PWA is available.

Just remember that, in both cases, if the PWA is replacing the website, the app deep links will need to match up with the URLs used in the PWA. If the PWA is in addition to the main website, only the web URLs that are associated with app URIs will trigger the deep links.

As Google begins adding PWAs to Google Play and indexing them on the web, this could make it easier for it to add app logos to SERPs for both Android and iOS, improving the appearance, CTR and engagement of the PWA links. Regardless, there may still be a push for all app deep links to be moved into its Firebase system, to help Google improve its cross-device, cross-OS reporting and attribution. Depending on how quickly Google is able to finish launching mobile-first indexing, this is something that may be a big push for the company in the second half of 2018.

We are seeing similar changes on the app store optimization (ASO) front as well. The Google Play algorithm is historically much less sophisticated than the Google search algorithm, but recent changes to the Google Play app algorithm show a much larger focus on app performance, efficiency, engagement and reviews, and a relative decrease in the importance of app metadata. This could be considered a signal of a potential impending merge between Google Play and regular SERPs, since we know performance is an important ranking factor there. When PWAs are added to the Google Play Store, native Android apps will be competing against PWA websites in terms of performance. Conversely, this will likely mean that PWAs may also be subject to ranking fluctuations based on user reviews and star ratings.

Though it is less prominent for SEO, the same may be true in the Apple world of technology. Historically, Apple was resistant to allowing their Safari browser to support PWAs, but recent announcements make it seem as though the company’s perspective has flipped. In 2017, Apple finally made it clear that Safari would soon support the Service Worker files that make PWAs so useful, and just this month (Dec. 12, 2017), in its quest to eliminate the use of app templating services, Apple seemingly endorsed PWAs as a better option for companies with limited budgets than templated native apps!

Apple’s sudden and emphatic endorsement of PWAs is a strong indication that PWAs will be supported in the next Safari update. It may also indicate that Apple has developed a scheme to monetize PWAs. Apple could also plan on adding them to its App Store (where they can exercise more editorial control over them). This is all yet to be seen, of course, but it will be interesting.

Cross-device convergence

The next major theme to expect in 2018 is cross-device convergence. As the number and purpose of connected devices continues to expand, mindsets will also need to expand to take on a wider view of what it means to be “cross-device.” Historically, cross-device might have meant having apps and a website, or having a responsive design website that worked on all devices. But in 2018, people will start to realize that this is not enough. As the line between app and web merges on mobile, it will also merge on desktop and the Internet of Things (IoT).

As more information moves to the cloud, it will be easier to seamlessly move from one device to another, maintaining the state, history and status of the interaction on all devices simultaneously. The presentation layer will simply include hooks into a larger API. Developers will be more focused on testing data integrations of one app across many different devices, rather than testing multiple, device-specific apps on multiple devices (somewhat similar to the transition to responsive design on the web).

There is a store for Google Home and a store for Google Actions, Google’s Voice-First and Voice-Only channels, but these will probably merge into the same store — possibly when the mobile-first index fully launches, but more likely soon after. You can expect an eventual convergence of mobile and desktop app stores, operating systems and search utilities, though this won’t all be completed or even initiated in 2018. It is just the direction things are going.

We have already seen this happening in some places. The convergence between mobile and desktop is most obvious when you look at the changes that happened in Windows 10. The desktop OS incorporates an app store and looks much more like an Android phone, even including customizable widgets in the “Start” screens. Microsoft announced just this month that Service Workers, push notifications and local cache will all also be enabled by default in Microsoft’s new Edge browser, which is intended for both desktop and mobile.

PWAs and Android apps are already available in the Windows app store, which means that PWAs are already available and partially usable on desktop. In that same vein, Microsoft has now made a point of making some of the top software, like Outlook, Excel and Word, available on Android devices, without a license.

There are also indications that Google may begin to test sponsored App Pack rankings. Since App Pack rankings happen in the regular SERP rather than an app store, this could be important for desktop, too. As companies begin to realize how useful PWAs are, they will have a visual advantage over other sponsored results on both mobile and desktop.

Google and Microsoft/Windows have always been more willing to coexist without walled gardens, while Apple has always leaned toward proprietary products and access. If Safari mobile will support PWAs and Service Workers, then it may also be true for the desktop version of Safari, meaning that the line between mobile and desktop will be merging in the larger Apple universe, too. The MacOS has had its own app store for a long time, but the Apple teams, like the Android and Windows teams, have also reported that they will be merging the MacOS and iOS stores into one in 2018.

This cross-device, voice- and cloud-oriented model is already being pursued with Cortana’s integration in Windows 10, where the mobile and desktop app stores have already merged. Similarly, Siri, Safari and Spotlight work cross-device to surface apps and websites, and Google has added voice search to desktop — but they have both yet to really push the assistant to the front and center as a means of surfacing that app and web content on all devices.

There were rumors that iOS apps would also be available in the Windows app store, but that looks like it has fallen through, at least in terms of 2018 planning. Instead, Apple may have decided to extend or merge its own iOS App Store with the desktop version of the store and could also have decided to include PWAs for the desktop experience.

The last thing to watch out for in this trend is changes with Accelerated Mobile Pages (AMP). AMP was designed to make webpages fast and mobile-friendly, and even though these enhanced pages can work on desktop and probably could integrate easily with voice, Google has reportedly struggled to integrate them into the mobile-first index. While it does provide a lot of advantages, AMP will probably have to make major changes or face a reckoning in 2018. There are still significant problems that need to be resolved in terms of UX and measurement.

Increased reliance on structured data markup in more places

The final thing to watch for in 2018 is Google’s push for webmasters to mark up everything with structured data, including social profiles, corporate contact information, books, events, courses and facts. Structured data, and specifically markup that is formatted in JSON-LD to provide semantic understanding, is what allows Google to understand “entities.” (The “LD” in JSON-LD stands for Linked Data.)

We know that structured data will be a big deal because it helps Google figure out what is going on without having to rely so heavily on crawling and parsing all the content on the web — which has become quite a monumental job with no end in sight. This is why Google has switched to requesting most data-rich assets in the JSON-LD format, including Google Action markup, Web-app manifests, and the files saved by Service Workers.

Last year, before Google I/O, Google made a big point of creating a structured data testing tool that gave specific implementation instructions for a variety of different kinds of markup. The kinds of schema included there, not surprisingly, are specifically good for interactions with Google Home, Google Assistant and Chromecast — things like restaurants, reservations, travel plans, music, TV, movies and recipes.

Content that is well marked up with structured data can be easily parsed and presented on non-traditional devices through voice search and interaction (like with Google Assistant, Google Home, Android Auto). This is also a big deal for non-Google products like Amazon Alexa, Siri, Fitbit (which launched its own OS-specific partner apps) and voice-enabled TV remotes.

The one thing in Google’s structured data documentation that has not gotten due attention is the database or data set markup (i.e., instructions for how to add structured data markup to your database). Databases don’t necessarily have URLs or need websites, and this is core to the theory that the mobile-first index will not require URLs for indexing and that it will rely on schemas and entity understanding.

Let’s look at an example of how markup is creating “entity” understanding. Below, you can see a search result for a specific boot. Rather than showing all the web locations where you might find that boot, Google has aggregated it into a utility that can give users a lot more information directly from the SERP.

The result shows the full name of the boot, as well as what stores have it in stock and at what prices. It also shows the star ratings for the boot and lets me toggle to different sizes and colors. If I click the tabs, I can see more details about the boot and read reviews that have been aggregated from all the places that sell it. Since this information is an aggregation of information from all over the web, it actually does not have a static URL, so Google includes a triangle “share” link so that the aggregation itself can be shared.

This sharing functionality is something that you can expect to see much more of in mobile-first indexing. It is an indication that Google views a topic as an entity and thus has stored, aggregated or assimilated information on the topic as a whole (the entity). Dynamic links are links that Google generates on the fly, for content that it understands, but that does not naturally have a URL.

It is important to remember that Google’s very first (unsuccessful) attempt to encourage app deep-linking used Dynamic Links, as part of Google Now On-Tap. Then, they were used as a unified link that united the same piece of content on the web, in an iOS app and in an Android app. They allowed one link to trigger the right experience on any device, and if the appropriate app was not installed, the link would fall back to the web version of the content. Now, Dynamic Links are still included as an important part of Google’s app indexing platform, Firebase.

In the next example below, you can see how the linked data helps support entity understanding in a search result. The query is for a popular author, so the result shows pictures and a brief biography at the very top. There are only minor differences between the Google Now result and the Google Web result — one has a dynamic share link, and the other offers the ability to “follow” the entity or concept.

In both, the result aggregates information such as quotes and movies attributed to the author, lists influences and links to a Wikipedia page. Below that, Google displays a carousel of his most popular books, with pictures of the cover and the date they came out. Below that, it shows a “People Also Searched For” carousel, which is full of authors who write in the same genre.

We believe Google is using clicks on these bottom two carousels to verify and vet the linked data that it has assimilated about this author. The more clicks a carousel item gets, the more likely it is linked to the topic of the query.

A new way to think of mobile-first indexing

Knowing these trends should help you understand how mobile-first indexing fits into the larger SEO picture. Inclusion of the word “indexing” in Google’s official title for the update is telling. It indicates that this is not just an algorithm update, but an update to the fundamental architecture and organization of the system. Remember, an “index” is just a repository of ordered information that is easy to query or search. Indexes can be created for all different kinds of information and ordered in a variety of ways: alphabetically, numerically, or in Google’s case, historically based on URLs.

Since native apps and progressive web apps don’t require different URLs to show different content, we believe the method of indexing and organizing content has to change. Forcing URLs into those new technologies has proved untenable, so Google needs a new index — and it will be one that prefers “portable” content that lives in the cloud and is well marked up with structured data. It will probably be an “entity index” based on unique “entity concepts” that include domains (with URLs), native app entities and their content, PWA entities and database entities that need no design elements at all.

Use of the phrase “mobile-first” in the name is also interesting. With both the mobile-friendly update and mobile-first indexing, Google repurposes phrases that were previously used to describe design elements — but in both, Google mainly focused on the technological back end that made the design changes possible. For the mobile-friendly update, Google did provide guidelines on how content should look on the page, but based on their testing tool, their main focus was really on the crawlability of dependent files on the site (specifically, the CSS and JavaScript).

The mobile-friendly update was an important precursor to mobile-first indexing because it gave Google what it needed to feed and train its machine learning programs about how they should ingest and interpret JavaScript. As SEOs, we all endured the mobile-friendly update, which preferred sites that qualified as such and awarded them with a mobile-friendly icon when they appeared in search results.

Similarly, the phrase “mobile-first” was originally used to describe a design principle in which responsive design website frameworks were established with the most essential elements of functionality first, and these were meant for mobile devices with the smallest screens. Only later were designers able to add in other, less necessary elements of the design and UX for larger-screened devices that had more room.

It now appears that Google has also co-opted the term “mobile-first” to mean something slightly different, with implications that are much larger than just design. Rather than focusing on mobile devices and screen sizes, Google will put the focus on content accessibility and the cloud and focus much less on the presentation.

This is an important trend because “the cloud” is where Google has been focusing most of their time and innovative energy. Content that is hosted in the cloud, without being formatted specifically for any one device, is exactly what they are after; it is the easiest for them to process with AI and the easiest for them to redisplay on any screen (or read out loud, in voice-only contexts). That is where Google Now and Google Assistant come in.

Google Now was Google’s first attempt at a predictive search engine that anticipated queries before a user even submitted them. It used all the information it knew or could detect about your habits to anticipate information you would want and displayed it in an interface to the left of the home screen on Android phones. It was also available as the Google App on iOS, but it was never as good since they weren’t able to aggregate as many personal habits and preferences from iOS users. Google Now included a voice search capability, but it just translated voice queries into text.

There are minimal differences in most search rankings when you compare regular search in Google.com and a search in Google Now. The primary differences happen when there is a PWA available (like the Weather PWA). There are also some minor variations in the “share” and “follow” functionality, which probably also hint at what to expect in mobile-first indexing. You can see the differences below.

Google Assistant is a bit more sophisticated in that it can sometimes answer simple questions directly rather than just returning a search result. It also uses passive and active signals about a user to ensure that it is giving the most accurate and useful information possible. Google Assistant is the critical element of a Google Home device, which operates primarily with voice but can cast results to connected TVs or phones if visual review is required.

Google Now and Google Assistant are obvious precursors for mobile-first indexing and give us a great deal of insight into what to expect. The two utilities are very similar and may simply be combined for mobile-first indexing. One of the strongest endorsements of this idea is that Google has recently gotten much more aggressive at pushing Android users into the Google Now/Google Assistant world. They moved the query bar from the Google Now interface (one swipe left of the main phone screen) to the standard layout (accessible on all versions of the home screen).

The new search bar just says “Google,” so most users won’t realize that they are accessing a different experience there than in the web-oriented version of Google (google.com).

Google’s most recent blog post about the mobile-first index didn’t really add anything new to the equation, so our best guess is still that the new index will probably also lean heavily on Google’s existing semantic understanding of the web (which is based on Knowledge Graph and its historical incorporation and build-up of Freebase). It will also use cards and AI, like we are used to seeing in Google Now. This concept is backed up by Google’s retirement of the term “rich snippets” and the launch of the new Rich Results Testing Tool on December 19.

The image below shows the different methods Google is using to inform the Google Assistant about an individual user’s preferences, which will help further personalize individual search results. But this data could also be aggregated — in a “Big Data” way — to determine larger patterns, needs and search trends so that it can adapt more quickly.

On the left, you can see a Google Cloud Search, which draws together information about assets on all of my devices that are logged into a Google Account. This includes emails, calendar entries, Drive documents, photos, SMS and apps. Though this has not been the focus of any Google marketing, it is part of Google’s Business GSuite package, which is turned on by default for all GSuite users.

On the right, you can see the Google My Activity tracker. This is another feature that is turned on by default. It is similar to the Cloud Search function, but instead of just being a searchable database, it organizes the information in chronological order. It breaks out my daily activity on a timeline and a map. The data includes the amount of time I spent walking and driving. It also shows the businesses that I visited and the times I was there. It also places pictures that I took on the timeline and associates them with the locations where the pictures were taken.

Elements like this are meant to help Google Assistant have a greater understanding of personal context so that it can respond when surfacing search results, either to an explicit search or to an anticipated want or need (e.g., Google Now).

In the long run, Google Assistant may be the new entry to Google search on all devices, forcing people to log in so that their state and history can be maintained across different devices, and so that a personal history and index can be developed and built out for each user. The beginning of this personal history index is already in Google Now for Android users. It uses active and passive machine learning to track and compile all of a user’s cross-device activity in Google Cloud, then translates that information into predicted needs in Google Now.

Google has already begun promoting a “one-click register and form “complete” and “one-click sign-in” that works and transfers credentials across different devices. This functionality is all currently made possible by Google’s Credential Management API, which means that it relies on a cloud-hosted shared “state” managed by coordination of local Service Workers that pass state changes to the cloud-hosted Google Account. If and when this takes off, it will be a huge boon to engagement and e-commerce conversion because it eliminates the main friction.


From a search prospective, data that lives in one state, regardless of the device, is great — but assimilating all the different types of potential search results into an index is hard. The new mobile-first index will mix together websites with apps, PWAs and other data sets that don’t all have URLs, so this is where structured data markup will come in.

Just as advertising systems profile individual users with device fingerprints, Google will have to organize the new index with similar unique identifiers, which will include web URLs and app URIs. But, for content that does not have an existing unique identifier, like a page deep within a PWA experience or an asset in a database, Google will allow “Dynamic Links” to stand in as their unique identifier so that they can be indexed.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

The upcoming mobile app Monday: Be prepared

The season is upon us: mobile download season. Christmas falls on Monday, and if history holds true, Christmas and the day after will be the top mobile app download days of the year. With less than a week left, your app store optimization (ASO) activities should be in full swing.

Becky Peterson heads up our app store optimization at Walgreens. Becky was looking to be on the nice list, so she put together some optimization tips for new and existing apps to help you maximize the download season.

Optimization essentials

Title: Choose a title for your app that is creative but concise. If appropriate, take advantage of the character limit to include relevant keywords that describe your app’s core functionality. (Just don’t overdo it — you don’t want to appear spammy!)Icon: Create an eye-catching icon that is clean and easily recognizable. A recognizable icon can make the difference when customers are searching specifically for your app.Keywords & description: Conduct keyword research to determine the most valuable and relevant terms for your app. Utilize the keyword field in iTunes Connect, and use your keywords throughout your description and in your creative assets.Video: Create a preview video (or three for iOS!) that walks through your core features and provides visitors an overview of how to use your app. On iOS 11, your previews will autoplay in search results and on your store page; in Google Play, they will underlay the Feature Graphic. Create videos that are engaging. Test, test, test to determine which video version generates optimal downloads prior to the top download days.Screen shots: Create clean and visually appealing screen shots that capture the essence of your app and encourage visitors to continue scrolling through the gallery.

Additional tips

Take full advantage of free app store intelligence platforms, such as App Annie or Sensor Tower, or invest in an app store analytics platform that will provide you with keyword ranking, competitors, Top Chart and download data.If applicable, seasonalize or incentivize your store listing! Use your description to highlight how your app is seasonally relevant and provide offers (i.e., shopping deals, products and more), and update your creative assets to showcase a holiday theme.Respond to your app reviews. Demonstrate to your users that you appreciate their feedback and are constantly working to improve your app. Some reviewers may even choose to update their original review simply because you responded in a considerate manner. Prospective users are more inclined to download an app when it is clear the app owners take feedback seriously.

Capitalizing on the top download days of the year can be the difference between an average app and a top download. Keep your content fresh, do not over-optimize, and remember that the goal is to assist customers in finding the right app for the right purpose. Put in the effort, set download goals, and allocate plenty of time to respond to the flurry of reviews that occur soon after installation and use.

Remember to document your lessons learned once the season is over. Download season will be back before you know it, and those valuable lessons can be the difference-maker next year.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Apple Search Ads expanding to Canada, Mexico & Switzerland

The Apple App Store has announced it is expanding support for Search Ads into Canada, Mexico and Switzerland.

Apple released Search Ads for the App Store a little over a year ago, with previous support limited to the US, the UK, New Zealand and Australia.

Apple’s Search Ad product is the iOS version of what Google Play has offered in its store for Android devices since 2015. Both are aimed at driving app discovery by users.

Search Ads are generated automatically from app metadata, with advertisers setting a daily or total campaign budget. Ads appear based on keyword searches specified by advertisers, along with demographic segments such as gender, age and location. Advertisers can also separate bids by device: one bid for iPhone users, another for iPad users.

A hands-on review of Apple’s Search Ads upon its release in the UK outlines the pros and cons of the platform, along with some items to look out for.

Apple is still offering a $100 USD credit for first-time advertisers. The newly-added countries will be available on the platform starting October 17.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Apple Search Ads: Still tapping after 6 months of testing

It’s been five months since Apple expanded their Apple Search Ads program to advertisers in three additional countries (UK, New Zealand and Australia). After its initial, US-only launch in October 2016, I was really excited to finally get to test out this brand-new platform when it finally launched in the UK.

Now that I’ve had some time to experiment with it, I’m going to discuss what I like, dislike and hope to see in the future across this new and exciting platform. I want to share my own experiences here in the hope that anyone looking to test some Apple Search Ads campaigns in the future can get started as soon as possible.

One of the reasons I was so interested in Apple Search Ads is how booming the app market is globally, with 2.2 million apps available in the App Store alone as of March 2017. Furthermore, according to research by Flurry, the mobile browser is effectively dead — on average, 90 percent of time on mobile devices is spent within apps. So, what does this mean for advertisers? They need to find effective and efficient ways of reaching these potential app users that are growing in value in an ever-increasing competitive market.

Over the past few years, recognizing this clear shift in user behavior, various app install and promotion campaigns have been launched. Universal App campaigns in AdWords and App Cards in Twitter are only a couple. However, the elephant in the room here was the absence of an Apple-specific platform.

Luckily, thanks to the launch of Apple Search Ads back in Q4 2016, advertisers can now serve ads to relevant users at the top of the App Store search results page. They can bid on keywords that will allow their app to be advertised to potential users to increase the number of app installs and app engagement over time. Initial performance looks promising, with AppsFlyer confirming that praise for the platform is justified, coming third in the overall app platform ranking. Not too shabby for a new player in the market!

What I like

Following are some aspects of the Apple Search Ads platform that I felt were intuitive and well-done.

Platform & setup

It’s clear from the moment that you sign up that Apple’s ethos underpins Apple Search Ads, too. Like anything that Apple does, the interface itself is simple and easy to navigate, and it looks crisp and clear. As Apple itself highlights, Search Ads is “designed to be smart, effortless and flexible.” I’ve certainly found this to be true with campaign setup — if you have a confirmed budget and an existing app, you could launch a campaign within a few minutes.

Your ad groups are keyword-focused, with a brand and generic split highly recommended based on our experience at Merkle | Periscopix (my employer).

Another exciting feature is the Search Match option that is selected by default. With this function enabled, your ad will be matched to relevant search terms, without your actively selecting them in the Search Ads interface. Another time-saver. As with brand and generic, you can split this out from your other campaigns so you can closely monitor performance and searches that you are matching against. Similar to the classic Dynamic Search Ads campaigns in AdWords, you can use the Search Match feature to scope out potential new keywords to add manually into your campaigns, giving you more control.

For a client sitting within the retail vertical, we have seen performance differ across the different keyword areas, with generic and Search Match naturally generating a higher cost-per-install (CPI) than brand. Competitor brand targeting has been especially strong, with high tap-through rates (TTR), a low CPI and the second-highest volume of installs.

Average Cost-per-Tap (CPT)Tap-through rate (TTR)InstallsAverage CPIInstall rateBrand£0.1625%6,462£0.2180%Generic£0.8110%26£1.1968%Competitors£0.416%2,170£0.6465%Search Match£0.504%489£1.2739%


As I touched on earlier, from a performance perspective, the numbers are particularly pleasing. At Merkle | Periscopix, we have seen astoundingly low cost-per-install figures, especially when compared to similar campaigns on other platforms like Google, Twitter and Facebook.

For a client within the recruitment vertical (below), the “tap through rate” (Apple’s version of click-through rate) has been regularly over 11 percent across all areas of the account, naturally much higher for brand areas, compared to under 2 percent across Twitter and AdWords.

Apple Search AdsTwitterAdWords (UAC)CTR/TTR11.3%0.4%1.3%Install rate67%2.7%6.5%CPI£0.9£5.5£3.4

One of the things we have noticed is that there is fierce competition for the one available ad slot at the top of the results page:

Daily bid adjustments and monitoring are needed to ensure you aren’t missing out on installs, so don’t forget to keep a close eye on performance metrics. Considering the low CPIs that we have seen to date, especially compared to more well-established platforms, I expect them to increase over time as more and more advertisers begin to utilize the platform.


According to Business Insider, around 30 percent of apps get uninstalled, with companies missing out on potential revenue and future engagement from a large pool of people. Another feature that is particularly important in the world of app promotion is the ability to integrate with other platforms to ensure value is being driven and measured post-install.

Thankfully, third-party tracking tools can connect to the Search Ads API to assist in optimization and reporting and offer more visibility on post-download value and actions, leading to increased user retention and engagement. It’s not just the install that is important but how you keep the user re-opening your app.

iTunes Connect

For those advertisers with multiple apps, the ability to sync with your iTunes Connect hub is pretty great, too. You can market to users that have already installed a linked app of yours, as long as they are all housed under the one iTunes Connect account. For retailers with multiple brands or products that are housed within different apps, this gives you an incredibly simple way of upselling or cross-selling to an already brand-aware user base.

What I dislike

Now, on to the aspects of the platform that didn’t thrill me.


When you consider how pleased we have been with performance to date across this platform, it’s a shame that it’s not easy to actually report back on the metrics. The whole reporting aspect is fairly cumbersome, with no account-level graphs or even a “total” row/column available in the interface. In order to report on performance, you need to download and manipulate the data manually, which is not ideal.

There is always the option of connecting via the Search Ads API for a more advanced reporting option; however, this is not going to be possible for many advertisers for a variety of reasons, so the in-platform capabilities should be addressed as a priority here.


There are quite a few features to which we have grown accustomed through other platforms like Google AdWords and Bing Ads that are not available currently within the Search Ads interface. These include:

segmentation for day parting, device type and location.inability to “select all” at keyword level for bulk bid changes.phrase match keywords — at the moment, it is only possible to use broad or exact match, which can be limiting here.visibility of competitor activity through Auction Insights — as an increasing number of advertisers use this platform, more insight into auction performance is key.more granular location targeting (e.g., ZIP codes) — for those advertisers with tighter location restrictions, this would be fundamental to their campaign setup.

I’m sure these are common feature requests from a large number of advertisers, so I wouldn’t be at all surprised to see these added (plus other more advanced features) over the coming months, as platform usage continues to grow.

Final thoughts

It’s still very early days for this new and exciting platform!

With less than a year since the initial launch in the US, it’s not surprising that there is a lot of room for improvement. For one, I’d like to see Apple Search Ads continue to maintain its strength as a simple and flexible platform, allowing advertisers to continue to see strong performance through campaigns.

As time progresses, I’d like to see the interface become more sophisticated, drawing on the strengths of some of the more well-established platforms to facilitate more advanced optimization and much easier reporting. This will allow agencies to continue to drive value for clients, and advertisers themselves to continue to drive their app promotion activity forward. Watch this space.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

Apple rolls out Search Ads for the App Store

After a beta period that began in June, Apple is now opening up Search Ads for the App Store to all publishers and developers. It’s currently available for the iPhone and iPad only in the US.

While Apple will certainly make money from this program, the main rationale appears to be app discovery. Google has had search ads in the Play store for well over a year.

Search Ads will be delineated with a blue background. Apple will generate the ad images and copy from the app metadata supplied by the publisher or developer, so there’s no ad copy per se. It appears there will only be one ad per search.

Developers set a max daily budget and an overall campaign budget. Apple’s Search Ads use the familiar “second price auction” to set winning bid prices. Apple says that relevance and bid price will determine which ads show. (Developers will pay on a “cost per tap” basis.)

Search Ads allow for bidding on the iPhone or iPad individually. There’s a keyword suggestion tool, with popularity indicators and negative keyword capabilities. There are audience targeting features, including customer type (e.g., has not downloaded) gender, age and location. And of course there are analytics.

App store search is the dominant way that apps are discovered. However, other discovery channels are now growing in relative importance, according to comScore.

Beyond this, comScore says that roughly 50 percent of smartphone owners don’t download any new apps in a given month, while the average user downloads two apps per month.

Search Ads will go live in the App Store on October 5. Developers also receive a $100 credit for the first campaign.

Apple gets into the SEM business with paid-search for app developers

Apple is getting into the paid-search business. At next week’s WWDC, according to a report in The Verge, the company will unveil paid-search ads for the App Store. It’s also going to introduce a new app-subscription revenue sharing model.

The App Store SEM possibility was first raised in a Bloomberg report in April. The actual product launch will come in the fall, but developers are being invited to join the beta today. According to copy on the Apple site:

Search Ads is an efficient and easy way for you to promote your app within the U.S. App Store search results, helping people discover or reengage with your app at the very moment they are searching for apps like yours. Designed to give users a safe search experience, Search Ads sets a new standard for delivering relevant ads while respecting user privacy.

Paid search ads could certainly help solve the app-discovery problem for iOS developers. There’s no information so far on bidding or ranking, although that will probably be further explained next week. A little less than a year ago, Google introduced search ads to the Google Play store.

In addition, Apple will encourage developers to use a subscription model to generate recurring revenue, by giving them a larger cut of the pie after the first year. Apple will continue to take 30 percent revenue cut in year one. But in subsequent years, that will drop to 15 percent. Developers will keep 85 percent of the money, accordingly, after the first year.

Apple will also be expanding the app categories that can sell subscriptions. Previously, only a few had access to subscriptions. The new subscription option will launch at WWDC next week.

Apple announced last quarter that it had roughly $6 billion in “services” revenue, which includes App Store revenues. In 2015, the company said it saw $20 billion in App Store revenue. Both of these moves will benefit developers, but they could equally benefit Apple’s bottom line.

According to several studies, search and search ads (in Google Play) are responsible for a substantial amount of consumer app discovery. In 2014, TUNE found that just under 50 percent (47 percent) of users found apps through App Store search — the primary method, ahead of “friends and family” and a range of others. To date, Facebook has reaped millions of dollars in app-download advertising.

I haven’t done an analysis to estimate how much money Apple might stand to make from App Store SEM, but it’s probably quite a bit. Even more intriguing is the possibility that it might be a prelude to a bigger SEM play via Spotlight Search.

Report: Apple building AdWords-like ad product for the App Store

Taking a page from Google, Apple is reportedly building a paid-search-style ad product for its App Store. According to Bloomberg, Apple “has constructed a secret team to explore changes to the App Store, including a new strategy for charging developers to have their apps more prominently displayed.”

Bloomberg says that there are roughly 100 employees working on it. Some of the engineers on the project are from Apple’s iAd unit, which has substantially scaled down over the past year or so.

Given app discovery challenges, I would expect an auction for prominent placement to be both popular and lucrative for Apple (provided Apple does a good job with it). When the App Store launched in July 2008, there were only 552 apps. Today, there are more than 1.5 million, creating a significant visibility/discovery problem for publishers and developers.

A substantial chunk of mobile ad revenue is still tied to app promotion. Facebook has been particularly successful with app-download ads.

Assuming the story is accurate, it’s not clear whether Apple is driven by a desire to improve the overall App Store experience or to generate revenue, though probably both. App and services-related revenue amounted to roughly $20 billion (with a “b”) for Apple last year.

How To Take Advantage Of The Recovery Search Opportunity On iOS 9

Apple’s launch of iOS 9 has sparked renewed attention on Apple Search, including the way Apple places more importance on app content in search results on iPhones. 

In an iOS 9 world, the more you interact with an app on your iPhone, the more likely it is for that app to appear higher in iOS Spotlight, Siri and Safari search results on your iPhone. So how should brands think about Apple Search? The answer hinges on how you use search to acquire and service customers.

Recovery Search With iOS 9

With iOS 9, Apple Search has become a far more powerful tool for “recovery search” by drawing upon a number of local data sources, including app content. Author John Battelle introduced the concept of recovery search in his book, “The Search.” 

When consumers conduct recovery searches, they already know about your brand, are more likely to be doing business with you and seek to recover information such as your street address to contact or visit you. “Janet Smith, Chicago cardiologist” or “Burger King, Western Avenue” would be considered recovery searches.

Battelle contrasted recovery search with “discovery search,” which consists of initial searches for businesses in a category, such as “cardiologist near me” or “restaurants near me.” Discovery searches are more likely to be conducted by someone who is not yet a customer of a particular establishment.

To help customers find the location of a company they’ve done business with, it is important that enterprises improve the recovery search experience by making their location data accurate and easily findable.

Improving Findability In Apple Search

iOS 9 has taken some big steps to make business location data more findable by casting its search net more broadly across multiple data sources. In doing so, Apple has become a stronger tool for recovery search.

Businesses that wish to improve the user experience for their customers need to make sure they are present for recovery searches conducted via Apple Search.  

For your brand to be findable via recovery searches in the Apple Search universe, you should ensure that your location data is present and accurate on the following data sources, which I have ranked by how likely each source is to appear in a recovery search:

  • Contacts app content. Apple assigns the highest preference to apps that people use most frequently. When someone does a search in Spotlight or Safari, Apple places a heavy premium on the Contacts app. I asked 20 co-workers with iOS 9 installed to take out their phones, type the first two letters of any word they could think of in Spotlight and tell me what the top result was. In all cases, Contacts information dominated results, as shown here:
  • Apple Maps databases, including publishers such as Yelp and Foursquare, as well as aggregators like Localeze, which distribute location data to publishers. An enterprise that does a good job syndicating its data with data aggregators is more likely to appear more prominently in Apple Maps databases. Are you working with one or many of the companies that submit data directly to Apple? If not, it’s time for you to form relationships with them immediately.
  • Bing search suggestions via “Suggested Website” results. Enterprises with limited time and resources are tempted to put a lower priority on optimizing their content for Bing. With iOS 9, it’s much more important to improve Bing indexing and results.
  • Frequently used third-party apps. Although there are multiple ways that app content can be indexed by Apple Search, to appear in search results, enterprises need to do more than make their data available to be indexed. The frequency with which people use an app to perform a search is the overwhelming factor determining whether that app content becomes available for users performing searches on their iOS devices.

    Considerations For Digital Marketers

    These data sources underscore how iOS 9 is designed more to enable recovery searches than discovery searches. So how should digital marketers be thinking about iOS 9 and Apple Search? I recommend that brands do the following:

      Examine whether and how Apple Search should be a priority at your organization. Is your primary mandate to acquire new customers, those who are more likely performing discovery searches? Then devote your time and resources elsewhere. Is your goal to improve your existing customers’ mobile experience? If so, put a higher priority on Apple Search.Identify a partner that will allow you to send data directly to Apple. As with Google, authenticated data directly from your business will generally trump other data sources. Have strong relationships with data aggregators, which perform the crucial role of providing your location data to publishers such as Apple and Facebook. Publishers are constantly launching new apps, and those businesses usually first turn to aggregators as their sources for location data. Apple started using data licensed from aggregators two years ago, and perhaps Snapchat or some other popular app will soon launch an app that connects consumers to local businesses. If you want to make sure your business is part of that launch, be there when they acquire that data.

    Apple clearly wants to call the shots when consumers use iPhones to conduct searches. To improve your brand visibility in an Apple world, understand first how your customers are using Apple Search to recover information about you. Focus on people first, apps second.

    Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

  • Apple's iOS 9: What Are The Implications For Search Marketers?

    Mobile apps have long posed an issue for search marketers. Because search engines have historically been unable to crawl and index in-app content, mobile apps have traditionally fallen outside of the realm of SEO professionals.

    All of that has changed recently with the introduction of app indexing, which enables app content to surface in mobile search results where relevant.

    While much of the conversation on app indexing has focused on Google — but with the iPhone accounting for almost half of all US smartphone users, it’s important to consider Apple, as well. Search marketers will need to begin optimizing their mobile app content for Apple Search indexation if they want to stay ahead of the competitors.

    The release of iOS 9 last month brought with it some changes that search marketers (among others) may want to take note of. In particular, iOS 9 introduces several APIs to help developers make their content available in the appropriate index on the device.

    In my article over on Marketing Land today, I talk with search expert Sri Nagubandi and UX professional Andrew Korf about the impact of iOS 9 on both the search and user experience — and how marketers can benefit from the new technologies and features introduced by iOS 9. Check out the full story here:

    What Apple’s iOS 9 Means To Marketers (Hint: Search And UX In Particular)

    Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

    With iOS 9, Apple's Siri & Spotlight Search Get Smarter

    The latest version of Apple’s iOS operating system is out today, iOS 9. It brings with it improvements to both Apple’s Siri personal assistant and its Spotlight search engine. Here’s a rundown of what’s new.

    Spotlight: Apple’s Stealth Search Engine

    Last year, Spotlight was improved to seek more than information just on your phone. That included gaining the name “Spotlight Search” when you pull down to conduct a search.

    Earlier this year, Jason Calacanis wrote a nice piece about how Spotlight is Apple’s search engine to destroy Google. I agree. I don’t know how much it’ll really destroy Google, but it has evolved nicely along the ways I predicted Apple would go — “containment” against Google slowly over time, rather than a “thermonuclear” breakup.

    As I wrote in 2012:

    What you do if you’re Apple is what you’re already doing. You keep growing Siri to work with other search partners, to keep Google contained, to win away areas of search where you feel confident Google won’t be missed.

    Eventually, maybe you launch an Apple search engine that’s a web-based version of Siri. Perhaps you even call it Siri and make it available through Siri.com. Over time, as Siri continues to grow with answers to popular searches from selected providers, you might eventually change the “backup” search engine that kicks in for when you don’t have a partner. Silently, Google gets replaced by Bing.

    That’s how you fight Google, if you’re Apple. No bombs get dropped; no consumer is even aware that you were fighting a war.

    That containment war has continued with Spotlight. Oddly, however, the Spotlight name has been dropped. Here’s how it looks on iOS 8 phone (on the left) versus iOS 9 (on the right and really, iOS 9.1, as I’m in a beta loop slightly ahead of the public):

    One of the things you’ll notice is that when you pull down to do a Spotlight search, you’ll get new Siri “app suggestions.” This is part of Siri’s new “proactive” features that I’ll return to below.

    Bing & Others In Spotlight

    Spotlight search taps into more sources than it did previously and has richer-looking results, along with some “card”-like responses for things like sports scores. For example, here’s a search for “angels” on my iOS 8 (on the left, as will be the case with all other examples) versus my iOS 9 phone (on the right):

    You’ll notice that with iOS 9, I get a special sports scores box for the Los Angeles Angels of Anaheim of Orange County of Southern California. Here’s another side-by-side:

    In that, you can see a new “Web Videos” area has appeared, pushing down the Twitter match and pushing matches from Bing even farther down. Here’s one more side-by-side:

    In the examples above, both top their lists with Wikipedia as a source. Oddly, the iOS 9 search doesn’t find matching content from Notes, as with my iOS 8 device, even though the notes are in sync on both. iOS 9 again gets a Web Videos area. Both again include Bing at the end.

    What you see in Spotlight will also depend on the apps you have installed, and in turn, how those apps make content more visible to Spotlight. For more about that (as well as with similar efforts by Google), see these excellent articles from Emily Grossman and Cindy Krum here on Search Engine Land:

    App Indexing & The New Frontier of SEO: Apple Search + iOS App IndexingApp Indexing & The New Frontier Of SEO: Google Search + Deep Linking

    Google Stays In Safari

    When all else fails, Spotlight turns to Bing, a change that was made last year and still continues. This is one way Google’s been cut from the Apple/iOS search ecosystem.

    Google remains in Safari, however. This is despite the fact that the long-term deal between Apple and Google is widely assumed to have expired months ago. Google said last May that the deal wasn’t quite up and that talks were continuing. My assumption is that either a deal was quietly signed or there was a temporary extension to get through the next six to twelve months.

    Like Bing in Spotlight, Google is the search engine of last resort. By default, Safari will pull from Spotlight to suggest things as you type. When you get results, they may come from other sources and include, in some cases, card-style information for weather and sports scores. Here’s a side-by-side showing how a weather card appears in iOS 9, while the iOS 8 suggestion is for The Weather Channel app:

    Siri Tries To Be Proactive

    You can also search using Siri, Apple’s now long-standing digital assistant. For those with the new iPhone 6s and iPhone 6s Plus coming out later this month, Apple’s even added the ability to say “Hey Siri” and activate it hands-free without being plugged in.

    Siri’s gained new abilities. Apple has a whole list of Siri tricks here. A new one is that you can ask it to find photos of yourself in a particular location, and it will check in Apple Photos for any matches. Another is that if you have a place selected in Maps, such as a grocery store, you can say something like “Remind me to buy pickles.” Then you’ll get a reminder when you arrive at the store, similar to functionality in Microsoft’s Cortana.

    I’ve tested both of those examples. The photo one worked great. The reminder linked to a location on a map worked fine once, but then I couldn’t get it to work for another location, no matter what I did.

    Siri is also trying to predict what you want before you even ask, in the way that Google Now does. This “proactive” feature has a long way to go to match Google Now, especially in that it does not tap into any of your search or browsing history and checks your email in a very limited fashion.

    Yes, Siri does look at your mail. But like Cortana, it only looks at mail on the device itself rather than in the cloud, and only if you use Apple’s Mail app. Anything it learns from your mail is stored in a local profile. Google looks at your Gmail in the cloud and stores what it finds in a cloud-based profile.

    Siri predictions are most noticeable if you swipe left to a new dedicated search page. There, you’ll find any contacts that Siri feels you commonly reach out to, frequently used apps, news headlines and “Nearby” information:

    The side-by-side above shows how this page changes both in the apps and headlines displayed, as well as for Nearby. Yesterday evening, Nearby was suggesting buttons for Dinners and Bars. Today, when I looked in the late morning, that switched to Lunch and Coffee.

    Tapping any of these buttons takes you into Apple Maps, where related information is shown. Below, see how lists of dinner and bar locations appeared near where I was:

    This is similar to the recently added Explore feature within Google Maps, a smart move by both companies.

    Siri will also remind you when to leave for flights or appointments, if you’ve added these appointments to your calendar or it has suggested adding them by checking your email. Personally, I’ve yet to see any of this work in real life, in the three weeks I’ve been using the iOS 9 beta. But we’ll see.

    Finally, Siri tries to be smart when you’re interacting with apps. Plug in your headphones, for example, and it will figure out the last thing you were doing, such as listening to an audiobook, and play that.

    The Privacy Tradeoff

    Overall, the additions are nice, and they continue Apple pushing Google to the edges of search wherever it can. But when it comes to predictive assistance, the new Siri is more limited compared to the robust Google Now, which at times gushes out useful stuff.

    For example, Siri will suggest news headlines, as best I can tell, largely based on what you’ve selected as general interests. Cortana works in a similar way. Google Now, however, taps into your search history and thus can surface interesting news stories and related material on very specific topics, all without requiring work on the part of the user.

    That a great feature, though it comes with a privacy tradeoff. You have to trust Google and trust how it keeps a profile about you in the cloud. For those who don’t want that, Siri has become a more attractive alternative. But that comes with its own trade-off, fewer predictions.