Hello and welcome to the 3rd of a series of webinars where we're looking at various different aspects of the 51Degrees product.

This webinar is for developers, particularly C sharp developers, and I'm joined by Eugene Dorfman, one of the engineers who works on the 51Degrees code base, to go through a series of getting started examples to show you exactly how device detection and IP intelligence can work together, and how the 51Degrees pipeline solution.

It makes this super easy for you to be productive very, very quickly.

Welcome, Eugene.

Thank you.

So, let's make a start by showing our audience the examples.

They're all open source.

They're all on GitHub.

We're going to be specifically looking at C# today, and they can be found in GitHub.com/51Degrees, and then you've got device detection .net examples, and then you've also got IP intelligence .net examples, and everything you're going to see today that Eugene's going to take us through is derived from these examples.

Right.

Yeah, so as James said, we have those GitHub pages where you can find, the actual examples, the short read me file, the documents, how to run them, and, uh, yeah, well, you can clone those uh, repostories locally and run them yourself.

So what we start with is, I think, IP intelligence.

Yeah, we'll start with IP intelligence.

Show us the first example.

We're gonna be using, just as Eugene gets things set up.

We're gonna be using an on-premise data file for IP intelligence.

So this is a data file that we've downloaded ahead of this webinar, and Eugene's going to connect to that data file and take us through the getting started web example.

Yeah, so we actually have a collection of examples.

We have both getting started, a console, which is a common line example, which, you know, just shows you a simple programme that integrates, everything, in the in the common line example, and we also have like a web example that shows you the same thing of working in the browser.

There is, like, there is a duality of how you can configure, 51Degrees products.

So, one of the things that 51Degrees API features is using the concept of pipeline.

So the pipeline is actually a collection, a chain of elements that process data, and they get an input and an output, and then that output is the valuable data that you can display on screen in any way possible.

So there are two ways how you can configure the pipeline, so one way is to do it in code manually.

So you would instantiate a pipeline, using a pipeline builder, then you would instantiate each element or engine that you want to add into the pipeline, and you would add it through that flow element.

Cold to the pipeline, and then, you know, there is the next step would be to acquire what's called a flow data object, and this flow data object is something that is flowing through the pipeline, and takes the input data that we call evidence, and produces, the output data that we call results.

And so this is demonstrated in this particular common line example, through add evidence, then there is a process call.

Then, basically, there is a retrieval of the results through this data that gut method.

The second way to configure a pipeline would be through the configuration.

So we have a way to declaratively specify which elements the pipeline has, without the need to do it in code.

Then in the code, all you would have to do is just read that configuration file.

And...

Right.

So, there is a way to use a pipeline through the special middleware.

So this middleware would pick up the configuration from the JSON file, with the settings, where the elements are specified.

So use 51 is a middleware that 51Degrees provides to round the pipeline.

Let's start with the console example.

Just because that's the simpler of the two.

And this is the example that we'd advise anyone to start with, really because it is the simplest.

We're creating a pipeline.

We're passing some evidence to it.

We displaying the results on the console, and then we're shutting everything down.

So this is really the starting place.

It really takes 10 to 20 minutes to just run this example, and by doing that, you're getting a flavour as to all the different aspects of the 51Degrees product.

Let's see the outcome from that.

Yeah, so that example actually takes, Well, I accidentally ran a mixed example, I think.

No, I actually ran the on premise, getting started console example.

So, this example takes the IP address as evidence, because it's a common blind, which has manually provide this example, is input, and then it outputs the bunch of associated properties to that IP address.

Yeah, so some of them make sense, uh, when we look at them now, some of them, we're actually going to see more visually, the web example in a second.

Right so this is, command line example.

So, as we said before, you can find it on GitHub.

The evidence that we provide for testing is also part of this example.

So it's easy to, replace this evidence with your evidence, with any IP address that you want to test it on.

So, Right.

So, then, we have the web example. So one thing I wanted to note is that because those are on premise examples.

Both the common the command line example and the example they take the data file path as input as a programme argument.

That is just for, we could hard code this path, but it is much easier to be flexible and provide this as a common line argument.

So, we provide all of those examples take.

I just provide them the path to the data file that is local on my disk.

I downloaded the data file before, before this session.

Well, just before you continue, it's important that there are, for every 51Degrees product, when you're dealing with on premise, two broadly, two types of data file.

There's the free light data file. That doesn't include all available properties, but it's enough to get started.

It's enough to support the testing, the integration, the unit testing, that we provide.

And then there's an enterprise data file that you would need to get a subscription for, which contains more properties.

So, Eugene has downloaded that beforehand, and that was the path that you were just showing people.

Right.

Okay, well...

So let's switch to the web example.

A bit more visual than the console example.

Right.

So we are running on the local host.

So first, if I go here on the local host, you would see the look back IP address, which is not very interesting.

