Closed
Bug 529862
Opened 15 years ago
Closed 15 years ago
Ensure update ping for lightweight themes support metrics
Categories
(Websites Graveyard :: getpersonas.com, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
2.0
People
(Reporter: pedro.alves, Assigned: kkovash)
References
Details
We need to make sure that we use an update ping that allows metrics to be gathered. Required steps are: 1. Identify the questions that need to be answered 2. Define the structure of the request for the updates 3. Implement on getpersonas.com 4. Metrics to parse that information
Comment 1•15 years ago
|
||
Looping in the Firefox team as Firefox will need to do the ping. Pedro: I think we should copy as much as possible from how Firefox pings AMO for updates as Personas will eventually be moved over to AMO.
Comment 2•15 years ago
|
||
To be clear on the context here, I just had a conversation with Pedro on the phone earlier, where I said: - Firefox accomplishes personas updates by pinging an updateURL once a day or so, and checking to see if there is a new JSON blob available - This updateURL is an optional property specified as part of the initial personas install event - It is a simple GET request - no information beyond a normal web request is sent. However, since the structure of the URL is under the control of the site hosting the personas, it could be constructed so as to contain the relevant metrics. Things like logging the number of active users of a given persona should be straightforward using this approach, since the persona ID is likely to be included as part of the update URL. Things like Firefox version or locale should be available through the request headers (albeit somewhat unreliably). In theory, the URL *could* be constructed to have other information embedded within it, e.g.: http://getpersonas.com/update.json?persona=38924&installdate=20091102&... as long as Firefox gets back a JSON blob corresponding to the active persona, it's happy. However, the decisions that Mozilla makes about what information to embed in that URL should be guided by our own principles around protecting user privacy, and should be kept to things that do not identify individuals and do not otherwise violate the privacy expectations of our users, or the trust they have in Mozilla.
Reporter | ||
Comment 3•15 years ago
|
||
I'll add some deadlines here: 1. Identify the questions that need to be answered - Assigned to: Ken and Amy - Deadline 24/11 2. Define the structure of the request for the updates - Assigned to: Pedro and Ken - Deadline 25/11 3. Implement on getpersonas.com - Assigned to: Ryan - Deadline: 01/12 - Comments: Rough estimate, can't be accurate as it's not our team 4. Metrics to parse that information - Assigned to: Pedro - Deadline: 04/12 - Comments: Can be back processed and makes only sense when this is live 5. Roll out the changes
Assignee: nobody → kkovash
Assignee | ||
Comment 4•15 years ago
|
||
Pedro -- just a heads up on something you and I discussed last week. 3.6 users will be able to select a Persona via the following touch points: - Fx Add-ons manager (Tools -> Add-ons -> Themes). The user's five most recently selected Personas will be displayed. - getpersonas.com - add-ons gallery (at addons.mozilla.org) - firstrun page - whatsnew page - get personal page and customize page (among other pages at mozilla.com) The last four items listed above will all direct the user to getpersonas.com. We're not 100% sure about whether or not the first item also directs users to getpersonas.com. I'll let Suneel or Johnathan clarify.
Reporter | ||
Comment 5•15 years ago
|
||
Thanks for the info Ken. We need to know if the first point queries the server or not. If it does *not* query the server I suppose it caches the response json and uses the information that was returned when that old persona was suggested the first time. In this case we can't get any date information (as we'd get the date from the previous selection). The only relevant bit of information is the persona itself. If the first point pings the server, then we can return more info in the updateUrl field. Waiting for feedback here, guys
Pedro, please ping Johnath with your question, or raise it at the Thursday uplift meeting.
Severity: normal → major
Priority: -- → P2
Reporter | ||
Comment 7•15 years ago
|
||
Johnathan, can you help us here? The question we're trying to answer is if when a user locally changes his persona (by using one of the last N chosen persona) he'll ping the server or not. We are assuming that in all other cases the main server (on our case getpersonas.com) is pinged. Thanks
Comment 8•15 years ago
|
||
(In reply to comment #7) > The question we're trying to answer is if when a user locally changes his > persona (by using one of the last N chosen persona) he'll ping the server or > not. I'm copying Dave Townsend here to make sure I'm not lying, but the short answer is: No. The longer answer: Changing from one persona to another one that is remembered in the addons manager will not cause an immediate update ping. It will mark that persona as the active one, though, so it will now be the one involved in the regular daily pings. I expect that changing to the new persona *may* cause Firefox to re-visit the header/footer images involved in the new persona, if they have expired from Firefox's cache. Firefox keeps a permanent copy of the active persona's images so there is no need for re-fetches, but for the unapplied-but-still-remembered personas, I believe we will just use the regular cache. This means that choosing a previously-applied persona may or may not need to re-fetch the images, depending on how much cache churn has occurred since they used it last.
Comment 10•15 years ago
|
||
Ken, please confirm that this has been resolved.
Assignee | ||
Comment 11•15 years ago
|
||
(In reply to comment #10) > Ken, please confirm that this has been resolved. I'll defer to Pedro. Pedro -- are we done here?
Reporter | ||
Comment 12•15 years ago
|
||
Yes, we are. I'll close this one
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified per comment 12.
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
Product: Websites → Websites Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•