Closed Bug 1343510 Opened 7 years ago Closed 7 years ago

Expose profile/session timestamps/times in UITour.getConfiguration for snippets on about:home

Categories

(Firefox :: Tours, enhancement, P3)

Product:
Firefox
Component:
Tours
Platform:
All
Unspecified
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 56
Tracking Flags:
Tracking Status
firefox55 --- fixed
firefox56 --- fixed

People

(Reporter: espressive, Assigned: giorgos)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Story

As a Firefox Retention team member, I would like to be able to display snippets to users based on weeks since their profile was created in order to provide useful information to users based on their product usage lifecycle.

Acceptance Criteria:
- Snippets are only displayed to users based on the profile creation date targeting used
-- Examples:
---1. Display snippet to users whose profile was created in the last 4 weeks
---2. Display snippet to users whose profile was created at least 52 weeks ago
---3. Display snippet to users whose profile was created at least 4 weeks ago but no more than 8 weeks ago

As a Firefox Retention team member, I would like to be able to display snippets to users based on weeks since their profile was reset in order to provide useful information to users who have recently reset their profile.

Acceptance Criteria:
- Snippets are only displayed to users based on the profile reset date targeting used
-- Examples:
---1. Display snippet to users whose profile was reset in the last 4 weeks
---2. Display snippet to users whose profile was reset at least 52 weeks ago
---3. Display snippet to users whose profile was reset at least 4 weeks ago but no more than 8 weeks ago

As a Firefox Retention team member, I would like to be able to display snippets to users based on weeks since their previous session ended in order to provide useful information only to users who use Firefox infrequently.

Acceptance Criteria:
- Snippets are only displayed to users based on the last session end date targeting used
-- Examples:
---1. Display snippet to users whose last session (prior to the current one) ended at least 4 weeks ago
---2. Display snippet to users whose last session (prior to the current one) ended at least 52 weeks ago
---3. Display snippet to users whose last session (prior to the current one) ended at least 4 weeks ago but no more than 8 weeks ago


---------------------------
Old Stories:
As a UITour consumer I will have access to the following properties on the result of Mozilla.UITour.getConfiguration("appinfo", …):

* Months or Weeks (if < 3 months) since profile creation (using weeks to reduce granularity)
* Months or Weeks (if < 3 months) since profile reset
* Months or Weeks (if < 3 months) since previous session of Firefox ended.

Attachments

(1 file)

Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.
59 bytes, text/x-review-board-request
MattN
: review+
jcristau
: approval-mozilla-beta+
Details 
The Firefox Retention team would like to use snippets running on about:home more effectively to improve retention of current, and new Firefox users. Although snippets do currently have access to UITour, UITour does not currently expose all of the information we are interested in.

The specific data points we are interested in are profile age(can be provided as both profile create and reset date) and, the amount of time that have elapsed since the user last used Firefox.

I some discussions with Benjamin Smedberg, and then Matthew Noorenberghe, it was determined that these data points do exist in Telemetry and can be exposed via the UITour's getConfiguration function.

This will however need sign of from a privacy/security perspective and will take some work to be implemented. Below is a transcript of the mail I sent with comments by Matthew:

Thank you in advance for your assistance.

"On Mon, Feb 27, 2017 at 3:54 AM, Schalk Neethling <sneethling@mozilla.com> wrote:
Greetings All,

First thing, I got referred to you good folks by Benjamin Smedberg, after an email I sent to him with regards to some research I am doing as part of the Firefox retention team.

The research is to look at the current snippets service and related snippets running on about:home and determine what is currently possible with these snippets, but also, what the retention people would like to be able to do.

Basically, they are after certain data points in order to target users more effectively. For the most part, snippets can currently do almost all of the things that are required but, there are one or two things missing.

This is where you come in :)

I know, and this was also confirmed by Benjamin, that Telemetry and/or FHR data contains data points relating to the user profile such as, the profile age, and profile creation date. Another question I have is whether there is data stored to indicate the last time the user used Firefox. Perhaps something like lastSessionEndTime or something.

​I believe FHR would also have that data but if not we have something similar outside FHR: Services.appinfo.replacedLockTime which tells you the last time the profile was *started* (before the current session). 

Now, knowing that data exist is great but, that leads to the next question. 

Do you know whether snippets running on about:home has access to that data?

​There is some documentation on what is available via UITour at https://bedrock.readthedocs.io/en/latest/uitour.html#getconfiguration-type-callback . getConfiguration is the main API to get various configuration options.

The snippets do currently have access to UITour for example. If snippets do not have access to the above data points(environment.profile.creationDate etc.), could this be securely exposed without impacting user security or causing fingerprinting?

​I guess it depends on how much we trust the list of origins on the UITour allow list. I think an easy mitigation would be to use buckets/rounding instead of exact times. e.g. respond with `N days ago` where N is a non-negative integer. That would probably offer enough precision for snippets.

Perhaps it could be integrated into UITour and snippets can get at these values that way?

​Sure, if the data privacy​ ​team is fine with that then I have no problem with adding it to getConfiguration.​ A bug in Firefox::Tours would handle it.

If all of this can indeed be done but, there is some development work that needs to be done, can you perhaps give a ballpark for how long it would take to implement?

​If Georg can confirm the APIs to use and someone defines the bucketing/rounding then this should be one day of work. I believe you will want .created and probably .reset from ProfileAge.jsm and some aggregate from TelemetryArchive.promiseArchivedPingList() to know what the last session was? Maybe Georg can explain the algorithm to consume promiseArchivedPingList to answer the question or a better API to use.
 
Thank you in advance for your assistance.

​You're welcome​,
Matthew"
To break down the wall of text into what we need, below is a summary of the above:

Who
---

The Firefox Retention team


Why
---

Use snippets running on about:home more effectively to improve retention of current, and new Firefox users.

