How to make a YC demo video

I’m a YC alum, and alums get the privilege of reviewing YC applications. I’ve applied to YC 3 times, and have gone through the program twice.

Part of the application is a 1 minute pitch by the founders. It’s my favorite part because there is so much signal to noise in the video.

There are so many simple mistakes people make that get in the way of clearly explaining what you do. I want to outline a few so your videos get better.

Today is the last day to apply to YC by the way, so read this fast and get back to work. At the end of my post, I include my video for YesGraph.

Minimal Production Value

You can make the video off your smartphone or laptop webcam. The video quality doesn’t matter. Try to be in a quiet place without city car horns or babies crying.

Plan Ahead

You should outline what you want to say. There are only a few basic areas to focus on:

  • Who are you
  • What are you building
  • Who is it for
  • Why it’s awesome

For example, here is a minimal script: “I’m Ivan, I worked at Facebook and ran growth at Dropbox. I helped them grow 12X in 2 years. Now I want to help other apps grow. YesGraph can use machine learning to recommend exactly who a user should invite, boosting viral growth”

One of the best reasons to apply to YC is to refine your pitch down to a short bit of plain English. This editing is incredibly valuable.

Don’t Use a Script

When you use a script, you’re not talking to a human, you’re reading from a prompt. This doesn’t work because it masks your passion and creativity. Another problem is that the way people talk doesn’t match the way they write.

Make an outline, but don’t read from it. It’s only a minute long — you should be able to practice and avoid looking like a robot.

Don’t Use Jargon

Industry jargon is really confusing. Unless there is a really well known idea, like “PC” (you know, that thing that literally billions of people have), avoid using acronyms.

The problem with jargon is that it gets in the way of communication with people that aren’t as knowledgeable as you. They might sound impressive to you, but it is a barrier to understanding.

Don’t Use Complex Video Editing

Complex editing isn’t going to matter, but it will take time away from your plan. Even if you already made some explainer video for your website, don’t include it. Those are for different audiences.

Sometimes you might have founders in different places. First off, try to avoid that. It’s better for your company to all be in the same place. Beyond that, it can make video editing a little tricky because you want to include everything. I’d recommend taking snippets from each founder and putting them together — just introduce yourself. It probably also works best if one person gives the rest rather than a cute splicing of different people and ideas.

This balancing act happens in person too where you might not want one person talking the whole time. Just try to check your egos — you don’t need to split video time equally. Do what is best to convey the ideas.

Do Give a Shit

Passion is really important in startups because they are really hard to finish. Passion is what gets you through the marathon. Showing you care can help convey your drive, but also that you’re knowledgeable about your domain.

Keep It Short

You love your company, so you have a lot to say. But you need to edit it down to something others can easily consume. Reviewing might be watching dozens of these in a row. It’s inconsiderate to think your startup is so important that it demands more time. The actual signal you’re sending is that you are a poor editor and don’t understand your idea well enough.

Record Yourself, Watch it, Repeat

This is my favorite part. Record your video and then watch it. It’s incredibly painful. Plan on doing this a few times in a row. Even a handful of takes will get you much more refined.

This also helps you avoid using a script. You’ll know what you want to say and will have practice saying it enough that it’ll come naturally.

There is a wonderful Italian word that matters here: sprezzatura. It means to “to hide conscious effort and appear to accomplish difficult actions with casual nonchalance.”

If you refine with practice, you’ll get good enough to look brilliant but casual.

But I have a warning: you might get into the habit of saying the same thing so much that you lose your passion. You might have accidentally made a mental script that you’re reading from. You need to notice when you’re doing that and do another take.

Get friends to help here. Have them review the video and say whether you sound sane, robotic,  or passionate.

YesGraph’s Application Video

Note that YesGraph pivoted to what we’re building now, so at the time of this video I used a different name, SignalLens. We since decided to keep the name YesGraph because it’s better.

I’m sure this video has problems. I probably talk too fast, for example. But in my humble opinion it is better than most application videos I watch. And it’s not because I can say things like “Facebook” and “Dropbox” — but for entirely controllable things you can change. That’s why I wrote this post!

Subscribe to future posts here

Roach Mode

There has been an incredible amount of chatter about the coming downturn. Public tech stocks are down, but people are confused about how this might affect earlier stages.

You don’t want to over react and miss the opportunity in front of you. But founders tend to be hopeless optimists and bias towards driving off a cliff with their foot slammed on the gas.

So it’s time to consider roach mode: do whatever you need to do to survive, like a cockroach.

Study History

