This is the culmination of a process begun several months ago, and it was done in a rather interesting way — and, it should be noted, huge thank yous are due to Chris Appleton, Ross Bruniges, Andrew Hayward, & Matt Patterson for designing, coding, and, you know, actually building it.

The frst thing that’s worth noticing is that it’s pretty freaking beautiful. I mean, check out those event guides!

But it’s also got some neat functionality in there (as well as some features we’re looking to add in the future).

Some of it is pretty close to the off-the-shelf Blue State Digital events module, with some tweaks like extra opt-in/privacy policy checkboxes. To see that path, choose the left-hand column on this page, or see a sample event like so.

What’s really interesting — and potentially very useful to other groups on BSD — is the open, custom app built on top of BSD. We wanted to figure out a way to provide a true big tent, and part of that means not requiring that you create your event on our platform.

So we (well, Team Ross) built an app that also allows you to add an external event — anything with an external URL — but still have it listed on our map & calendar.

To do that, simply choose the right-hand option on the create event page, log in/create an account with browserID/persona (Mozilla’s awesome new identity service), and you’re on your way.

There are some functions that just aren’t supported too well in BSD (ticketing & attendee categorization, to name two), and this feature allows organizers to use another service if it’s better for them, while still getting the benefits of being a part of Mozilla Webmaker. And, of course, that’s not to mention events that already existed, to prevent organizers from having to manage separate RSVP streams.

So, what do you think? Does it make you want to organize a summer code party on June 23rd?

Please take the tools for a spin — if you see any bugs, we welcome reports on Lighthouse, or if you’re adventuresome and want to fork the code (or submit a patch), it’s on Github here.

• Total Q1 numbers
• T-shirt campaign results from February & March
  • February Email Test results
  • FF Channel Promotion Results
• What’s next?
  • Summer campaign
  • Monthly donor program
  • Moz Fest Contest

Total Q1 Numbers

Q1 was a very promising start to 2012 for us. We closed out the quarter having raised just over $200,000, at $204,000, from 7,424 donors. Awesomely, 6,755 of those donors gave for the first time!

And we closed out the quarter with an email list of ~310,000 subscribers (we’re at ~315,000 today).

Month by month, here’s what we saw:

March: $87k from 2,667 donors (2,519 first time)

Feb: $48k from 1,792 donors (1,357 first time)

Jan: $69k from 3,131 donors (2,880 first time)

I don’t expect to hit the same pace in Q2 — the January numbers featured some carry-over from our end-of-year campaign, the February numbers were helped by a direct fundraising appeal over email, and the March numbers were helped by having a strong presence in Firefox channels (about which more later). That said, this is a really promising pace, far exceeding anything we’ve seen before except for December of last year.

T-shirt campaign results

Our recent t-shirt campaign had two principal stages — February’s direct emails to the Join list, and March’s presence in Firefox channels. I’ll describe both, and then embed the stats for all.

Direct appeals

We sent two appeals to the list — an initial one from Mark, and a follow-up from me. For Mark’s, we did a test of a one-time ask (donate $30 or more and we’ll send you a t-shirt) vs. a monthly ask (make a monthly donation of $5 or more and we’ll send you a t-shirt).

The results were very inconclusive — the one-time test raised just less than 10x as much as the monthly test (which would lead to the monthly segment being better, since a 12-month average retention would be a conservative projection). However, the monthly segment had much higher unsubscribes, and it also had a much higher open rate (and, therefore, click rate). While the latter would normally be a good thing, in this case I concluded that it was inflating the relative performance of the monthly segment, since the messages had identical subject lines and headers (so there was no reason why open rates should differ). We decided to send the one-time ask to the full list, through it could have gone either way.

The second appeal was just a quick note from me on top of Mark email. Overall, using 12-month projections from the monthly gifts, email 1 raised $15,201, and email 2 raised $11,763.

Firefox channel promotion

Over the course of March, we were heavily in channel on the Firefox home page snippet, and we were also placed in the Firefox e-newsletter, and on Firefox twitter & Facebook. Here’s the Facebook post. Who is that handsome model they got?

