Show HN: Contactive API – Turn telephone numbers into full profiles(developer.contactive.com)
developer.contactive.com
Show HN: Contactive API – Turn telephone numbers into full profiles
http://developer.contactive.com/?hackernews
50 comments
Sales. The more you know about the people you're cold-calling, the better chance you have of selling them something.
"Turning phone numbers into full profiles" is a primary objective of every telephone marketing/"lead-generation" campaign in the history of time, and automating part of it by aggregating publicly available data seems only natural.
I would guess this is aimed less at telemarketers calling people's homes, and more at telemarketers selling business services (especially B2B startups), where cold-calling is seen as more legitimate and is the way a lot of business gets done. You want to know, at the very least, that you're calling someone whose job title indicates that they have the authority to spend money.
"Turning phone numbers into full profiles" is a primary objective of every telephone marketing/"lead-generation" campaign in the history of time, and automating part of it by aggregating publicly available data seems only natural.
I would guess this is aimed less at telemarketers calling people's homes, and more at telemarketers selling business services (especially B2B startups), where cold-calling is seen as more legitimate and is the way a lot of business gets done. You want to know, at the very least, that you're calling someone whose job title indicates that they have the authority to spend money.
The term "big data" stands for the nature of the data Contactive stores, which comes many sources. Most of this data is unstructured and unorganized, and we are able to structure and index it.
Every time we get new data, we have to compare it with the existing set. This is done in realtime..
So, the fact we have 600+ million identities ready to be queried is the result of having a much bigger dataset were all the non-matched-yet data is stored.
Every time we get new data, we have to compare it with the existing set. This is done in realtime..
So, the fact we have 600+ million identities ready to be queried is the result of having a much bigger dataset were all the non-matched-yet data is stored.
Hi. Thanks for the comment. We only use data that is publicly available (LinkedIn, Twitter, Facebook, Yelp (for businesses), etc.
Regarding the "big data" logic we use a lot of complex algorithms to provide accurate resolution and to be able to create compelling profiles. We consider ourselves as a "big data" solutions because of the principles we use to aggregate this data.
So the connected social networking data gathered from a person's use of the 'Contactive' app is kept separate and private?
As with everything, I'll assume nothing is free unless I'm the product.
As with everything, I'll assume nothing is free unless I'm the product.
Just because a phone number is publically available doesn't mean that the owner of that number wants all of their public information aggregated for an unknown purpose, which looks to be a pipeline for sales lead generation.
What use case is your product addressing?
And I'm sorry, but 600 million unique data entries isn't "big data" that would fit into a single Excel 2013 worksheet if you used multiple columns (570 ish columns) but still 1 worksheet.
What use case is your product addressing?
And I'm sorry, but 600 million unique data entries isn't "big data" that would fit into a single Excel 2013 worksheet if you used multiple columns (570 ish columns) but still 1 worksheet.
The 600+ million records are not just unique records since phone numbers are not necessarily primary keys. One of the challenges of Contactive is about indexing and building relationships between phone numbers, emails and social identities. Every time we collect new data, it is stored into the directory and indexed in realtime.
It is also important to know that we only index public data and also we provide an opt-out option if someone wants to be unlisted.
It is also important to know that we only index public data and also we provide an opt-out option if someone wants to be unlisted.
What's the provenance of this information?
Where's the opt-out, both for individuals with individual phone numbers, and for businesses who own large blocks of numbers?
Where's the opt-out, both for individuals with individual phone numbers, and for businesses who own large blocks of numbers?
We get all the information from public sources: Facebook, LinkedIn, Twitter, Yelp, Google Places, AngelList, etc.
You can always mail us to [email protected] for any privacy concern. We would remove any phone number upon request.
You can always mail us to [email protected] for any privacy concern. We would remove any phone number upon request.
Do you plan to be able to input 3rd party private information? I would like to import my 3rd party phone numbers database and related information, being only accessible for my API account. This could lead to interesting integrations with sales databases.
Yes! This is in the horizon of the product and it would be more likely to be the following step after we get out of beta.
Are you guys using Truecaller data?
How much out of 600M are Indian Contacts?
Can we have countries vise count of Data you own?
How much out of 600M are Indian Contacts?
Can we have countries vise count of Data you own?
Hi, thanks for the question. We don't use any Truecaller data. As a general break down by country, 51% of our resolved calls are from the United States, 4% from India, 9% from Spain, 9% from Singapore, and fairly dispersed after that.
Seems like Full Contact? http://www.fullcontact.com/
These are some difference with Full Contact:
- All Contactive API accesses are real time. If we have the data, we will return it right away, if we don't, we will try to find it as soon as we can and return it on the same API request. Full Contact uses the callback pattern, where they notify when they are able or not to resolve the information on a separate call (if they dont have it at the moment of query).
- Contactive not only gives you social network identities, it also gives you aggregated and prioritized data, like the job history of someone, or the list of pictures. This data is returned in the best possible way to be displayed. This saves time from developers because they do not have to make any effort prioritizing each field of the many sources we return.
- Contactive also gives you HTML rendering of a contact, allowing you as a developer to embed it on a iframe. This allows you to integrate it in a web app in a matter of minutes.
- All Contactive API accesses are real time. If we have the data, we will return it right away, if we don't, we will try to find it as soon as we can and return it on the same API request. Full Contact uses the callback pattern, where they notify when they are able or not to resolve the information on a separate call (if they dont have it at the moment of query).
- Contactive not only gives you social network identities, it also gives you aggregated and prioritized data, like the job history of someone, or the list of pictures. This data is returned in the best possible way to be displayed. This saves time from developers because they do not have to make any effort prioritizing each field of the many sources we return.
- Contactive also gives you HTML rendering of a contact, allowing you as a developer to embed it on a iframe. This allows you to integrate it in a web app in a matter of minutes.
Hi there,
I'm one of the lead engineers for the FullContact Person API and there's a few inaccuracies with your feature comparison that I'd like to address.
1) True, we can optionally do callbacks. However we'll return the data immediately if we've seen it recently. This is most cases. If callbacks don't work for you, data is usually populated within 10 seconds and can be polled for.
2) We also prioritize data. All of our fields that make sense are sorted and have flags to denote preferred elements.
3) We also have an HTML endpoint, however it's a terrible idea to embed into an iframe as you'll leak your API key. For this reason we recommend that our customers proxy calls through their own server-side endpoint to ensure their API key does not leak. That being said, we do provide the HTML endpoint, mainly for internal usecases where users can be trusted or cases where users bring their own keys.
I'm one of the lead engineers for the FullContact Person API and there's a few inaccuracies with your feature comparison that I'd like to address.
1) True, we can optionally do callbacks. However we'll return the data immediately if we've seen it recently. This is most cases. If callbacks don't work for you, data is usually populated within 10 seconds and can be polled for.
2) We also prioritize data. All of our fields that make sense are sorted and have flags to denote preferred elements.
3) We also have an HTML endpoint, however it's a terrible idea to embed into an iframe as you'll leak your API key. For this reason we recommend that our customers proxy calls through their own server-side endpoint to ensure their API key does not leak. That being said, we do provide the HTML endpoint, mainly for internal usecases where users can be trusted or cases where users bring their own keys.
Yes. The difference is that our core data is based on phone numbers. Instead of an email address you can query a phone number and retrieve a profile associated to that phone number. Imagine "Full Contact" for phone numbers.
FullContact also offers searching by Phone Number. Its not very good though. How is your's better?
Well. We have a much more bigger phone number database and provide very compelling profiles associated to each phone number. Full Contact doesn't focus on phone numbers. We do.
As a matter of fact, our API powers our core services like our Contactive Caller ID app which has more than 1 million downloads in the Google Play Store with a consistent 4-5 star rating.
As a matter of fact, our API powers our core services like our Contactive Caller ID app which has more than 1 million downloads in the Google Play Store with a consistent 4-5 star rating.
Direct question: are you using the app to collect info about the users to you can enhance your database also based on that data?
We use the app for machine learning purposes. When you get a call that cannot be identified, we ask the user to input the name of the caller.
Additionally, if we identify a call, but the resolution has low confidence, the user will be prompted to vote it up or down. This feeds directly into our identity graph, recalculating in realtime the connections between identities and contact information.
We also use the client app to enhance the existing connections in our identity graph. Each edge in our graph has a confidence level, and by using the data available to the app we adjust and recalculate the confidence levels of our directory in real-time. We never publish data points like photos, notes, etc. from the address book of our users.
Additionally, if we identify a call, but the resolution has low confidence, the user will be prompted to vote it up or down. This feeds directly into our identity graph, recalculating in realtime the connections between identities and contact information.
We also use the client app to enhance the existing connections in our identity graph. Each edge in our graph has a confidence level, and by using the data available to the app we adjust and recalculate the confidence levels of our directory in real-time. We never publish data points like photos, notes, etc. from the address book of our users.
So the answer is yes??
I'd be interested in knowing the answer to this too.
Do you also work with email addresses? i.e. give you an email address and get a profile back in return?
Yes. It would work. We are very focused on phone numbers but we have a big and growing email address database.
Who would want to use this, other than inbound sales teams? Customer support already has it, and it is not that useful to go from phone number to profile as it is to go the other way.
This looks interesting to integrate with sales apps. What are the demographics of the 600M phone numbers? Mostly US? Percentage of business/residential?
As stated on webpage:
"Contactive provides enhanced information for 86% of incoming calls in the U.S., and for more than 50% globally, adding rich context with photos, names, companies, addresses, and more."
Exactly! These numbers represent the percentage of API calls that we resolve depending on the numbers' country.
That is, we are likely to add information to a phone number if the phone number is from the US, but we also do quite well globally.
Around 50% of the numbers are from the US and most of them are residential. We estimate that around 1% of the numbers are from businesses.
Bingo! This is precisely what I was looking for. With the number of calls I receive, I need to figure out which ones I can safely ignore. Contactive rocks.
What is the price of this after 1000 queries?
What if the person who calls doesn't want to show his profile to man that he call to?
This is the beta of our API and we have pricing plan with SKU's upon request. We first want to get data on what a typical usage of the API looks like.
This + twilio = user identification. Looks like I'm gonna have to be more careful with my phone number...
We know there may be some privacy concerns regarding the use of our data but we don't allow anyone to systematically query our API to build phone number lists (We just allow 180 requests per min) We are very strict in the way people use our API. That's the reason we don't have an open registration process.
Yikes 180/m may seem like a lot ... but in the world of data that is a very small amount of usage. Your site says "big data" so this limitation begs the question -- Are you big data (enterprise) or not?
180/m? That's a database of over 10,000 records in an hour, and that's only if the querying party is stupid enough to not think of using multiple API keys in parallel.
This is already a business reality for most savvy organizations. Example, ordered pizza on saturday. Sunday, call another branch of the same pizza shop and the person answering the phone greets me by name before I even have a chance to say hello...
I was creeped out for a second, but then proceeded to order more pizza.
I was creeped out for a second, but then proceeded to order more pizza.
There's nothing weird going on there.. They took down your name when you called and they simply log you in their system with the phone # you called in with, your name, and likely your address if you got it delivered.
Information sharing is only recently the norm. Even between different branches of the same pizza chain.
I'm just saying it's not likely they used a API or something to find your name from your phone number. They are just using good ol manual registration to make your ordering time faster next time.
We would like to add this feature to our app. How often do you guys refresh your data?
We have partnerships with other data companies and we also use the social network APIs.
Everything is stored in a graph and to make the connections between phone, emails and identities we've created algorithms to compare contact information. For this we use signals like name similarity, location, friends in common and many others.
All of this is indexed in realtime and when you do a query to our API you get the most up-to-date data.
Everything is stored in a graph and to make the connections between phone, emails and identities we've created algorithms to compare contact information. For this we use signals like name similarity, location, friends in common and many others.
All of this is indexed in realtime and when you do a query to our API you get the most up-to-date data.
This looks like a ripoff of EveryoneAPI.com
We solve a similar problem but our approaches are different. For example, we don't charge for every bit of information and we integrate with social networks to provide a more complete version of the profile, including job position and education.
Hi Chris Brunner here, from EveryoneAPI.com. I agree that this is not a ripoff of our product. As uqimu stated, we're solving the same problem, but we use very different sources. While social is a component that we utilize, it is not our primary source. hackmorris is correct that we'll be adding more datapoints from social shortly, and uqimu is correct that we don't offer all of it today.
I look forward to checking out the Contactive API, and perhaps even having a discussion with them to see if there is an opportunity for us to work together.
In the meantime, since our product was mentioned here, I'd be happy to field any questions.
I look forward to checking out the Contactive API, and perhaps even having a discussion with them to see if there is an opportunity for us to work together.
In the meantime, since our product was mentioned here, I'd be happy to field any questions.
I was told by phone that those same features are coming soon. I am going to check out your product and theirs and run some accuracy and coverage tests.
Also what does "big data logic" mean?