What we need
-------------

In order to use said snippets more effectively, we need some additional data points exposed via the UITour. These are:

* Profile age
* Profile creation date
* Time since last use of Firefox
* Screen resolution (although this can be determined with JS i.e. window.screen.width and window.screen.height)
* Accessibility

What we know
-------------

Profile age/creation date exists in Telemetry and possibly FHR as environment.profile.creationDate, environment.profile.resetDate

In terms of "time since last use", outside of FHR there exists Services.appinfo.replacedLockTime which tells you the last time the profile was *started*. To mitigate any possible privacy/security concerns here, it has been suggested by Matthew that we can use buckets/rounding instead of exact times. e.g. respond with `N days ago` where N is a non-negative integer. I can confirm that this will be sufficient for our needs.

As far as screen resolution and accessibility is concerned, if this data already exists and exposing it will not add significantly to the amount of work, it would be great if these are exposed as well.

> Also, quoting Matthew here: "I believe you will want .created and probably .reset from ProfileAge.jsm and some aggregate from TelemetryArchive.promiseArchivedPingList() to know what the last session was"

That would be perfect.

The best way to expose all of this information to snippets would be to add these to the object returned by calling UITour.getConfiguration();

Open Questions
--------------

1. We need someone from the data privacy team to sign off on this so, is there anyone else I need to CC on this bug?
2. Should we receive sign off, and the changes are implemented, I am guessing this would need to ride the trains? If so, how long(ballpark) will it be before this is in release channel?

I hope this makes things a bit clearer. If not, please feel free to ping me on IRC, drop me a mail, or add a comment on the bug. Thanks!
Thanks for the clear rewrite!