I feel old saying this, but some founders don’t remember 2008. There was a financial crisis that caused the funding environment to change very quickly.

Sequoia Capital went into freak-out mode and sent their portfolio a presentation called “RIP Good Times”. You should go and read the whole thing here. The advice is rock solid: cut burn now in order to save the company later.

More recently, Paul Graham wrote an excellent essay: Default Alive or Default Dead?

First Round describes the Watney Rule: “We need to act like we’re Mark Watney in the Martian. We can’t assume we will get a shipment of new potatoes to save us.”

Roach mode” rhymes, so it might be easier for founders to remember. ?

Investor Relations

If you’ve raised money, talk with your investors. Mine have been proactive about explaining how they think the environment is evolving. Hard times are a test for the quality of investors. The best investors are honest and transparent, making them predictable even in hard times.

I love our investors, and they’ve expressed strong support for us. But I’m going to act like that isn’t true. Roach mode means acting like there isn’t more money coming.

Another version of this is taking a lower valuation than you expected. If you shut down your company because of some valuation pissing match, you’re an idiot.

Revenue Structure

There has been a major problem brewing in SAAS businesses: they can predictably grow revenue, but normal accounting makes it look like they lose money. Spend $1K in ads and sales team comp, in 12 months you get back that $1K, and in another 12 you make another $1K. This sounds like a deal until you realize this depends upon external funding to push growth through the short term trough of losses.

Some SAAS companies see this pattern and push to be paid early. For example, eShares just changed to annual billing. This means you pay upfront for a year so that the company doesn’t go into the hole at all. The problem with this approach is that it doesn’t match up with customer value. Any decision that is good for your business but bad for customers should be suspect. But in roach mode, every option is on the table.

Check out this excellent post about strategic finance for more.

Screenshot 2016-03-10 15.14.15

New Revenue Channels

YesGraph recently launched an awesome class around growth, where we help you build an experimental process, understand your analytics, understand virality, hire for growth, and more. It is not free, but compared to the value it’s cheap at $199. Check it out here: http://learn.yesgraph.com/

Why are we doing this? One of the reasons is that it’s a lead gen source for us — a premium content marketing play. But there are other structural issues. If we can run ads to get people to pay for the class, then the paid acquisition strategy isn’t the same as the problem in SAAS with marketing and sales costing too much up from. We can efficiently run ads to buy the class, which then pays off immediately.

Plus the ad campaigns we run are going to be open to people that take the class so we can demonstrate what paid acquisition looks like. That’s delightfully meta.

We’re trading more leads with high quality leads (you’re willing to pay for growth), and biasing towards immediate revenue.

We just launched another similar effort: growth teardowns. We just reviewed Telegram Messenger, and are queueing up more. These aren’t free: we’re essentially scaling consulting work in a way that strongly aligns with the service that we build. We’ve been helping YesGraph’s customers with growth advice already, so this fit our mission of helping companies grow faster.

Similar to the growth class, we can run ads to the teardowns to get more clients. It’s transactional and more efficient than other kinds of lead gen. If you want to better understand your growth, email teardown@yesgraph.com

Screenshot 2016-03-10 10.49.58

Cutting Payroll

Besides expensive paid acquisition, another major expense for many companies is payroll. Good engineers are expensive, so one of the simplest ways to live longer is to cut payroll.

This is brutally hard at times, but that’s roach mode. Take this slide from RIP Good Times.

Screenshot 2016-03-10 14.55.55

If you cut early, you’ll have the extended runway to live forever. If you don’t, you’ll fall off a cliff.

But use your judgement here. YesGraph has recently hired some excellent engineers. I don’t think we have too many. I think we have enough to take on the opportunity, and we’d be strained to make progress with fewer people. We’re already lean because I started out sensitive to over hiring, even without a downturn coming.

Your Strategy

I might be doing something obviously wrong. Some people think offices are expensive, but our office is less than 3% of our expenses. We still buy food, but that’s less than 1% of our expenses.

One reason I wrote this is to hear what I might be missing. So tell me in the comments or email me: ivan@yesgraph.com

Subscribe to future posts here

Growth Teardown: Telegram

We’re starting something new on this blog: breaking down a product to better understand its growth. This means both finding out what they do well and suggesting ways that they can improve.

We just launched a guide to growth, and breaking down different apps is a natural extension: from theory & tactics to practical ideas for a specific app.

We’re channeling our inner UserOnboard.com, where Samuel Hulick breaks down the onboarding for new products. Samuel is a friend of YesGraph — check out our interview with him here.

