Did you know password sharing is costing OTT and streaming media providers big money? At least $2.3 billion a year for Netflix, according to a recent study by Cordcutting.com, and an estimated $1.5 billion in 2018 for Hulu, according to a CNBC report.
Watch this webinar to Learn 5 easy ways to crack down on password sharing and to see examples of how OTT/Streaming Media providers are using IP GeoPoint decisioning data to mitigate password sharing and protect their subscription revenue.
Moderated by Eric Schumacher-Rasmussen Editor-in-Chief of Streaming Media, Jason Thibeault, Executive Director, Streaming Video Alliance, and representatives from Neustar will share strategies for reducing revenue loss from password sharing.
Attendees will learn:
- How to identify subscribers who are likely sharing their passwords
- 5 recommended best practices for using IP decisioning data and analytics to address password sharing in a way that balances both content licensing mandates and the customer experience
- Examples of how providers are using decisioning data and subscriber communications to crack down on password sharing
Hello and welcome to today's StreamingMedia.com webinar sponsored by Neustar. I'm Eric Schumacher-Rasmussen, and I'm the VP and editor of Streaming Media magazine and StreamingMedia.com. And I'll be your host and moderator today. And today's webinar will pose the question are you delivering subscription-based content? And we'll provide some answers for five ways to crack down on password sharing.
Before we get started, just some quick housekeeping notes. We will have a live question and answer session at the end of the presentations, but you can ask your questions at any time during the event by entering your question into the Q&A box provided and then hit the Submit button. When the presentations are done, I will read the questions to the speakers. And if we run out of time and don't get a chance to answer your question during the event, someone will get you an answer offline once the event is over. Also this webinar will be archived within 24 hours for on demand viewing, and the presentation will be available as a PDF download once that archive is posted.
Now let me introduce today's presenters. We have Jason Thibeault, who is the executive director of the Streaming Video Alliance, Steven Hindman, the senior product manager from Neustar, and Jackie Wadhwa, the IP Geolocation specialist and customer success management head at Neustar. If you'd like more information on today's presenters, you can click on the arrow under their photos on your console.
Problem with Password Sharing
Let's take a quick look at our agenda before our first speaker today. We'll start by talking about the problem with sharing passwords. And then we'll get a perspective from the Streaming Video Alliance with Jason Thibeault. And then we'll talk about extending the value of your IP decision and data, the five best practices to prevent password sharing. And finally, we'll look at some success story case studies before we go into the Q&A. And with that, I'd like to pass the event over to Steve Hindman, senior product manager at Neustar. Steve?
16% of Game of Thrones Finale Viewers Were Password Sharing
Hi there. Thanks, Eric. As Eric said, my name's Steve Hindman. I'm a product manager. I work on our IP Geolocation service. And what I'd like to tell you about is password sharing. So is there a problem? It really depends on if your revenue depends on individual logins or not. A number of third party surveys have indicated that password sharing is on the rise, particularly among young people. A recent survey found that it was 16% of the 17 million viewers total that watched the HBO finale of Game of Thrones said that they were doing password sharing. So that's a significant amount of revenue potentially lost to HBO. And the real question is does HBO care or not? And that'll be up for you to determine. And hopefully, we can provide you with information that will help you make a better decision on that. And so now I'd like to hand it back to Eric so we can go to our next speaker.
Streaming Video Alliance
Hi. This is Jason with the Streaming Video Alliance. Thanks, Steve. So talking a little bit about password sharing. Before I do that, I want to explain a little bit about what the Streaming Video Alliance is. The Streaming Video Alliance is a global organization. And we represent video companies from across the ecosystem.
So we have member companies that are network operators, content owners — that's slash rights holders — service providers, and technology companies. So we bring together all of these companies to basically collaborate on best practices and create specifications from functional requirements to make for a better viewing experience. The ultimate goal is to provide some consistency across the industry so that end users when they move from one service to another pretty much get the same quality, whether that's comparable to broadcast television or even greater.
And so we have a couple missions you can see on the screen. We try to educate the industry about what those challenges are. We provide a forum for collaboration. Even competitors come together and try to solve problems together. And then we try to define solutions. And again, those documents like best practices and things. So putting that into context, now, we have a lot of conversations around the water cooler and in our working groups and elsewhere amongst member companies about things like password sharing.
So if you start thinking about this as a problem, you can see that from a broad swath of our members, we have issues. And a lot of our members companies are struggling with how do they stop password sharing? I guess "stop" is not necessarily the right word. It's really how to mitigate and control. Obviously, there are companies like Netflix who have made a business model out of allowing people to share their passwords with a certain number of people. But consumer behavior has changed so much that they're actually exceeding even those thresholds. If you're allowed to share with four people or six people, well, what if I share with just a couple more? It's no big deal, right? So there is definitely a conversation that's happening amongst our member companies and within the industry about what you do or what can you do to really help mitigate that problem.
So thinking about it as really a growing issue. Obviously, you have companies in our membership and in the industry that are focused on technological solutions. So how do you keep people from sharing passwords to their friends and family? By, for example, georestricting or identifying where people are logging in and understanding that's not their home turf. There are other ways too that they're looking. Some of our member companies will look into their logs. So they'll examine patterns of behavior amongst their users and their subscribers who are definitely probably password sharing. I just realized I said "definitely probably." But they're most likely password sharing with their friends and family. Or even worse, they put their credentials out on the web for anyone to use.
So there are definitely issues here that are trying to be solved technologically, trying to be solved from a manual process. And then there's obviously business models that companies like OTT distributors and network operators are exploring as even an alternate way to take advantage of that. So if a certain number of your users are sharing passwords, perhaps there's a means to upsell them or convert them to a higher tier of service. So there are lots of discussions happening especially within our member companies and around the industry about how this problem can really be solved. But it's definitely recognized as an issue that needs to be addressed. Now I'll hand it back to Eric.
5 Geolocation Best Practices
Thank you very much, Jason. And now I'd like to turn things over to Jackie Wadhwa, the IP Geolocation specialist and customer success management head at Neustar. Jackie.
Thank you, Eric, for that introduction. I'm looking forward to reviewing what we've picked as the top five best practices when you're looking at password sharing. There's so many other best practices out there, but we picked the top five that we thought are going to be the most important to review on this webinar. So first and foremost — and by the way, I'm going to have some help from Steve here as well on some of these. So I'm excited to be able to share this with everybody and have Steve coming from the product space helping identify some of the best practices here as well.
1. Have location data of end users
So first and foremost, the best practice that we have is the location. If you don't know the location of your end user, you're not going to be able to do anything at all, right? I mean, that's first and foremost. That's foundational. If you know where the login is coming from, you can make decisions on how to treat that end user or the subscriber. At the very least, you can know whether to flag a login for further investigation.
So the best practice is obviously identify the location. And that may depend on the granularity that you care about as an OTT operator. Do you care about country? Do you care about more granular city or DMA if you're in the US? And being able to identify whether that content should be served or not or whether that person who logged in is within the limits of where they picked up the subscription from.
And having also insights into how they are connected is very important. So not just the location, but are they coming in through a mobile data connection such as 3G, 4G, LTE? That's really important to know because of how mobile carriers can handle traffic. So you might want to flag that and ask for an additional step into where they're logging in from.
And then if you're familiar with anonymous proxies, this is a very huge thing to be able to identify as well because that end user could actually be sitting anywhere in the world, right? Coming in from a proxy in the US, but they could be sitting in France, for example. And they're not supposed to be identifying the content there, or they could have shared their password with their best friend who lives in France to be able to access certain content that's only available for the US. So you'd be able to flag that. And it's a very huge component to understanding where that user is by just knowing the location. The second best practice on the next slide, Steve is going to go ahead and go.
2. Identify anonymous proxies
Yeah. And I just want to add one more thing to what Jackie was saying, which is that typically, a few years back, almost anybody could get location information from a registry. Unfortunately for us or for OTT providers, now these days, registry and privacy laws are making it much harder to just do essentially screen scraping or collection of that information. And so it's becoming more challenging. You can rely on the browser or the client to provide that information unless you're dealing with a user who specifically wants to remain hidden, or else the user wants to present a false idea of where they are. And the way they would do that is by using a virtual private network or an anonymizer service.
And so these anonymous users are going to mask their identity. They may present no IP address because they're completely blocking it. Or they may present an IP address that when you do some sort of look up on it, it says that it's in the country that's allowed to view that content or is allowed to access that service or whatever. But there's some ways that you can identify that.
And so some Geolocation services will identify that this address has been previously associated with a proxy or VPN. And they'll provide you with that data. Then you can build algorithms around that to say, Ah. This is not a pure IP address. This is coming from an anonymizer. Maybe I should build some rules to deal with that.
And so one of the rules you might want to build to deal with a situation like that is when you're able to identify that this is a VPN or anonymizer address, you ask for some secondary identification. And this is non-threatening to the user. You're not cutting them off immediately. You're saying, I just want to make sure you are who you say you are. So in those cases, it's probably much less likely that your paying user would have shared some other secondary credential with a family member, a friend, especially they wouldn't share it with the general public.
So by doing that, that allows you to keep your users that were OK'ed allow to get in. But meanwhile, you're providing an extra layer of security or prevention to keep out people who are just sort of free riding. So now let's turn it back over to Jackie, and she can tell us about one more best practice.
3. Tracking typical user behavior patterns
Sure. So tracking typical behavior. So as your subscriber logs in and as they continue to login, you start to see patterns that come up of where they're logging in. They're always logging in from a certain IP address or location, and it's consistent. Now, you can build that to add into a user profile, which can be a very powerful tool for weeding out what we're calling bad actors or suspicious activity.
For example, when you aggregate the user's login behavior and compare real time data, you can flag outliers for further investigation. So I think an example of this would be most users have at most two to three simultaneous logins from locations within, let's say, 50 miles. I know at my house, two or three of us might be logging in at one time watching something on video on demand. But you can build a decision to flag logins from the same account that occur within 30 minutes from each other that are actually maybe 50 or more miles apart. Because that might mean that there is somebody else that has access to that password and is logging in.
And the result is that you're actually losing revenue because somebody might be sharing that password and being able to watch on somebody else's dime, right? And that's not exactly what most OTT operators are looking for when you have a subscriber base. So some of the best practices are capture and store the user's location consistently visited, flag and filter users who are frequent travelers — like myself — and request additional authentication for login activity that is outside of their normal behavior.
So you can just have a pop up and be like, oh, it looks like you might be traveling. Can you please confirm? There are little things that you can do here or there to help identify is this a legitimate user logging in with that password or not, for example. Steve, would you want to talk about the next best practice?
4. Build baseline profile of user activity
Sure. So building on top of what Jackie said about monitoring, building a baseline profile of your subscribers or your users, you can start to think of new ways to differentiate between legitimate logins and false logins, because you have some background data. So one of the things that we look at is something called a velocity check.
And what that means is that if you know that a certain user — you can build historical information on how often they login, frequency of login, where they're logging in from, et cetera. Then what you could do is actually say, oh, this user typically logs in from — I don't know — an IP address here in San Francisco. But I've noticed that 30 minutes later, they logged in from New York using the same credentials.
This would be the case of not where — we're talking a password like Netflix where you can have four users on the same account, and each user has a different user. But if someone's logging in Steve in San Francisco, and then they use Steve again in New York, and it's 30 minutes later, one of those two is probably not really me. So that's where you can, again, do things like ask for a secondary two factor authentication or other types of credential check just to make sure that this person is who they say they are. Let's see. So now we'll go back to Jackie again about one more best practice.
5. Adopt flexible user rule and policies
So the last best practice we have — and again, we have many we can talk through — but the last one is always, I think, a valuable one because you don't want to outright block somebody you might get — anyone that's trying to watch content online and gets blocked is not going to be very happy about that. So if you have a zero policy for just blocking somebody outright, you're going to have some unhappy customers, especially if they're legitimate. And you're going to have higher churn, which is also not what anybody is after.
So new customers cost more to bring in versus keeping existing customers, right? So you don't want to upset them, block them from content without having some sort of soft enforcement, for example. So some of the best practices that we have here are rather than just be like sorry, you can't watch us because you appear to be in a location you shouldn't be, have the soft enforcements be around having a dialogue that assumes that it is legitimate behavior or a message of concern, for example.
Hey, we've seen your login pop up in three applications in the last hour. We're afraid that your password might have jeopardized. Please let us know if this is an issue. So having little messages there that are not saying, hey, we think you're sharing your password. Because again, people might get defensive and upset, and then you lose your customer.
You can request verification. You could set a deadline too. For example, yes, we've seen your user login from three different locations that are 200 miles apart. Please let us know within the next 30 days if this is legitimate or not. Otherwise, we're going to have to disable your service until we understand more what's happening, for example. Or have some challenging questions.
Pardon to interrupt, but that's a great example because if you think about when people are speeding going down a road, and you see those radar signs that tell you what your speed is, you will slow down. So I think if you tell users that we know who's logging in, that's probably a soft way to deter them from — so tell their friends. Maybe you shouldn't do that.
Caution. We know what you're doing.
[LAUGHS] Yeah, that's a really good point. So an example is if you block all anonymizers or VPN [?] accounts immediately, we've seen that it can result in up to 10% false positives, and therefore, a 2% increase in churn. So again, to avoid that, maybe send an email to the account holder asking for more verification to reduce that false positive and to prevent churn.
So those are our five best practices. I think they're very foundational when you're looking at how password sharing might be occurring or how to avoid customers from password sharing and therefore hopefully be able to enhance your revenue, because you'll have to have these people actually sign up for their own account. And what we also thought we'd talk about are some of the best — or sorry — some of the case studies that we have, with some of the experiences we've had within our own customer base. We are not allowed to actually talk about the specific end user customer name, but we can talk about at a high level what they're doing and how our data is helping alleviate certain challenges that they've had.
IP Address Data and Geofencing
All right. So I'll go first here. I'd like to talk about one of our customers. It's a [LAUGHS] big sports streaming provider. And the issue that they have is when they televise these games, they need to be able to block the games based on the home location. It has to do with whether or not the stadiums or the fields or wherever they're playing are sold out or not.
And so one of the data that they look at is the postal code because that is a good map. It's more precise than just, for example, the city because some parts of postal codes may be considered part of the city, and some are not. And so if you can get a data source like that provided by Neustar that has the postal code, you can then do a look-up IP addresses — which they do — and then they determine whether or not that particular customer is eligible to view the event or not. We also provide even more specific levels of detail that they build algorithms around called confidence factors, which lets them know we feel very strongly or not that these attributes are actually valid.
In some cases, you may find — and this is typically overseas where data is sparse — that there may not be enough data to make a strong case one way or the other. But within the United States, most vendors have very strong data. I will hand it over to Jackie now to talk about another one of our customers.
Using Geolocation Data to Identify Outliers
Thanks, Steve. So we have a large cable alternative provider. When you hear people cutting the cord, they go to these alternative OTT providers. The one that we're going to be talking about here is based in the US. And they go down to the DMA level. The DMA is a designated marketing area. And that can span postal codes, even in some cases states, depending if they're on the border, for example. And that is to be able to provide local listings. So if I'm sitting in Chicago, I want to see the Chicago listings as opposed to just seeing an LA listing, which might have nothing to do with where I actually am.
So the business need was, as I mentioned, identifying down to the DMA level based on where that user is coming from through their IP address. Identify any potential suspect activity. So that may be outside of the user's DMA or viewing area. And then also they needed to be able to differentiate between a normal user, related travel logins, and password sharing. So again, what we talked about earlier, one of the best practices is the patterns, the profile logins and the patterns, and knowing the usual locations of an end user.
So the solution here was, as I mentioned, we provide DMA level in our database. The IP Geopoint provides that. We also provide confidence factors, which Steve just mentioned. It is a number of 1 to 99 essentially that helps you understand how confident we are in that end user's location being in the same vicinity as that IP address.
Also our IP Geopoint data identifies whether the login is coming from behind anonymous proxy so you can flag that. And customers, as Steve mentioned, one of the best practices, do a velocity check by associating server login time stamp with user location. If somebody logs in in LA at 2:00 Pacific coast time, and then they login again an hour later from New York, why is it moving that fast? It could flag that.
And Neustar's product and support teams are able to help identify a custom solution. So we can sit down with you and help understand more about how we can help with your support requests that come in based on feedback, that you're getting for any discrepancies and things like that so that we can make sure that the IP addresses that we're seeing are identified and corrected if needed because IP addresses change every day. We don't have insight. Nobody tells us we're going to reallocate this IP address to a different location tomorrow. That doesn't happen. So by working with our customers and seeing how some of the natural dynamic traffic is changing, we're able to actually keep up with that information as well.
So that's the use case for this cable alternative provider. We have another use case, I think, that Steve's going to talk through.
Geolocation Data Sources Need to Work Together
Yeah. So we have a satellite broadcasting provider who's actually switching or adding a streaming video mechanism. And the way that they do their content fencing is they're using zip codes — zip codes and counties, actually. So zip code/postal code is pretty standard information. Counties sometimes are not available. So depending on — this is just something you can — depends on how your database is set up, really. So this particular customer, they prefer to use county to do fencing.
But in all other aspects, they're completely like any other vendor. So the key here is that when you pick a Geolocation vendor, make sure you understand how your business systems work so that you can build an architecture for customer login, password enforcement that matches up how your business systems are. And the other thing that you'd want to look for is the vendor that you work with or even if you build it in-house, just make sure that you are able to get feedback from your users because there may always be false positives. You can never absolutely eliminate them. But what you want to do is if you do get a false positive on a password sharing enforcement, you can always resolve that short term. You don't want this to go on as a continuing issue because then you eventually lose that customer.
So the ability to update your system with feedback. Essentially, the customer calls customer support, customer support validates that maybe they're slightly outside the county or the postal code that says yes, you're actually within your rights. You update your business systems, the customer does not see that problem again, they don't call in.
And there's a secondary impact. Other customers who are located nearby to that particular customer, they will not see the problem either because typically when you update, we don't update one IP address at a time with a location. You're updating a block of IP addresses. So by making these positive what we call geofeedbacks, it can leverage a positive effect on your customer support side and reduce future calls from other customers in the same area. So now we're going to go — we have one more.
Yep. One last one.
And I think this is a good one to talk about because it is a global OTT provider. We talked about some of the US ones. So this one, that they provide content globally, they have licensing restrictions globally on who can see what and from where. And so they need to identify the end user's country and control access to licensed content based on Country's end user login that they are originating from.
So there are a couple of ways that people can go around this. And so we wanted to help with the solution to be able to work with the database that provides not only country level information and confidence factors, which I mentioned earlier, but also it's really important to identify anonymous proxies. So I could be living in the Netherlands and wanting to watch US content, I could easily proxy through a US anonymous proxy if it's not being actually identified by a IP location database.
So the solution was have a Geolocation center that does provide anonymous proxy identification where possible and be able to block that end user so that they go through another set of questions with this global video on demand provider before they can actually access that content. So it's really important at a global level to be able to identify where IP addresses are coming from.
So with that, those are the case studies that we have that we were able to review with you all. We're happy to go into some.
Yeah, I guess we'll hand it back to Eric and see if we have any questions from our viewers.
Thank you very much, Steve and Jackie. And yes, we've got a number of questions here. And there's still time. If you do have a question, you can submit it in the Q&A box and click Submit, and I will pose to our speakers.
What's the difference between rights holders and content providers?
The first question here is really about definitions. And so I'll ask JT from the Streaming Video Alliance to take that one. And in this industry, just like any other industry, there's so many changing terms. What's the difference between rights holders and content providers? Are they the same thing, JT?
Yeah. So I think we're seeing a lot of blurring the lines between those two terms. Traditionally, yes, they are very different. You had rights holders like, for example, HBO, somebody who produces content and licenses it out to other providers like cable companies. But over the years, as companies like Netflix and Amazon have started to not only license content from other people but create their own content, they've become rights holders as well as content providers.
So there is a lot of blurring in the industry right now. We're starting to see some combinations of those things come together. But with a lot of the direct consumer plays that we're seeing as well — like Disney+ that's coming out and the new Time Warner offering that's going to be coming out — what they're starting to do is they're starting to pull their content in from being licensed and starting to create offerings that will push it directly out to consumers. So in essence, yes, rights holders and content writers were separate ones. They came together as a business model, tried to figure themselves out, and they seem to be like they're pulling themselves apart again.
Thanks so much. That's very helpful. The rest of the questions are more granular in nature. So let's dive right in. And these will be for Steve and Jackie. And the first one is should I allows users who are behind anonymous proxy to login to my service?
Should I allows users who are behind anonymous proxy to login to my service?
So I'll take a stab at that first. I think the key is what type of information are you trying to protect? What's on your service? So as we talked about in the presentation, you may want to allow users from an honest proxy to login, but you may want to require a secondary form of authentication. If your service is, for example — if you have something confidential so it's not simply streaming content or — let's say for example that we have some customers who are running online gaming.
There may be severe penalties from the state or local government for allowing people who are not clearly within the territory that's allowed to play that game to play. And so in that case, you may not want to allow anonymous proxy to login. You may have to tell the user we see you're an anonymous proxy. Please exit that service and log back in in order to use this game. Did you have anything to add to that, Jackie?
No, I think you're good.
Which companies provide complete credential sharing detection solutions today?
OK. Why don't we answer the question from Steve F's team at CineMedia?
Yeah, go ahead. Yeah. Steve from CineMedia asks which companies provide complete credential sharing detection solutions today?
So the credential sharing detection, in terms of that level, really, you have to build your own systems around that because it's private. It's called PII, which — I'm blanking, Jackie. Help me out.
Personally identifiable information.
Yeah. So essentially, you would have to — because the PII is your own information, unless you can work with a company that has a way to firewall off their services and allow it to interact with your data kind of like a private Geopoint, for example — I'm not sure how many companies have that. Neustar has it. But what you would want to do is build something internally that uses external data such as we talked about Geolocation data that matches that data to your own credentials, your own business information. And then you build your own logic around that because everything has to be tailored to how your company wants to do the credential sharing enforcement and also what your business systems look like.
What's the best and simplest solution to prevent password sharing?
All right. Very good. Our next question says my requirements are pretty basic. I live stream conferences and workshops for associations who charge a ticket fee to each viewer for watching the webcast. While these events are, in fact, password protected, many viewers cheat by sharing their password with friends or colleagues, thus causing a loss to the association. What's the best and simplest solution to prevent this sort of thing?
This is a really interesting use case and a really good question. So I'm glad we're getting this. Thank you, whoever sent that in. So I would essentially first off look at who you're working with, the association that you're working with for your live stream conference and see if they have some sort of Geolocation embed into their system.
So that way, you could start building out requirements and rules that you might have of who you want to see. The content would say you only want people within the US to see it. So you could put that as one of the requirements assuming that and hopefully that the workshop you're working with or the association you're working with have some sort of Geolocation in place.
The other thing is you mentioned passwords. Is it the same password to login for everybody, or does everybody have an individual password? So what you could do there is only allow that one password to come in if it is unique to each user. And that's what I would suggest as well. And then you would be able to see that somebody is logging in with ABC123, and then you see somebody else logs in with ABC123 from a completely different location, you'd be able to block that end user from login, and they have to pay for that to be able to get back in.
You could pop up something that says we see you already logged in from this username and password. Please double check, or please resubscribe with a new username and password because this person's already logged in. Something simple like that. But first and foremost, I would find out if the association you're working with and the live streaming platform that they're using have some sort of Geolocation in place.
It looks like she's saying they do have Geolocation built in from North America only. So it sounds like maybe it depends on whether they're seeing sharing come from within North America, or if it — if not, that could be — if it's external, then they have to expand their Geolocation solution to include other countries, I guess.
Right. And if they're only doing North America, they'll be able to identify that IP address is not in North America, right? So they should outright block that. And again, if you're using a unique password for everybody that signs up, I would say that would be a great requirement to have. And then, again, if that person's trying to login twice, you'd see that they're sharing it. They'd have to block that one person the second time they tried the attempt. That's what I suggest is the best practice there.
Oh, it's interesting. So it looks like they've tried different password techniques. I guess you might want to reach out to find your provider and trying to — hopefully a provider that does consultative understanding of your specific problem, and see if they can help custom craft a different solution or augment your existing solution, try other things other than what you've apparently already tried.
Very good. The next question goes back to Neustar specifically.
How often is your database refreshed?
So the standard refreshes weekly. But we do have options for any of our customers that want to do daily. We could do daily for just not only location, but for also anonymous proxy information as well.
OK, the next question has to do with how you deliver information to customers. What sort of reports do you give customers? And how can your customers expect to receive information from Neustar?
Sure. So we have several methods and delivery methods that our customers use. The two most popular that our customers work with are either what we call an on-premise what we call a [? duo ?] directory server. It's on premise. It's locally in your environment. It has been set up to have tasks to look for updates every day, and it will pull one of the ones available. Again, the standard for that is weekly. We also have a hosted service, hosted API. So our customers, instead of having them manage it locally, we manage it in the cloud. So those are the two most popular ways.
Great. One thing that's been in the news a lot lately is credential stuffing using bots. Do you provide any details on bot detection?
We do. So Neustar has a supplemental service to our IP intelligence data, our Geopoint data. It's called IP Reputation. And at a very high level, we supply a real user score. It's a number of one to five, five being very likely not human, so therefore, a bot. One being all our signals, all our information for that specific IP address is showing that it is very likely human. So what some of our customers do is at the top of the funnel, when they're doing IP check before it actually gets to the Geopoint check for the location, for example, they'll identify hey, this IP address is a bot. Let's not let it do any other activity on our site and blocks it from any other activity, for example. So we do have bot detection.
How does Neustar price its geolocation service?
Excellent. And our next question is a question, of course, everyone has underlined. How does Neustar price its service?
So at a high level, I mean, we definitely love to sit with our customers and understand exactly how they want to use it and consult with them about what their needs are. But at a very high level, we look at first and foremost the query volumes. How many queries do they expect to do on a monthly basis, for example? And we also look at the package that they might most be interested in.
So I mentioned that we have a global OTT provider, and they really care only about country level. So they don't need the package that includes the city level information. But they wanted anonymous proxy information. So we would bundle those two together and provide a price based on that.
Whereas we have other customers that want, oh, 30 plus data points. And so that would be another price point based on the bundle there. And again, looking at the query volumes. So it really depends on the customer's needs, their traffic, how they want to work with the data. Also, are they also looking at other data insights too that they would be interested in for other uses like localizing content and things like that? So we would bundle all of that up together. So those are the main criteria for pricing.
All right. Very good. Thanks so much. And I think that's a good place to wrap things here. I'd like to thank everyone for joining us today. And I'd like to thank our speakers, Jason Thibeault, the executive director of the Streaming Video Alliance; Steve Hindman, senior product manager at Neustar; and Jackie Wadhwa, IP Geolocation specialist and customer success management also at Neustar.
If you'd like to review this event or send a colleague to view it, this event will be archived for 90 days. And you'll receive a follow up email within 24 hours once the event is archived. Also, just for attending today's event, you were entered into a drawing for a $100 AmEx gift card. The winner will be selected on June 28. And we'll reach out to you via email to claim your prize.
Also, as you may have just seen on the slide that just passed, if you stay on the URL for this webinar when it's over, you'll be taken to a white paper with more information about the password sharing challenge. That wraps things up for today. Thank you for joining us. And have a great day.