I want an Airbnb rewards credit card.
Every major hotel chain has a rewards program and rewards credit card. SPG Amex. Hilton Honors. Etc.
Airbnb should have one too. Here’s a few reasons why:
- Points-based rewards programs allow marketplaces to manipulate prices without forcing discounts on sellers. Glut of supply in Chicago next week? Increase the dollar value of points for guests there. Everything booked in SF this week? Decrease the dollar value of points. Manipulation like this is otherwise hard to do in a marketplace, beyond suggesting prices.
- Incentivize business travelers to use Airbnb. When employees book travel for work, usually their company pays, but the employee collects rewards points. The employee is incentivized to book wherever they can collect points for their favorite rewards program - not by price. An Airbnb rewards card would incentivize business travelers to stay at Airbnbs for work in order to earn rewards points for personal travel.
- Simple brand loyalty. Points help people justify economic decisions, both rational and irrational, in order to “earn” a free or discounted stay.
- Free marketing. I use my rewards credit card multiple times per day. Every time I’m showing the hotel chain brand to at least one person (the cashier) in addition to anyone else around them. Per year, that’s a few thousand free impressions in the physical world.
I’m sure negotiating a card with credit card companies is a burdensome and painful process. Hotel chains would threaten to switch away from any credit card company who strike deals with Airbnb. It would make Airbnb appear even more competitive with hotels, at a time when they are trying to fight that perception. It would be a huge pain in the butt.
I’d sign up on the first day though, and I bet I’m not the only one.
How I made $10k in one day with Facebook Ads (re: bots)
In light of the speculation about bots on Facebook, and tech journalists who have resorted to trolling Hacker News for stories, I’d like to share a story about how Facebook ads brought real human beings to my house at 9 AM on a Saturday to spend real money.
Before I started working in tech, I founded and ran a business selling vintage vinyl records. It was fun, but the records were piling up in storage at my folks’ place (thanks for your patience, mom!) and I needed to get rid of all these records that were piling up.
Took about a half hour. Three weeks and $150 later, there were 341 people “attending”, and 104 “maybes”. I’d run Event Ads before, but I was skeptical - we’re these all real people who had not just clicked on the ad, but would actually show up at 9 AM on a Saturday?
They were. Saturday morning, there was a huge line of people in front of my house. They kind of looked like zombies (I mean, Saturday mornings can be rough), but I can attest that they were definitely not bots. For the next five hours, the scene looked kind of like this:
At the end of the day, hundreds of happy customers later, I counted $10,000 in cash (and some payments accepted via Square - yes, I’m reporting the income, IRS). Over 3000 records sold in one afternoon. The majority of my customers came from Facebook Ads, so what is the calculated ROI, 2000%? 3000%? You do the math.
No optimization, no professional consultant, no special relationship with an account manager. As far as I’m concerned, clicks coming from Facebook are the realest clicks in the game right now. Need to track them on your site, Limited Pressing? That’s what UTM tags and Mixpanel are for, dude.
Why ifttt kicks “connector” software in the face.
Every day, people create workflows, combining multiple pieces of software to solve problems. Sometimes these are consumer problems - syncing photos, managing notifications. Sometimes these are content distribution problems - businesses need automation to manage content across platforms. Sometimes these are product/project management problems - syncing file management and communication systems. Etcetera.
Up until now, startups and companies have been formed around these problems - aggregating, connecting, managing services. As an increasing number of developers release APIs for their software, these pieces of “connector” software have exploded. In many cases, they are very profitable.
None of them really “do” anything though - instead, what they “do” is to allow users to build workflows that make things easier and faster, with less manual work. For consumers, this convenience is often THE selling point. For business and enterprise customers, even slight gains in efficiency and reductions in manual work are worth a CRAPTON of money. These businesses are basically built around reshuffling and reorganizing data between systems, because they are often built by those who understand that efficiency and integration are core needs of customers - they capitalize on these needs.
Even with APIs on both ends, and as hard as Facebook works to change things, by building its platform as a centralized node through which 3rd-party apps interact, there will always be software that doesn’t sync right, or suit the exact needs of a given user. Increasingly, these needs have less to do with the core functionality of the application, and more to do with how a given application fits into the user’s other software. For developers, there are simply too many services, and too many options, to provide each user with the right functionality - software (ahem, CRM tools) that attempts to do everything dies a painful death through feature creep.
Instead, ifttt enables the everyday person to create the conditional logic to build the external connections they need, outside of a programming environment. Let me rephrase that - ifttt enables someone with zero knowledge of APIs or software development to make their shit work the way they want shit to work.
The point is, it’s awesome when startups build things, instead of repackaging other tools. If ifttt is successful, it will eliminate the need the current batch of software that makes a few APIs interact and repackages services in a fancy new view. These services make a lot of money from everyday people who just want software to work the way they want it to, particularly when their work depends on it. Open APIs + smart people creating recipes + ifttt = custom integrations for everyone.
If you’re working on a product that’s included in ifttt’s channels, I’d be paying close attention to each of the user-created recipes - each one is an incredibly valuable piece of feedback from a user who wants to use your product in a way you haven’t yet accounted for. Some are bound to be niche, but others are boneheadedly obvious - it took an ifttt recipe for Instagram to wake up and realize their Facebook integration was simply sharing links, instead of using the photos API. Every ifttt recipe is an example of users wanting to use a product in a way that it had not yet been built, which is feedback you can’t get through analytics or customer emails (if your customers email you with suggestions this good, you should probably hire them).
I hope ifttt continues to grow and kick “connector” software in the face.
Will Facebook eventually allow advertisers to target ads based upon subscriptions?
Just a thought. If celebrities, musicians, journalists, etc. migrate from Twitter and Facebook Pages to letting users subscribe to their personal accounts, that’s a lot of social capital and connections that would be inaccessible to the self-serve ad tool.
Targeted Page Posts
What if Facebook allowed Facebook Page administrators to target posts using social graph data?
Throughout 2011, I managed and grew a Facebook page that started at 15,000 likes, and currently sits at over 65,000 likes. As the page grew, reaching everyone became increasingly difficult. Facebook’s Edgerank algorithms reward pages for posting engaging content and punish them for over-posting or posting content that does not generate significant response. As a page grows its following, each post carries more and more weight, not necessarily because it reaches more people, but because it has an increasing impact on the future ability of the page to reach its following.
By posting a few pieces of engaging content, the administrator of a page with under 10,000 likes can reach the majority of the page’s active following quite easily - the dedication and participation of the initial following creates a high affinity score. As the page grows, a given post reaches a smaller percentage of people relative to the total number of likes, pushing the page administrator to post more in order to spread a single message. Repetitive content and messaging generates less engagement though, hurting the page’s Edgerank relative to its fans.
Pages with over 100,000 likes face the most difficult struggle - marketing to a large and diverse group of people, with no way to segment messages by anything other than language and location. Facebook has the data and infrastructure that they allow pages to use to target posts by age, gender, education or connections with other pages, but this data is reserved for Facebook Ads. Allowing page administrators to use this data would cannibalize Facebook’s ad revenue overnight.
What if Facebook allowed Facebook Page administrators to target posts using social graph data?
Let me sketch out a simple, plausible scenario - Let’s say I’m the page administrator for a popular apparel brand who makes clothing for both men and women. I know, from experience, that when we post photos of our new women’s clothing line, we get a huge positive response from women, but most of our male customers either don’t care or just comment on the attractiveness of the models. But in order to get the message out, in the current paradigm, I have to post content to an undefined portion of the brand’s following, and trust Facebook’s semantic and affinity algorithms to display that content to the “right” people.
As the community manager, I know the brand’s customers incredibly well, but outside of advertising, lack the tools to properly segment which content is posted to a particular audience. If only I could choose to post photos of our women’s clothing to women, and our men’s clothing line to men.
This kind of segmentation is a large part of why email marketing remains incredibly popular - the ability to create different messages based on rich data allows smart marketers to create dozens or even hundreds of messages tailored to specific audiences.
Imagine catering a party of thousands of people, but only being able to serve one dish at a time - there’s simply no way to please everyone this way. The more diverse the tastes of the audience, the more generic the dishes have to be, in order to appeal to the widest set of people. Moreover, the next time you throw a party, it’s for a whole new subset of your audience.
This prevents page administrators from running more precise experiments. Whereas the success of the Facebook Ads platform hinges upon advertisers experimenting with targeting options, even if Facebook Page Administrators use the Ad tool to gather data about their following, they cannot use the data to run smarter experiments that target more specific audiences.
While this may be a strategic decision, because it could potentially devalue Facebook Ads, or because the vast majority of Facebook Page Administrators still struggle with the basics, I think targeted page posts in some format are inevitable. Facebook values dynamic and personal campaigns from brands and advertisers that use Social Graph data to create value for fans and customers, and if Facebook Pages are to remain dynamic, not just repositories for millions of “likes”, Page Admins need better tools to direct their message to the right audience.
Differentiating subscriptions from friends in the Facebook Graph API
Question: How should the Facebook Graph API integrate subscriptions & public sharing?
Introduced in mid-September, the subscribe functionality introduced two layers to the ways people connect on Facebook. Previously, Facebook had only two core types of relationships, friends and page likes - one for people you know, and one for brands, companies, celebrities, and other public entities that you like. The subscribe button added the ability to subscribe to public updates from Facebook users without being friends, as well as the ability to manage the priority and type of updates from any user.
While Facebook has not released usage statistics for the subscribe function, it has clearly taken off for some users, as prominent figures in entertainment, sports and technology have gained tens of thousands of subscribers in just two months.
However, Facebook is yet to integrate subscriptions into its Graph API for developers. For apps built on the previous generation of the Facebook Platform, like social games, this is of little consequence - these apps are designed to be used between friends. Open Graph applications, however, create new opportunities to curate relevant content. Through Facebook Pages, Twitter, and blogs, content is already being curated by individuals with substantial online followings, and the subscription functionality extends upon the demand for this curation to happen with less friction within Facebook.
As more Open Graph apps are introduced in the coming months, Facebook will have to integrate subscriptions into the API in order to remain consistent across the platform and product.
Currently, the Graph API allows applications to request access to the IDs of a Facebook user’s friends, but not their subscriptions. This limits the reach of Open Graph activity within applications to friends-only - a user who subscribes to Sean Parker on Facebook will see status updates that he actively publishes publicly, but not his Open Graph activity within the ticker or within Open Graph applications.
Edit: While it took me some time to find an example, Open Graph activity from subscriptions does appear in the ticker and news feed:
But what if Sean Parker, as one of the key public representatives of Spotify, wants to share what he’s listening to with his subscribers via Spotify’s Open Graph integration, within Spotify itself?
Conversely, many of Sean Parker’s subscribers might want to know what he is listening to, and the most relevant context for this information to appear is clearly within Spotify itself, where users are already listening to music. Clearly there is an opportunity for relevant, mutually beneficial content to be shared, and Facebook will inevitably attempt to create this connection. This extends to social news applications like the Washington Post Social Reader, The Daily, and more.
But not necessarily everything, which is where privacy settings become necessary and complicated.
A musician may want to allow their subscribers to see what they’re listening to on Spotify, and share their musical tastes publicly, in real-time. But they might not want to share what they’re reading on The Daily, because it’s not relevant to why people subscribe to them to begin with. Likewise, if Techcrunch or GigaOM creates an Open Graph social reader application, it’d be great to have tech news content filtered through the individuals in the tech community who I subscribe to. Twitter currently fulfills this desire, but the frictionless sharing of Open Graph allows this filtering to happen in a much more scalable and organized way.
This is further complicated by how widely celebrity, fame, and being a public figure can vary. For a celebrity like Justin Bieber, subscribers want details about everything from what he’s reading all the way down to how many seconds he brushed his teeth in the morning. Clearly, to whatever extent he’s willing to share his personal life, there exists a demand. On the other end of the spectrum, for a well-regarded engineer at Facebook or technology writer, subscribers are likely most interested in content related to technology, and what that user listens to on Spotify or reads from the sports section is less relevant.
End-user controls would be necessary in order to maintain privacy and prevent “noisy” or irrelevant content from being presented to both friends and subscribers - users are already clamoring for such controls as the negative press surrounding frictionless sharing grows. Facebook users who allow non-friends to subscribe to their updates would need to be given an option to publish their activity within an Open Graph application only to their friends, only to their subscribers, or both. This choice would need to be made available within each individual application - there is no blanket privacy setting, because one-way subscriptions are not personal connections, and users subscribe often for a particular type of content.
These finer points reveal the fundamental issue Facebook is currently attempting to address - how to provide the most relevant content possible to individual users, every time they login. The addition of the subscribe function both adds in relevant streams of content from non-friends that had previously been inaccessible, and removes noise by presenting a clear way for users to remain friends without being bombarded with irrelevant or poor quality content. The degree to which subscriptions extend into Open Graph applications will be an indication of Facebook’s investment in the feature, and will reveal the extent to which public figures are willing to share their online activity with the public.
UPDATE (01/26/2012): Developers can now read user_subscriptions and friends_subscriptions via the Graph API. Let’s see how long it takes developers to integrate…
Pushing The Envelope, Not The Share Button
Thoughts from Techcrunch’s MG Siegler on Facebook Open Graph and the subsequent knee-jerk reactions that have followed. The changes that Facebook is pushing towards are so misunderstood, and so monumental, that it’s really unfortunate how little intelligent discussion there has been to-date.
Human nature is reading something and wanting to talk about it. It’s not reading something and then clicking a button while coming up with some pithy or profound statement in a (probably) lame attempt to engage people.