Full Feature Page: https://wiki.mozilla.org/Features/Fennec/Cloud_to_Device_Messaging Meta Goal: The 2012 Firefox Mobile goal is to achieve 4.2 M ADIs Use Cases: * Reactivation - Reactivate 2 - 4% of installed-but-non-users into an incremental 530,000 – 1M ADIs * User Research (surveys, etc) * App or System update messages (not necessarily confirmed as a use case) Requirements: P1 - Enable messaging to users who have not used Firefox Mobile in X (what?) period of time P1 - Enable messaging with a call to action in the message P1 - Must be opt in P1 - Can be opted out P1 - Must work for Firefox Mobile Beta P2 - Must work for Firefox Mobile GA Next Steps: 1) [Done]Marketing to provide requirements for this feature 2) UX to provide specifications to Mobile Frontend team based on Marketing's requirements 3) Mobile Platform and WebDev to work out a protocol based on Marketing's requirements 4) Mobile Platform, Mobile Frontend and WebDev to build out their pieces

15 -> Future?

Updated requirements to support version 1 of this feature (also updated summary): Version 1 Requirements, Cloud-to-Device Messaging 1. A communication method that allows marketing to send a message to GA users that have Firefox for Android installed, and allows a message to be sent regardless of whether or not the application is currently open. Google Cloud Messaging is probably the best tool. 2. A mozilla server side set-up that will allow us to send messages to our users. This server side set-up should contain: a. A text field (to enter a text that will be displayed in the message) b. A URL field ( c. A localization/region field (to set specific targets) d. A target field (to select specific cohorts) 3. Specific Requirements: a. The ability to launch Firefox for Android using the URL Field i. In this case, the user would just be taken back to their last viewed page and/or the start-up page b. The ability to launch a specific page using the URL Field c. The ability to message ALL GA users d. The ability to target GA users based on last ADI using the “target” field. f. The ability to track response rate--# of messages sent, # of messages received, # of messages acted on (opened) 4. Tool Mock-Up: uploaded image

Very unlikely to be related to the Services Notifications product, so removing that sec review. Sam, would you please file a new bug for sec review for this feature?

Security Review Bug: 789296 Privacy Review Bug: 788878

Little bit of metadata cleanup from your friendly local metadata elf.

Richard had some follow up questions in an email thread, and I'm capturing those questions and my responses below: •What kind of delivery latency is acceptable? If these messages are "hey, did you know Firefox can do this?", presumably "at the client's leisure" is acceptable, right? (Real-time or near-real-time are very expensive in every sense.) --I don't think nano-second delivery is necessary. I would say that we would want these messages to be delivered within the same hour as they were sent, and at most within a few hours. I'm guessing that we'll be throttling the messages that we send (1000/second, for instance), so certainly there will be a delay from first 1000 messages sent to last 1000 message sent. • How does the requirement to track response rate align with reasonable expectations of user privacy? Are you expecting these messages to be open-broadcast like snippets, with approximate fetch rate being computed from client requests? The requirement to track messages acted on is a complication, both from implementation and privacy standpoints. Is it enough to, say, track the hits on the destination URL, rather than having per-client reporting? --I don't have any specific requirements for how we track, just that we capture the full conversion funnel: 1)# of messages sent, 2)#of messages received, 3) #of messages opened (destination URL). This information doesn't need to be user-specific; an aggregate is sufficient. I may be misunderstanding your question. If I am, please let me know. • Is message expiration not a requirement (and if not, why not)? Not sure I want a Christmas addon popup on December 30th. --I didn't think we had this type of control. I was under the impression that once a message was sent, it was on the user who received that message to dismiss/close the message. We will be sure to plan our sending schedule around the time-frame of our message so that no message is received at an inappropriate time. • As well as the requirement for opt-in and easy-off, we probably need a rulebook for its use… there are territories where, e.g., Christmas messaging would be offensive or downright dangerous, and even large swathes of the western world where it would be offensive or intrusive. --I totally agree. Part of the MVP is targeting by region, so we'll make sure that we are delivering relevant messages to the appropriate user base. • How do you want to work l10n into this flow? --Good question. I'm quite sure how to proceed here. But, so long as we have the ability to target by regions, we can localize the message.

(In reply to Sam Mott from comment #7) > --I don't think nano-second delivery is necessary. I would say that we would > want these messages to be delivered within the same hour as they were sent, > and at most within a few hours. I'm guessing that we'll be throttling the > messages that we send (1000/second, for instance), so certainly there will > be a delay from first 1000 messages sent to last 1000 message sent. Let's take a step back a bit; I think you've got a particular implementation in mind, which probably doesn't match up to how we'll end up building this. My questions are tailored to figuring out what your firm requirements are so that we can decide on the cheapest, most functional, user-centric approach to deliver. So: is "message must be delivered within three hours" a hard requirement (that is, it's required regardless of cost), or nice-to-have? Presumably if you're talking about hour-granularity delivery, you're planning to use this for something really user-critical, and not just marketing? If not, why so urgent? Do you really want to wake a user up to tell them about a cool add-on? If you are intending to use this for security updates (instead of, say, Google Play), what do you plan to do for users who opt out, or don't have a reliable network connection? Would daily or weekly suffice as a hard requirement? > --I don't have any specific requirements for how we track, just that we > capture the full conversion funnel: 1)# of messages sent, 2)#of messages > received, 3) #of messages opened (destination URL). This information doesn't > need to be user-specific; an aggregate is sufficient. I may be > misunderstanding your question. If I am, please let me know. No, that sounds perfect. > --I didn't think we had this type of control. I was under the impression > that once a message was sent, it was on the user who received that message > to dismiss/close the message. Again, implementation is TBD. In any case there's a decoupling between the system notification on the phone and the message hanging around in the ether. What I'm saying by "expiration" is twofold: * that a client that hasn't grabbed a message by December 25 shouldn't be able to grab it on December 26 * that a client that _has_ grabbed a message by December 25, but for some reason hasn't displayed it yet (tiny race condition) can decide not to display it. > We will be sure to plan our sending schedule > around the time-frame of our message so that no message is received at an > inappropriate time. I think you're assuming that sending time ~= receiving time. That's not the case for a variety of reasons. Even SMS can't achieve that. But do you want the client to respect user preferences in when it presents a notification? > • How do you want to work l10n into this flow? > --Good question. I'm quite sure how to proceed here. But, so long as we have > the ability to target by regions, we can localize the message. I think it goes beyond that. What language are you going to send to USA customers -- English? Latin American Spanish? Etc. I don't want to get notifications in Polish when I travel, and my friend in Washington wants to get her notifications in Mexican Spanish. Some implementation approaches come with built-in ways to solve the language-selection problem, but it needs to be called out as a requirement. Additionally, are you wanting to leverage Mozilla's existing localizer network? Something else? That is, how are you planning to get a message from your Etherpad in English to an Austrian Fennec user's phone?

Oh, I guess this raises another assumption: what do you want to happen for: * New installs that become active after you've declared that users should receive message A? * Existing installs that are offline? That is, should messages disappear into the ether if they can't be delivered immediately (like IRC/IM), stick around for people who were in the target set but weren't online to get the message (like email), or stick around for anyone suitable to pick them up until they expire (like a bulletin board)?

I've started sketching up a strawman client-side implementation for this.

After discussions with Richard, and looking at this and the email thread, I've built some refined mockups for what the webtool should look like: https://www.dropbox.com/sh/b6u81s9e7ma3u1x/cy5KWsiako#/ Some caveats: * I'd rather have a date picker for the dates, easy enough with a JS lib. * We'll have to design the reporting/analytics backend with the Services team. * I need to figure out with l10n how we'll notify localizers and control access. That said, what's missing here?

> So: is "message must be delivered within three hours" a hard requirement > (that is, it's required regardless of cost), or nice-to-have? Given your feedback, and after a little more thought about our use-cases, I think that the most time-sensitive messages that would need to be sent and received would be those related to a product vulnerability and/or a message that references a time-sensitive event (the last day of a contest, for instance). With that in mind, 12 hours would be an appropriate time-frame for sending/receiving messages. I'm open to extending this time-frame to 24 hours. > Do you really want to wake a user up to tell them about a cool add-on? This is one of the most annoying parts of building a messaging system--how do we prevent (to the greatest extent possible) messaging people when they are asleep. The US isn't too difficult to handle: message sends can be initiated early enough in the day that no messages are sent past, say, 8PM PST. It become tricky when you need to account for users abroad. In these cases, targeting messages by regions usually is enough. Do you have any ideas about how we could address these time-zone issues? > If you are intending to use this for security updates (instead of, say, > Google Play), what do you plan to do for users who opt out, or don't have a > reliable network connection? Unfortunately, if a user decides to opt-out or if they don't have a reliable network connection, there isn't much to be done (at least as far as this feature is concerned). I think it is worth exploring a separate feature to handle this use case. In particular, I think the application start-up page is ripe for change; we should use some of that real estate for a message & graphic that can be updated server-side. > * that a client that hasn't grabbed a message by December 25 shouldn't be > able to grab it on December 26 > * that a client that _has_ grabbed a message by December 25, but for some > reason hasn't displayed it yet (tiny race condition) can decide not to > display it. Gotcha. Perhaps we should extend the eligible grab-time to 24 hours beyond the time the message should have been received? In general, I think a one-day grace period is a good start. Though, some types of messages won't need such tight parameters. > > > > We will be sure to plan our sending schedule > > around the time-frame of our message so that no message is received at an > > inappropriate time. > > I think you're assuming that sending time ~= receiving time. That's not the > case for a variety of reasons. Even SMS can't achieve that. My plan was to schedule the message sending based on region. For instance, a new years message targeted at the US would be sent on December 31st at AM while a message target at Japan would need to be sent on December 30th. > > But do you want the client to respect user preferences in when it presents a > notification? Absolutely! And any insight you have into how we could make this automatic would be really appreciated. I don't want to be up at the wee hours of the night pressing "send, send, send!" > I think it goes beyond that. What language are you going to send to USA > customers -- English? Latin American Spanish? Etc. The plan was english--but if we can, it would be preferable to check the user's language preferences (as you mentioned). > Additionally, are you wanting to leverage Mozilla's existing localizer > network? That was the plan! --- All this brought to mind another important component of this new feature that we need to have: the ability to stop and restart message campaigns, just in case we need to.

(In reply to Sam Mott from comment #12) > With that in mind, 12 hours would be an appropriate time-frame for > sending/receiving messages. I'm open to extending this time-frame to 24 > hours. Gotcha. > This is one of the most annoying parts of building a messaging system--how > do we prevent (to the greatest extent possible) messaging people when they > are asleep. The US isn't too difficult to handle: message sends can be > initiated early enough in the day that no messages are sent past, say, 8PM > PST. It become tricky when you need to account for users abroad. In these > cases, targeting messages by regions usually is enough. > > Do you have any ideas about how we could address these time-zone issues? By letting go of the idea of "message sends". The fact that a client has to somehow obtain whatever you want to show is orthogonal to the scheduling problem. Ideally you would specify "show this the day before the contest ends", and the client will have fetched the message by then, and be able to decide when to display it. If you use an active push system, you're essentially wiring up a button directly to an Intent in the user's application, and you have to use a great deal of judgment in deciding when to send. GCM is fine for an iMessage clone, but not for marketing broadcasts. (Exercising this judgment requires a lot of information, which is why I don't consider GCM to be a viable option. There's no way in hell we should have a database containing the release, OS, architecture, language, *current position*, and broad-stroke usage patterns of millions of uniquely-identified users, but that's exactly what we'd need to do this with GCM.) > My plan was to schedule the message sending based on region. For instance, a > new years message targeted at the US would be sent on December 31st at AM > while a message target at Japan would need to be sent on December 30th. Again, you're conflating message live-time with send-time. If we decouple those two things, you create campaigns for those two locales with appropriate lifecycles, and allow the client the leeway. > Absolutely! And any insight you have into how we could make this automatic > would be really appreciated. I don't want to be up at the wee hours of the > night pressing "send, send, send!" ... > The plan was english--but if we can, it would be preferable to check the > user's language preferences (as you mentioned). ... > That was the plan! ... > All this brought to mind another important component of this new feature > that we need to have: the ability to stop and restart message campaigns, > just in case we need to. OK, so not push notifications, then :D This is good. All of your requirements are aligning on the design I'm implementing, so that's fortunate :)

Ongoing work: https://github.com/mozilla-services/android-sync/pull/254 Server-side work is yet to be resourced or scheduled.

This is a hook to let our service start when Fennec starts, because that's the first intent we'll get. Sketched out, but might as well put it somewhere.

I cleaned up the feature page. https://wiki.mozilla.org/Features/Fennec/Android_Snippets

I'm happy with how this is shaping up. One thing I'd like to clarify: In the mock-up that mconnor had included, it got me thinking: if we want to target users that have not been actively using Fennec and have likely not updated to the latest release, we want to capture all of those users on X release and older. We will need to make the tool more explicit about how to manage that versus just targeting users on a specific release. I am also going to make the assumption that we can capture all of the parameters we sent out with the message when we're analysing the incoming data, i.e. ensuring we capture release version, time, etc etc so we can end up data mining later if we haven't thought through all of the metrics tool development yet on this first go-round?

(In reply to Karen Rudnitski from comment #17) > I am also going to make the assumption that we can capture all of the > parameters we sent out with the message when we're analysing the incoming > data, i.e. ensuring we capture release version, time, etc etc so we can end > up data mining later if we haven't thought through all of the metrics tool > development yet on this first go-round? Any time we "capture" data, we need to get a privacy/security review. We already collect a lot of data with the blocklist ping. What other data do we need from this service?

My point is that for this to be a useful tool, we'll need to know what messages are being responded to and whether our tactics are working or not. For instance, if we send a note out to folks to encourage them to upgrade after they have been inactive and missed 4 releases, is that more or less effective than prompting users who have been inactive and missed 1 release. I also don't want to be bugging users too much by targeting those who have been inactive and have been targeted after 4 release cycles and again if they have missed an additional 1 (if we decide to increase our frequency). I can only imagine we'd need a way of ensuring we know and capture WHO we are hitting with WHAT, and that's what I'm trying to ensure is captured. The goal is to know how we're being most effective, while also striking a balance with not being overly annoying to the user.

I absolutely agree with Karen here. But what we'll record is going to be pretty far from PII, in that what I expect we'll record is: Version Channel Days since last used Platform Campaign ID for the snippet returned. I think there's a strong case to be made for only recording this info for clients that get a snippet back, not for every check-in, since the vast majority will be no-ops.

(In reply to Karen Rudnitski from comment #17) > In the mock-up that mconnor had included, it got me thinking: if we want to > target users that have not been actively using Fennec and have likely not > updated to the latest release, we want to capture all of those users on X > release and older. We will need to make the tool more explicit about how to > manage that versus just targeting users on a specific release. My expectation is that we'll allow targeting 1-N different values for a given snippet/campaign. I just couldn't force Visio to show multi-select! That said, we can make it pretty obvious (i.e. text saying "Ctrl+click to select multiple values") if people aren't figuring it out themselves.

(In reply to Mike Connor [:mconnor] from comment #21) > That said, we can make it pretty obvious (i.e. text saying "Ctrl+click to > select multiple values") if people aren't figuring it out themselves. Please make it obvious :). I expect new faces to be using the tool and we want to make it as intuitive as we can to avoid user errors.

Dropbox doesn't like renaming of folders. Bah. Uploading the original stuff, will post updated versions rsn.

Let's morph this into a meta bug. I'll file a separate bug for the backend service, front-end opt-in and settings, and we'll file a bunch for the server, too.

Comment on attachment 660265 [details] [diff] [review] Broadcast intent on Fennec start. v1 Moving this to the client implementation bug.