cte

Does this work for marketplace payments?

From Groupon's S-1:

"To demonstrate the economics of our business model, we have compared the revenue and gross profit generated from the North American subscribers we acquired in the second quarter of 2010, which we refer to as our Q2 2010 cohort, to the online marketing expenses incurred to acquire such subscribers. The Q2 2010 cohort is illustrative of trends we have seen among our North American subscriber base. The Q2 2010 cohort included 3.7 million subscribers that we initially spent $18.0 million in online marketing to acquire in the second quarter of 2010. In that quarter, we generated $29.8 million in revenue and $12.8 million in gross profit from the sale of approximately 1.2 million Groupons to these subscribers. Through March 31, 2011, we generated an aggregate of $145.3 million in revenue and $61.7 million in gross profit from the sale of approximately 6.3 million Groupons to the Q2 2010 cohort. In summary, we spent $18.0 million in online marketing expense to acquire subscribers in the Q2 2010 cohort and generated $61.7 million in gross profit from this group of subscribers over four quarters."

They are seeing >3x profit on typical cohorts, so they decided to buy as many users as possible (which is smart).

Here's a piece of the S1 that I haven't yet seen cited:

"To demonstrate the economics of our business model, we have compared the revenue and gross profit generated from the North American subscribers we acquired in the second quarter of 2010, which we refer to as our Q2 2010 cohort, to the online marketing expenses incurred to acquire such subscribers. The Q2 2010 cohort is illustrative of trends we have seen among our North American subscriber base. The Q2 2010 cohort included 3.7 million subscribers that we initially spent $18.0 million in online marketing to acquire in the second quarter of 2010. In that quarter, we generated $29.8 million in revenue and $12.8 million in gross profit from the sale of approximately 1.2 million Groupons to these subscribers. Through March 31, 2011, we generated an aggregate of $145.3 million in revenue and $61.7 million in gross profit from the sale of approximately 6.3 million Groupons to the Q2 2010 cohort. In summary, we spent $18.0 million in online marketing expense to acquire subscribers in the Q2 2010 cohort and generated $61.7 million in gross profit from this group of subscribers over four quarters."

A typical cohort that returned >3x what it cost? Sounds like a good business to me.

blippy.com is hiring: Chief Security Officer, engineering, and product.

We're trying to free your purchase data to allow any developer (including us) to add value. Social commerce (as a space) is ripe to explode, and we are at forefront.

Some of our tools include ruby, rails, haml, memcached, mongodb, sphinx.

Backed by August Capital, CRV, Sequoia, Ron Conway, Evan Williams, and many other awesome angels.

Team: http://blippy.com/about

Funny pictures: http://blippy.com/jobs

Social software doesn't provide value unless your friends are using it.

What specifically is wrong w/ web2.0, consumerism, etc?

Clixpy is a decent clone of clicktale.com, userfly.com, and exactostats.com, but doesn't seem to have a "shtick" that differentiates it from the other offerings. With userfly.com, we tried to make everything dead simple, and much cheaper than clicktale. We also focus on capturing quality user sessions (lots of page views, lots of actions fired per page, bounced users don't count against your quota).

However, at the end of the day, watching individual user sessions, one after another, doesn't really scale; you need a way to aggregate the data to identify trends that may suggest pain points for the end user, and we haven't really cracked that nut (and neither have our competitors).

Out of curiosity, why the long wait before launch?

According to http://lsvp.wordpress.com/2008/09/02/facebook-selling-digita... facebook is selling digital gifts at a $35m run rate. A friend at fb tells me this number is significantly inflated though.

I would concentrate on a mobile strategy. It is probably very difficult to get anyone to placemark anything without some kind of mobile integration. Additionally, you might want to consider adding incentives for placemarking via gaming mechanics. Or perhaps ride the geocaching trend. There are a few iPhone apps that you can use for brainstorming (for instance, check out GoWalla).

Looks a lot like campaignmonitor.com.

Built something very similar and showed it to HN: http://news.ycombinator.net/item?id=362906

Its tough for a startup to attract big players to use their messaging platform or service because it is difficult to guarantee uptime, reliable service, etc. Might be perfect for mashups and hackers, but they won't pay.

Cool stuff though; I had a lot of fun playing with it.

for "micro-analytics", try http://userfly.com, http://clicktale.com, or http://crazyegg.com

We're still unsure of the cost to run this service as we scale up. We are looking for beta testers to try out our advanced features, so please email us, and we can get you a pro account for free, and start to iterate on the product to meet your specific needs (and lighter weight JS is definitely something we can fix for you).

Our pricing page sucks. Will fix asap. In the meantime.

Simple events = mouse movements, clicks, focus events, scrolling etc.

Advanced events = DOM mutation events triggered by ajax and other types of sophisticated javascript: http://en.wikipedia.org/wiki/DOM_Events

We will likely have to do customer specific fixes to get advanced event captures working well during our beta phase, which is why we want you to email us if you are at all interested.

I have a cold :(

Honestly, we haven't thought enough about our pricing; the cost will likely be proportional to the # of users you need to capture in a given period of time. For small sites I don't see us charging more than $10 a month. We are also playing around with the idea of licensing our software, so that companies can run the captures internally to enable ajax functionality, and keep their data private.

To answer your first question, we don't actively capture username/passwords. However, in order to follow a user into an authenticated site, we have to either setup some type of proxy (which requires some work on the client's side), or we do some simple cookie capturing (which requires no work on the client's side) to see what the user sees. Obviously, cookies might contain sensitive information, which is why we're offering this as an optional premium service only.

As for your second question, we can certainly setup the service such that it captures a certain percentage of users, and it's certainly a route we would consider depending on the size of the client.

Thanks for the feedback. Your idea about offering certain users a chance to take place in the study is dead on to what we think is the next logical step. Connecting an actual user with actionable contact information could help companies close the loop with an actual user, and interact with them in the same way they do in paid usability studies.

That's exactly right. One user per hour means a single session. And, that seems like a good candidate for the first FAQ :)

Thank you!

Please do! :)

As a developer, I can vouch for that :)

In fact, I ended up building this because I didn't want to pay for the other mobile services platforms (there are a few of them) when attempting to add mobile features to another project I'm experimenting with.

But to your original point, I absolutely agree, pitching this as a "mobile" "platform" for "widgets" is probably hopeless. Quite simply, it must solve somebody's problem. And I believe that we can get it to do just that. One area that we think is promising is using email to invoke applications that do interesting things because (1) everyone knows how to send email, and (2) you can attach lots of useful things to email.

So, what if we added the ability to recognize a ton of different file formats and allowed you to query the data within an attached file to invoke other web services?

For example, lets say you have a site that does group payments, and you want to let your users send you an Excel spreadsheet with the names of your friends and how much they owe you for that trip you just took together and automatically create an invoice on your site, and then notify everyone that they owe money. That seems interesting, and our product could support that pretty easily.

Anyways, it is definitely our immediate burden to focus this technology on solving _real_ problems.

Definitely agree. And its really easy to do so because you control the code. I actually have a bot that just executes whatever function name I give it, and I have a bot that runs arbitrary system commands on my server, which is kind of like having an IM terminal (_not_ recommended for security purposes :))

There were some mobile features that I wanted to implement on an orthogonal project that I'm toying with, and I noticed that there were no good APIs for IM-enabling your app, and I wasn't truly satisfied with the existing SMS solutions, so we built this. However, to your point, we need a killer app to really show the potential of the platform. Arguably though, it might make the most sense to simply target my original use case, and build the platform for developers who want to add mobile features to their products but don't want to spend huge amounts of time figuring out exactly how to do so in a scalable and highly-available way.

If your first line of code is 'x = prompt', there is no ping needed to invoke the application. I should have touched on that in the video because it ends up being a very bad user experience if it requires a ping to start your app.

I realize now that we didn't show a stateful app, but basically an application is run in steps, and the boundaries between steps are the calls for user input because the app must pause to wait for input. So we store the last instruction executed and halt the app. Then when input is provided, the app is restored at the proper point and continues running. It is not ruby specific, but it is _much_ easier to build this with interpreted languages.

I don't think we have the killer app yet, but we implemented a mobile interface to google calendar with ~5 lines of code which I've been using for a little while, and its surprisingly useful. When all is said and done, I think we might want to simply pitch this as a platform for adding mobile features to your existing app, so it becomes more of a developer tool than a consumer facing product.

As for monitoring, yes, it becomes a tricky task to achieve high availability (and scalability), but its a really fun problem to tackle :)

Haha :) I ended up writing the blog entry, and by the time I was done, my snarky inspiration had somehow transformed into something resembling diplomacy.

Would love a link to that if you can find it (assuming it exists somewhere on the interwebs).

I'm not a business guy.