I mean, you can input any IP address manually here and do a look up.

For example, this is a Swedish IP address.

But if you want to capture, like, our current location.

We're gonna run this through the reverse proxy, and we will just navigate to the same server, but from outside.

So this is our current location.

So we are in the United Kingdom.

Yeah.

That's what the results that we would expect for that particular IP address.

So really importantly here, you've got the polygon that's being returned, which we're showing on that map at the bottom, and that shows us provides a view as to where we are.

So we're not dealing with circles, we're not dealing with a point and a radius.

You can get that information if you want, but sometimes it's going to limit the information that you've got coming back.

So that's the advance, one of the advantages of 51Degrees is that we've got this polygon effectively where the location is most likely to be in.

What we can also see here if we go up to the results that have come back as the location confidence.

I don't think we...

We don't actually have that one in here.

Yeah, we have it on the IPTester page.

But...

We're just not showing that in this particular example.

So you've got location confidence.

You've got human probability, things like that, that come back as well.

And it would be very easy for you to add them into the web examples.

We're gonna show you that in a minute with device detection.

All right.

Let's look at adding countries, though, to this example.

So that we can actually see the countries that are associated with an IP address.

So Eugene's going to change the example over to add those properties.

What we've found as we've developed, our approach to IP intelligence is that very often an IP address isn't associated with a single country in reality, whether it's VPNs or carrier grade gnat, or these sorts of issues mean that an IP address might be associated with several countries in practice in terms of where it It's actually being used, the service area effectively for that.

IP address.

So, you saw earlier that polygon, effectively, which was just the United Kingdom, that polygon could cover multiple countries, and you might not want to deal with polygons and WKT well known text format, very popular in the geospatial sector.

You might just want a list of countries and the probability of the country that the IP address is located in.

So we'll go through the code change in the minute a little bit more slowly.

But what we can see here. Is the example modified to include the country codes.

Eugene, do you want to explain them to our audience?

Right, so, because, uh, like, as James said, uh, this polygon on the map covers not a single country, uh, this means that probabilistically, you could be located in any of the covered countries, but with different probability.

So 51Degrees has computed this probability for you, so we can display, like, what is the level of confidence, or what is the probability that you are located in any of those particular countries?

So, right here, you see, like, actually country codes, but they can easily be translated into country names, and we have special engines that are added into the pipeline, will show them in a minute, that actually do this translation, and as a result of that translation, you also get a drop down list with all of the countries listed in the order that is IP relevant.

So, the word there would be, like, the highest probability country you're located in goes to the top, and then the rest go beneath, and then, uh, when all of the rest of the countries are just sorted alphabetically.

So this makes a selection of country, on the page really easy for someone who has navigated to, say, your page from abroad, and you're asking them from which country they are, it becomes quite easy for them to select their country, from this list, they don't have to scroll, and find it alphabetically, although alphabet is a natural index, but it's still somewhat time consuming to do that.

So, unless they have used VPN, for example, and have VPN to your side, then they would have to...

Well, they probably know they're doing that, right?

Yeah, say, rather than what they were expecting.

Oh, right.

So here we've got geographical and population and 2 different dropdown lists for each.

So geographical is where the probability is based on the geographic area and population is based on the population within that geographic area.

So this is a really good example, so we can see when we look at geography, 89% is associated with the United Kingdom based on the area.

But actually when we look at the population, it's 95.

Right. Percent.

So let's have a look at how that's done in coach, shall we usually?

Right, should we show the translation first or let's look at the code?

Because we can actually display countries in the native language when we navigate to this page.

Let's do that.

Excellent idea.

Yeah.

So what happens if you're not speaking English at this moment and you want to use a different language?

Right, well, let's switch the browser language.

I mean, let's check French, maybe.

So French is our preferred language right now.

So if we refresh the page, we get the country list in French.

That is very cool.

That is very cool indeed.

So it is as simple as that.

The pipeline is not just looking at the probability, it's also looking at the translation as well.

Right, and if you check the, actually, the page code, If we go into, the, the select, you can see that the value is actually the country code, while the label is the country name, so that makes it easy, because when you submit this form, for example, on the website, you need the country code, because, like, independent of language, you don't want to have, the name of the country, as a code.

The code is preserved across languages, but the labels are language dependent.

That makes perfect sense.

So when you're capturing the data, you're going to use the language neutral code, which is ISO 2 character code.

But of course, people don't think that way.

They deal with the natural names, which is what they're selected. From that dropdown list.

So this is both human and machine friendly, way of...

That, that for me, is super cool.

So that's what a true modern IP intelligence solution should be doing.

It's not just returning a value, but it's the full package effectively of what you need as a developer to actually produce something useful for your business customers.

Right, and we have, like, a lot of popular languages already implemented, but we'll be aiding languages.

Yeah, just let us know.

Or, indeed, these language translation files are in the open source GitHub, so you are free to make a pull request and add your own language translation if there's one that we haven't got.

All right, well, let's look at the...

Yeah, look how it's made.

Right.

So before I was showing you the pipeline.

It actually had just the IP on-premise engine attitude as a flow element, but for countries to work, we had to add two more flow elements into the pipeline.

The first flow element, does the country code translation from the codes to the names, and the second element actually translates the names into your preferred language.

So, we also had to add two more properties here, without those...

So, we actually give the...

We configure the IP on Primus engine builder with the list of properties, it should return.

But if we actually don't submit any properties, it will return all properties.

So we can restrict the IP on Primus engine builder to the list of properties we need.

For example, if we don't, for performance reasons, for example, we only need, like, three properties, we can just lose them here, but, for example, if we need all of them, we can just admit everything.

But in this...

Just before you move on from that, this is an important aspect of performance.

So if you only wanted one property, then the way the 51Degrees product works, there's a graph that's evaluated for each different component, so the network's component, locations of component, bottle, human is a component.

Each of them have separate graphs.

So, if you specify the properties and a graph doesn't need to be evaluated, then you're going to get a performance improvement.

So all our examples encourage you to list the properties that you're actually going to want to get back because we can then configure the execution to be optimised for performance.

Yep, that's right.

S so, as I said, we, we add 2 more engines to this, uh, pipeline to process the country codes and give you the, the list of countries in the language, that the browser currently has.

So if we go and take a look at the concept of evidence, we actually take the client IP address as evidence, but also accepted language is actually taken as evidence as well. To do the proper translation.

So, currently, my preferred language is English.

If I change it to, Ukrainian, for example, uh, then the Ukrainian will be the primary accepted language, uh...

And our drop analysts have changed.

Yeah, and the job down list has adapted.

So, like, actually, this evidence is listed, it was all present for detection.

This is marked as a primary evidence that is used to do the detection, but, Except language was also taken into account to actually produce.

This is not marked as used just because it was not used by the intelligence engine itself.

It was used by the other engines.

So this engine actually takes header accept language as evidence.

Very cool.

So, and all of this is being done in configuration.

So, you're not actually changing code, you're changing the configuration, but as Eugene showed earlier, you could also do this in code if you didn't want to use configuration.

Right.

Yeah, so, actually, the command line example is an example of that.

So it already has these two translation engines added to the pipeline.

So, it's the same thing.

So, if we're on the common line example, uh, again, sorry.

So, example, uh, we will get this huge list of countries, not as a drop down list, but as a list, uh, on the screen.

So, you would see, uh, well, for this particular IP address, you get, like.

It looks like Switzerland and Denmark.

Right.

And because, and because I provided the accepted, accept language as French, here, for this first example, you get, French list of countries here, uh, in the translation.

So this is what goes, like, this is what goes into the option values in the HTML.

So this is the key.

And this is what goes into the labels that you see on the screen.

And they are ordered in the same, they're sorted in the same order, so you can, they match one, one to one, so that, you just, you know, loop through them by index, and put them into the list on the page.

Cool.

So this is how it's done.

Makes sense.

So we've given you a brief introduction there to IP intelligence.

Let's shift to device detection.

So some of that evidence you saw earlier wasn't used for IP intelligence, but is used for device detection.

So as Eugene switches, is exactly the same model in terms of how you build your pipeline.

You can do it in code, or you can do it from configuration.

And we have similar examples for device detection.

We've got the console example, and the web example.

There are other examples available for both device detection and IP intelligence.

So if you're doing offline analytics, for example.

You have that option as well.

So let's start with basic device detection.

Right.

So, yeah, just as James said, we have both common line and web and web examples for device detection, but there is one more dimension to device detection, which is using either on premise or cloud, API, for device detection.

So the example I'm gonna show you first is going to use a 51Degrees cloud API.

So the actual cloud service is, running live, on the domaincloud.51Degrees.com, and to actually use it, you will need a resource key, which we actually obtained before this demo.

So this cloud API works.

It provides data when you provide evidence to it.

It outputs data in the JSON format.

For you.

So, Let's look at the uh, run an example first maybe, and then we'll go through the pipeline, how it is set up.

So let me run it.

We're gonna start with Web, yeah?

Yeah, we are gonna start with Web, and, uh...

We are gonna navigate to this local host year round.

So this is gonna be using your Mac as the input data here.

Correct.

So it's using my Mac.

That's around this example, clean.

And if I.. Navigate to the irrelated output, All right, so this is the results of the device detection for my Mac, so it's detecting the vendor, uh, uh, hardware name, platform, name and version, which is platform means operating system in this case.

So, and the browser and the browser version, have the, what's called device ID so?

#um.

This is not the device.

#Ah instance I did this is like a device model lady.

