914757 - Optimizations to the Firefox for Android Product Announcements Campaign Admin Panel

Status: UNCONFIRMED

(Cloud Services :: Server: Product Announcements Campaign Manager, defect)

Description

[Jesse Montano]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

I recently did the first deployment to 5 versions and 8 localizations. So I was able to use the panel several days and times and have some recommendations for optimizations I have outlined below.
I have also put them in this Google doc: https://docs.google.com/document/d/1CrbZNo28XNrJaupViA7BDOPEreVk7pePhaXIhr-D6YQ/edit?usp=sharing



Expected results:

1) Campaign name changes to Campaign Identifier. Then make each deployment be labeled by the Campaign Identifier + any parameters deployed with. For example:
Campaign Identifier: FFA Beta Bump to 24 
Deployed to: Indonesian, Beta, V22
Label for that deployment’s report would be: FFA Beta Bump to 24+ID/Indonesian + Beta + 22

2) Idle time should change to have parameters. ie. Idle from 0 to 10 days.
3) Body should be bumped up right under title. It’s character limit should be 51.
4) Click through URL: It would be great if we had 3 choices:
release build: market://details?id=org.mozilla.firefox
beta build: market://details?id=org.mozilla.firefox_beta
Other: with a write in field
5) Languages: Indonesian is repeated. I always blasted to the first one in case they are different sets.
6) Version: it would be great if these can be checkboxes so we could pick more than one version at a time.
7) Reporting: Would be great if we can bump up the served and touched number to the top row (versus being in the row underneath) and giving them each their own column. I would also add the Click Thru rate. This makes exporting it and reporting MUCH easier.
So it would look like this: 3 new columns: Served, Touched, CTR (touched/served*100) - if I could be picky, I would have this before author and after platforms.

Nice to have’s
8) Exporting reports: It would be great if we can export reports to an XLS, but if we do the change above (#6) I can live with copy pasting. This would also be useful since you will have to pull the report several times as more people click as time goes by.
9) For Body and Title, it would be great if the write in field can remember your previous 10 write in’s so you don’t have to go back and copy paste from wherever the doc is. 
10) It would be awesome to record certain add Title+Body combinations that you can pull and use/edit as needed into the panel.
11) It would be great if you can copy an old deployment and use it as a basis of a new blast. Several ad serving platforms use this as a nifty feature.

Comment 1

[Jesse Montano]

Hey guys,

Has this been assigned? Wanted to get updates on what you think the foreseeable timeline is for this and if you have any questions.

JM

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

There are a number of feature requests here and I've begun working on a few. In some cases, the requested feature is minor (clarify which of the Indonesian or other multi-code language a code refers to) and easily done. Others are significantly more difficult (e.g. idle time windows which will impact a significant portion of both the selector code and the caching layer.)

Rating the features from easiest to most complicated, I'd offer:

* Body moved and limited.
* Language codes clarified
* Fix reporting data
* Click thru URL templating
* Campaign name to Campaign Identifier
* Idle time windows
* Multiple version

I'm also a bit confused about the 

As for the "Nice to haves"
* I can see what I can come up with for CSV exporting.
* I know that Firefox tends to remember previous form values. Are you not seeing previous values if you double click on a field?
* I might be able to use something like local storage to provide a personal catalog of titles and bodies, but that would obviously require work to include management, cataloging and editing.

I'm also a bit concerned about how Campaign Manager is being seen. As I understood it, this was supposed to be a tool that would not be used heavily. For instance a campaign might inform users that unusual action might be required, or encourage users that have not updated in several weeks to do so, or similar functions. I was told that there might be at most 20 campaigns running at a time. Granted, with the fact that campaigns must be targeted toward platform, versions, languages, locations, and other elements, this may mean 100, but that's still reasonable.

I would be very concerned if there were thousands of campaigns or if we started to send more than one campaign to a given user within a month. (This might happen if we have one campaign that is targeted toward the users of Nightly and another that targets users that have not used their device in 3 days, and yet another that targets US users.) Such an event might cause users to get annoyed and either turn off the feature or simply remove firefox.

Comment 3

[Richard Newman [:rnewman]]

I think it's worth me following up on JR's comment: the client and protocol, too, aren't designed to have more than one applicable campaign at a time (which realistically means a hard limit of one campaign that might match a particular device in, say, a week).

As dslater put it, "a powerful tool like this will be used sparingly".

If you're talking about re-running announcements, you're going to hit (and annoy) the same users multiple times. If you're thinking about having variable idle intervals, you're probably misunderstanding what that parameter means and how the protocol avoids duplicate fetches.

Neither is the user experience particularly suited for more than a few "advertisements" a year: the less urgent/security-related an announcement is, the more strongly we violate Google's Android interface guidelines, and the more we annoy users.

Product Announcements is a low-touch broadcast feature: it was designed and built to support a handful of non-nagging messages a year, with the specific use-case of encouraging users to upgrade from an old release, install a security update, or work around an issue.

If you want high-touch, A/B testing, multiple persistent ads, and the like, you would be better served by the nascent Dynamic Snippets work… or just Google Adsense.

If you have a strong non-advertising product need to re-run announcements and manage high-volume messaging, or have fine-grained control over recipients, then we need to revise the client, not just Campaign Manager.