The snippet was by far the most lucrative channel of the four, though results from all were actually very good.

Snippet: $53,405.56
E-newsletter: $9,082.27
FF Facebook: $1,643.00
FF Twitter: $1,131.41

Here are the full stats from the campaign:

What’s next?

There are three different pushes in the next few months that we’re thinking about (to take us into the Fall). They are:

Summer campaign

In concert with our Mozilla Summer Code Party, we’ll be doing some fundraising integrated with our other communications. That will most likely take the form of a fallback ask (eg: Can’t host a summer code party? Please think about making a donation to help us make this campaign as awesome as it can be), but it will definitely be very present.

Monthly donor program launch

One of the flaws we were guilty of in the monthly appeal we did around the t-shirts is that we didn’t make a real case about why giving monthly is important — steady stream of income, long-term stability, etc. So at some point in the next several months we’re going to try to make that case in as straightforward and compelling a way as possible.

Moz Fest Contest

Taking a page from the presidential campaigns, I want to run a “win a trip to the Mozilla Festival” campaign. You could enter without donating, but it will be primarily pitched for fundraising. Hopefully a trip to London for three days of awesomeness will be enticing!

As always, any thoughts/questions/concerns are more than welcomed in the comments!

Some great thoughts came out of it that I don’t think we’ve touched on yet. Specifically, we came up with a set of questions that need to be answered and thought through as we’re getting this off the ground (along with an assortment of other thoughts, which I’ll get to at the end). Some of the bigger questions are:

Who are we asking to lead?

There are two main potential structures for our kitchen table events — peer-led or parent/guardian-led — and the way to promote and talk about those is pretty different. We need to do both, but it means that we’ll need to tailor our messaging to the medium, and not just assume a one-size-fits-all approach will work.

What’s our support structure?

No matter how we do this, event hosts & participants will have questions that cannot be answered by how-to guides & FAQs alone. Are we getting a group of super-vols, poised to answer questions in realtime during the day of action? Or something else? Either way, we need to be ready.

What’s our follow-up ask?

In the classic house meeting model, hosts of one meeting try to get attendees of their meeting to then go off and host their own. But, that’s not really what we’re after, here — it seems like what we really want is for people to, based on their original events, essentially form those groups into “teams” of sorts, who will continue working together through the summer (or longer).

What’s the goal of the event? Or, more precisely, how do we accommodate different goals?

This has a few different parts. First, there’s the basic idea that there are a few different reasons why you might want to have friends/your child’s friends over hack & learn some webmaking (or, different goals you have coming in).

One is the idea of getting together to have fun, with the specific thing you’re making being somewhat incidental — this could use one of the Hackasurus missions, for example.

But another is where the goal is to address a specific problem — maybe it’s a group of 15-year-olds who started a band and want to make a website, or maybe a few friends who want to do something to help out in their town — and where the goal really is to make a very specific thing.

Now, both of these are models we definitely want to support, but there would probably be differences in how they would be structured and how they’d be pitched so the people who have a problem they want to solve recognize they could do it through one of our events.

And, finally, since what we’re really trying to teach is a tool or language to get you somewhere else, we need to create ways for affinity groups to join up, who want to use these events for their own purposes (so, not just appealing to webby groups, but to groups who could benefit by doing something webby).

A couple other thoughts

One key insight is really that the promotion we’re doing (at least for the kickoff of the summer campaign) is almost purely about hosting, rather than attending. The informal nature of the events is such that we aren’t asking people to have strangers into their homes, but rather to create the event they want, with whoever they want to be there. That definitely changes how we should talk about the events and build the campaign — in part, at least, in that we shouldn’t start small by just asking some select group to host, but also in other, still to be discovered, ways.

Another really interesting idea (which it’s likely too late for this year, but summer 2013?) is if we could be developing a fellows program, essentially a service-learning program for CS majors, to be able to help teach kids to code for their summer, in exchange for some sort of credit. Might be unworkable for any number of reasons, but could be a neat idea to explore.