I guess for for the cool.

Yeah, so it's formed of the model, the operating system version, the browser version and whether it's a crawler or not and that forms the 4 integer numbers that make the device ID.

So it's an identifier, uh only for the model.

It's not Eugene's phone or anything like that.

It's not a personal.

Yeah, it's not personal.

Yeah, so it's an identifier in the 51Degrees database of devices, basically, if you want to.

And if you're dealing with analytics, then this is the value to store because then you can look up the other information and it's nice and efficient.

It's just four 32-bit integers.

So you would store that, and then you would look up the other data, rather than storing all the information in your analytic solutions.

It going to save you a lot of storage cost.

Right.

Well, let's look at the pipeline.

So we already covered the pipeline concept in the previous demo of IP intelligence.

So for device detection, it is very similar, but in this particular case, we were covering, cloud, device detection.

That's why it's using cloud request engine, and then it's using device detection. Cloud engine.

So you've got that resource key there, which we need to put in instead of the data file.

Correct.

Yeah.

Yeah, so it specifies, actually, the cloud request, well, it specifies, like, resource key.

By default, it goes to the cloud at 51Degrees.com, but if you are hosting 51Degrees on your domain, for example, you could also specify an endpoint here and go to your custom.

In that case, you wouldn't need.

Yeah, so we actually have an example web server.

We don't have time in this webinar to get into that, but you could host your own endpoints effectively, rather than calling our public cloud.

You've effectively got your own private cloud if you want to deploy that way.

Right.

Well, also we have a couple of other elements.

There is a child's grade builder element that actually is needed to collect client side evidence.

The client side evidence is something that is running on the child script that is running on page and does various tests and it works for Apple to make the Apple model detection more precise.

Well, this is also, I would say, non-Apple as well, like, get high entropy values for, anyone using a cranium based.

Right, for example, if you haven't got various HTTP heading settings set, then it's useful there as well.

And that's a great segue to show people on an Apple phone.

Yeah, yeah, yeah.

So, I guess we can run the same example.

We will just run it in the, through the river's proxy.

Oh, so you've changed the reverse proxy to go to the device detection demo, yeah?

Yeah, well, reverse proxy is just looking at this port on my machine.

No, actually, we're now running it on fire.

So anything that runs on this port?

Well, just, you know, will be shown.

And because all of our dot net examples are running on this board.

We can just, you know, refresh the page with the reverse proxy and we'll get the example.

So on my phone...

You've got mirroring, right?

So we can see it on the on the screen, right?

Yeah, just a second.

So, cool.

Let's connect to the phone.

All right, so if I navigate to this #um.

You're real #um.

We are gonna see.

I'm sorry the UI is not #ah mobile friendly.

It's just this example, but you can see that it recognises the iPhone 12 Pro Max which my iPhone is.

I can actually navigate to the, to buy settings.

And we can go into general.

And see that it's iPhone 12 Pro Max.

Running version 26.3 of IOS.

Right, so.

Yeah, and this is what is recognised.

By our client side evidence, #um so we get actually a list of devices here, #Ah, which is a probabilistic Apple model detection.

So we think that iPhone 12 Pro Max is the most probable.

device, but these are also potential.

This is the best precision we get, we can get with Apple.

Well this is because that will go out of their way to hide the model information, so what we're doing here.

If you scroll down, actually, on the big screen, you can see the evidence that's available.

So we have user agent headers, so we're using them, in the first instance, to kind of narrow it down, so we can get, like, the operating system version and things like that from that information.

But then we've got this JavaScript that's running, that's collecting more information, which allows us to narrow it down to a group of models.

But often they share similar characteristics.

So can we modify, or do you want to switch to on premise first?

Are you happy to continue with cloud?

Yeah, we can add a property here, if you like, or?

Yeah, let's add price band.

Okay.

Yeah.

You happy doing that on the cloud?

Yeah, sure.

So let us modify the pipeline to actually add a prize band, property, we will need to.. Also add that property in the model, to display it all the screen.

So just by using typing, what you see here is the IDEs, always have strong, strongly typed excessors.

So, you can actually just choose from the list of properties that are available.

If you happen to be using an environment where you don't want to use that, then you can get them as a dictionary of key value pairs, that we use the strongly typed accessor to just make it easier to understand what properties are available and add just in time documentation effectively so you can actually see what the property means and things like that.

So in the case of price band, this is the price band of the device or group of devices at the point of launch.

So it's not the current price because obviously prices change over time.

But it's the point of launch.

So this is quite useful, if you want to know the kind of price, obviously, of the device, at launch, and then there are other properties we have, like the release age, for example, when it was released onto the market, how old it is, and those age properties are available for operating system browser and hardware as well.

So there we go.

So for iPhone 12 Pro Max, it was 1300, around 1300 when it launched.

These are in US dollars.

