Closed Bug 868169 Opened 11 years ago Closed 11 years ago

Redirect former interstitial android download pages to Play Store with UTM vars

Categories

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

Product:
www.mozilla.org
Component:
Bedrock
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: cmore, Assigned: sgarrity)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kb=955417] r=123194)

Attachments

(2 files)

pull request
(deleted), text/x-github-pull-request
Details
Patch to remove android-download HTML files from SVN
(deleted), patch
pmac
: review+
Details | Diff | Splinter Review 
This page is currently in php:

https://www.mozilla.org/mobile/android-download.html
https://www.mozilla.org/mobile/android-download-beta.html

We should implement the same functionality in Bedrock. Code is here:

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/mobile/android-download.html?view=markup

http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/en-US/mobile/android-download-beta.html?view=markup

Once they live at URLs like:


https://www.mozilla.org/mobile/android-download/ we should put in redirects from the old to the new.

Note: We should always be passing the query string parameters from the mozilla.org page to the Google Play store link including when we redirect from php to bedrock.
Whiteboard: [kb=955417]
Priority: -- → P3
Blocks: mozorg-redirects
Seems that these should now live at mozilla.org/firefox/mobile/android-download (or just /firefox/android-download) since the /mobile/ page isn't specifically about Android (or Firefox).
Assignee: nobody → steven
OS: Mac OS X → All
Hardware: x86 → All
These interstitial pages exist only for analytics reasons, right? Otherwise we'd redirect directly?
(In reply to Steven Garrity [:sgarrity] from comment #2)
> These interstitial pages exist only for analytics reasons, right? Otherwise
> we'd redirect directly?

Yes
Correct. This is just for analytics since we don't get a ton off of Google Play store. The current URL is still being used so when we go live with a bedrock version, we will have to redirect it. Also, the redirect will need to be delayed long enough for the GA call to successfully send to Google's servers. We did a regular http equiv refresh after 1 second and that seemed to be fine.
(In reply to Steven Garrity [:sgarrity] from comment #5)
> Pull request here: https://github.com/mozilla/bedrock/pull/1097

Will this code take the UTM parameters described here and pass them along to Google Play? https://bugzilla.mozilla.org/show_bug.cgi?id=845603#c29
(In reply to Chris More [:cmore] from comment #6)
> (In reply to Steven Garrity [:sgarrity] from comment #5)
> > Pull request here: https://github.com/mozilla/bedrock/pull/1097
> 
> Will this code take the UTM parameters described here and pass them along to
> Google Play? https://bugzilla.mozilla.org/show_bug.cgi?id=845603#c29

Looks like it won't. You'll need to do the redirect with JS to construct the new URL with the query params appended.
On a side note: I thought at one time we decided there was a way to send a ping to GA from the server. Would that be good enough in this instance, and just have our bedrock urls be a view that will do the ping then redirect to the play store w/o ever needing to serve any HTML?
After following a bit of a rabbit-hole of bugs, it seems that this interstitial page is used mostly (only?) by about:home snippets (see Bug 845603 for more detail). Any Android download links on mozilla.org point directly to the Play store.

The last comment from cmore on that bug [1] says:

> I am going to close this bug. We should either just re-make
> this page in bedrock or just point links directly to the play
> store. Will reach out to Winston and Sam about what they want
> to do. Most links to this page are coming from snippets.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=845603#c35

Winston, can you let us know if this interstitial page is still required? 

If it is still required, sancus wrote a patch to pass the query string to the play store for the PHP site (https://bugzilla.mozilla.org/attachment.cgi?id=751946&action=edit). We could adapt that to bedrock, but no one is enthusiastic about that method.
Gareth: Can you comment here on what you learned on GA + Google Play store analytics? This interstitial page was created because we have very little analytics on the play.google.com.
Flags: needinfo?(garethcull.bugs)
We are currently on the waiting list for GA + Google Play Store Integration. Once this is set up, Google Analytics will be able to report on Google Play views and installs by campaign. This integration will remove the need for us to capture traffic data to the Play Store via a page such as https://www.mozilla.org/mobile/android-download.html.
Flags: needinfo?(garethcull.bugs)
I think we should just close this bug and WONTFIX it and redirect the old php pages:

https://www.mozilla.org/mobile/android-download.html
https://www.mozilla.org/mobile/android-download-beta.html

To our respective play store pages and call it a day. The chances of everyone pointing Android campaigns to the right place on mozilla.org and then doing something with the data seems low. We are getting some very basic data out of Google Play now and it is more likely people will just point right to those pages. 

If we agree, we can remove these pages from SVN and redirect.

Thoughts?
(In reply to Chris More [:cmore] from comment #12)
> I think we should just close this bug and WONTFIX it and redirect the old
> php pages:
> 
> https://www.mozilla.org/mobile/android-download.html
> https://www.mozilla.org/mobile/android-download-beta.html
> 
> To our respective play store pages and call it a day. The chances of
> everyone pointing Android campaigns to the right place on mozilla.org and
> then doing something with the data seems low. We are getting some very basic
> data out of Google Play now and it is more likely people will just point
> right to those pages. 
> 
> If we agree, we can remove these pages from SVN and redirect.
> 
> Thoughts?

I checked and android-download.html is being hit about 18-20k times a day. Hmmm, that's quite a bit.
The issue here is that if we use this page and don't pass on UTM parameters to the play store, we don't know the install rate success of campaigns. If we point Play Store campaigns directly to play.google.com with UTM parameters, we get only basic data, but we get install data and that's the ultimate metric. It is not ideal either way and I'm leaning still pointing all links to the play store and not use the interstitial pages at all.

Winston/Jean/Jess: thoughts on the past few comments?

Steven: Is your thoughts just to keep this page since the dev work is pretty much done regardless of how it is used?
Hey Chris,
I think Install data is the ultimate metric but it would be nice to be able to measure conversions from clicks to install. It sounds like all of this would be a non-issue once we get Google Play + GA integration right? 

Gareth, do you know when that will be? Can we get them to give us a sense of timing and rush that a bit?
(In reply to Jesse Montano from comment #15)
> Hey Chris,
> I think Install data is the ultimate metric but it would be nice to be able
> to measure conversions from clicks to install. It sounds like all of this
> would be a non-issue once we get Google Play + GA integration right? 
> 
> Gareth, do you know when that will be? Can we get them to give us a sense of
> timing and rush that a bit?

We have Google Play + GA integration now and it is nothing more than I showed before. It is just basic conversion rate and there is no timeframe for anything else. The info here is also a bit confusing and doesn't make me want to trust the integration. They said more is coming in the future, but this is all we get for now.

https://support.google.com/analytics/answer/2848113?hl=en&utm_id=ad

If we use this interstitial page, we don't have any install data. If we use the Play Store directly, we don't have any data beside installs.
We can wait to see what the others say, but I think the Install data is the most important thing. So I would forget about the interstitial.
Hi Chris and Jesse,

Forgive me but I'm not as familiar with "interstitial" and such terms so I am not following you guys as well but I do know that for the about: home snippets we are sending users to two places. Currently we are directly sending them to the Google Play store which we can track the clicks in GA but as far as installs, I don't do anything with that data (I wouldn't know how to access it). 

The second place that we did send users to were the SMS text page: http://www.mozilla.org/en-US/firefox/sms/
in which we are using Exact Target at the back end to gather data (but I don't think it gives us install numbers) however there is an error right now in using this page so we stopped directing users to this page (temporarily until we get it fixed). 

But Jesse is right in that the install data is very important, however it seems that the interstitial page was created for a reason so I will follow up with Winston on that.
If we use a bit.ly link to track clicks does that screw up the install data on Google Play reporting?
(In reply to Winston Bowden from comment #19)
> If we use a bit.ly link to track clicks does that screw up the install data
> on Google Play reporting?

It shouldn't as long as the bit.ly links point to play.google.com. Maybe that is the best solution here. Skip the mozilla.org redirect page and just use bit.ly. I would support that.
(In reply to jcollings from comment #18)
> Hi Chris and Jesse,
> 
> Forgive me but I'm not as familiar with "interstitial" and such terms so I
> am not following you guys as well but I do know that for the about: home
> snippets we are sending users to two places. Currently we are directly
> sending them to the Google Play store which we can track the clicks in GA
> but as far as installs, I don't do anything with that data (I wouldn't know
> how to access it). 
> 
> The second place that we did send users to were the SMS text page:
> http://www.mozilla.org/en-US/firefox/sms/
> in which we are using Exact Target at the back end to gather data (but I
> don't think it gives us install numbers) however there is an error right now
> in using this page so we stopped directing users to this page (temporarily
> until we get it fixed). 
> 
> But Jesse is right in that the install data is very important, however it
> seems that the interstitial page was created for a reason so I will follow
> up with Winston on that.

What we mean by interstitial is that a link on the web points to a redirect page on mozilla.org and then immediately redirects to play.google.com. We have Google Analytics on the interstitial/redirect page, it gathers some anonymous info, and then sends the user to the play store. It is just a way to get some basic data about a campaign since there isn't much GA on the play store. Bit.ly would accomplish a similar thing.
Thanks CMore for the explanation and walking me through this! Yes, bit.ly will work for us in terms of tracking clicks. We can get rid of the interstitial page, however, let me test/run this for a few days and I will get back to you if everything is good to go.
Let me know if this is the route we decide to go (getting rid of the interstitial page).  Right now I use bit.ly + GA on the interstitial page, and I get my weekly click to download stats from GA, not bit.ly


I use: 

http://mzl.la/10vIySv

http://www.mozilla.org/mobile/android-download.html?utm_source=newsletter&utm_medium=email&utm_campaign=FFx%26You



Cmore/Jesse - what does the link URL need to be to get the right install data?  And will there be a way that we can add/substract some characters to the end of that URL so that we can differentiate the different bit.ly links for email, social and snippet?
(In reply to Jessilyn Davis from comment #23)
> Let me know if this is the route we decide to go (getting rid of the
> interstitial page).  Right now I use bit.ly + GA on the interstitial page,
> and I get my weekly click to download stats from GA, not bit.ly
> 
> 
> I use: 
> 
> http://mzl.la/10vIySv
> 
> http://www.mozilla.org/mobile/android-download.
> html?utm_source=newsletter&utm_medium=email&utm_campaign=FFx%26You
> 
> 
> 
> Cmore/Jesse - what does the link URL need to be to get the right install
> data?  And will there be a way that we can add/substract some characters to
> the end of that URL so that we can differentiate the different bit.ly links
> for email, social and snippet?

That's probably overkill since it is two redirects. mzl.la redirects to www.mozilla.org and mozilla.org redirects to the play store. Each gives a bit more data, but probably bit.ly > play.google.com is good enough for what most people want.

I would suggest creating mzl.la links that go from:

http://bit.ly/18VrGY1

to:

https://play.google.com/store/apps/details?id=org.mozilla.firefox&utm_source=newsletter&utm_medium=email&utm_campaign=FFx%26You

bit.ly will give you clicks and demographics and the GA on the play store will give us install rates. The interstitial page only gives us a bit more demographics, but I don't think many people even use it.
Hey y'all-

Can I close this bug?  And file a separate bug to delete the old php pages referenced in comment 0?

Thx,
Jen
Flags: needinfo?(chrismore.bugzilla)
Yes, you can close this one or just rename this bug. The separate bug for the old php pages should redirect these pages:

https://www.mozilla.org/mobile/android-download.html
https://www.mozilla.org/mobile/android-download-beta.html

to the appropriate URLs to the play store app *and* also pass along UTM variables to the play store.

Basically, we just want to reconstruct these redirect pages in Bedrock's redirects since these pages are really no more than just html redirects.
Flags: needinfo?(chrismore.bugzilla)
Thanks, Chris.

Who should I ping to get "the appropriate URLs to the play store app *and* also pass along UTM variables to the play store"?
This is the Play Store link:
https://play.google.com/store/apps/details?id=org.mozilla.firefox

Not sure about the UTM variables that go with that.
(In reply to Jennifer Bertsch [:jbertsch] from comment #28)
> Thanks, Chris.
> 
> Who should I ping to get "the appropriate URLs to the play store app *and*
> also pass along UTM variables to the play store"?

They are right in the php files since the php files are just html redirects

https://play.google.com/store/apps/details?id=org.mozilla.firefox

https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta

The play store will accept all of the normal UTM variables. Just need to make sure appended UTM variable start with a & symbol since there is already a ? query parameter in there.

i.e.

https://play.google.com/store/apps/details?id=org.mozilla.firefox&utm_source=snippet&utm_medium=banner&utm_campaign=test
What UTM variables are we talking about here?

It seems to me that current Android download buttons already point directly to the play.google.com URL. 

I presume we're just redirecting the /mobile/android-download.html and /mobile/android-download-beta.html for any legacy links that might remain?
(In reply to Steven Garrity [:sgarrity] from comment #31)
> What UTM variables are we talking about here?
> 
> It seems to me that current Android download buttons already point directly
> to the play.google.com URL. 
> 
> I presume we're just redirecting the /mobile/android-download.html and
> /mobile/android-download-beta.html for any legacy links that might remain?

Yes, it will be a redirect, but also passing along utm_(source|medium|campaign) and their associated values to play.google.com. We have GA on the play store and it can see those campaign tags.
(In reply to Chris More [:cmore] from comment #32)
> Yes, it will be a redirect, but also passing along
> utm_(source|medium|campaign) and their associated values to play.google.com.
> We have GA on the play store and it can see those campaign tags.

Got it. I'll have to pass this on to someone with more Apache-fu than myself.

To summarize, for the benefit of the next person to look at this, the ask is to:

Redirect:
https://www.mozilla.org/mobile/android-download.html
to https://play.google.com/store/apps/details?id=org.mozilla.firefox

and 
https://www.mozilla.org/mobile/android-download-beta.html
to https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta

and make sure any utm_(source|medium|campaign) and their associated values are passed on to the play.google.com links.

Once this is in place, we'll remove the .html pages from SVN.
Assignee: steven → nobody
Summary: Migrate Firefox on Android interstitial page to [Bedrock] → Redirect former interstitial android download pages to Play Store with UTM vars
Assignee: nobody → pmac
Status: NEW → ASSIGNED
Attached file pull request (deleted) — 

    
    

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

https://github.com/mozilla/bedrock/commit/4c22c820ba4109e7bbb48b292e566490d0aa4f3a
Bug 868169: Redirect android download interstitial pages to play store

The [QSA] flag on the RewriteRule causes apache to keep and
merge the Query String from the original URL with the new one.

https://github.com/mozilla/bedrock/commit/aa764e109d3fee93fb683bab385f0fb1881e23b0
Merge pull request #1487 from pmclanahan/redirect-android-download-868169

Bug 868169: Redirect android download interstitial pages to play store

    
    

    
  
fixed on stage
curl https://www.allizom.org/mobile/android-download.html -i | grep Location:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   273  100   273    0     0    504      0 --:--:-- --:--:-- --:--:--   505
Location: https://play.google.com/store/apps/details?id=org.mozilla.firefox


curl https://www.allizom.org/mobile/android-download.html\?stuff\=hello -i | grep Location:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   289  100   289    0     0   1974      0 --:--:-- --:--:-- --:--:--  1979
Location: https://play.google.com/store/apps/details?id=org.mozilla.firefox&stuff=hello

    
    

    
  


  
Here's a patch to remove the old files from SVN.
Assignee: pmac → steven
Status: RESOLVED → REOPENED

        Attachment #8343706 -
        Flags: review?(pmac)
Resolution: FIXED → ---

    
    

    
  
Comment on attachment 8343706 [details] [diff] [review]
Patch to remove android-download HTML files from SVN

Review of attachment 8343706 [details] [diff] [review]:
-----------------------------------------------------------------

Huge success!

        Attachment #8343706 -
        Flags: review?(pmac) → review+

    
    

    
  
Patch applied in trunk in r123194
Whiteboard: [kb=955417] → [kb=955417] r=123194

    
    

    
  
Merged into tags/stage in r123195 and tags/production in r123196.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: