Refining Lookery's Pricing -- Campaign Service

Taxi MeterMeter Image by JL08 via Flickr

After Lookery sold its ad network to Adknowledge in the Fall, we finished building our user-targeting service and started licensing data. We obviously needed pricing. I normally start by analyzing the competition but the existing demographic offerings did not offer much guidance. They’re panel data which is super cheap as it doesn’t perform for individual targeting, credit bureau data that is bundled with credit card transations and has all sorts of PII problems, one-off deals with portals that are individually and expensively negotiated, and spammer data which has been collected in ways that create civil or even criminal liabilty.

We also sell Lookery MyProfiles, which is SaaS profile hosting and distribution, though MyProfiles’ marketing is low-key for now. We’re not aware of a comparable service, so the competitive info is thin again.

In that kind of data vacuum, the steps we took aren’t very surprising, but they do vary a bit from what I usually read:

  • Without useful competitive info, start with the obvious, and start quickly. Obviousness, which includes simplicity, is never the whole answer, but it’s the best way to the learn the most in the least time.
  • Iterate slowly, customers and prospects don’t like prices to change. I try and keep the frequency down to twice a year.
  • Price from value, not cost, but know what your costs are. Of increasing importance in a cloud-computing world is understanding the fixed versus variable costs. Because cloud-hosted enterprises are no longer buying or even committing to server hardware, our variable costs (i.e. our Amazon, Media Temple or Google App Engine bills) are a greater fraction of our total expense than previously. Watch those changes.
  • Don’t worry much about cannibalism. My most influential professional mentor, who could sell you your own eyebrows, looks at distribution from the angle of, “If you don’t have channel conflict, then you don’t have a channel.” The same lesson applies here. If your pricing options don’t overlap a little, then your pricing is excluding in-between customers entirely. That’s more expensive than the alternatives.
  • Decide what you are optimizing for — this month’s revenue, commitment, or building distribution for your next offering. Lookery cares most about building long-term financial relationships with its data licensees and licensors, so we offer lower prices for time and volume commitments.
  • Keep the number of pricing options low. We had two types of Network Service (see below) at first. When we added Campaign Service, we were planning to offer two versions of that as well. Even with just four options, our sales prospects quickly started entering analysis paralysis, because we were asking them to make too many subtle financial decisions. Now in its final form, we offer just one way to buy Network-wide data and one way to buy Campaign data. The simplification is already a clear sales cycle improvement.
  • Think about how future services will fit — very briefly. We all naturally overestimate our ability to foresee even the near future. Make sure there’s no live-or-die pricing conflict being created but attempt no optimization.

Lookery Network and Campaign Pricing
Using the above, the first pricing scheme Lookery offered was Network Service. We charge a flat monthly fee for every unique demo profile that we license each month. The data is delivered in the form of Birthyear, Gender, and Location, i.e. 1975, male, and San Jose, CA. That profile, completely anonymous before Lookery even gets it, can be used by the client for any targeting they like as long as they do not sublicense it. The profiles are stored in an  unusual and advantageous system on Amazon Web Services, and delivered via pixel dropping like the rest of the online ad world.

Midyear, it became time to update our pricing in order to address a much larger portion of our market. As is typical in advertising, more customers run their accounting on a per-campaign basis, so we added Campaign Service pricing. In campaign pricing, we deliver a different version of the same demographic data but at a lower price. Instead of querying Lookery for “What’s this person’s birthyear and gender?,” customers ask our system “Is this person a female between 35 and 44?” We respond with Yes or No, and the license to that data lasts for the campaign or the life of the cookie.

Reblog this post [with Zemanta]
Deprogramming VC & Reprogramming SWOT

SWOT analysis diagram in English language.Image via Wikipedia

Much is written about both whether or not the VC model is broken and how to evolve startup business plans in the face of market changes. Today, it hit me just how inextricably linked the two issues are and how my own tactical process needs to catch up to market realities.

I spent from 1992 to 2006 presuming VC-backed startups were the business I was in, and I worked towards understanding that system. After all that time, two things happened to radically change my outlook.

  1. I finally figured out that one should only raise VC if one is already rich,
  2. I also figured out that being boring and late has better risk|reward characteristics than being sexy and early, and
  3. Cloud computing arrived, making VC deal terms economic only as growth capital for Internet startups, leaving the early-stage field clear to angels (and bootstrapping).

Taking any number of lessons from Mashery’s good work, Lookery is a cloud-hosted SaaS vendor that uses an API to provide deep benefits to its customers and suppliers. Like Mashery in early 2007, we’re actively sorting our which customers and which decision makers love us and which look at us crosseyed (or don’t look our way at all). We have numerous data points in each category and the right kinds of patterns are emerging.

The problem is 15 years of old work vs. 3 years of new work. I haven’t finished retraining myself not to presume VC. I find myself mentally parcelling out multimillion dollar budgets that don’t exist. More importantly, calculating low-capital SWOT is not truly intuitive, particularly when analyzing VC-backed companies in Lookery’s market sector.

The VC-backed companies in our sector (principally Blue Kai and  Exelate) are doing a great job getting and giving data distribution via cookie exchange without the benefit or overhead of a centralized profile hosting system.  Cookie exchange works well for many user-targeting applications, but there are a few key tasks that aren’t covered including:

  • Efficient combination of data from multiple sources;
  • Forcing and enforcing the anonymization of targeting data without depending on good behavior by publishers and/or ad networks; and

Lookery exactly runs that exact scaled profile hosting system, and it changes the equation — but how in a SWOT context? We’re angel-funded and intend to remain that way until we’ve completely nailed the revenue model (see #3 above). Relative to the other sector participants, our near-term enterprise value calculations and related tactics are different. My erroneous, knee-jerk reaction is to compete directly with them but that makes no financial sense. They have an order of magnitude more resources (from their VCs) and a lot more pressure to scale revenues quickly without much regard for expense (also from their VCs). We certainly grow revenues every month but breakeven in Q4 is a much higher priority than absolute scale right now.

The punchline on SWOT for Lookery in 2009 is to build on the unique strengths of our system putting priority on relationship depth and interconnectedness. We want to be our customers’ profile hosting and delivery system — and the one they want their partners to use. That means of our customers require a little more care and feeding, plus we have to be careful to disclaim all rights to their profile data. It’s business that the heavily funded startups can’t quite slow down enough to satisfy, gives them a good reason to do business with us, but is healthy enough to drive us to scale next year.

Reblog this post [with Zemanta]
  1 of 1 

Based on a theme by Hunson (Designed by Josh) / Powered by Tumblr