So we standardise everything into US dollars.

We're not dealing with local currencies.

Right.

So, and this is how easy it is to, if you follow the COVID, this is how easy it is to add a property, you just add a list of properties you retrieve, and then you just express it in the model and view code to show it on the screen.

Again, if we don't supply properties here, like, the list that we need, we're gonna get all of them, which is, like, really, like, we have, I think, over 20, maybe 300, nearly 300 bridges.

So it's a huge JSON payload that you're gonna get in the response, which is a might not be optimal in terms of bandwidth and speed, so that's why it's recommended to limit those of properties to the ones that you need for it.

Should we look in on premise now?

Let's do the same thing, but on premise.

Okay.

So...

The examples are actually sorted under cloud on premise.

So, the on premise example is, Name the same, getting started web, but it's an on premise example.

I believe this one will, by default, run with the light data file.

Let's look at the...

That's the free one that doesn't contain all the properties.

Yeah, so, by default, um...

This one would say unknown property because, uh, likely this is because the data file is light.

So, in the pipeline configuration.

Let's just go back and have a look at that.

I think we were a bit quick on that one.

So we're saying here, for example, hardware vendor, it's not included in the light data file.

So it's just giving you a bit of an explanation.

So every time you retrieve a property value, It might be missing.

So you can check for that. Using a billion flag, or it'll throw an exception, if you're not doing the check.

And then there's another value called missing property message, and it will explain why the property is missing.

In this case, it's because it's not in the data file.

Right.

Yeah, so we, we specified the light data file here.

But we should specify the full data file, and that's gonna be, it is just, in particular, location on my disk.

Again, this is the one you downloaded earlier before we started the webinar.

Um.

English is the.

If I was try, maybe I messed up the path, but we'll see.

If I would have messed up, it wouldn't start, I guess.

Right, so now we get...

So now we're getting all our properties.

All of the properties, right?

Can we do that?

I found trek again?

Can we try it in the?

Uh, sure.

let's...

So, uh, let's update this reverse proxy thing.

So it's pointing us at the same example.

well, I mean, from the screen, you cannot easily recognise that this is the same example.

It's maybe do some, I don't know, like modify the title here or integration.

Premise, yeah.

On premise.

Just so we don't confuse.

Yeah, so this is on premise example just to know you know we are not. #ah substituting things #ah so.

Yeah, let's do iPhone mirroring.

And if I go refresh this page.

So we run in the on premise example, and the device detection works pretty much the same way.

And we get a zero here.

Because we don't have crueller properties.

Yeah.

So in this particular instance, when Eugene listed the properties, we haven't got a crawler.

So it's not evaluating the crawler.

You could put crawler name in and restart and it will populate that value.

Um...

Let's check.

I mean...

I mean...

The beauty of live code.

We didn't rehearse this.

Right.

Let's see if it comes up.

Yeah, there we go.

So the crawler is here and it should be also this ID actually means we are not a croller.

Yeah.

This is the profile lady that tells, you know, this is a genuine client.

So just to come back to that, those integers, you can also download a zip file that contains CSV format data files, which turn each of these integers into the corresponding properties.

So when I mentioned earlier, you can just store those identifiers.

You do need to also then get that CSV file, and that comes with all our on premise subscription.

So you can download both the runtime file, which is what we're using, which is optimised for performance for device detection or IP intelligence, and then you can look up the data for device detection, using those IDs with those CSV files.

Right.

So should we add a prize man here also?

Yeah, why not?

Just why Eugene's doing that, so it's the same change with modifying the model, we're adding using the strongly typed accessor to get, the value.

What you're seeing here is that the code is exactly the same, as far as your consumption is concerned, whether you're using cloud or on premise.

And we think that's really important, because sometimes you might do your evaluation of data using on premise, sorry, a cloud, sass, subscription, and then you might say, okay, well, we want better performance, we want to be milk control, we want to host our own service, well, then you can just switch to on premise, and everything's exactly the same.

We're protecting you via this pipeline and this engine model from that complexity.

You're just starting your pipeline, you're getting your data, you're adding evidence to it, you're processing it, and then you're consuming the results, and that's the same for anything we do.

Right.

So the difference between this pipeline that is on premise is in this element that is the cold device detection, cash engine builder, and the cloud would have a cloud request engine, plus device detection cloud engine.

So, this is the whole, like, the two elements that are different are this.

So this is what you need for cloud.

And this is what you need for on premise, so this element.

So this are, the difference in the pipeline construction.

Cool. #um so if I run the example.

We're gonna.

And again, we're gonna see #ah this #ah passive device detection where it's just using the HTTV headers.

That it's got available to it and then we've got that active component, which is useful for getting additional information.

JavaScript.

Right.

One thing to know here is that for my Mac, there is no price man, because we don't know the precise model of the Mac, but for my iPhone, there is a...