Our first review is of Telegram, a very popular messaging app. If you like this and want it for your own app, get in touch at teardown@yesgraph.com.

Check out the embedded slideshare below, or the raw pdf here. We also recorded a voice-over video so you can just sit back and listen. You’ll want to go full screen and take notes.

If you have any feedback on the format on content, email me: teardown@yesgraph.com

To get future teardowns as soon as they come out, subscribe here.

Just Launched! Our Complete Guide to Growth

The problem with “Growth Hacking” is that there are legit growth teams at companies like Facebook and Dropbox, but there is still a huge amount of confusion about how to actually drive growth.

It doesn’t help that much of what you can read about the topic isn’t from people that have done it at scale. Worse yet, a general problem with advice is how to synthesize good ideas from others into what you should do for your own company.

We’re launching a class on growth to help solve this problem. We want to help companies get a grip on their data, understand their users, make better decisions, and grow faster. We want to dispel the bullshit and instill the practical advice that you can use today.

celebration

I’ve been obsessed with this idea for years — ever since my first startup didn’t take off and I learned how Facebook ran their growth machine. I ran growth at Dropbox and refined my advice — and since have talked to hundreds of companies about what works and what doesn’t.

At YesGraph, We build a product that can help with growth. But much of what we’ve learned about growth isn’t something that can be productized. These lessons learned are about how you think and organize your team. It’s how you run experiments. It’s how you ask the right questions.

So check out the class right here.

This class covers analytics, virality, referrals, growth process, hiring and more. We’ve embedded the syllabus below — it’s pretty long! The format is video lectures plus written essays. We think this will help you get two perspectives to better understand the material. The first lecture is free to preview!

On top of all this, we’re making a living document. We’re going to take feedback, and upgrade the class. This might mean more examples, more exercises, and more topics covered. If you purchase the class, you’ll access to all this new material for free. Feedback loops are as essential part of making your product excellent — and this class is a living example of how much we believe in that.

We have more coming soon too! We want to have more options, like product reviews and maybe even off-sites! You can email me anytime with feedback or questions about the class: ivan@yesgraph.com

Subscribe to get more updates here.

>>> And here is the class link one more time <<<

class plan syllabus 600

YesGraph Javascript Library Now Available

We just released the first version of our Javascript SDK. This makes it easier to integrate YesGraph into your web app.

The library we’re releasing today helps manage YesGraph’s API. What we aren’t launching today is the user-facing features. We wanted to get the library out faster for some apps that need it. If you already render contact lists, this is for you.

You can head over to our documentation page to learn about how to do the integration. It’s just one line of code, plus we use jquery. We’re working with Amazon Cloudfront as a CDN, so you can include it directly in your page.

Screenshot 2016-02-08 12.20.08

That’s minified, and you can see the code on our Github repo here.

We’re not done! We’re working on a flow that will actually power the user-interface to send invites in email and social channels. That’ll take a few more weeks — we’re really excited to launch that as soon as possible!

We’re actively working on this and would love your feedback. Please take this survey if you’re interested in influencing what we build: http://goo.gl/forms/JaAMftdDuv

You can also email us at support@yesgraph.com anytime.

[Navel Gazing Startup Post]

Mark Cuban thinks YC founders are entitled. PG thinks Shark Tank is a waste of time.

PG is right, because of the way founders behave.

Screenshot 2016-02-02 09.01.48

Context: I’ve been through YC twice and Sacca was an investor in my last startup. I think everyone involved here is bright.

Founders put a lot of weight in Shark Tank, and invest too much in getting there and performing. Sacca and Cuban are acting like the founders got up that morning with no plans and spent 10 minutes pitching millions of consumers. The problem isn’t Shark Tank but the way founders behave around it.

This is a specific version of the general phenomenon: founders seek some magic bullet, some golden ticket to solve growth. I’ve written about that here, “The #1 Mistake in Driving Growth”. It’s a mistake. Founders should focus on making the best product for their customers. They should do marketing too — focused on sustainable progress (probably not PR).

Cuban saying YC founders are entitled is both 1) obviously true and 2) difficult to distinguish from Cuban’s anguish over the price of the rounds for YC companies. The fact is that there is a market for company stock, and YC companies get higher prices. They expect higher prices and more, which is entitled, but they get them, to Cuban’s chagrin.

Is it lost on the people looking on that Cuban has a strong business interest to dismiss the value of YC so that he can get a better deal? It’s so transparent it is barely worth mentioning, but apparently people don’t notice the conflict of interest. Plus people like Cuban predict that deflation of prices in some bubble burst as often as founders complain that VCs are slow and lack vision.

 

Problems in the Recruiting Market

YesGraph pivoted away from a product in the recruiting space. I get asked about recruiting a lot by other founders, so I wanted to explain some problems that startups in the space might face.

I’ll also cover how we decided to pivot, how we decided to take the plunge. But that will be in a future post, so subscribe here to get new posts right away.

Because I’m not in the recruiting business anymore, I don’t have to be nice to the key players. That’s great news for you because so much written about the space is vapid bullshit.

How Old-YesGraph Worked

Today YesGraph helps apps grow through social graph analysis. We started out as a recruiting app which helped companies boost referral recruiting.

It worked like this: first create a job spec and invite your team. Your employees connect to Facebook, LinkedIn, and email address books. YesGraph would parse and clean up these contacts, and rank by the ones that fit the job. We created a feed of your contacts, with “yes”/”no” one-click referral actions. Those referrals enter your pipeline. Our core problem was not enough companies got that far.

Saturated Market

Finding and keeping the best people is literally the most important job at every company stage. From cofounders, to early team, to growth stage, to retaining talent past an IPO. Recruiting is valuable!

But this isn’t a secret and the space is incredibly crowded. Just look at AngelList for “Social Recruiting”

companies better

This is obvious even to casual observers.

What isn’t so obvious is how this affects people in the market. You might think your product is better than everything out there, but the recruiter you’re pitching might have heard that every week from a new startup. This can dramatically affect how easy it is to sell your product.

At YesGraph, this became a problem with team onboarding. We were actually 10X better… once you were inside the product with your data. This required recruiters to tell their teams, and the employees to connect to the data, and then you’re in. So there were two kinds of companies, those which did this and got a huge number of great referrals, and those that didn’t.

Problems with Pricing

We started out with $19/employee/month. The logic here is that a typically referral bonus is a few thousand dollars, and the cost of other channels are higher. So if we enabled a single referral per seat per year, we’re still incredibly inexpensive.

The problem appeared to be mentally mapping that price to a whole organization, and it was a lot of friction to even try a pilot. Anchoring to the value of a new hire with referral bonuses seemed too much for some recruiters. They treated referrals as “theirs”, despite wanting more of them.

Then we moved to a model with tiers of the number of employees. We blogged about it here.

new pricing

This was definitely more effective. But this was on top of other tools companies were paying for, like their applicant tracking systems. Once you get outside of tech, this starts to be a budget problem. Some companies just don’t hire for a whole quarter or year, and their appetite for SAAS subscriptions is weak. That isn’t like CRM or other markets where your company is dead if it isn’t closing deals.

A common model for sourcing tools is to pay a placement fee for a hire. Sometimes it is 20% annual salary or higher, which is CRAZY expensive.

I should stress this is common in executive recruiting and in hot tech. For most companies, this is wildly too expensive. I expect the next contraction in tech will cause a bunch of recruiting companies to lose momentum as their placement fees aren’t tolerated.

I regret not experimenting with fees for placement. It could have been much more revenue, but I didn’t think it was fair. I shouldn’t have been so opinionated.

One wrinkle I’ve seen is how some companies get paid incrementally over years. So instead of 15% salary upfront, it is 20% paid in 1% increments monthly. This makes sense for startups because the discount rate is so high. The net present value of future round money is small. It’s better to spend less now, live longer, and build your team to earn the round.

The Cluster Fuck of Applicant Tracking Systems

This is such a disaster, it’s hard to know where to start.

Applicant Tracking Systems (ATS) are a collection of tools to help companies manage the recruiting process. This means different things to different companies, so the result is a hodgepodge of features and flows. Document management, req writing, syndicating to job boards, processing applications, collecting interview feedback, managing referrals, and a dozen other things. Most end up as a product design mess.

Some are tailored to different market segments or focus on different kinds of talent. Some are for huge companies with crazy analytics and automation needs. This means that there is no standard, but huge fragmentation.

Switching costs are incredibly high and recruiting teams are afraid of it. This means selling to users of one ATS hoping they switch to yours is hard.

Worse yet, most are closed and don’t care about your integration. These aren’t modern, developer-friendly services. If APIs are BD 2.0, ATSs use BD 0.1: GTFO. They want to lock down the pipeline and implement everything themselves, poorly.

So where does a new company start? Do you compete directly and implement the features? Do you try to integrate with dozens of players? Do you ignore it and hope it doesn’t matter for your early traction? Do you try to hack an API around a service that doesn’t have one? What a mess.

https://xkcd.com/927/

https://xkcd.com/927/

 

LinkedIn Fucks Users

I should stress that I love LinkedIn. I use it all the time. Plus the people that work there are incredible.

But they did something really bad. They promised a network, and then closed it down. Their API no longer allows a user to share their network with another app. This eliminates the main value of LinkedIn, the network. Yes, LinkedIn earned it, but the opportunity cost here is incredible. New products can’t be made by other companies that leverage their network.

Some startups have decided to scrape lots of that data, but that is dangerous territory because LinkedIn’s legal team has a budget 10X that of your last round.

trump

So LinkedIn keeps the data for themselves, and then they don’t do anything new with it! Where are the productivity tools that leverage the network? Besides recruiting and some sales, why aren’t professionals on LinkedIn all day?

They could definitely implement a better version of the old YesGraph for referral recruiting, and 4 years after I had the idea for it, they might just implement it. They could compete with Slack with full knowledge of your org chart, but they don’t. They could build a CRM, but they haven’t. They could build an ATS, but they haven’t. They could build tools for career discover, knowledge management, online education & certification, company directory & interest graph, internship applications, automated assessment, a remote freelance marketplace, crowdfunding, crowdsourcing, and a million other things. But they haven’t.

I hope they start to move here, because I want to live in a world with these better tools.

Recruiters from Mad Men

I’ve worked with many very savvy recruiters. I’ve also worked with some that think about recruiting in no different way than the characters on Mad Men. I mean literally their thinking hasn’t changed in 60 years.

Find a stack of resumes, and work through the list.

As a technologist, I don’t get this. The process of managing recruiting is painful for everyone involved. But there appears to be a huge amount of resistance to the upstarts working to solve problems.

mad men

Let me give a really simple example. I have some resumes. Some passed my filter and some didn’t. Train an automated filter to go through and score future resumes by likelihood I’ll like them. Then instead of processing the first in first out, look at a ranked list. It’s been 15 years since we solved the email spam problem, but my idea is actually innovative in recruiting. It’s a tech backwater focused too much on people. Ironically, better tech could free recruiters to focus more on the human aspect of recruiting.

Another, simpler example. Why do people stop making referrals? The common guess is that it’s because they run out of contacts. Nope, consistent feedback has been that an employee has a bad experience and doesn’t want to do it again. It can be literally as simple as telling the employee who made the referral the current status of the candidate. All you need is more transparency, even if the candidate is rejected. Getting this done is an innovative idea, and that’s sad.

Naive Founders

The technical innovation potential is clear to engineers. The problem is that they might not understand recruiters — especially how recruiting works outside tech hubs. This is a big deal when your go to market and sales process are essential to getting traction and reaching the large audience your VCs expect.

For example, I just met a founder working on some cool tech in the space. I like the problem and I hope they win. But he had never hired anyone. He had never done sales. There is just no chance he understands his customers yet. If you’re self aware, you’ll figure this out and solve it. A founder’s naiveté can be an advantage in daring to take on a huge industry. Just look at Stripe taking on payments. The difference is the Stripe founders really understood their customers, the developers, and the industry knowhow was just an implementation detail.

Engineers that understand the tech but not the customer should focus on how fast they can learn about their customers — table stakes for deploying your tech.

Leaving Recruiting

YesGraph ended up exploring and executing a pivot into a whole new product outside of recruiting. Sure there were problems with recruiting, but we found something compelling to go forward. Now we help apps grow through social graph analysis, and I’m incredibly excited to blaze this trail.

We’ll cover exactly what we did to pivot in our next post. Subscribe to updates here.

And if you’re at a recruiting startup and traumatized, come chat in our growth-focused community slack: http://community.yesgraph.com/

Grow Faster with YesGraph’s Android SDK

We’re happy to announce that YesGraph’s Android SDK is now available!

Like our iOS SDK, it powers the whole invite flow for mobile apps. We built the most performant design, meaning you can get better performance with less work. Plus it’s open source on Github! (Here is the repo, and here are our docs).

YesGraph’s contact recommendations are built in. Users see suggested contacts that are the most likely to get invited and accept invites. Here is the flow:

android-demo trimmed gifbrewery

But there is another interesting feature that highlights the long term power of YesGraph. It’s got me so excited!

Unlike iOS, Android contacts contains wondeful data like favorites and a people you’ve recently contacted. These are wonderful signals to highlight your top contacts. This data just isn’t available through APIs on iOS.

But YesGraph is more than a simple utility for sending invites. It’s a powerful social graph database with machine learning running over millions of points of data.

If you have both an Android app and an iOS app and use YesGraph,  you can can leverage this incredible data on Android for your iOS users. The data just isn’t available on iOS, but the reason this works is social graphs. No really, they are like a super power!

Your Android users are connected to people that are on iOS. Affinity data across your users is symmetric in many ways. In other words, knowing the close friends Android users have on iOS means you know some close friends of your iOS users.

Normally only big data teams at LinkedIn and Facebook and Twitter do this kind of analysis. This is what makes YesGraph powerful: we leverage all of your data to deliver better results.

Let’s walk through an example. Let’s say Anna uses Android. His contacts look like this:

  • Beth
  • Carl
  • Dennis
  • Esther (favorite)
  • Hunter (favorite)

YesGraph’s ranking puts Esther and Hunter as suggested invites because they favorites. Anna invites Esther, who signs up on iOS

Esther’s contacts are:

  • Angie
  • Bob
  • Carole
  • Hunter (yes, the same Hunter that Anna knows — they have the same phone number).
  • Finn

Without any other information, you can apply a few social graph heuristics:

  • Hunter knows both Anna and Esther
  • Hunter is a close connection with one of Esther’s close connections.

Then we can rank the contacts:

  • Suggested:
    • Hunter
  • Alphabetical:
    • Angie
    • Bob
    • Carole
    • Finn

This social graph analysis and cross pollination of your data is a really big deal. This heavy lifting is why YesGraph can deliver far better performance for your invite flow or referral program. Plus it adds a network effect to every app.

To get started on Android, create an account on YesGraph to get access to our service. Invite your developers to join in, and check out the Android docs and Github repo.

You can get help by emailing support@yesgraph.com and joining the YesGraph growth community slack here: http://community.yesgraph.com

Subscribe to get new blog posts here.

The Top 5 Analytics Tasks for Your New Startup

So you have a new project and you want to setup your analytics. This post is to understand the minimum you should be doing.

Don’t fret! The companies with the most advanced data systems like Facebook and Amazon and Netflix didn’t start out with that system when they were young.

And the good news is that tools and services have grown substantially better in the last few years. This post will be opinionated but you can trust that you’re doing the right thing.

Oh, who the hell am I to have strong opinions? I ran growth at Dropbox and my startup YesGraph focuses on helping apps grow so I constantly talk to companies about their metrics, analytics, and growth. I’ve seen every stage, from startup to Facebook scale, so to reiterate, this is for young startups.

0. It’s event driven, obviously

If you’re looking at Google Analytics for pageviews, you’re missing what users are actually doing. Good analytics starts with the user experience, which means following a series of events the user went through.

Some would argue that this should go further, that you need to look at events and the state of the user at the time. I agree, but that’s starting to get complicated, like with advanced cohort analysis. The real point is that some people don’t even understand event based systems and are looking at vanity metrics. So let’s not make perfect the enemy of the good.

I’ve talked to some growth managers who have trouble explaining the idea of event based analytics to their management. That’s crazy. Your management might be incompetent, so email me if that’s you: ivan@yesgraph.com

1. Abstract calls to analytics events.

You want to make adding analytics events really easy. In your code, create an abstraction for logging an event that you can call from anywhere, (web front end, app server back end, mobile client). This helps avoid having vendor specific code peppered across your codebase. This will also make switching vendors much easier and your code easier to read.

On your app server or mobile app it might look really simple:

log_event(some context, the user, stats, etc)

This doesn’t need to be some huge library.

On the front end, you can make a similar call in javascript. Plus you can go further with connect triggered events. I’ve implemented an attribute system so that a click on an element like this:

<div click_event=”signup button”>...</div>

…would trigger a call like this:

log_event(event=”Button Click”, 
click_target=”signup button”)

That makes adding front end instrumentation very easy. This whole effort is to make it easy to think about and add instrumentation. If instrumentation is painful, lazy engineers will leave holes. Fun fact: all good engineers are lazy; that’s why they are so fast.

2. Abstract your vendors with Segment or MParticle

Now that your whole codebase is insulated, what happens inside “log_event”?

You should log analytics events using Segment or MParticle. I prefer the former. These services aren’t like Mixpanel, where you feed data and then look at dashboards. They multiplex out the analytics events to different services like Mixpanel and Amplitude.

This lowers the switching costs of trying new tools. It doesn’t require a code change! If you can try a new tool easily, you can move faster and have more agility with your analytics. This also means you aren’t locked-in to a specific vendor.

segment dashboard 600

3. Store you own analytics data

Segment makes this really easy, whether by using their webhooks to store events in your own DB or using their service to send the data to your database directly with “warehouses”.

Storing your data is essential because not every question can be answered with a tool. If Mixpanel can do it, awesome. If not, it’s better to code a solution on your own data than to not answer a question.

Sometimes it takes correlating events with other data you have, like subscription states or other objects in your DB. It could be that a Business Intelligence tool can help do this work for you, but if you’re just starting out, that is unlikely to be your best solution.

If you’re logging events from multiple platforms, syndicating out to Segment and getting everything back in one place with webhooks is technically less work than storing the data yourself first and then syndicating out to segment. For the latter, the biggest headache is working on APIs to ingest front end and mobile client events.

4. Instrument the User Experience

Now that you’ve established your analytics pipeline, you need to add your events. The way to do this is really easy: just pretend you’re a user. Walk through your onboarding and core product and write down what happens. Each event you notice matters.

If you have 10 or fewer, you should probably go into more detail. If you have 50 at the start, it will be hard making sense of them later. This is one reason I don’t like systems that automatically log events, because it’s hard to make sense of the deluge of events. Systems that do this, like Heap, might get better with time.

Note that it is really easy to add events, but this can cause headaches later. So you want to be conscientious about which events you have. The literal strings used as event names unfortunately matter here. So pick a format and decide on the degree of detail. You don’t want to have multiple events like: “User signed-up” and “SIGNUP”.

I like to put all the events in a single file in your code to the degree that is possible so that it’s clear what all the events are. Front end vs back end makes this painful to do 100%.

Sometimes having a high level event with a data attribute is better than lots of events. Let’s say you have a social signup experience using Twitter and Facebook, plus an email signup option. Sometimes you care about the channel but usually you just care about the signup.

So this is better:

{‘event’: ‘SIGNUP CLICKED’, ‘channel’:’Twitter’}{‘event’:‘SIGNUP CLICKED’, ‘channel’:’Facebook’}{‘event’:‘SIGNUP CLICKED’, ‘channel’:’Email’}

…than this:

{‘event’: ‘TWITTER SIGNUP CLICKED’}
{‘event’: ‘FACEBOOK SIGNUP CLICKED’}
{‘event’: ‘EMAIL SIGNUP CLICKED’}

Similar things are true for web page views, button clicks, and other kinds of events.

Eventually your data team is going to go crazy with the problems here and start versioning their analytics like your database, API, code base. I wouldn’t bother with that effort at the start.

What are some good events? Here are some that come to mind, as I imagine a user walking through some SAAS app:

  • viewed blog post
  • viewed landing page, with referrer tracking to the blog
  • clicked learn-more
  • viewed pricing page
  • viewed create account page/modal
  • entered email in create account form
  • create account form submitted
  • user signed up
  • viewed onboarding step 1
  • email sent, (welcome email)
  • user created project
  • user viewed integration page
  • user sent invite
  • invite landing page viewed
  • invite accepted
  • user sent message
  • user signed out
  • email sent, (subscribe email)
  • user subscribed

I could go on. This app isn’t even real and I came up with over a dozen things to track.

5. Product questions compel analytics NOT vice versa

So now you have instrumented events that are getting logged into data systems meant to analyze it. Awesome! So the next step is to look through Mixpanel, right? Wrong!

Start with your product experience and ask questions. Those questions will rely upon your analytics to answer them. Sometimes you might need to add new events to answer the questions. Sometimes you need to write code if the tools aren’t up for it.

The big problem with starting with the tools is that you are immediately biased by what the tool shows you. You aren’t thinking about the truth, but of the buttons and graphs on their dashboard. These are general purpose tools not designed just for you.

Don’t get me wrong: if you can answer a question with a tool like Mixpanel, go for it. But don’t confuse the tool with the goal. Your goal is to make your product fucking awesome. You do that with relentless focus on your users and their experience.

This last one is recurring. You have a question, sometimes add events, find your answer, run an experiment, and measure the results. Do this again and again to make your product better, which is the point of your analytics systems.

I’d love to hear what you think! Try this out, check out YesGraph, and email me: ivan@yesgraph.com.

Subscribe here to get new posts from our blog.

Creating a Web Referral Program with YesGraph

We write a lot about referral programs at YesGraph because our product helps make them better.

We’re written about which metrics to track, how to test whether a referral program might work, and described dozens of tactics to improve performance.

In this post, we’ll cover exactly what it takes to create a referral program and add YesGraph. This is for people just getting started. If you have a referral program and want to increase performance, start from step 4.

1. Invite URL to track referral signups

To track performance and grant rewards, you need a way of having one user share a link or code with a friend to get them to sign up.

Uber made popular having a referral code because lots of sharing was in person, but we have supercomputers in our pockets and links are easier to click than typing a code.

The simplest invite link just has the inviter’s username or a referral code, like this:

example.com/invite/kirigin

That url should go to a registration page. Making this a dedicated registration page separate from your normal signup form is a good idea because you can optimize it as a referral landing page.

2. Grant a reward

Many apps create an incentive to send referral invites. This helps motivate the inviter to send referrals and motives the invitee to accept the invite.

dropbox bonus

You don’t need to grant the reward just on signup. It can be deeper in the funnel. Dropbox required the invitee to signup, install the desktop client, and sync a file. This helps bring in better users and motivates users to go deeper into your product. It can also help avoid some fraud.

Note that regardless of the vendors you’re using, you’re probably going to have this build this part yourself. General purpose vendors might make system that work on some platforms, like Shopify. But granting a reward probably requires custom code.

The reward doesn’t need to be money. Extended trials, time on pro features, and some currency like Dropbox extra space all work in the right context.

3. Prompt users to refer

Think about marketing a referral program like you would any other product feature. It isn’t “if you build it, they will come”. It never is, but people seem to forget that for referrals.

In fact, tracking what percentage of your users even participate in your referral program is a primary metric. You should try to make it be as high as possible because this is the top of the referral funnel.

Start with prompts in your app and emails to your users. Consider creating multiple or recurring prompts so that it isn’t just new users that are told about the program.

Ideally, embed the prompt in the product experience. This is why messaging apps and social networks grow so fast: users are frequently active and the products are about communicating with friends. For example, for ecommerce or marketplaces, prompt upon purchase.

dropbox getting started

4. Add sharing channels, including contact importing

If you have an iOS app, congratulations, you’re done. Just add the YesGraph iOS SDK, which includes all the right parts for sharing channels and sending invites. Read more here.

We’re about to launch an Android SDK and also a web SDK that will completely solve this problem.

There are a few basic channels:

  • copy the invite link, to share wherever
  • social networks, like Facebook and Twitter
  • email, where you type in the contacts
  • contact importers, where you select among contacts

If you track the performance per channel, you’ll find email is the highest converting channel per invite. So the goal is often to drive more email invites. You just don’t have as much control over a shared link or Facebook posts.

So add a contact importer to really start to scale. Typical contact importer channels include Gmail, Yahoo Mail, Outlook, Hotmail, and Aol. It’s a fair amount of work to add these and others, which is why we’re building Superwidget.

dropbox invites

5. Add YesGraph suggested invites

The problem with contact importers is that there are typically hundreds if not thousands of contacts. If you allow users to send to all of them, your app will get marked as spam and your emails will stop being delivered. It’s a bad experience for everyone.

YesGraph helps recommend exactly who users should invite. The most successful apps use yesGraph to recommend who among the hundreds or thousands to invite. We filter out spam and duplicate contacts.

Most importantly, YesGraph builds a machine learning model to rank contacts just for your app. This is heavy lifting that normally only data teams at huge companies like LinkedIn and Facebook could hope to accomplish. The signal to noise is so high that you can even pre-select our recommendations to drive far more invites while maintaining an excellent user experience and good deliverability.

suggested invites

Send contacts and getting recommendations means using YesGraph’s API. If you have any trouble, email support@yesgraph.com. In short, raw contacts go in, and ranked contacts come out.  Read more about YesGraph’s API on our documentation page. We have an SDK for Python apps too.

POST /address-book → suggested contacts

To exclude current users from our recommendations, use the API to tell YesGraph whom to exclude.

POST /users

To help improve YesGraph rankings over time, tell YesGraph which invites were sent and accepted. This is the basis for our machine learning models and helps us understand your app.

POST /invites-sent
POST /invites-accepted

6. Track performance and iterate

Like any other product feature, there is a support lifecycle after launch. Referrals might be unique in how much optimization is worth it. Unlike other features, optimization directly leads to higher growth.

So you’re going to run multiple tests to get better performance over time.

YesGraph helps here too, in a few ways. First we automatically get better with our contact recommendations from tracking what invites are sent and accepted. We also constantly refine our invite flows available through our SDKs to put forth the best product design.

We also can help reflect what is working through our metrics dashboard. We reflect invites sent and accepted and have powerful cohort analysis tools.
To get started with YesGraph, create an account and invite your developers to dig in. Email support@yesgraph.com with any questions — not just about integration but about your whole referral program. We’re here to help you grow.

cohort graph 600 invites graph 600

Subscribe here to get new posts from our blog.