1195369 - Redirect iOS /new visitors to the product page

Status: RESOLVED FIXED

(www.mozilla.org :: Pages & Content, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

This bug is opened to create an Optimizely test to redirect iOS /new visitors to the iOS product page. This will allow us to avoid placing geolocation on the /new page.

The product page is being developed in bug 1136538.

Comment 1

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

NI cmore, adavis

Can I ask one of you to get this test up and going on Sept 1 while I'm out of the office?

We want all iOS visitors to /new to be redirected to the iOS product page.

I created a placeholder in Optimizely (https://app.optimizely.com/projects/246059135/experiments/3323351443).

Here is the WIP product page: https://www-demo1.allizom.org/en-US/firefox/ios/

Thanks!

Comment 2

[Alex Davis [:adavis]]

(In reply to Cory Price [:ckprice] from comment #0)
> This bug is opened to create an Optimizely test to redirect iOS /new
> visitors to the iOS product page. This will allow us to avoid placing
> geolocation on the /new page.
> 
> The product page is being developed in bug 1136538.

Is Sept 1st a firm date or is it more the day our app hits the app store?

Comment 3

[Chris More [:cmore]]

I assume the product page will be located at /firefox/iOS/ and that it will go live on Sept 1st as a pre-launch promo. I'll get the experiment setup and get it code reviewed.

Comment 4

[Mike Alexis [:malexis]]

(In reply to Chris More [:cmore] from comment #3)
> I assume the product page will be located at /firefox/iOS/ and that it will
> go live on Sept 1st as a pre-launch promo. I'll get the experiment setup and
> get it code reviewed.

That is correct, Sept 1 is our go live date and /firefox/iOS/ is the URL, but we will need to coordinate with the product team to confirm that the app is available in NZ before we push the page live.

Comment 5

[Josh Mize [:jgmize]]

I'm not sure what benefit Optimizely provides for this use case. For a global redirect that applies to all iOS users, wouldn't it make more sense to write it directly in our existing js? I think that would be more reliable in production, easier to review in context, and easier to test in our dev, stage, and demo environments.

Comment 6

[Jennifer Bertsch [:jbertsch]]

(In reply to Josh Mize [:jgmize] from comment #5)
> I'm not sure what benefit Optimizely provides for this use case. For a
> global redirect that applies to all iOS users, wouldn't it make more sense
> to write it directly in our existing js? I think that would be more reliable
> in production, easier to review in context, and easier to test in our dev,
> stage, and demo environments.

+1 Josh.  I'd prefer to go in this direction and remove the risk of tying this to Optimizely.

FYI Cmore.  Please ping me if you want to discuss.

Comment 7

[Chris More [:cmore]]

The intention of this redirect in Optimizely was only during the select country roll outs because geo redirects on /firefox/new/ was adding more complexity and geo is built-in to optimizely. As soon as iOS is rolled out globally, the redirect in Optimizely would be disabled and it could be just added to the existing page's js. If we would want to reconsider doing the geo redirect without optimizely and use geodude, I'd be for that too.

The optimizely test here wasn't meant to be a permanent solution and shouldn't be.

Comment 8

[Jennifer Bertsch [:jbertsch]]

(In reply to Chris More [:cmore] from comment #7)
> The intention of this redirect in Optimizely was only during the select
> country roll outs because geo redirects on /firefox/new/ was adding more
> complexity and geo is built-in to optimizely. As soon as iOS is rolled out
> globally, the redirect in Optimizely would be disabled and it could be just
> added to the existing page's js. If we would want to reconsider doing the
> geo redirect without optimizely and use geodude, I'd be for that too.
> 
> The optimizely test here wasn't meant to be a permanent solution and
> shouldn't be.

Hey Cmore-

In comment #1 above, Cory says we are redirecting all ios users from /new to the /firefox/iOS product page (and then using geolocation on the product page to serve the correct content by country), so I'm in favor of using what Josh is proposing.

Thx,
Jen

Comment 9

[Chris More [:cmore]]

+1 then as there is no point to having optimizely do the redirect if you are using geo location on the product page. We can keep this bug open, but let's do it with a JS redirect and *not* optimizely. Optimizely only makes sense if it was temp and if there was some feature we wanted to use that we didn't want to built into the page.

Comment 10

[Josh Mize [:jgmize]]

:cmore great, thanks. I think now we just need to know what UTM params we should add to the redirect target url, assuming we want them.

Comment 11

[Chris More [:cmore]]

(In reply to Josh Mize [:jgmize] from comment #10)
> :cmore great, thanks. I think now we just need to know what UTM params we
> should add to the redirect target url, assuming we want them.

Good point, because if we don't, they will look like direct traffic with a 301 redirect. 

Here's a few options and we'll get Gareth to weigh in:

https://www.mozilla.org/firefox/ios/?utm_source=www.mozilla.org&utm_medium=referral&utm_campaign=ios-redirect

https://www.mozilla.org/firefox/ios/?utm_source=firefox-new&utm_medium=referral&utm_campaign=ios-redirect

Gareth? ^^

Comment 12

[Gareth Cull [:garethc]]

We get a decent amount of traffic from ios and it would be great if we could somehow preserve the referrer in this case, else we'll be attributing everything to a re-direct or direct traffic. We'll no longer be able to attribute traffic coming from organic or referral. I'm getting some feedback from Google on this and will update the bug with some additional details.

Comment 13

[Gareth Cull [:garethc]]

Here's Google's response:

"The best way to preserve the original traffic source information is to implement a server side redirect from the download page to the new page. GA automatically handles 301/302 server side redirects and keeps the original traffic source.

A server side redirect is a method of URL redirection using an HTTP status code (e.g., 301 Moved Permanently, 303 See Other and 307 Temporary Redirect) issued by a web server in response to a request for a particular URL. The result is to redirect user's web browser to another web page with a different URL. Here is an HelpCenter article which will explain you in details for your reference: https://support.google.com/analytics/answer/3198398"

Can we do this redirect server side jpetto?

Comment 14

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/a966e6ed738fde5379d48cc09c9634e86a67b9bc
[fix bug 1195369] Redirect iOS users on /firefox/new/ to
iOS product page.

https://github.com/mozilla/bedrock/commit/c3a876a5c31b4e5a369c7f9f40e1bedcfbc17589
Merge pull request #3257 from mozilla/bug-1195369-redirect-ios-visitors-on-firefox-new

[fix bug 1195369] Redirect iOS users on /firefox/new/ to iOS product page.

Comment 15

[Jonathan Petto [:jpetto]]

:pmac - The waffle switch used for this redirect has been removed from the code base, so we can remove the switch from the servers. The switch was named 'firefox-new-ios-redirect'.

Comment 16

[Paul [:pmac] McLanahan]

Done.