We know enough.

Yeah.

For my iPhone, we are gonna have...

And this game is coming from the on premise data file, not the cloud service.

Yeah, so this is the on premise example, that lost the data file, and very cool.

Right.

So we've shown people device detection, cloud and on-premise, we've shown people IP intelligence, but how do we do it together?

How do we change these pipelines to consume the 2 at the same time in the same pipeline?

Because that's one of the things I think is very, very cool indeed.

Right.

So because of this, pipeline concept that is kind of agnostic to what elements are in it.

So it's just a chain of processes, we can add both device detection and AP intelligence to the same pipeline.

Let's do it.

For that, we have a what we call a mixed example under IP intelligence, so let me stop running this one. And switch to, um.. And switch to the IP intelligence examples.

Under IP intelligence examples, under on premise, we currently have this for on premise.

Actually, we also have it for cloud, but we're going to show you the own premise version.

Uh, we have a set of mixed, uh, examples means that we mix both device detection and IP intelligence in the same example.

So the, as I said, so the configuration can be done in code, I mean, the setting up of the pipeline can be done in code, or it can be done through the declarative configuration.

So, in code, you would see that there is two engines that we construct, one of them is device detection, engine builder, the other is IPI on premise engine.

So the builder is just the object that allows you to construct the engine, and through that builder, you can provide the properties to the engine.

And then those engines are added into the pipeline.

So, with this, let me, yeah, and in the, again, started web, example, we can also see those 2 elements being added into the pipeline as separate elements.

So we've got two data files, two elements, pretty much the same as what we showed earlier, just being put into the same pipeline.

Correct.

While we're looking at it, we have, like, data file hard coded here, but in the code of the example, we actually have an override for this data file path, to take the common line arguments, because it's easier and more flexible, to provide the data file path on the colon line.

So, basically, I have data files provided here as arguments to this programme.

so if we're on, um.

Let's start with the console, shall we?

Just check everything's running, then again, this is where we would suggest a developer starts because they can very easily see without having to be concerned about HTTP and all the middleware and all those Gubbins.

You can just quickly see the results and very easily see what happens.

All right, so, on previous mixed console, so I might need to configure and provide the data file.

It probably might fail now, but we'll see.

Again, the beauty of live code, webinars.

Right, so let me.

Actually, copy they staying from here.

It's done something.

Yeah, it actually worked, maybe because I had a.

You surprised yourself.

I, I, I might have had something hard-coded in the, um.

Let's not worry for the moment, let's show you the audience, the output show.

Yeah, okay.

Sure.

So the mixed example actually takes.

Two types of evidence, one is the evidence that is specific to device detection, another is specific to IP intelligence.

So for device detection, we actually take useration, useration client hints, for IP intelligence, it's an IP address.

And we provide like device detection, results.

And you can see here that my iPhone model is not very precise.

This is exactly because this is running in the common line, and it's not given extra evidence that JavaScript, builder element, builder element, would extract from, JavaScript, would extract from the client side, from the browser.

So, that's why the Apple Mono would be in person.

Every possible iPhone, basically.

So that's a common support question is people say, well, I'm only getting, I'm getting all the iPhones coming back.

You need that 2nd stage, you need that JavaScript stage, which will show you in a minute, again, in the web browser.

Right.

And the...

IP address is from Poland, I think, and it just shows the.. Some data for this Polish IP address, that we got.

There are different other, so that's a desktop device we've got there in the example.

Brazil, Brazil.

What else have we got there?

An iPad?

Again, similar group profiling.

Let's have a look at the cloud service. At the web example?

Web example.

Always more visual.

Yeah.

But a little bit more going on for the developer, which is why we recommend you start with console, just to get familiar with the components and then move to the web example after that.

Right, so, for the web example, we are gonna.. Look at this page.

again, this is, uh...

Yeah, so it got...

Yeah, it's local host, so it got a look, look, look back IP address.

So if I run it through the reverse proxy.

We're gonna have...

We got the tables.

We got device detection on the left IP intelligence on the right.

Yeah.

So, and I think this design, in this particular example, is a bit more mobile friendly.

It should at least compact both tables when you are looking at mobile device, we'll look in a minute.

Let's look at the map.

Yeah, so we already saw this map when we demonstrated IP intelligence alone.

So the results from the IP intelligence are the same as in the, I'd be intelligent specific example, but what we add here is the device detection results.

Like, uh, on the same page, uh, as AP intelligence.

so.

We, um. #ah.

Wanted to.

Maybe add.

A couple properties here into the #um. #um IP intelligence results so.

#Ah, we actually though those examples are already on GitHub and this particular example already has those properties on GitHub.

So for like to demonstrate adding them, I had to remove them.

So now I will...

We gonna put them back.

I will just add them back.

So, and I will just undo the changes that I've done to the actual examples, uh, so that was on the IP intelligence.

Dot net.

And the change was removing the properties.

So I will. #um.

I, I will just show you like the #um the result of of undoing it in a second, so that would be for.

Right, so this is for.

Um.

Yep, score changes. #um.

So the result of undoing this was.

On the mixed getting started web.

And premise.

We've got in the IP intelligence engine.

We've got two more properties which are country called geographical and country called population, and then we got two more engines added that will do the translation.

And with that, let's try to rerun this.

New rules.

And we change the model and controller a little bit as well, but just to map those properties across.

Right, so I do have #um.

The Ukrainian is the main language currently selected, let me change it to.

English.

And let me around this, we get the familiar.

IP relevant order of countries.

I hear #um and.

And there's probabilities, yeah, yeah, and the pro villages and. #um also let's check on iPhone.

Well, let's see it all together.

Yeah, so we're using an external device now, which is an iPhone.

Yeah.

And we go to the.. IPhone viewer.

Right, so...

First, you can see that we've got the correct model.

In that group, yeah.

Yeah, the group model of the iPhone detected.

then.

Uh, we've got...

Actually, I'm running a VPN on my phone right now, and that's why you see, you see this?

So I can actually, let me switch off the VPN.

I was VPN into Croatia right now.

So, I will switch off the.. The VPN.

And now we will refresh the page.

In the browser.

To now we've got a different IP address.

Yeah, so now we we should be in the UK #ah and.

Well, yeah, so this is this is the AP address.

Yeah, of the studio we're in, yeah.

And on the map, on the iPhone, you can also see that we are kind of in the UK, and United Kingdom is the primary country, to select, in the dropdown.

right?

So I think this is...

Yeah, that's covered the 2 of them together.

Thank you very much for going through that.

Just before we wrap, a couple of common questions we get.

So one is around auto updating the data file locally.

Can you just talk us through how you would go about doing that for both IP intelligence and device detection?

And the clue is it's the same for each.

And it can happen in the background.

Right.

So, well, I would first refer to, 51Degrees, uh, documentation, uh, to the API feature, page automatic data file updates, and actually lists various scenarios you can use to do, auto update.

So, the engines, either IP intelligence, or device detection, they both have the same, uh, data file service component in them, which enables you to, out of data files in one of three ways, I think.

So, the first way would be, it would just directly download the data file and replace the current data file with the new one.

Another way is, it would just do, like, uh, it would watch the file system, uh, for the changes, and when you replace the data file that it is watching.

It will just pick it up and use the new data file.

And, well, the 3rd way, I guess, would be just the combination of these two ways.

So it's using various parameters.

For example, you can either, use a, uh, you can either use or not use the temporary file.

and.

Well, I think there's a little bit to say here.

So, uh, the key point is that you don't want to bring your processor application down when you're updating the data file, right?

So all the methods for updating don't require a process restart.

So what happens is no matter how you get the data to your application, the new data is loaded and made available.

The old data is then when it's finished being used, is shut down and then gracefully cleaned up.

So if you're using, we'll talk about performance profiles in a minute, but if you're using a temporary, if you're using a file where you're not loading all the data into memory, then in order to use auto update, you need to create a temp file for that data so that you can actually do the refresh of the data in the background.

Right, right.

Yeah, and well, I wanted to also highlight the, the, the 3rd way is, like, the 1st way would be to download the data file from the, what we call a distributor service, and for device detection, uh, and, uh, another way would be to, to self host the data file on your, custom endpoint, for example, on S3 bucket or anywhere else, and download it from the custom URL.

So, uh, that may be considered, like, a third scenario, and there is a certain flexibility around, like, what checks you want to do, like, whether you want to verify MD5 on the downloaded, uh, data file, uh, or not, and there are various keys that are described in this documentation.

And there is an example of the, by playing configuration that you can do to do out date.

So there is the main flag here is ought to update true, that allows you to enable auto dates.

It's, like, a master key for updates, and then you would specify, like, whether you want to update it on startup, whether what's the pulling interval, like, how often you check for the new data file, or what is the custom URL, like, whether you want to verify MD5, or you just don't load and trust.

We recommend this, this is true by default.

So this is just a modification of the default setting.

We recommend checking MD5 for guarantees consistency of the download.

There are, the example that we have for update data files is under. #um well we we have both we have for example for both IP intelligence and for device detection device detection. # we should say that device detection data files are. #um about like 10 TIMEs like #Ah smaller than IP intelligence.

Well, they're typically under 100 megabytes uncompressed IP intelligence a little bit larger.

So I just want to finish by showing people the startup time with the different profiles.

But let's finish auto update.

But yeah, yeah.

So I want to run out of it right now, but we can show, the example that we have for auto updates, it doesn't use the pipeline configuration, but it uses the equivalent configuration through the code, so it constructs the pipeline using methods in the code, and you can see that we enable how to update this corresponds to this, out of date, true pipeline configuration, like key, uh, this method just enables it, and it would attempt to download the data file, on startup, and updated.

The key thing is, if you're using, on premise, the line you've got there, it's got license key.

So if you're getting the data from us, and you're using that distributor service that's explained in the documentation, you've been touched on earlier, you need to put your license key into the configuration so that we can authenticate your subscription and provide you the correct data file.

Right.

Yeah, so this distributor page in the documentation actually highlights the parameters that distributor service takes.

So you can use it, either through this, update data file feature, or you can use it.

Yeah, you can just call a URL with it, right?

License key in there.

So we've listened to customers over the years.

I think we've pretty much given you every way possible to update the data file and ensure that you do not have to restart your process or your application.

So just before we wrap.

I would love to show our audience the different performance profiles.

So IP intelligence in particular is quite a large data file in comparison to device detection.

And we've got different ways of handling that from a performance perspective, which we can easily see in the time it takes to do the startup of on-press.

Let's check, let's check, get inside.

Well, let's go get inside and console.

Yeah, it'll be a little bit easier.

So we've got an option here called set performance profile, which is set to max performance at the moment.

You've already got that in the lineup up.

Oh, wait, sorry.

Yeah, cool.

So let's just start that up as we did earlier with Mac's performance.

Uh one.

So it's now creating the #ah on premise engine took what three or four seconds there to do the startups.

It was loading all the data into memory and doesn't complete the build until the data is in memory.

And then if there was an auto update, The there would need to be another instance of the engine created with the data in it and before they switched over.

So that could be quite memory intensive.

And then, of course, that's a trade-off with CPU.

Eugene's now changed it to low memory.

So what it's doing now is it's just initialising the data file and then it's pulling the data it needs from the data file when it needs it.

Yeah, it doesn't load it into memory.

It results in like much faster startup time.

We don't have this lag, like you're gonna see the results output immediately.

Like, this is the whole programme just ran.

So, no lag at all, like, unlike, if I change it back to next performance, we're gonna see a pause here.

This is where the data file of 6 gigabytes, or maybe over, like, at least over.

It can be, depending on which properties you...

Oh, over 4 gigabytes, definitely, is read into memory.

So it takes a little bit of time.

Well, with low memory, meaning, like, you don't use as much memory, and you're much faster too.

But each lookup's gonna be that little bit slower, 'cause it's got to pull in the data from the fire.

So it's that trade-off, right?

Trade-off, yeah.

Fundamental to computer science, I think.

Yes, exactly.

We can't change the laws of physics, but we have tried to make it easier for you.

And to get business benefit from information related to device, network, human or bot and location, of course, as well.

So, we're coming to the end of this webinar and the time that we've got available.

We've shown you the configuration, both through file, which is really easy, particularly for DevOps, people, who maybe don't want to be touching and changing code, or you can do it in code, everything you can see and do in code, you can do in configuration and vice versa.

You've got the backing of the cloud.

And you've got on premise, so you can choose based on your subscription requirements and your performance requirements.

But you can also add your own elements into the pipeline, for example.

So we showed you translation and then listing countries, for example, these are just simple engines that you can add in.

They're all explained in the documentation.

Thank you, Eugene, to for coming there.

So you can add your own.

So if you wanted to have your own take on fraud, for example, you might want the age of the browser, for example, so if it's over 2 months, you might say, well, that's possibly suspicious, we've got the human probability indicator, that comes from IP address, and then you might want to track the number of requests in a web session as well, and then you might want to combine those together to basically say whether you want to display a capture or not, proof of humanness, for example, then you can put that in, uh, to the pipeline.

So it's really, really configurable.

You can bring your own data in there as well. And use exactly the same techniques we've just shown you to deliver your own application services.

So it's ideal where you've got anything where you've got a relatively small amount of data coming in, quite a complex calculation that needs to take place, then you want to augment and bring that data together, and then consume it in a really simple interface.

That's what we do.

Anything I've missed, Eugene.

Well, I think it's very comprehensive, if you missed anything, then we would refer our audience to the documentation.

I think it's...

Yeah, and GitHub.

You can raise issues there, right?

So, yeah, if you've got a question for us, get helps your 1st action as a developer or you can contact us via the website.

So, thank you very much, Eugene, for joining me and taking our audience through that introduction to the 51Degrees products, the IP intelligence, the device detection, bringing them together, those neat features like countries as well.

We will be back in 2 weeks time. Where we're going to be going through a similar set of examples, but this time it will be for the Java developers.

So if you've enjoyed this, please give us your comments.

If you haven't enjoyed it, please let us know and we'll see if we can address them.

And thank you very much and good luck with getting your real-time data into your applications easily.

We hope we make it a bit easier for you.

Thank you.

Thanks for watching.