Closed Bug 1139691 Opened 10 years ago Closed 10 years ago

[breakdown] Create an interstitial page which will detect which mobile platform a user is on, and redirect to the appropriate store

Categories

(www.mozilla.org :: Bedrock, defect)

Product:
www.mozilla.org
Component:
Bedrock
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ckprice, Unassigned)

References

Details

(Whiteboard: engagement-fxGrowth-2015)

Attachments

(1 file)

snippet-sms.jpg
813.80 KB, image/jpeg
Details
We are designing snippets in bug 1136440 and bug 1137292 to highlight our mobile platforms. The application we're talking about here is - User loads a snippet which has an embedded phone number submission form[0]. - The user submits the phone number and a link is sent to their device. - The text contains a single link and a prompt to "Download Firefox for Mobile!". - The link will take users to a bridge page e.g. /firefox/mobile/bridge/ - Once the page loads, the user's platform will be detected. - If the user is on iOS, they will be sent to the App Store. - If the user is on Android, they will be sent to the Google Play Store. - If the user is neither, maybe we include a parameter which will tell the bridge how to redirect. - Ideally the bridge will have the ability to fire off GA events before redirecting the user. Less optimal options are: - add a radio button on the form to ask the user to select iOS/Android. - send the user two links in the text message; one for Android and one for iOS. [0] Android snippet with form; it would be updated to reflect iOS and Android - https://snippets.mozilla.com/show/5100/
See Also: → 1136439
See Also: → 1137290
No longer blocks: 1137292
4:33 PM <•cmore> ckprice: http://people.mozilla.org/~cmore/android-redirect.html 4:36 PM <•cmore> ckprice: try this URL from your iphone: people.mozilla.org/~cmore/apple-redirect.html 4:36 PM <•cmore> http://people.mozilla.org/~cmore/apple-redirect.html 4:37 PM nemo-yiannis → nemo-yiannis|out 4:38 PM <•cmore> ckprice: for apple it is itms:// and market:// for android both instead of https:// and they work with redirects 4:39 PM <ckprice> cmore: it works!! 4:40 PM <•cmore> ckprice: perfect. a UA sniffer that changes the redirect from either the app store or play store should work and is than accessing their stores via https 4:44 PM Osmose → Osmose|away 4:45 PM <•cmore> ckprice: this is also how we changed the download buttons to market:// for android users. We should do the same for itms:// when ios is out. https://bugzilla.mozilla.org/show_bug.cgi?id=934807
^ added a chat with cmore.
:pmac, :sgarrity - any thoughts on the above approach? Technical limitations, etc?
Flags: needinfo?(steven)
Flags: needinfo?(pmac)
Primary thought is no GA events. There won't be time, and if we wait for time it'll be a terrible UX. We can add UTM parameters to the Play Store url that should give us what we need (or that's what I've understood in the past). Not sure about App Store, and really not sure with either when doing the itms:// and market:// urls. More research is required. The way to do this if you want analytics is to have the page to which the SMS and email links be a simple mobile friendly "Get Firefox for Mobile" page with App and Play store links. I feel this is the superior approach, especially if the snippet just says "get mobile Firefox" since having both links on the page tells the user that we have both. Someone like me for example would like that since I have Android phone as well as an iPad. It would also be a future proof solution in case they launch a Windows Phone Firefox as well (or whatever else).
Flags: needinfo?(pmac)
I agree with pmac on having a simple, mobile/tablet optimized page that lists our mobile offerings. It's better for multi-platform folks, easier to share a URL with friends/family, easy to optimize/augment, easy to do GA, easy to download later (if the user is on a bad connection). This page could have intelligence that places the best link on top with a distinct UI.
The benefit of the bridge URL was that there would be one less click from the sms to the download. The single sms link would send the user directly to the store appropriate for them. If an interstitial page ends up being the best option here (vs. 2 separate links in the sms itself or the bridge option offered in this bug) would it make sense to just send them to /new, which will handle presenting the user with the appropriate download button? Is this page seen from the path of clicking on the sms link on mobile only or is it important to have a shareable page for any platform with all mobile download options? If it is only seen via sms users on mobile only, sending them to /new seems like a viable option.
I would strongly recommend against overloading /new for this. It's complex and heavy. The idea with the separate url and page is that it would be quick, light, and to-the-point. We've gotten ourselves in a lot of trouble with trying to be overly fancy and magic. Browser and platform detection is an inexact science, especially on android where it's very hard to predict which browser might display the page from the SMS link. I realize it's an extra click, but I think it's the least likely solution to be wrong and end up blocking some people from downloading Firefox. I also like Jon's suggestion of doing a bit of magic to move the iOS link to the top when we see we're on iOS (much easier to detect a definite iOS), but apart from that I really like simple and easy. If we desperately want to eliminate any link, we could do a between option where if we do a platform detection that we're pretty confident means the user is definitely on Android or Definitely on iOS then redirect them instantly, otherwise have the simple mobile download page that will load and give them the option.
We should also take in to account the large number of android devices that cannot use the google play store link, and provide a fallback link to a direct download of the apk. I think the discussion in bug https://bugzilla.mozilla.org/show_bug.cgi?id=686489 is relevant here.
See Also: → 686489
(In reply to Paul McLanahan [:pmac] from comment #7) > I would strongly recommend against overloading /new for this. Speaking to this: We're going to update the download button anyway for iOS (as we've done for Android or other platforms). Unless I'm missing something, this solution shouldn't cause any additional programming.
(In reply to Cory Price [:ckprice] from comment #9) > We're going to update the download button anyway for iOS (as we've done for > Android or other platforms). Unless I'm missing something, this solution > shouldn't cause any additional programming. We are. The issue is that the /new page is very complex and heavy. Since these people have already told us that they're on mobile (it's why they gave us their email or phone number) we don't need all that magic and can just offer them our mobile downloads. /new has a TON of graphics and JS and CSS and states and even the HTML is heavy because of all of the possibilities. We need that sometimes, but not in this case.
Do we need to do a little research about how this is being handled already out in the wild? Opera offers me links to both stores when I visit the mobile download page from my laptop: http://www.opera.com/mobile And Opera offers me an itunes button when I visit the same page from my iphone: http://cl.ly/image/0j1e0d2Q3h0D As Pmac and jpetto suggest, I wonder if offering the simplest solution that trusts the user to make the best choice is the way to go? You have the following choices:
(In reply to Josh Mize [:jgmize] from comment #8) > We should also take in to account the large number of android devices that > cannot use the google play store link, and provide a fallback link to a > direct download of the apk. I think the discussion in bug > https://bugzilla.mozilla.org/show_bug.cgi?id=686489 is relevant here. I think though that most other markets for Android support the market:// urls now. I know F-Droid does [0]. When I click an install link I get the choice of which market to use based on the Android Intents framework. Maybe not everyone does and a direct download would be a nice option as well and I agree that we should have a direct download link from this page for Android. My only point is that we may get more mileage out of the market:// link than was originally suggested in that bug. [0] https://f-droid.org/repository/browse/?fdfilter=Firefox&fdid=org.mozilla.firefox
(In reply to Paul McLanahan [:pmac] from comment #10) > (In reply to Cory Price [:ckprice] from comment #9) > > We're going to update the download button anyway for iOS (as we've done for > > Android or other platforms). Unless I'm missing something, this solution > > shouldn't cause any additional programming. > > We are. The issue is that the /new page is very complex and heavy. Since > these people have already told us that they're on mobile (it's why they gave > us their email or phone number) we don't need all that magic and can just > offer them our mobile downloads. /new has a TON of graphics and JS and CSS > and states and even the HTML is heavy because of all of the possibilities. > We need that sometimes, but not in this case. Pmac, when you say /new is complex and heavy are you worried about it loading slower for a mobile user? They shouldn't need to know about the magic (that's why it's magic :). All they should know is that we gave them a download button that was right for their device. If this page is too heavy and as a result makes the experience poor for mobile then we should take the appropriate steps to solve this larger issue rather than avoid the page. Perhaps creating a separate page with both buttons on it is better for this purpose, but we should make this decision based on the goals of the project. If it's not important for an iOS user to know about the Android download (and vice versa), then offering an experience like Jen shared above http://cl.ly/image/0j1e0d2Q3h0D seems like the way to go. Our /new page should already be able to handle this. If we create a /mobile page for the purpose of downloading a mobile Firefox product, it sounds like we'd be shifting the strategy of our /new download page to be desktop only.
(In reply to Holly Habstritt Gaal [:Habber] from comment #13) > Pmac, when you say /new is complex and heavy are you worried about it > loading slower for a mobile user? They shouldn't need to know about the > magic (that's why it's magic :). All they should know is that we gave them a > download button that was right for their device. If this page is too heavy > and as a result makes the experience poor for mobile then we should take the > appropriate steps to solve this larger issue rather than avoid the page. What I mean by "heavy" is physical size. It will be slow to load on mobile because there is so much extra stuff downloaded by that page. It's a large bit of HTML because of all the possibilities, there's a lot of JS for detection and fancy animations to scene2 and all of that, there's a lot of CSS to support it all, and it's quite graphically heavy as well. We could improve it some I guess, but this is a special case where we know the people only want the mobile links since that's why they got this link in the first place. But you're right that we do need to improve the /new page for mobile for all of the reasons above, as well as because it's nearly impossible to detect Android reliably. Also as Josh pointed out, all we do is send Android users to the Play store, but many Android users don't get their software from Google. We want users running forks of Android to be able to get Firefox as well, but we're very unlikely to detect them as Android, so we're probably showing them a desktop download or even an "Unsupported" message. I guess what this bug is solidifying for me is that the /new page is too many things and too bloated right now. It's too magical and that is making us miss potential users. Browser and platform detection just isn't reliable enough, and our heavy use of it is surely making us misdirect people. I like the simple standalone page for this mostly because these users are unique. We don't need to guess what their platform is. They've told us they're on mobile. Let's just give them a simple page that gives them our mobile options and nothing else.
(In reply to Paul McLanahan [:pmac] from comment #14) > (In reply to Holly Habstritt Gaal [:Habber] from comment #13) > > Pmac, when you say /new is complex and heavy are you worried about it > > loading slower for a mobile user? They shouldn't need to know about the > > magic (that's why it's magic :). All they should know is that we gave them a > > download button that was right for their device. If this page is too heavy > > and as a result makes the experience poor for mobile then we should take the > > appropriate steps to solve this larger issue rather than avoid the page. > > What I mean by "heavy" is physical size. It will be slow to load on mobile > because there is so much extra stuff downloaded by that page. It's a large > bit of HTML because of all the possibilities, there's a lot of JS for > detection and fancy animations to scene2 and all of that, there's a lot of > CSS to support it all, and it's quite graphically heavy as well. We could > improve it some I guess, but this is a special case where we know the people > only want the mobile links since that's why they got this link in the first > place. > > But you're right that we do need to improve the /new page for mobile for all > of the reasons above, as well as because it's nearly impossible to detect > Android reliably. Also as Josh pointed out, all we do is send Android users > to the Play store, but many Android users don't get their software from > Google. We want users running forks of Android to be able to get Firefox as > well, but we're very unlikely to detect them as Android, so we're probably > showing them a desktop download or even an "Unsupported" message. > > I guess what this bug is solidifying for me is that the /new page is too > many things and too bloated right now. It's too magical and that is making > us miss potential users. Browser and platform detection just isn't reliable > enough, and our heavy use of it is surely making us misdirect people. > > I like the simple standalone page for this mostly because these users are > unique. We don't need to guess what their platform is. They've told us > they're on mobile. Let's just give them a simple page that gives them our > mobile options and nothing else. Sounds like optimizing /new is not something that is in scope for this project. I'd argue that we wouldn't want to create a dedicated page for all things mobile without some more thought about our mozilla.org download strategy since this would turn /new into a desktop-only download page and/or create redundant places to download for iOS and Android. Without using the bridge solution presented in this bug or a web page that detects the user's OS, the least amount of dev work with the shortest flow for the user would be to present 2 links in the SMS. One to iTunes and one to the Play Store. Fabio has an example of other apps doing this exact thing. I believe we can still track clicks from SMS to each play store. Curious to hear Fabio's thoughts on going back to this solution, given the discussion in this bug.
(In reply to Holly Habstritt Gaal [:Habber] from comment #15) > Sounds like optimizing /new is not something that is in scope for this > project. I'd argue that we wouldn't want to create a dedicated page for all > things mobile without some more thought about our mozilla.org download > strategy since this would turn /new into a desktop-only download page and/or > create redundant places to download for iOS and Android. I think we're still misunderstanding each other. This proposed simple page is _only_ for people who get these SMS or email messages. Nothing on the site would link to them. The /new page wouldn't do any fewer things. It would definitely not be for "all things mobile", it would only be for this SMS/email campaign. It would fill the same spot as the bridge, it would just show a couple of simple buttons instead of automatically sending them somewhere they may indeed not wish to go. > Without using the bridge solution presented in this bug or a web page that > detects the user's OS, the least amount of dev work with the shortest flow > for the user would be to present 2 links in the SMS. One to iTunes and one > to the Play Store. Fabio has an example of other apps doing this exact > thing. I believe we can still track clicks from SMS to each play store. > Curious to hear Fabio's thoughts on going back to this solution, given the > discussion in this bug. That ignores the fact that many Android users don't use Google Play as we've discussed, but maybe we're fine with that for this campaign. I don't like ignoring users, but this is a specific thing and only for people willing to give us their phone number, so maybe it's a very small number. I'm not sure.
(In reply to Paul McLanahan [:pmac] from comment #16) > (In reply to Holly Habstritt Gaal [:Habber] from comment #15) > > Sounds like optimizing /new is not something that is in scope for this > > project. I'd argue that we wouldn't want to create a dedicated page for all > > things mobile without some more thought about our mozilla.org download > > strategy since this would turn /new into a desktop-only download page and/or > > create redundant places to download for iOS and Android. > > I think we're still misunderstanding each other. This proposed simple page > is _only_ for people who get these SMS or email messages. Nothing on the > site would link to them. The /new page wouldn't do any fewer things. It > would definitely not be for "all things mobile", it would only be for this > SMS/email campaign. It would fill the same spot as the bridge, it would just > show a couple of simple buttons instead of automatically sending them > somewhere they may indeed not wish to go. Understood that this would fill the spot in the bridge and only be shown to users accessing it from sms. > > > Without using the bridge solution presented in this bug or a web page that > > detects the user's OS, the least amount of dev work with the shortest flow > > for the user would be to present 2 links in the SMS. One to iTunes and one > > to the Play Store. Fabio has an example of other apps doing this exact > > thing. I believe we can still track clicks from SMS to each play store. > > Curious to hear Fabio's thoughts on going back to this solution, given the > > discussion in this bug. > > That ignores the fact that many Android users don't use Google Play as we've > discussed, but maybe we're fine with that for this campaign. I don't like > ignoring users, but this is a specific thing and only for people willing to > give us their phone number, so maybe it's a very small number. I'm not sure. As an Android user, I'm really interested in this statement "That ignores the fact that many Android users don't use Google Play as we've discussed". Do you have a link to some stats? In order to decide if we're fine with leaving some users out, we should have an idea of just how many would not like to download via the play store.
Attached image snippet-sms.jpg —
The point of this snippet is to get users who don't need a lot of convincing to download Firefox on their mobile phone (ignoring the users that can SMS to tablets). These users require no information, just need the process to be simplified for them. We will be explicit that this is accomplished via Google Play and App Store only.(see rough mock up). It sounds like having two links available in the SMS is not only the easiest approach, but also the safest in terms of making sure users don't have redirect issues. I'm happy to go with this approach.
Thoughts: 1. The users who are getting their apps outside the store are probably not the target audience for SMS/email activation. 2. The Firefox mobile ecosystem is something that is far from figured out, and these two products are very different at this point. I don't know if we should be making any high impact decisions on how they are presented. 3. At this stage - and for this purpose - I think we should try to implement as low of a touch program as possible. 4. The download strategy is a much larger (and very valid) topic, and probably out of scope for this conversation. +1 to Fabio's approach. Thanks all for the input.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(steven)
Resolution: --- → FIXED
+1 to option 2 in Fabio's mockup, at least for now. I'd love to test a couple of options at a later time to see if a single link in the sms performs better than 2 links. One comment unrelated to the flows. (though Fabio probably intended to add this and other details later) Even though only users located in the US will see this, it's a good idea to mention that we accept US phone #s only and give a little guidance for what the syntax is that we accept.
(In reply to Holly Habstritt Gaal [:Habber] from comment #17) > As an Android user, I'm really interested in this statement "That ignores > the fact that many Android users don't use Google Play as we've discussed". > Do you have a link to some stats? In order to decide if we're fine with > leaving some users out, we should have an idea of just how many would not > like to download via the play store. According to https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android-aosp-gro "...forked Android or AOSP smartphones grew 20% sequentially from 1Q 2014 to 2Q 2014 (total market growth was 3% sequentially) and also accounted for 20% of the smartphone market." My understanding is that only devices that have been approved by Google can install and use the Google Play Services.
(In reply to Josh Mize [:jgmize] from comment #21) > (In reply to Holly Habstritt Gaal [:Habber] from comment #17) > > As an Android user, I'm really interested in this statement "That ignores > > the fact that many Android users don't use Google Play as we've discussed". > > Do you have a link to some stats? In order to decide if we're fine with > > leaving some users out, we should have an idea of just how many would not > > like to download via the play store. > > According to > https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android- > aosp-gro > "...forked Android or AOSP smartphones grew 20% sequentially from 1Q 2014 to > 2Q 2014 (total market growth was 3% sequentially) and also accounted for 20% > of the smartphone market." > > My understanding is that only devices that have been approved by Google can > install and use the Google Play Services. Thanks! It says "AOSP’s growth is driven by the development of Chinese and Indian handset manufacturers, not only in their domestic markets, but increasingly throughout Asia and beyond" I'd love to find more specific location data, but it doesn't seem like we should ignore this, even if we don't address it for this campaign specifically. Regardless of what location this is happening most, have you seen how other apps are solving for this? A separate link below the Google play button?
(In reply to Josh Mize [:jgmize] from comment #21) > (In reply to Holly Habstritt Gaal [:Habber] from comment #17) > > As an Android user, I'm really interested in this statement "That ignores > > the fact that many Android users don't use Google Play as we've discussed". > > Do you have a link to some stats? In order to decide if we're fine with > > leaving some users out, we should have an idea of just how many would not > > like to download via the play store. > > According to > https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android- > aosp-gro > "...forked Android or AOSP smartphones grew 20% sequentially from 1Q 2014 to > 2Q 2014 (total market growth was 3% sequentially) and also accounted for 20% > of the smartphone market." > > My understanding is that only devices that have been approved by Google can > install and use the Google Play Services. Josh: Do you know any ways of detecting these users from other android users via the user agent string or other methods?
(In reply to Chris More [:cmore] from comment #23) > (In reply to Josh Mize [:jgmize] from comment #21) > > (In reply to Holly Habstritt Gaal [:Habber] from comment #17) > > > As an Android user, I'm really interested in this statement "That ignores > > > the fact that many Android users don't use Google Play as we've discussed". > > > Do you have a link to some stats? In order to decide if we're fine with > > > leaving some users out, we should have an idea of just how many would not > > > like to download via the play store. > > > > According to > > https://www.abiresearch.com/press/2q-2014-smartphone-results-forked-android- > > aosp-gro > > "...forked Android or AOSP smartphones grew 20% sequentially from 1Q 2014 to > > 2Q 2014 (total market growth was 3% sequentially) and also accounted for 20% > > of the smartphone market." > > > > My understanding is that only devices that have been approved by Google can > > install and use the Google Play Services. > > Josh: Do you know any ways of detecting these users from other android users > via the user agent string or other methods? While we could search for specific forks like CyanogenMod, which do seem include their name in UA strings (http://www.webapps-online.com/online-tools/user-agent-strings/dv/plugin117559/cyanogenmod), I don't think we can possibly enumerate all the different forks-- indeed, I would be surprised if most of them bothered to modify the UA string at all.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: