This is a slightly edited version of the talk I gave at the MyData 2017 conference, during the technical building blocks workshop
👋🏼Hi, I’m Ziad WAKIM — the founder of Kumbu. I hope you’re not too tired. I promise we’ll all make it to the boat :)
I’m the founder of Kumbu, the digital souvenir box — I’m not going to talk about it today, but I will share some of the thoughts and conversations we had as we were building it, and try to put that in a broader context.
Trade-offs
It is now super fast to build a new internet service. With a few clicks, anyone with a little bit of technical know how can get up and running really easily.
But this velocity has trade-offs, especially as startups grow. Technical conversations usually focus on trade offs such as security, build vs buy, or cost — but today I want to talk about the privacy trade offs.
I’ll say it from the start, I favor a balanced approach, with ideally informed consent from the consumer. That is, I’m not advocating for building everything from scratch nor keeping absolutely no record — What I’d like instead is to present a framework for thinking through these issues, and helping startups make the right decisions.
Levels of Customer Data
I’ll start by describing more precisely what I’m talking about. There are 3 levels through which we can consider customer data :
- What the customer think they’re giving you
- What you’re collecting and how you use it
- What you’re expanding, leaking and sharing
Even for privacy minded end user, customers generally underestimate the quantity of data they’re sharing
The general rule is, even for privacy minded end user, customers generally underestimate the quantity for data they’re sharing directly or indirectly with you. That’s probably a topic for a separate talk, but it ties into our particular challenge here, which is that expectations are mismatched from the start. This gap makes it very difficult to obtain informed consent from customers, especially if you’re relying on providers with un-clear data collections themselves.
The second topic is what you’re directly collecting. This has been covered in a couple of the previous talks, but how often you update, change, or assess the quality of your internal data collection policies is something you should pay attention to from the start. Customer databases for marketing and sales of course, but also support. When we built kumbu, it was important for us that in support scenarios, the customer could trust that we wouldn’t get access to their data — and so we’ve had to consider proper procedures to handle support, both to educate and re-assure our customers.
But what I want to talk about today is really the third point, which is the data that, when building a startup we’re sometimes not even aware we’re leaking.
What Startups usually outsource
Let’s look at the building blocks that a startup typically outsource:
- Analytics (Google Analytics)
- CRM / Messaging (Intercom)
- Email Automation (Mailchimp)
- Social Sharing (Facebook)
- Error Messages and logging (Rollbar, Papertrail)
When you’re focusing on building a new product, you’re not going to spend time re-inventing the wheel — and SaaS services are a cost effective, and arguably better way of dealing with rapid scaling than building it yourself.
But let’s look at data collection policies for those providers. If you read the terms and services, which you haven’t, you’ll notice that they all comply very seriously with all privacy requirements towards yourself as an individual user. For example, intercom won’t share your usage of their application with law enforcement unless compelled to. They’re protecting you, as their user and customer.
Most services are very vague about what they do with the information they collect from your users
But, and I don’t want to single out a particular company here, most of these services are very vague with what they do about the information they collect about your users. They acknowledge they share some of it with 3rd parties (so they can expand from an email to a probable twitter handle, etc). But it looks reasonably easy for them to run a query such as “for a particular email adress, how many “powered by x” services does it subscribe too?”. It can get even more complex than that, because many SaaS services embed 3rd party tracking themselves.
Remember that your customers aren’t their customers, they’re data
Customer Privacy as part of your selection framework
These scenarios leave us with 2 issues :
- How do I chose a 3rd party SaaS service that will respect the privacy of my customers ?
- How do I communicate this to my customers in a way that ensures trust ?
For choosing a service, here are a few questions that are worth asking :
- Do we actually need it ? (This is a good question to ask for google analytics for example)
- What amount of information are we sharing ? Is there a way to minimize it ?
- What do they say about their data collection practices ?
- What do they say when we contact them about it ?
That last bit can yield surprising insight. It will tell you how in tune the company is about their practices for data collection. If you can’t reach them, or if they seem tone-deaf about the issue, that’s a red flag for us.
Of course those shouldn’t be the only questions you ask yourself before choosing a provider — there are technical, contractual, security and performance topics to consider as well. What I’m advocating for here is for these questions to be added to your list.
Here’s how it broke down for us :
- We’re not using Google Analytics, nor social share buttons in the app
- After reading and understanding their ToS, we’ve picked Intercom, Mailchimp and Papertrail
Of course your mileage may vary — it’s up to you to figure out what’s the right mix for your company.
Then there’s the “how do you display it for users”. To be honest, we’re still struggling with this one. We went back and forth on our privacy policy, and we’re still not satisfied by it. Here’s where we are now:
- We list all of our third party software in the privacy policy. This is important as a first information step.
- We provide contact information for users who want to know more, and encourage them to ask. We get requests roughly once a week. It seems to work better than saying too much on the site (to my dismay), because being too straightforward actually scares some customer away (and I take this as a way of us not having found the right way of explaining this to our users)
Let’s talk about this
And with this, let’s go on a boat and keep the conversation flowing. As you’ve seen, we have more questions than answers, and I’m eager to learn how you’ve dealt with these issues yourself.
