When I’m working on a user acquisition project, I use Optmizely to A/B test the email capture landing page. I always create a custom event that triggers when the user successfully submits an email. Unfortunately, Optmizely doesn’t have a proper API which makes doing this difficult without redirecting to a new page.
First create a regex function to validate an email
Next, create a function that fires when the user clicks the submit button
Put the entered email into a variable
Write an if statement that uses our ValidEmail function to test if the email is valid
If the email is valid, send the event to Optimizely
In the last line we are calling our event ‘email_submit’. You can change this to any event name that you want.
All together it looks like this:
In Optimizely create a new custom event goal. Set “Custom Event to track” to email_submit.
Next week we’ll be releasing an app called Matchbook. Signup to be notified when it’s out. We’re a proponent of the lean startup methodology, so we wanted to share the process we used to get this app out the door.
We like to build software that mimics real life. The goal of software should be to make already occurring behavior easier, not to create new behavior. So, if you’ve ever taken a matchbook from a restaurant to remember it later, then you have an understanding of what this app does. Matchbook is a dead simple bookmarking application for places. When someone gives you a recommendation about a bar, restaurant, or shop you can bookmark it. The app will organize those places so you can make a fast decision about where to go out. We’ve heard it described as Delicious or Instapaper for places.
I called up a buddy I often discuss tech with and said, “Something is nagging me about the location based space. It doesn’t feel like mainstream America is quite ready for the check-in.” The question became, “What type of location based activities are normal people ready for?”
Mobile location research should be preformed in real locations, outside of the office. To answer our question we sought out feedback from normal people instead of from the tech industry.
To achieve this we planted ourselves at a bar, approached groups of people, told them we were about to build an app, and asked some questions. We also used the dating site HowAboutWe.com to go on dates so we had the undivided attention of a female for market research. No judgment; we paid for dinner. This turned out to be a great place to do market research because:
This is what we found:
We started wireframing the app in Omnigraffle. We spent most of our time removing features until we had what we thought might be the minimum viable product.We went back out to the bars and tested them. We rigged up a clickable prototype with a great app called Interface that allowed us to do our user testing. We would get a nights worth of feedback, re-do our wireframes, and then go back out. We iterated through this process about 30 times.
We kept going until:
When we began, we thought that Matchbook would be a social app. We envisioned it helping people make plans, share tips, or share bookmarked places. As we talked to more women, we found th
at they were a little burned out on social and a more then a little concerned about sharing their location. The number of women that perfectly articulated the
social circles problem was amazing. As a result, our wireframes pivoted away from social and became a personal app. We will probably add in social in the future, but we need to rethink exactly how that should work for this market.
The MVP is a bookmarking application for places. The user can:
Once we had our MVP, we moved onto the development phase. We outsourced the entire thing, which involved a good chunk of time spent iterating through developers instead of code. That will be the subject of another post, but in the end we found a great team. My co-founder and I developed the entire thing for about $10,000, paid for out of our savings.
A key problem with building an iPhone app is that Apple only allows 100 slots for beta testers. This was rough as we tried to test our assumptions. We needed to ASK all of our users to download it, which skews the data.
After some brainstorming we came up with an alternative. We are going to launch in the Canadian app store first. Since we can’t do a private beta, this will be our beta test. People in the US can’t see the Canadian app store so we will localize things there. We’ll use our Canadian launch to get feedback and gather metrics.
Once we’ve iterated based on that feedback we’ll launch a more polished product in the US app store. The idea is to couple the download traffic from launch PR, with the iTunes Recently Released app list. This concentration of downloads will hopefully bump us onto a Top Downloads list in our category.
These are the assumptions our lean process has yielded. We will be testing these in Canada next week:
We started with this step at the same time as Step 3. We decided that offering local deals is the best bet for monetizing a location based startup. Since we don’t have the money for a sales force we began our customer development process by speaking with group buying sites. We found out that they:
To better understand the group buying market, we offered to help out a NY based group buying site with their metrics. This gave us enormous insight into the types of challenges our customers face, and we learned great tactics for optimizing daily deal sales.
That’s it for now. The app will be out in Canada in a week, and out in the US shortly after.
Thank for reading,