And we also talked about how much of an asset partnerships will be, both within Mozilla and outside of our community. I’m particularly hopeful that ReMo could be an enormous help with something like this — time to get talking!

Finally, as a side note, people seem to like the Kitchen Table branding for our low-bar events. So, perhaps the naming there was not so temporary…

Picking a bunch more brains next week — looking forward to where this goes.

• Figuring out what our basic, public-facing event offerings would be
• Getting a “go to market” plan on an infrastructure that we’re satisfied will actually allow people to self-organize and affiliate within our learning tent

The first has already been ably treated by Michelle Levesque over here — I’ll let her tell you:

We identified a large number of event-types that we have experience with, and then narrowed it down to a set of three event types that we wanted to surface front-and-center.

These were:

1. Kitchen Table (official name pending ). This is for parents who want to grab their daughter and 3 of their daughter’s friends. Or a 17-year-old who just wants to show some of her friends how to do something cool. Like all Mozilla events, the purpose of this is still to learn by making, but this is a relatively low-bar event: grab some people you already know, and gather together to play with building some stuff on the web. We’re going to package some example curriculum with this event, but this can really be about anything when it comes to webmaking.

2. Hackjam. A group of people (who you might not already know) gather together in a public space to learn and build things together. This is probably what most people think of when they think of maker-style events.

3. Pop-up. Sort of like a science fair. Bring local groups together to and invite people to come play and make with technology. Expose people to what local organizations are offering around webmaking, and sort of sample a lot of different things.

And for the second, we’ve mapped out basic user stories and the feature sets we’ll need to support them (looks a lot like those initially specked out here and here) — and through some awesome Jess Klein design magic, we’ve got some mockups for two pages: the basic /events page where you can find out about our basic offerings and plug in to any use case you want, and the event search page. Both have a pretty awesome look and feel that stands apart from anything I can recall seeing — I’m very excited to see them in action.

Here’s the main page mockup:

And here’s the event search mockup:

So how are we getting there? Well, one big question — the platform we’re planning to use — has been resolved for now.

It turns out that Blue State Digital — which we already use for much of our online organizing — is actually much more localizable than we’d thought. While there are definitely some features we’d like which are not supported — most notably a real ability for event organizers to run effective campaigns/efforts of their own through our tools over the long run, as opposed to simply doing one-off events –  it gets us far closer to all of our needed features than anything else that’s possible within a reasonable timeline.

So, that leaves us with what we want to build. Our goal is to launch by May 1st (in time to launch with enough time to have our day of Action in June while still providing enough lead time to hosts) with a site that supports the following uses/flows:

• Agenda & Curriculum design can either happen at “learn about event types” stage or after publishing
• Desired additional feature: duplicate past events & address all previous attendees of your events at once

We’re having an “event sprint” this week, and, yesterday morning, we had a great session to start really planning what this could look like. Leaving branding and timeline aside, we concentrated on:

• What would the actual events look like

• Why would potential particicpants want to actually do so

• How do we report back out of the events/day

• What’s the followup/What do the next events look like?

• What are some actual user stories, and are they taken care of in our framework?

So, here’s what we’re thinking! Really eager to get feedback and other thoughts — this is the first thing like this that we’re trying, so we really want to get it right

The Actual Events:

To start with, we want to organize all of these around a single day of action — essentially “youth of the world making cool shit on [DAY TBD].” This will allow us to plant a flag to bring people in and provide a specific moment to organize around. There would be followup and strong pushes into more than one event, but organizing around a kickoff/launch day will help make this as big as possible.

Beyond that, we want to concentrate on remixing — the idea that the best way to get kids interested is to leverage something they’re already passionate about (baseball, lady gaga, whatever), and let them make something awesome based on it.

So whether it’s a parent with their daughter and 2 of her friends, or a 15-year-old geek who wants to get a few of her friends on board, this would lead to cool stuff being produced in a single day, which will (hopefully!) inspire learners to continue pushing forward.

In terms of the actual learning curriculum…that’s still a bit tbd. There are some great projects and tools on our end already in existence or planned for the next few months, and we’d also want to make sure that folks feel free to plug in some of the other great offerings out there.

Why would participants participate?:

This is a pretty important question to make sure we’ve answered very solidly — we need to weave it into everything we put out as part of this effort. Luckily, we’ve got some ideas.

From the perspective of a parent, it’s something for you to do with your kids that’s both fun and educational — in the process of making something awesome, they’ll start to learn webmaking!

And for the kid participating (or leading a group of friends), you’ll be:

• Making something awesome to share, remix, and remake

• A part of something much bigger than yourself; with many events happening around the world, you’ll be able to see what others are producing, at the same time, so you can be building on and hacking what others are doing while they do the same to what you make

• Earning badges for participating/teaching

Report back:

Telling the story of all these events — before, during, and after — will be crucial for keeping the excitement, making, and learning going after. At a minimum, we’ll want to make sure we put together galleries where people can share what they make and remix what others have done.

We’ll want to encourage sharing on social networks — hashtag for the day on twitter, etc. — and should come up with ways to aggregate that content.

And, hopefully, we’ll be able to get some great press coverage to showcase what’s happening.

What’s the followup/What comes next?

There’s a real tension between the desire to get as many people in the door as possible versus the desire to make sure that participants keep on making and learning after the day — if all they do is get a taste without going further, we won’t be succeeding.

But the answer isn’t either/or. We can welcome people to one event at a time — we want them to come and have fun, because that’s what’ll make future events attractive — while consistently pushing the idea that you aren’t finished if you just do one thing.

We can incentivize future learning/events through badges and tangible gains from continuing on, and, most importantly, we can make sure people want to come back by making sure the events are *fun*.The specific asks/phrasing obviously remain tbd, but we’re definitely aware of and actively want to work through the tension in both goals.

User stories:

So, we’ve come up with three different sets of user stories for both learners and instructors (participants & hosts). I think there’s something here for each of them…is there? The biggest hole I see is for our instructor “Rose” who needs to do some learning herself before she could really instruct…but that just means we need a solid “train the trainers” to happen beforehand.

Instructors:

• A father, Mark; 42 yo; self-proclaimed techie; 2 kids; wants kids to learn to hack; has passion around Open Web

• Omar; 15 yo; a geek, who tweets and is on  FB; belongs to a youth org; has some understanding of html & css

• Rose; 60 yo; retired; on social networks & computer literate; has played with wyswygs; has kids & grandkids

Learners:

• Jackson; 14 yo; home-schooled; likes video-making; zero knowledge of code; close to parents; reads lots of fiction

• Mary; 13 yo; goes to sleep-away camp; plays soccer; knows no code

• Zainab; 15 yo; likes computers, is on FB/Twitter; loves fashion; doesn’t code but loves making her mark on the web; has summer internship

Timeline:

So there are a lot of ducks to get in a row before this can actually happen — and the timeline needs to work back from there. Here’s the task list  see ahead. What’s missing?

• Curriculum development
• Partner development (orgs who’d want to join us)
• Platform for people to create and promote their events <–link to my post
• Easy guide for how to hold a successful event
• Branding for the day/summer
• Gallery for people to share what they’ve made
• Badges for the day/summer
• Followup event development
• More to come…

It’s evolved a bit since then — both in terms of what’s actually at Lovebomb.me and in terms of some additional mockups that Jess put together for what it could become.

But while it’s already on the right track, what we want to do is further evolve it, into something a bit more polished and broadly approachable, which could satisfy the following three objectives — and launch for Mother’s Day:

1) Provide an approachable, fun onramp into our learning offerings
2) Teach a little bit (and possibly more) of code, without being too scary for a non-coder
3) Grow our base of supporters

Michelle Levesque and I did some brainstorming this week, and here’s what we started to come up with on where it should go from here. A basic framework (along with plenty of outstanding questions) is below — whattaya think?

–  Take Jess’s “<3 Generator” mockup as the starting point. (Concept #2 in this post.)

– Have a few more initial templates the user could choose from (some themed around Mother’s Day, for launch)

– Have the main creation go as follows:

1. Allow the user to click on elements of the card to change them (as in the mockup). This would allow the user to edit without actually directly altering code, but would show the code surrounding the element. Ideally, this would also include Atul’s positioning add-on to allow people to easily move elements around on the page.
2. Have the right-hand 1/3 of the page show the lovebomb’s code as it stands (updating as elements are edited as in step 1)
3. Have key page elements highlighted in the code (colors & fonts, in particular), so a user could click on the highlighted piece of code and choose from a drop-down menu of options and see the love bomb updated immediately.

– The code editor should be easily hidden, and we should be able to govern based on a URL parameter whether or not it’s initially visible by default. This would allow us to tailor the initial “cody-ness” of a user’s experience, so that those coming in through less technical channels (e.g. a tweet from @Firefox or the FF & You newsletter) can still have something that’s approachable.

– Once published, we should provide the current menu of options to publish, as well, hopefully, as a direct “email this lovebomb” ask that then allows us to have an email signup checkbox (this could be integrated with a BSD share form or something?).

– We should add a persistent email signup as a footer, like in some of Jess’s other mockups.

– And we should create a directory/gallery of people’s lovebomb’s, so that others can see what’s been done and build off of it.

Some outstanding things to think through:

– What code, precisely, do we display around each element when someone clicks to edit? Is it too imposing if we expose the text as well as the html and css that govern the element?, since the css is what contains that actual words that people will see (colors, underline, etc). Perhaps we could make it so that when you hover over any bit of the css, there’ll be an explanation of what it is? Or we could build in dropdowns/menus to allow you to change the formatting without changing the code, but that then show you the resulting change in the code?

– What are we actually calling this? We don’t want “Lovebomb” to be what this goes broadly with, but it’s not like it’s an card maker, either. Any thoughts, internet?

– How well can we integrate email signup as an action, so that we’re able to keep users engaged and move them further along in learning after they make their love bomb? Anything we’re missing besides figuring out an integration at the end and having it as a persistent footer?

2012 online donations to Mozilla: 3,723
2012 online revenue: $78,657.80
Current @Mozilla followers: 4,880
Current email subscribers: 292,263

These are pretty great numbers. We don’t expect them to hold at this clip on their own, but it’s a very promising start to the year.

So, what’s next? Well, we’ve got a few things on the docket:

• Next week, we’ll be launching a new push for the Firefox/I support Mozilla t-shirts we have. We’ll be testing two different asks: “Donate $30 or more and get a t-shirt” vs. “Make a monthly donation of $5 or more and get a t-shirt“. We’ll be emailing the Join list about this campaign a couple of times, and we’re also planning to be in social media, email, and snippet channels on the Firefox side next month.
• Either this month or next, we’ll be launching a monthly webmakers newsletter, to spread the word about the awesome progress that’s being made with and connected to Mozilla projects
• Next month, we’re planning an engagement campaign around our Hackasaurus project, to get people a bit more familiar with it.
• We’re working on figuring out ways to onboard people into our learning initiatives in fun, low-bar ways, while still imparting a bit of coding goodness. The Hackasaurus team has created an early version of something called the “love bomb” maker, which we’re working to build up into something that we can push more widely later in the year (and which will likely not be called the “love bomb” upon actual launch . Matt Thompson wrote up a great post on the Love Bomb — just in time for Valentine’s Day — here.
• And the other big thing that we’re all monitoring is ACTA. Mitchell Baker blogged on it this morning, and we’ll definitely be keeping our eyes peeled as the debate moves forward with ways for us to constructively and meaningfully engage.

Mozilla Japan Scratch/Hackasaurus Pop up. Photo from Mark Surman

Michelle Thorne has already done a bunch of thinking about how this maps across our events — her event menu is here — and I’m trying to think about what type of infrastructure we’ll need to set up to get people to organize these types of things on their own (with our support, or course).

There are some pretty clear functionalities that are needed, which Michelle has laid out elsewhere, beyond simple event creation & categorization — localization, data portability & access, good developer APIs, participant email capture, and more.

In addition to those, there are a couple that seem necessary to me to be reasonably effective:

–Ability for event organizers to organize over time: This means an ability to create an event (on one or many days or several events in a series) and have the ability to directly communicate, over time (so both before and after the event) with the people who sign up to take part.

Most tools — even those with something like this — seem to lack either the ability to communicate with attendees at all, or, even if they have that, lack the ability to do so over time and across events. Example: I want to start a weekly meetup. Within the Mozilla event infrastructure, I should be able to create an event once and set it to happen every week at Time X. I should be able to change the event time of a given week. People should be able to sign up for one/all/some of those events. And I should be able to communicate with all the attendees (who have opted in to communications, of course) both before and after the events.

–Groups: Part of this whole thing needs to be people easily finding and joining groups of people they’d want to talk to — that could be based on geography, ability, program, interest, whatever. These should be easy to search for, find, and join, and allow people to discuss things and move forward in their own way. This could be anything from glorified listservs to something more Facebook-y, but it’s definitely important for fostering an engaged core of people doing this stuff.

Now, there are examples of organizations doing things like this — or at least setting up infrastructure close to it — quite successfully. From Rebuild the Dream to Code Year to Tedx and a whole lot more, they’re out there, but generally there’s something making each not quite what we need, or not quite what would work in this context.

So the questions are as follows:

1) Is the description of needed functionality above correct? Are there gaping holes, or things that aren’t necessary?
2) How should we create that infrastructure?

There are platforms out there which meet some, but not all, needs. There’s Meetup Everywhere, but what’s really needed is a combo of Meetup Everywhere with the richer functionality you can have as an individual user of Meetup. 350.org is building its own tool in the open, which could potentially be forked for our needs — https://github.com/350org/localpower. There are tools that don’t yet exist (ex: http://www.controlshiftlabs.com/) and then there’s the better known tools from BSD to Action Kit to EventBrite to Lanyrd and more. BSD is what we use for other things, but their event tool unfortunately wouldn’t localize too well. Otherwise it would have almost everything else.

So, what say you, techies, organizers, people who care? Please chime in with thoughts on any of this — or thoughts on anyone else I should try and talk with — in comments. Thanks!

Also, many thanks to, among others, Jim Pugh & Nathan Woodhull for recent discussions that have helped crystallize my thinking enough to get to where I currently find it.

The biggest piece of the EOY campaign was the animated video we put together which can be seen at http://mozilla.org/story. The numbers discussed below all refer to pushes to that page, though about $40k in additional donations came in through the Join page, the t-shirt campaign, and others.

Along the way, there were pushes from all major Firefox channels, along with frequent promotions to our own base of supporters.

For us, the biggest takeaway from the results of this campaign is that when we’re in channel with a chance to tell our story in an understandable way, we can be successful – even with a not-yet-initiated audience.

However, we also saw that the more space & time we had to tell that story, the more successful we were: our own emails, which featured a multi-part arc, were the most successful channel in terms of dollars raised per impression, followed by the FF email list, with the snippet and social media behind. Interestingly, the snippet was far more successful overall than social media, which does track with the results most organizations see when trying to fundraise directly on Facebook and Twitter. While social media can be an effective tool for many things, fundraising effectively on it remains a not-yet-perfected art.

Going a step further, here’s what’s contained in this report:

• Top-line results by communication channel
• Some of the takeaways from the different tests we ran
• Breakdown of more in-depth results for email & snippet communication channels

Channel-by-channel results

Testing

Due to the sample sizes and other constraints in different channels, the only ones in which we were able to conduct true A/B tests were the about:home snippet and the FF & You newsletter.

Snippet tests

The following snippets were tested against each other at one point or another:

Test 1

Snippet A: Watch <link>The Mozilla Story</link> to see how we’re shaping the Web and <link>how you can help!</link>

Snippet B: Watch <link>The Mozilla Story</link> and help us keep the Web a constantly evolving source for innovation.

Results: Snippet B had fewer clicks through to the video, but a statistically significantly greater number of donations.

Takeaways: Nothing too concrete here, except the wording of the second ask provides a bit more meat on what the user will be doing – helping us keep the web a constantly evolving source for innovation rather than just “how they can help” shape the web.

Test 2

Snippet B: Watch <link>The Mozilla Story</link> and help us keep the Web a constantly evolving source for innovation.

Snippet C: Help Mozilla keep the Web a place where anyone can dream, discover and create. <link>Make a donation by Dec. 31st.</link>

Snippet D: See how Mozilla is keeping the Web a force for good in the world — <link>and help us keep it up by making a year-end donation today!</link>

Results: We expected Snippets C & D to outperform B due the direct nature of the ask; the expected result would be fewer clicks on C & D, but more donations from them. That result held with C – it had ~1/4 the clicks of B, but twice the donations. However, D generated about the same number of clicks as C, but fewer donations than B.

Takeaways: Here, there are two factors that could lead C to outperform D – one is the specific date as the deadline, which makes it a bit more tangible, and the other is the “dream, discover and create” language, as compared to the “force for good in the world” wording. Helpfully, this matches precisely with where the Foundation is heading in the coming year.

Test 3

Snippet B: Watch <link>The Mozilla Story</link> and help us keep the Web a constantly evolving source for innovation.

Snippet F: Know the Mozilla story? How we’re a non-profit that puts you first? <link>Watch this quick video to learn more.</link>

Results: Snippet B significantly outperformed Snippet F on both clicks and donations.

Takeways: The difference was likely because there was a bit more substance to B, instead of just questions.

Test 4

Snippet C: Help Mozilla keep the Web a place where anyone can dream, discover and create. <link>Make a donation by Dec. 31st.</link>

Snippet E: Mozilla is a non-profit dedicated to keeping the Web awesome. <link>Help us make it happen. Donate today.</link>

Results: These snippets were roughly equal in their clicks generated, but C generated about 1.5X the number of donations as E.

Takeaways: Hard to draw any specific conclusions, other than the “dream, discover and create” language continuing to resonate.

Firefox email test

In this send, we were able to test three subject lines against each other. They were:

1. The force behind Firefox
2. Thank you for all you do
3. Help Mozilla protect the web

Results: “The force behind Firefox” vastly outperformed the other two (fewer unsubscribes, 50% more donations), and “Thank you for all you do” did slightly better than “Help Mozilla protect the web.”

Takeaways: For this audience, tying the ask back to their reference point – Firefox – was absolutely crucial.

Conclusions

It’s hard to draw too many conclusions from these tests, but the few that seem sound are:

• Providing a more tangible ask is better than trying to be mysterious
• If using a deadline, provide the specific date, even if it’s a common day
• The specific wording of the web as a place where people can “dream, discover and create” resonated more than the wording of the web as a “force for good in the world”
• With the Firefox audience, it’s important to tie the ask back to their reference point as much as possible

Fuller Results

Here’s a more in-depth breakdown of results from email and snippets, followed by a bit of summary of each one. A few metrics to define at the top:

• Clicks: Number of clicks on the main link
• Click %: Number of clicks / Number of recipients
• Response %: Number of donations / Number of recipients
• Unsubs: Number of recipients who unsubscribed in response to the email
• Donations / Unsubs: The ratio of donations to unsubs in response to an email. This can be a crucial monitoring metric to gauge relative success of an email. As a rule of thumb, a donations/unsubs rate of 1:2 for non-donors is good, and of 2:1 for donors is good.
• Conversion %: Clicks through to the page / number of donations

Firefox email

By far the most valuable channel for this campaign was the Firefox & You newsletter list. The EOY campaign & story video was promoted twice to this audience – in the December newsletter on 12/15, and in a standalone email from mark Surman on 12/28 (subject line tests) & 12/29 (main send).

Here are results from those sends:

The biggest takeaway for me from these results is that they were pretty great, especially for a non-donor/consumer-oriented list. They showed an appetite from this list to be told the story of what we at Mozilla are doing – and the story of how they’re doing something good just by using Firefox.

On the level of the most important metrics, the response rate and donation/unsubscribe ratio were both *very* good when compared with industry benchmarks to large lists of non-donors. I would have been very happy to see a response rate around 0.10% and a donation/unsub rate of 0.5. Instead, we saw a 0.15% response rate and a 0.8 donation/unsub rate!

The promotion in the December newsletter was less successful, as we’d expect when it’s put alongside a bunch of other content, with less space to tell a compelling story and make the case for giving – but it stands up fairly well to other results we’ve seen in that channel.

About:Home snippet

The homepage snippet was also tremendously important for the success of this campaign – including 100% snippet saturation in the final week of 2011.

Here are the results, split up by snippet and wave of rotation:

These were discussed a fair bit in the “testing” section above. A few things worth noting in addition:

• The low conversion rate is somewhat concerning, but it was much higher off of snippets with direct asks. This is in part a limitation of the medium – hard to tell a bit of story and make an ask in so little space — and partly a function of this being the first time a lot of folks were exposed to the idea of us as an organization that needs donor support.
• We certainly could have upped the total raised off of this channel by going with a “only direct ask” approach, but the strategy was also about long-term storytelling and cultivation, which was the reason for the large variety of approaches.
• Overall, the level of traffic that the snippet can drive is absolutely staggering. Working at Mozilla is awesome.

Join list emails

We sent four different emails to our own lists, with tailored content to folks who came in through SOPA (and actually only sent three to SOPA folks), and different ask amounts for donors and non-donors.

The first, on 12/8, had no direct asks – it discussed the story video along with some other things coming up (specifically the Ignite Project and the Learning, Freedom and the Web book.

The first direct fundraiser was on 12/21, with subsequent pushes on 12/26 (not to SOPA-only folks), and a final one on 12/31.

Here are the results:

We definitely saw the strongest results off of the first appeal, which isn’t too surprising. This audience had by far the best conversion rate of any major source of traffic, which I’d expect – every visitor who came through (except for the first email) did so from an explicit ask, made in long-form.

Overall, we definitely had the strongest “performance per impression” on this channel. That’s the main reason why it’s so important for us to continue building a strong list – it allows long-term narrative arc and a building story, rather than one-off touches.

Final Thoughts

Overall, we were thrilled with these results. In a single month, we raised more than we ever had before in a year. We shattered our goals for overall 2011 fundraising, and this is what did it.

Many thanks first, to everyone who donated to support our work! And tons of thanks to all the folks in User Engagement who helped promote this, and to the great people at Thought bubble, who produced the video.

Still reading? If you’ve any questions, thoughts, or concerns, please let me know in comments.

This fight is most definitely not over, but being put back on the shelf in an election year is a pretty darn good start.

So, congrats to everyone who worked tirelessly to make this happen, including tons of folks here at Mozilla and even more out there in the broader interwebz land.

Here’s the victory (for now) email we just sent out:

From: Me
Subject: You made it happen

Hi there,

Great news — this morning, Congressional leaders announced that votes on both the Stop Online Piracy Act and the PROTECT IP Act have been postponed!

Make no mistake — you made this happen.

This week, more than 13 million people spoke out against these disastrous pieces of legislation, and there is no doubt in anyone’s mind that it’s your protest and your action that made it happen.

To see some of the awesome numbers from Mozillians this week, check out this blog post, and you can see some internet-wide stats here.

There will be more that we need to do in the future on this — this fight is not over — but, for now: Thank You.

Ben

P.S. — We couldn’t do this without financial support from people like you. Can you chip in $5 or more so we’re prepared for whatever comes next?

–

Ben Simon
Join Mozilla Lead
Mozilla Foundation