(In reply to Schalk Neethling [:espressive] from comment #1)
> In order to use said snippets more effectively, we need some additional data
> points exposed via the UITour. These are:
> 
> * Profile age
> * Profile creation date
> * Time since last use of Firefox
> * Screen resolution (although this can be determined with JS i.e.
> window.screen.width and window.screen.height)
> * Accessibility
> 
> What we know
> -------------
> 
> Profile age/creation date exists in Telemetry and possibly FHR as
> environment.profile.creationDate, environment.profile.resetDate
> 
> In terms of "time since last use", outside of FHR there exists
> Services.appinfo.replacedLockTime which tells you the last time the profile
> was *started*. To mitigate any possible privacy/security concerns here, it
> has been suggested by Matthew that we can use buckets/rounding instead of
> exact times. e.g. respond with `N days ago` where N is a non-negative
> integer. I can confirm that this will be sufficient for our needs.

Reducing the resolution to `N days ago` sounds great, but if there are any relevant security concerns we should address them if we plan to add more data.
Was there a security review for this pattern already?

> As far as screen resolution and accessibility is concerned, if this data
> already exists and exposing it will not add significantly to the amount of
> work, it would be great if these are exposed as well.
> 
> > Also, quoting Matthew here: "I believe you will want .created and probably .reset from ProfileAge.jsm and some aggregate from TelemetryArchive.promiseArchivedPingList() to know what the last session was"
> 
> That would be perfect.

If you only need historic data, you should use the mentioned TelemetryArchive.promiseArchivedPingList().
You'll load the latest "main" ping [1], using TelemetryArchive.promiseArchivedPingById().
- The environment data [2] (ping.environment) has the mentioned profile data points and screen resolution.
- I'm not sure what data you need on accessibility? Maybe searching through [3] you'll find existing histograms.
- ping.creationDate will be a reliable indicator of the last activity date (documented as part of [4]).

Notes of caution here:
The scanning of the ping archive is delayed after startup (~60sec) for perf reasons.
If you need to access this data early we need to work together to make sure that this doesn't introduce perf regressions.
Data from crashed sessions is also not added until 60ish sec after startup - we might need to audit/QA that.
If previous sessions had startup crashes, you might not see any data for them in Telemetry.

Do you need data like screen res from fresh users too (i.e. on first launch)?
That wouldn't be covered by the above approach.

> 1. We need someone from the data privacy team to sign off on this so, is
> there anyone else I need to CC on this bug?

Benjamin, can you answer this or redirect?
This involves exposing additional data to about:home snippets, so i assume there are privacy & security angles here.

> 2. Should we receive sign off, and the changes are implemented, I am
> guessing this would need to ride the trains? If so, how long(ballpark) will
> it be before this is in release channel?

12-18 weeks to ride the channels normally. Although uplifting to Aurora or early beta is possible to cut this short.
You should talk to release management early about this [5].

1: https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/main-ping.html
2: https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/environment.html
3: https://georgf.github.io/fx-data-explorer/
4: https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/common-ping.html
5: https://wiki.mozilla.org/Release_Management/Release_owners
(In reply to Georg Fritzsche [:gfritzsche] from comment #2)
> > 1. We need someone from the data privacy team to sign off on this so, is
> > there anyone else I need to CC on this bug?
> 
> Benjamin, can you answer this or redirect?
> This involves exposing additional data to about:home snippets, so i assume
> there are privacy & security angles here.
Flags: needinfo?(benjamin)
Yura I'm adding you to this bug for awareness and assessment as a way to engage users for a possible accessibility beta community.
(In reply to Schalk Neethling [:espressive] from comment #1)
> As far as screen resolution and accessibility is concerned, if this data
> already exists and exposing it will not add significantly to the amount of
> work, it would be great if these are exposed as well.

Just wanted to plug in as our team (accessibility) would like to reach out to the user community that uses Firefox with assistive technologies. We currently expose if accessibility is enabled via appinfo. We also store in prefs things like: last loaded date, was it loaded in last session. 

We would also be interested in knowing if they are using a screen reader that is known to us (which is currently not exposed but we determine that on the platform level). This however might have some privacy concerns that I wanted to bring up.
Received an additional request:

If possible can we add "recordSearch" as another data point exposed to UITour via getConfiguration? 

From the request: "it counts the number of searches a user has done. http://gecko.readthedocs.io/en/latest/browser/browser/BrowserUsageTelemetry.html#search-telemetry"

Thanks!
The final data review happens against the final documentation changes in patch form, so this bug is not yet ready for the final data review.

For preliminary guidance, the goal of data review is to allow you to answer important questions while reducing risk and following our privacy principles and our privacy notice. In this case, to reduce risk you should chunk up the data as much as possible. So for example, knowing which exact date somebody created their profile is a rather identifying piece of data. So it would be far better to expose this in terms of ranges. e.g. "today", "yesterday", "past week", "past month", "past year", ">1 year".

Similarly for "time since last use". I suggest that you need to be more precise here: do you mean time since *use* or *startup*? If use, how do you define usage?

And what does "accesssibility" mean? a11y API used ever? Used recently? Do you care about the distinction between a11y used for a touchscreen or IME versus a full-on screen reader?
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> The final data review happens against the final documentation changes in
> patch form, so this bug is not yet ready for the final data review.
> 
> For preliminary guidance, the goal of data review is to allow you to answer
> important questions while reducing risk and following our privacy principles
> and our privacy notice. In this case, to reduce risk you should chunk up the
> data as much as possible. So for example, knowing which exact date somebody
> created their profile is a rather identifying piece of data. So it would be
> far better to expose this in terms of ranges. e.g. "today", "yesterday",
> "past week", "past month", "past year", ">1 year".

This would work perfectly for our purposes.

> 
> Similarly for "time since last use". I suggest that you need to be more
> precise here: do you mean time since *use* or *startup*? If use, how do you
> define usage?

I would say *startup* would be what I was referring to.

> 
> And what does "accesssibility" mean? a11y API used ever? Used recently? Do
> you care about the distinction between a11y used for a touchscreen or IME
> versus a full-on screen reader?

Michelle, can you clarify what we are after with regards to the a11y flag? I was thinking you meant an indication of whether the user is using an assistive technology, is that correct?
Flags: needinfo?(mwarther)
@schalk - yes, looking to know if a user is using assistive technology
@jean - this is the bug we talked about in scrum, let's figure out prioritization/timing
Flags: needinfo?(mwarther) → needinfo?(jcollings)
(In reply to Michele Warther from comment #9)
> @schalk - yes, looking to know if a user is using assistive technology
> @jean - this is the bug we talked about in scrum, let's figure out
> prioritization/timing

Sounds good. Nick Chapman and I have already had a lot of conversations with Elvin and Marshall around Telemetry and snippets so we should pull them into this bug.
Flags: needinfo?(jcollings)
(In reply to Jean Collings from comment #10)
> (In reply to Michele Warther from comment #9)
> > @schalk - yes, looking to know if a user is using assistive technology
> > @jean - this is the bug we talked about in scrum, let's figure out
> > prioritization/timing
> 
> Sounds good. Nick Chapman and I have already had a lot of conversations with
> Elvin and Marshall around Telemetry and snippets so we should pull them into
> this bug.

I have added the relevant people you mentioned to the CC list. Hopefully it is the correct Elvin and Marshall ;)
(In reply to Schalk Neethling [:espressive] from comment #11)
> (In reply to Jean Collings from comment #10)
> > (In reply to Michele Warther from comment #9)
> > > @schalk - yes, looking to know if a user is using assistive technology
> > > @jean - this is the bug we talked about in scrum, let's figure out
> > > prioritization/timing
> > 
> > Sounds good. Nick Chapman and I have already had a lot of conversations with
> > Elvin and Marshall around Telemetry and snippets so we should pull them into
> > this bug.
> 
> I have added the relevant people you mentioned to the CC list. Hopefully it
> is the correct Elvin and Marshall ;)

Removing Marshall/Elvin from the CC list as Benjamin will handle the data decision as data steward
Turns out I cannot remove people from the CC list so, if someone else can, please go ahead and remove them. Thanks!
Depends on: 1310150
I documented the existing return values in bug 1310150 and once I get more clarity on what pieces we need in this bug I can document them for data review. I'm going to try keep the User Story field reflecting the latest proposals.

(In reply to Schalk Neethling [:espressive] from comment #6)
> * Screen resolution (although this can be determined with JS i.e.
> window.screen.width and window.screen.height)

What's the advantage of UITour exposing this over using the JS API you mentioned? Snippets can trivially run that code IIUC.

(In reply to Schalk Neethling [:espressive] from comment #8)
> (In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> > For preliminary guidance, the goal of data review is to allow you to answer
> > important questions while reducing risk and following our privacy principles
> > and our privacy notice. In this case, to reduce risk you should chunk up the
> > data as much as possible. So for example, knowing which exact date somebody
> > created their profile is a rather identifying piece of data. So it would be
> > far better to expose this in terms of ranges. e.g. "today", "yesterday",
> > "past week", "past month", "past year", ">1 year".
> 
> This would work perfectly for our purposes.

What about simply using the number of weeks/months? That would be simpler to implement but perhaps still too fine-grained. Weeks or months with an upper bound would be easy to implement while still reducing fingerprinting. Do any of those work?

> > Similarly for "time since last use". I suggest that you need to be more
> > precise here: do you mean time since *use* or *startup*? If use, how do you
> > define usage?
> 
> I would say *startup* would be what I was referring to.

I'm worried this isn't actually useful (and therefore not what you want) since some users run Firefox for weeks. If this is to target occasional users then I think you want to know something like the number of days between this session's start time and the previous sessions end time? What are examples of how you would use "time since last use"?

(In reply to Michele Warther from comment #9)
> @schalk - yes, looking to know if a user is using assistive technology

That doesn't answer Benjamin's questions fully:

> And what does "accesssibility" mean? a11y API used ever? Used recently? Do you care about the distinction between a11y used for a touchscreen or IME versus a full-on screen reader?
User Story: (updated)
Flags: needinfo?(schalk.neethling.bugs)
Flags: needinfo?(mwarther)
(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #14)
> I documented the existing return values in bug 1310150 and once I get more
> clarity on what pieces we need in this bug I can document them for data
> review. I'm going to try keep the User Story field reflecting the latest
> proposals.
> 
> (In reply to Schalk Neethling [:espressive] from comment #6)
> > * Screen resolution (although this can be determined with JS i.e.
> > window.screen.width and window.screen.height)
> 
> What's the advantage of UITour exposing this over using the JS API you
> mentioned? Snippets can trivially run that code IIUC.
> 

I do not see any real problem other than a little less typing/code ;) So, if you call getConfiguration it will return all of the things so, you do not have to make two additional calls for the screen width and screen height.

> (In reply to Schalk Neethling [:espressive] from comment #8)
> > (In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> > > For preliminary guidance, the goal of data review is to allow you to answer
> > > important questions while reducing risk and following our privacy principles
> > > and our privacy notice. In this case, to reduce risk you should chunk up the
> > > data as much as possible. So for example, knowing which exact date somebody
> > > created their profile is a rather identifying piece of data. So it would be
> > > far better to expose this in terms of ranges. e.g. "today", "yesterday",
> > > "past week", "past month", "past year", ">1 year".
> > 
> > This would work perfectly for our purposes.
> 
> What about simply using the number of weeks/months? That would be simpler to
> implement but perhaps still too fine-grained. Weeks or months with an upper
> bound would be easy to implement while still reducing fingerprinting. Do any
> of those work?
> 

Number of weeks will work I would imagine.

> > > Similarly for "time since last use". I suggest that you need to be more
> > > precise here: do you mean time since *use* or *startup*? If use, how do you
> > > define usage?
> > 
> > I would say *startup* would be what I was referring to.
> 
> I'm worried this isn't actually useful (and therefore not what you want)
> since some users run Firefox for weeks. If this is to target occasional
> users then I think you want to know something like the number of days
> between this session's start time and the previous sessions end time? What
> are examples of how you would use "time since last use"?
> 

Michele might be able to answer this better but, for example. Should the user not have used Firefox in say 6 months, the retention team would want to show them a more specific "welcome back, here is what is new" kinda snippet as apposed to a more general snippet shown to regular users.

> (In reply to Michele Warther from comment #9)
> > @schalk - yes, looking to know if a user is using assistive technology
> 
> That doesn't answer Benjamin's questions fully:
> 
> > And what does "accesssibility" mean? a11y API used ever? Used recently? Do you care about the distinction between a11y used for a touchscreen or IME versus a full-on screen reader?

I will leave this one open for Michele to answer.
Flags: needinfo?(schalk.neethling.bugs)
Ben, 
Following up on this:

For the accessibility question - we want to know if yes or no, a user is using assistive technology (enabled). Then it would be great to get granular on what type of assitive tech is being used. [Let me know if my answer isn't giving you what you need to move forward].

Couple of questions/updates:
1. Michelle H. is speaking with Micah today about how we are reflecting/talking about data collection in the preferences specifically for snippets (in regards to Telemetry and UI Tour). Once we have that language - we will share with you.

2. We would like to open up 2 more attributes in this bug: if a user has opened the inspect element (this tells us if this person is potentially a developer or not) and session length (this tells us if the user is a heavy user or not). Is there any additional research/documentation needed for these 2 attributes?

3. Please let me know what else is needed to keep this bug moving.

Thanks,
Jean
Flags: needinfo?(mwarther) → needinfo?(benjamin)
Realize there's a lot of attributes thrown out there so wanted to put the list of attributes into a prioritized list if needed:

1.Profile age
2.Open Inspect Element
3.Session Length
4.Creation Date
5.Time last use Firefox (last used or startup - not sure where we landed on this)
6.Screen resolution
7.Accessibility enabled
8.# of searches done
There is too much going on in this bug, requests are very underdefined, and answers to existing questions aren't clearly addressed while new requests are added so it's getting quite frustrating. Please don't add any more data types to this bug… please file 2 separate bugs for #2 and #3 and please explain clearly what time period you're talking about for #2 and include user stories of what you're trying to do with each of them.

I don't understand what (1) in comment 16 is about but maybe Benjamin does… I'm not sure why he's needinfo'd though because we need to clearly write up the new data collection before he can review it as he said before. I offered to write up the details over email recently but answers are still not clear to me.
I have updated the User Story field to be what will be exposed in this bug. Please confirm that the granularity is acceptable for now and in the future. Other requests should go in separate bugs with clear time periods defined for data which involves counts.

(In reply to Schalk Neethling [:espressive] from comment #15)
> (In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are
> blocking you) from comment #14)
> > I documented the existing return values in bug 1310150 and once I get more
> > clarity on what pieces we need in this bug I can document them for data
> > review. I'm going to try keep the User Story field reflecting the latest
> > proposals.
> > 
> > (In reply to Schalk Neethling [:espressive] from comment #6)
> > > * Screen resolution (although this can be determined with JS i.e.
> > > window.screen.width and window.screen.height)
> > 
> > What's the advantage of UITour exposing this over using the JS API you
> > mentioned? Snippets can trivially run that code IIUC.
> > 
> 
> I do not see any real problem other than a little less typing/code ;) So, if
> you call getConfiguration it will return all of the things so, you do not
> have to make two additional calls for the screen width and screen height.

Sorry, the Firefox Desktop Front-end team who maintains UITour hasn't grown in at least 5 years despite scope being regularly added to the team so I don't want to add non-essential things to support especially when the existing solution is trivial to use with UITour since it's a synchronous API.

> > (In reply to Schalk Neethling [:espressive] from comment #8)
> > > (In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> > > > For preliminary guidance, the goal of data review is to allow you to answer
> > > > important questions while reducing risk and following our privacy principles
> > > > and our privacy notice. In this case, to reduce risk you should chunk up the
> > > > data as much as possible. So for example, knowing which exact date somebody
> > > > created their profile is a rather identifying piece of data. So it would be
> > > > far better to expose this in terms of ranges. e.g. "today", "yesterday",
> > > > "past week", "past month", "past year", ">1 year".
> > > 
> > > This would work perfectly for our purposes.
> > 
> > What about simply using the number of weeks/months? That would be simpler to
> > implement but perhaps still too fine-grained. Weeks or months with an upper
> > bound would be easy to implement while still reducing fingerprinting. Do any
> > of those work?
> > 
> 
> Number of weeks will work I would imagine.
> 
> > > > Similarly for "time since last use". I suggest that you need to be more
> > > > precise here: do you mean time since *use* or *startup*? If use, how do you
> > > > define usage?
> > > 
> > > I would say *startup* would be what I was referring to.
> > 
> > I'm worried this isn't actually useful (and therefore not what you want)
> > since some users run Firefox for weeks. If this is to target occasional
> > users then I think you want to know something like the number of days
> > between this session's start time and the previous sessions end time? What
> > are examples of how you would use "time since last use"?
> > 
> 
> Michele might be able to answer this better but, for example. Should the
> user not have used Firefox in say 6 months, the retention team would want to
> show them a more specific "welcome back, here is what is new" kinda snippet
> as apposed to a more general snippet shown to regular users.

OK, "time since last startup" works for a use case involving N months but will fall apart for use cases involving weeks for the reason I explained. Given that I don't want someone to have to spend more time making it work with weeks later on I think we should use time since last session ended.

(In reply to Jean Collings from comment #16)
> For the accessibility question - we want to know if yes or no, a user is
> using assistive technology (enabled). Then it would be great to get granular
> on what type of assitive tech is being used. [Let me know if my answer isn't
> giving you what you need to move forward].

Since I'm not familiar enough about how Services.appinfo.accessibilityEnabled handles IME and touch screens can you please file a separate bug for exposing accessibility info.
User Story: (updated)
(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #18)
> There is too much going on in this bug, requests are very underdefined, and
> answers to existing questions aren't clearly addressed while new requests
> are added so it's getting quite frustrating. Please don't add any more data
> types to this bug… please file 2 separate bugs for #2 and #3 and please
> explain clearly what time period you're talking about for #2 and include
> user stories of what you're trying to do with each of them.
> 
> I don't understand what (1) in comment 16 is about but maybe Benjamin does…
> I'm not sure why he's needinfo'd though because we need to clearly write up
> the new data collection before he can review it as he said before. I offered
> to write up the details over email recently but answers are still not clear
> to me.

Hi Matt,
Thanks for looking into this. Will clear info for Ben. And I will file separate bugs for #2, #3 with specific time periods and the accessibility info. 
J
Flags: needinfo?(benjamin)
(In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are blocking you) from comment #19)
> I have updated the User Story field to be what will be exposed in this bug.
> Please confirm that the granularity is acceptable for now and in the future.
> Other requests should go in separate bugs with clear time periods defined
> for data which involves counts.
> 
> (In reply to Schalk Neethling [:espressive] from comment #15)
> > (In reply to Matthew N. [:MattN] (behind on bugmail; PM if requests are
> > blocking you) from comment #14)
> > > I documented the existing return values in bug 1310150 and once I get more
> > > clarity on what pieces we need in this bug I can document them for data
> > > review. I'm going to try keep the User Story field reflecting the latest
> > > proposals.
> > > 
> > > (In reply to Schalk Neethling [:espressive] from comment #6)
> > > > * Screen resolution (although this can be determined with JS i.e.
> > > > window.screen.width and window.screen.height)
> > > 
> > > What's the advantage of UITour exposing this over using the JS API you
> > > mentioned? Snippets can trivially run that code IIUC.
> > > 
> > 
> > I do not see any real problem other than a little less typing/code ;) So, if
> > you call getConfiguration it will return all of the things so, you do not
> > have to make two additional calls for the screen width and screen height.
> 
> Sorry, the Firefox Desktop Front-end team who maintains UITour hasn't grown
> in at least 5 years despite scope being regularly added to the team so I
> don't want to add non-essential things to support especially when the
> existing solution is trivial to use with UITour since it's a synchronous API.
> 
> > > (In reply to Schalk Neethling [:espressive] from comment #8)
> > > > (In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> > > > > For preliminary guidance, the goal of data review is to allow you to answer
> > > > > important questions while reducing risk and following our privacy principles
> > > > > and our privacy notice. In this case, to reduce risk you should chunk up the
> > > > > data as much as possible. So for example, knowing which exact date somebody
> > > > > created their profile is a rather identifying piece of data. So it would be
> > > > > far better to expose this in terms of ranges. e.g. "today", "yesterday",
> > > > > "past week", "past month", "past year", ">1 year".
> > > > 
> > > > This would work perfectly for our purposes.
> > > 
> > > What about simply using the number of weeks/months? That would be simpler to
> > > implement but perhaps still too fine-grained. Weeks or months with an upper
> > > bound would be easy to implement while still reducing fingerprinting. Do any
> > > of those work?
> > > 
> > 
> > Number of weeks will work I would imagine.
> > 
> > > > > Similarly for "time since last use". I suggest that you need to be more
> > > > > precise here: do you mean time since *use* or *startup*? If use, how do you
> > > > > define usage?
> > > > 
> > > > I would say *startup* would be what I was referring to.
> > > 
> > > I'm worried this isn't actually useful (and therefore not what you want)
> > > since some users run Firefox for weeks. If this is to target occasional
> > > users then I think you want to know something like the number of days
> > > between this session's start time and the previous sessions end time? What
> > > are examples of how you would use "time since last use"?
> > > 
> > 
> > Michele might be able to answer this better but, for example. Should the
> > user not have used Firefox in say 6 months, the retention team would want to
> > show them a more specific "welcome back, here is what is new" kinda snippet
> > as apposed to a more general snippet shown to regular users.
> 
> OK, "time since last startup" works for a use case involving N months but
> will fall apart for use cases involving weeks for the reason I explained.
> Given that I don't want someone to have to spend more time making it work
> with weeks later on I think we should use time since last session ended.

For my understanding here, if we use "time since last session ended" - does that mean we can choose to talk to users with sessions that ended 6 months ago versus 1 month ago? To be clear, our goal is to show different types of messages to users based on when they last used Firefox (or in your definition: when the last session ended). If that's the case, - we are comfortable with this granularity of months. 

 
> (In reply to Jean Collings from comment #16)
> > For the accessibility question - we want to know if yes or no, a user is
> > using assistive technology (enabled). Then it would be great to get granular
> > on what type of assitive tech is being used. [Let me know if my answer isn't
> > giving you what you need to move forward].
> 
> Since I'm not familiar enough about how
> Services.appinfo.accessibilityEnabled handles IME and touch screens can you
> please file a separate bug for exposing accessibility info.
See Also: → 1354606
I re-summarized the three key user stories for this bug, and I'll file new child bugs for the other asks that were added in the comments.
User Story: (updated)
See Also: → 1357433
See Also: → 1357439
See Also: → 1357455
Summary: Expose additional information in UITour.getConfiguration for snippets on about:home → Expose profile/session timestamps/times in UITour.getConfiguration for snippets on about:home
Depends on: 1361713
Blocks: photon-onboarding
Priority: -- → P3
To implement the following…
> - Snippets are only displayed to users based on the profile creation date targeting used
> - Snippets are only displayed to users based on the profile reset date targeting used

we can implement a method like [1] which uses ProfileAge.jsm and then convert to Months or Weeks (if < 3 months). This data could simply be added to "appinfo" results from getConfiguration (though technically it's profile-related, not app-specific but I'm not sure it's useful to keep this data separate). Some m-bc tests should be added.

[1] https://dxr.mozilla.org/mozilla-central/rev/8a7d0b15595f9916123848ca906f29c62d4914c9/browser/components/nsBrowserGlue.js#728-741
(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #23)
> To implement the following…
> > - Snippets are only displayed to users based on the profile creation date targeting used
> > - Snippets are only displayed to users based on the profile reset date targeting used
> 
> we can implement a method like [1] which uses ProfileAge.jsm and then
> convert to Months or Weeks (if < 3 months). This data could simply be added
> to "appinfo" results from getConfiguration (though technically it's
> profile-related, not app-specific but I'm not sure it's useful to keep this
> data separate). Some m-bc tests should be added.

Thanks that's very useful!

(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #19)
> I think we should use time since last session ended.

Matt can I get this value from Services.appinfo.replacedLockTime? [0]

[0] https://dxr.mozilla.org/mozilla-central/rev/8a7d0b15595f9916123848ca906f29c62d4914c9/browser/components/nsBrowserGlue.js#924
Flags: needinfo?(MattN+bmo)
(In reply to Giorgos Logiotatidis [:giorgos] from comment #24)
> Thanks that's very useful!

You're welcome

> (In reply to Matthew N. [:MattN] (PM if requests are blocking you) from
> comment #19)
> > I think we should use time since last session ended.
> 
> Matt can I get this value from Services.appinfo.replacedLockTime? [0]
> 
> [0]
> https://dxr.mozilla.org/mozilla-central/rev/
> 8a7d0b15595f9916123848ca906f29c62d4914c9/browser/components/nsBrowserGlue.
> js#924

That will currently only give you the time since last startup which I explained has problems if users keep the browser running. After bug 1054947 we will also update the profiles.ini modification timestamp at least once every 24 hours which can be used to know roughly the last day Firefox was used. We could have that code also read the old modification time and store it somewhere like replacedLockTime does if you need.

> let lastUse =  Math.max(profilesIniLastModifiedTime, Services.appinfo.replacedLockTime);

Otherwise you can read from the previous telemetry payload to see the session end time and I think Georg mentioned earlier how to do that. There are concerns about the file I/O to read this information though. As I said before, if you only care about months since last "use" then time since last "startup" (not "shutdown") is probably good enough granularity and would allow you to avoid solving the issue of multi-week sessions.
Flags: needinfo?(MattN+bmo)
(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #25)
> (In reply to Giorgos Logiotatidis [:giorgos] from comment #24)
> > Matt can I get this value from Services.appinfo.replacedLockTime? [0]
> > 
> > [0]
> > https://dxr.mozilla.org/mozilla-central/rev/
> > 8a7d0b15595f9916123848ca906f29c62d4914c9/browser/components/nsBrowserGlue.
> > js#924
> 
> That will currently only give you the time since last startup which I
> explained has problems if users keep the browser running. After bug 1054947
> we will also update the profiles.ini modification timestamp at least once
> every 24 hours which can be used to know roughly the last day Firefox was
> used. We could have that code also read the old modification time and store
> it somewhere like replacedLockTime does if you need.
> 
> > let lastUse =  Math.max(profilesIniLastModifiedTime, Services.appinfo.replacedLockTime);

It seems that this is the best way forward. Storing this in a variable like Service.appinfo.profilesIniLastModifiedTime would be very helpful.
Matt, is the variable something that will be taken care of in bug 1054947? Do I need to do something about it or it will be available for use when the bug gets resolved and merged?
Flags: needinfo?(MattN+bmo)
(In reply to Giorgos Logiotatidis [:giorgos] from comment #27)
> Matt, is the variable something that will be taken care of in bug 1054947?

No, that bug doesn't need to persist the old last modified time so won't store it anywhere.

> Do I need to do something about it or it will be available for use when the
> bug gets resolved and merged?

If you really need to use the last shutdown time instead of startup time then you will need to add such an API. Perhaps we could add that "lastUsed" API to ProfileAge.jsm. We should probably ask Georg is he is fine with that idea…
Flags: needinfo?(MattN+bmo) → needinfo?(gfritzsche)
If we need to do that, profileage seems an ok place to put it i think.
Does that mean the bug 1054947 implementation should possibly move there?

It seems like we come back to a "give me some information about the user" pattern here (see also bug 1361713, test pilot & shield needs, etc.).
At some point we might want to consolidate this?
Flags: needinfo?(gfritzsche)
(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #28)
> > Do I need to do something about it or it will be available for use when the
> > bug gets resolved and merged?
> 
> If you really need to use the last shutdown time instead of startup time
> then you will need to add such an API. Perhaps we could add that "lastUsed"
> API to ProfileAge.jsm. We should probably ask Georg is he is fine with that
> idea…

I don't really understand what you mean here. Let me re-iterate on what we want to archive here:

We want to know if a user has been using firefox and how often. Our use case seems very similar to bug 1054947: If they haven't used firefox for a while we will show X, e.g. a reset firefox snippet, but if they are using it constantly we don't want to show that.

The way lastUse forms in bug 1054947 seems to cover our needs. If we can read this value from UITour.jsm then I can implement a patch. Otherwise I'd very much like your guidance on how to get there.
Attachment #8876690 - Flags: review?(MattN+bmo)
I submitted a review request for profile creation and reset dates, so we can take those off the table. 

I also submitted a pull requests against mozilla/bedrock [0] to update UITour documentation. 


[0] (In reply to Benjamin Smedberg [:bsmedberg] from comment #7)
> The final data review happens against the final documentation changes in
> patch form, so this bug is not yet ready for the final data review.


:bsmedberg can you please review the documentation changes? 

[0] https://github.com/mozilla/bedrock/pull/4892
Flags: needinfo?(benjamin)
Assignee: nobody → giorgos
Status: NEW → ASSIGNED
data-r=me on pull/4892
Flags: needinfo?(benjamin)
:bsmedberg I pinged you in pull/4892 on github and changed the commit comment. If you need anything else can you please explain?
Flags: needinfo?(benjamin)
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/25cc5df3bdb4ce41e5a21f26dc5ce7f4232ec903
[bug 1343510] Add documentation for UITour's createdWeeksAgo and resetWeeksAgo.

https://github.com/mozilla/bedrock/commit/7b18cc517589a1f6e5ad1f97f3f375f8b850b65f
Merge pull request #4892 from glogiotatidis/uitour-created-reset

[bug 1343510] Add documentation for UITour's createdWeeksAgo and resetWeeksAgo.
Flags: needinfo?(benjamin)
Blocks: 1372847
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review156914

In the future please PM me directly if a review is blocking you (like it says in my BMO name).

::: browser/components/uitour/UITour.jsm:14
(Diff revision 2)
>  Cu.import("resource://gre/modules/Preferences.jsm");
> +Cu.import("resource://gre/modules/ProfileAge.jsm");
>  Cu.import("resource://gre/modules/Promise.jsm");

Please make this use a defineLazyModuleGetter (see the block below) so it's only imported when needed

::: browser/components/uitour/UITour.jsm:1551
(Diff revision 2)
> +      try {
> +          let shell = aWindow.getShellService();
> +          if (shell) {
> +              isDefaultBrowser = shell.isDefaultBrowser(false);
> +          }
> +      } catch (e) {}

Please revert to two-space indentation throughout this method

::: browser/components/uitour/UITour.jsm:1585
(Diff revision 2)
> +      appinfo["profileCreatedWeeksAgo"] = createdWeeksAgo;
> +      appinfo["profileResetWeeksAgo"] = resetWeeksAgo;

(In reply to Giorgos Logiotatidis [:giorgos] from comment #32)
> I also submitted a pull requests against mozilla/bedrock [0] to update
> UITour documentation. 

I'm moving the documentation to be generated from the mozilla-central code (bug 1352316) and will be removing that documentation from bedrock eventually so please update the jsdoc documentation in UITour-lib.js.

::: browser/components/uitour/UITour.jsm:1589
(Diff revision 2)
> +     })().catch(err => {
> +         log.error(err);
> +         this.sendPageCallback(aMessageManager, aCallbackID, {});
> +     })

What are you worried about catching here? Or are you just following the pattern from `getAvailableTargets`?
Attachment #8876690 - Flags: review?(MattN+bmo)
(In reply to Giorgos Logiotatidis [:giorgos] from comment #30)
> (In reply to Matthew N. [:MattN] (PM if requests are blocking you) from
> comment #28)
> > > Do I need to do something about it or it will be available for use when the
> > > bug gets resolved and merged?
> > 
> > If you really need to use the last shutdown time instead of startup time
> > then you will need to add such an API. Perhaps we could add that "lastUsed"
> > API to ProfileAge.jsm. We should probably ask Georg is he is fine with that
> > idea…
> 
> I don't really understand what you mean here. Let me re-iterate on what we
> want to archive here:
> 
> We want to know if a user has been using firefox and how often. Our use case
> seems very similar to bug 1054947: If they haven't used firefox for a while
> we will show X, e.g. a reset firefox snippet, but if they are using it
> constantly we don't want to show that.
> 
> The way lastUse forms in bug 1054947 seems to cover our needs. If we can
> read this value from UITour.jsm then I can implement a patch.

Right, I'm saying you won't be able to from UITour.jsm.

> Otherwise I'd
> very much like your guidance on how to get there.

I think you would need to make a patch (file a new bug if we're going to land the profile age and reset age beforehand) which stores the result of the work in bug 1054947 into ProfileAge then UITour.jsm would retrieve it from ProfileAge when needed.
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review157022

::: browser/components/uitour/UITour.jsm:1585
(Diff revision 2)
> +      appinfo["profileCreatedWeeksAgo"] = createdWeeksAgo;
> +      appinfo["profileResetWeeksAgo"] = resetWeeksAgo;

Please also add an automated test for this after test_getConfigurationDistribution in browser/components/uitour/test/browser_UITour.js. At least ensure that profileCreatedWeeksAgo returns a number and use ProfileAge.recordProfileReset() to record a reset some weeks in the past and ensure that the returned number of weeks is correct.
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review157138

::: browser/components/uitour/UITour.jsm:1589
(Diff revision 2)
> +     })().catch(err => {
> +         log.error(err);
> +         this.sendPageCallback(aMessageManager, aCallbackID, {});
> +     })

I'm just following the pattern from `getAvailableTargets`
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review156914

> What are you worried about catching here? Or are you just following the pattern from `getAvailableTargets`?

I'm just following the pattern. Left this as-is for now.
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review157544
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review157546
Attachment #8876690 - Flags: review?(giorgos)
Attachment #8876690 - Flags: review?(giorgos)
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

https://reviewboard.mozilla.org/r/148022/#review157552

Thanks!

::: browser/components/uitour/UITour-lib.js:483
(Diff revision 3)
>     * @property {String} version - Version string e.g. "48.0a2"
> +   * @property {Number} profileCreatedWeeksAgo - The number of weeks since the profile was created,
> +   *                                             starting from 0 for profiles dating less than
> +   *                                             seven days old. Since Fx56.
> +   * @property {Number} profileResetWeeksAgo - The number of weeks since the profile was last reset,
> +   *                                           starting from 0 for profiles reset less than seven
> +   *                                           days ago. If the profile has never been reset it
> +   *                                           returns null. Since Fx56.

Move these above `version` to keep them sorted alphabetically.

::: browser/components/uitour/test/browser_UITour.js:317
(Diff revision 3)
> +        ok(typeof(result2.profileResetWeeksAgo) === "number", "profileResetWeeksAgo should be number.");
> +        ok(result2.profileResetWeeksAgo === 2, "profileResetWeeksAgo should be 2.");

Nit: Use `is` instead of `ok` when comparing with a non-boolean so that the logs should the two arguments in the case of failure.
Attachment #8876690 - Flags: review?(MattN+bmo) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/5ce62f7e6633
Add createdWeeksAgo and resetWeeksAgo to appInfo. r=MattN
Keywords: checkin-needed
Pushed by mozilla@noorenberghe.ca:
https://hg.mozilla.org/integration/autoland/rev/21c9938cfdef
Add createdWeeksAgo and resetWeeksAgo to appInfo. r=MattN
https://hg.mozilla.org/mozilla-central/rev/21c9938cfdef
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox56: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 56
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/55907128e47d98e22e051f81158feb0b85091a83
[bug 1343510] Update UITour documentation.

Update profileCreatedWeeksAgo and profileResetWeeksAgo.

https://github.com/mozilla/bedrock/commit/d9ba2b7b439810ea8563c0e5020af88cf296aacc
Merge pull request #4943 from glogiotatidis/uitour-created-reset

[bug 1343510] Update UITour documentation.
Giorgos, can you please request beta uplift for this patch into 55, assuming it sticks?
Flags: needinfo?(giorgos)
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

Approval Request Comment

[Feature/Bug causing the regression]: -

[User impact if declined]: Marketing wants this data available via UITour for use with snippets. Without this patch they can't target messages planned for the Q3 campaigns.

[Is this code covered by automated tests?]: Yes 

[Has the fix been verified in Nightly?]: Yes. Going to about:home (which is UITour whitelisted) and running 'Mozilla.UITour.getConfiguration('appinfo', console.log.bind(console))' returns an object with profileCreatedWeeksAgo and profileResetWeeksAgo

[Needs manual test from QE? If yes, steps to reproduce]: No manual tests needed.

[List of other uplifts needed for the feature/fix]: None

[Is the change risky?]: Not Risky

[Why is the change risky/not risky?]: This is low risk as the change itself is small and covered by tests. UITour is only used by some of our sites (Snippets, SUMO, SHIELD, mozilla.org). The failure case is that sites that use UITour won't be able to access information / take action.

[String changes made/needed]: None
Flags: needinfo?(giorgos)
Attachment #8876690 - Flags: approval-mozilla-beta?
Comment on attachment 8876690 [details]
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo.

add some information to uitour, beta55+
Attachment #8876690 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to Giorgos Logiotatidis [:giorgos] from comment #56)
> [Is this code covered by automated tests?]: Yes 
> 
> [Has the fix been verified in Nightly?]: Yes. Going to about:home (which is
> UITour whitelisted) and running 'Mozilla.UITour.getConfiguration('appinfo',
> console.log.bind(console))' returns an object with profileCreatedWeeksAgo
> and profileResetWeeksAgo
> 
> [Needs manual test from QE? If yes, steps to reproduce]: No manual tests
> needed.

Setting qe-verify- based on Giorgos' assessment on manual testing and the fact that this fix has automated coverage.
Flags: qe-verify-
https://hg.mozilla.org/projects/jamun/rev/7bd174ec72487842c2f272fda7ef8896a3ac57ab
Bug 1343510 - Add createdWeeksAgo and resetWeeksAgo to appInfo. r=MattN, a=jcristau
See Also: → 1431469
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: