We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Tracking Slippy Map Analytics

00:00

Formale Metadaten

Titel
Tracking Slippy Map Analytics
Serientitel
Anzahl der Teile
188
Autor
Lizenz
CC-Namensnennung 3.0 Deutschland:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache
Produzent
Produktionsjahr2014
ProduktionsortPortland, Oregon, United States of America

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Google Analytics is a great tool for monitoring and reporting on website traffic and user interactions but what it doesn't tell you is that 75% of the time your user's zoom in two levels every time they start to use your map or that external soils layer you added is taking an average three seconds to load. Client side map monitoring adds the missing chapters needed to complete your geo-analytics storybook.We'll briefly walk-through how to setup your slippy map to start tracking analytics, what can be tracked, and what can be discovered.
Schlagwörter
25
74
Vorschaubild
29:15
DatenbankMathematikSchaltnetzTypentheorieMAPElementargeometrieEntscheidungstheorieOrthogonalitätAnalytische MengeBitFunktionalIndexberechnungInhalt <Mathematik>LastMereologieMetrisches SystemPhysikalisches SystemZeitzoneFlächeninhaltGüte der AnpassungServerMehrplatzsystemCASE <Informatik>Prozess <Informatik>Nachbarschaft <Mathematik>VektorpotenzialAdditionOffene MengeReverse EngineeringSummengleichungQuellcodeClientEreignishorizontZoomWeg <Topologie>DifferenteSystemplattformKlassische PhysikElectronic GovernmentMultiplikationsoperatorDigitale PhotographieMapping <Computergraphik>TesselationCachingBenutzerbeteiligungComputerunterstützte ÜbersetzungTwitter <Softwareplattform>App <Programm>UnternehmensarchitekturOrdnung <Mathematik>SoftwareGebäude <Mathematik>Kategorie <Mathematik>DimensionsanalyseKonfiguration <Informatik>DreiEindeutigkeitGruppenoperationZellularer AutomatPolynomialzeitalgorithmusNichtlinearer OperatorCoxeter-GruppeVererbungshierarchieLesen <Datenverarbeitung>Prädikat <Logik>Elektronische PublikationMeterWeb SitePlug inDienst <Informatik>MusterspracheCDN-Netzwerk
CodeInformationMathematikProgrammbibliothekMAPEchtzeitsystemBenutzeroberflächeSoftwaretestElementargeometrieAnalytische MengeHyperbelverfahrenLastLokales MinimumMereologieProjektive EbeneZählenZahlenbereichServerCASE <Informatik>Prozess <Informatik>TemplateInstantiierungAdditionWeb-SeiteUmwandlungsenthalpieMinimumVerkehrsinformationSchnelltasteQuellcodeClientEreignishorizontWidgetZoomWeg <Topologie>Web SiteExtreme programmingDifferenteSystemplattformMensch-Maschine-SchnittstelleMultiplikationsoperatorURLStandardabweichungRegistrierung <Bildverarbeitung>Mapping <Computergraphik>TesselationEinsDatenbankCodierungFunktion <Mathematik>AbenteuerspielMittelwertDialektBitPrimzahlzwillingeSatellitensystemWechselsprungGüte der AnpassungReelle ZahlEinflussgrößeCoxeter-GruppeMetropolitan area networkComputersicherheitAbstimmung <Frequenz>Wort <Informatik>Data MiningKonfigurationsdatenbankEndliche ModelltheorieWeb logElement <Gruppentheorie>Dienst <Informatik>Figurierte ZahlComputerunterstützte ÜbersetzungTwitter <Softwareplattform>Vorlesung/Konferenz
MAPFormale SpracheMatrizenrechnungMittelwertComputeranimation
InformationDifferenteAnalytische MengeNatürliche ZahlSchaltnetzModallogikMAPKonfiguration <Informatik>IndexberechnungMomentenproblemZahlenbereichZeitzoneQuick-SortCASE <Informatik>PunktHilfesystemEreignishorizontZoomWeg <Topologie>MultiplikationsoperatorMapping <Computergraphik>Innerer AutomorphismusCachingEinsEntscheidungstheorieLastZählenUmwandlungsenthalpieElement <Gruppentheorie>Computeranimation
MAPPhysikalisches SystemUmwandlungsenthalpieMapping <Computergraphik>ResultanteHauptidealringVorlesung/Konferenz
MAPVorlesung/Konferenz
Mapping <Computergraphik>RückkopplungSoftwaretestVorzeichen <Mathematik>Vorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
Yes, so we weren't tracking analytics for our clients. And we use the traditional stuff. We use Google Analytics to track how many people aren't looking at our cat tracking website. Or we'd use New Relic to determine that, OK, that app, the bottlenecks in our app
on that $10 server, you can see things are running at a month. But nothing specific to web maps or the web mapping experience. Web maps are a huge investment. You spend a whole bunch of time on data, prepping the data, getting it in the database.
And then you spend all the time on the layers, making the layers look pretty. And then you spend a bunch of time on the actually mapping app itself, and then let alone all the other moving parts to make it work. And then once you're done, you sit back. You know, like any proud parent, you tweet about it, you tell your friends about it.
You know, it's a pretty good map. But like any good parent, you want that A-plus bumper sticker on your car. That's what web map analytics will do. It takes it to the next level.
You've got to make the changes based on informed decisions. A classic example is this. It's from a government website in Canada with loads of tools, loads of tabs. Well, maybe you don't need that many. Maybe all you need is a zoom in, zoom out button.
Don't get me wrong. Analytics aren't the be-all end-all to all your problems. You know, it's not the mountaintop guru that's going to answer all your questions. It's not going to tell you why x happens. And more than likely, the detailed data is inaccurate. But what it's going to show you
is it's going to show you trends. You're going to see the changes over time, what's going on. It's going to prove or disapprove any assumptions you have. And I'm guessing most have made assumptions about the web maps. And it's going to provide the metrics to justify changes in the future. So what map analytics are useful?
I think to start, if you're going to start tracking, start tracking the simple stuff, the obvious stuff. Start tracking map activity. Where are people zooming? Where are they panning to? Map layer load times. You know, I'm thinking more tile layers in this case. And then map tool usage.
So I have this friend, Dan. He's got this cool mapping platform. He couldn't make it here because he just had a baby a couple of days ago. So I thought I'd throw him into my presentation. He's got this new platform that he's created for web mapping. And it makes it super easy to add, create new maps,
add data, style layers. And his layers are all being pretiled and cached. But every time the user makes a change to any kind of style, the whole thing has to regenerate again. And in some cases, clients are the size of the geographic
area is like the size of British Columbia. I'm not sure who knows the size of British Columbia. It'd be millions of hectares, I'm guessing. And so the potential re-render process can be huge on that. So in addition to that, all his clients
are creating unique maps. So nothing's really the same. So you can't create a forestry layer and then replicate it for someone else because someone else might want to style it a little differently. So in Dan's case, his best scenario was, how can I predetermine what area should I be pre-generating
and leave everything else to generate on the fly as needed basis? So in this case, it's probably best to look at map activity, track where the users are spending their time, how often.
And for example, in this map here, rather than re-generating tiles for the whole United States, generate just for the San Francisco area. Find the hot zones. So with this kind of case, you're assuming that you're still going to get a pretty good map load time for most of your users.
And you're going to obviously decrease your processing time huge on this case. So that's assuming that. So as I mentioned before, you don't want to make the assumption the classic. You assume that you make an asset of you and me. At the same time, picking on Dan again,
he could also be tracking layer load times. So he re-generates this new layer for the whole US or San Francisco area. And then he needs to verify his assumption. So with the load times now, he is tracking, are his users having better load times or are they not?
Maybe he needs to tweak his process a bit more to find a good balance of user experience, load times, and then decreasing his server load. Or he could find it's an epic failure and scrap the whole thing and start back to square one. And I guess that's the way it'd be. But regardless of what he's doing and what his decision,
it's an informed decision. It's not just an assumption or a guess. So to look at layer analytics in general, I think it's to monitor them ongoing is important. And I think it's especially important for new maps. Track the layer load times.
There's cases where that neighborhood layer that you have generated the tiles for and you're loading it in your map and you're serving it up, may be way faster if you get it from a third party source because they have better servers, network, some content delivery network, whatever the case may be. But on the reverse side of that, you may have the opposite.
I've worked on maps where you've pulled in ortho photos from the government and for whatever reason it's a lot slower and it'd be faster for me to download, process the tiles, and serve them up myself. Another good thing on the monitoring the layer loads would be tracking the layer loads is tracking the load of multiple users hitting
your system at the same time. From one or two people, yeah, it's going to be fast. But if you start adding a whole bunch of people on there, it's going to start slowing down the user experience for the user. And also monitoring the health. You first get your map up for the first time, it's going to be lightning fast.
But over time, you're going to have more user base. You might start building up other craft on the server and it starts slowing things down. And tool use. Tool use isn't necessarily the case for everyone,
but I think it's important for a lot of users that you get excited about a new web mapping platform and I'm going to add every single tool there is, every tool. And I think it just confuses people and it's frustrating and it's intimidating to people, especially maps. You know, you look at general public type maps.
And I think tracking which tools people use and how often they use them is a good indication to justify if they should be there or you should remove them. Or you may find that a combination of three tools could be joined into one if you start tracking analytics.
And then it makes that more efficient for the user as well. But regardless what you do, it's back to the same thing. Make the decision. Make an informed decision of taking these tools and stripping them down to one tool.
So how do we track map analytics? Well, it kind of depends on the platform you're using. It could be as easy as a plug-in. Like in the case of Open Geo, you have MapMeter kind of built in as a plug-in. Or it could be Google Maps API for work where it's already pre-built in.
There's a dashboard and it's tracking a whole bunch of analytics for you already. But not everyone is using enterprise level systems. So what are your options? Well, there's Google Analytics. You can expand on Google Analytics. Or something that we've been working at Spark Geo just recently is Sliptix, basically Slippy Map Analytics.
So I wouldn't mind just running through a couple examples on this, maybe one for Google Analytics. So more than likely, you're already using Google Analytics to track your website. As part of the API that you're loading into your website, it has a nice little function for tracking events,
custom events. It allows you to define some categories, some actions, options, labels, values, that kind of thing. And you can track things like zoom level or in the case of the tool usage, you can track tool usage in your accounts. But for this example, I want to just go through
and just count by zoom level. How many times are each zoom level on my map getting hit? So I'm not sure how many people have set up the analytics part themselves. But generally, you register through Google Analytics website. You register your website. And they'll give you a little code snippet and a tracking
code that you need to embed in your website. If you're on a large team, it's more likely it's already there. And you don't want to be adding it twice. So just maybe either do a look around or a find in your project. For this example, I want to use Leaflet to for this.
So I want to include that. Creating the map and layer is nothing different than any other Leaflet map. So there's nothing new here. But what I want to do is, because I want to track the zoom level, I want to bind to the zoom and map event. So every time that zoom end is triggered,
I want to send that information, that zoom level, back to Google Analytics. And that's it. So right now, it'll track. So if we jump to the maps, find where my cursor is.
So maps loading. That's fine. You zoom in.
So I can see that I'm already connected right now, obviously. I'm not sure how many people are familiar with the interface for Google Analytics. For the real time, you can go into events. So it's got zoom level seven.
And go back to the map. It's probably a little extreme zoom in, but it starts popping up more and more. So that's just the real time stuff. More than likely, you're going to let it sit for a while, start collecting analytics, come back later, and go in.
In this case, I've created a custom widget. So if you're really keen on things, you can create a custom widget for your dashboard and then just outlays. These are my zoom levels. These are my events, how many times that each one's been hit. And then the nice thing about this, I can check my date. So if I find that there was a busy weekend or a busy week of lots of traffic, I can see where people are going,
that kind of thing. And back to that tool example of tracking tools, it's the same thing. It's not much different than what this would be. So every time the tool is clicked, you'd send that click event information back to Google Analytics. And then you could add basically another widget to this.
To add it into here, or just this chart? Yeah, when you sign up with Google Analytics and they go through the registration process at the end of that, they'll give you a little code snippet that basically dynamically loads
the Google Analytics libraries. So in my, I'll just go back. So in this case, I'm actually tracking the zoom level on the bottom there in the red. So you did a custom?
Yeah, well, it's not custom. It's a pre-existing event inside Leaflet. So I'm binding to that event. So basically, every time it zooms, it sends that information back to the server. And there's a whole bunch of events that you can bind to. You can bind to load events for layers.
You can bind to click events for markers on the map. But there's a lot you can track. So SlipTix. So SlipTix is a project that we started, I'd have to say, very recently at Spark Geo.
And basically, we wanted to start building better maps. And Will, a colleague of mine, we were always talking about, oh, we assume this is the way this is coming in fast, or we think this is slow. But we never had the answer. We never had the empirical data, basically,
to prove that was the case. So we needed to know what was happening on our maps. And so we needed to track analytics on it. Google Analytics is great if you just want to track simple stuff like that. But I think we wanted to take it to a new level and track more geo analytics.
And to do that, we needed something, I think, different. I'm not sure what exists out there for SlipTix maps, but I don't know of any. I'm not sure if any of you guys have run across any other kind of platforms. We needed it to be easy to implement into our existing
maps and easy to implement into new maps, and also support the major libraries that we use, which is Leaflet, OpenLayers, and Google Maps. We understand there's probably going to be able to performance it, but we want to keep that to a minimal as possible. And obviously, the more you're going to start tracking,
the slower it could potentially get. Basically, SlipTix was born from that. Like I said before, it's slippy map analytics. The other nice thing about it is we're not tied to a specific vendor. I can see how fast the British Columbia government layer is coming into our map.
I can see wherever the layers or wherever the information is coming from, I can see where it's happening. I'm not tied to necessarily my own data. So in this case, I want to run through a quick example of doing an A-B testing of a layer. So similar to Google Analytics, you'd register on the SlipTix website.
You'd get a tracking code similar to Google Analytics, which I'll talk about a bit later. And then you include the SlipTix client library. And because it requires Leaflet, you can see you just add it in just like any other JavaScript library. In this case, I want to test four different layers that I've
kind of randomly selected. And they're standard Leaflet tile layers, so there's nothing new here. And that was part of the requirement of what we wanted for the library. We wanted to keep things as minimal as possible, minimal changes as possible.
I guess there's one addition. I lied. There's the SAID. So the SAID is our way of identifying that layer in our user interface. If you don't supply the SAID, everything works fine, but you're going to have a URL. You're going to have the source URL template in your reporting.
So this just cleans it up a little bit. So in this example, I want to select a layer. So I randomly select a layer of the array, and then I create a map instance just like you do in any other Leaflet map. But now this is where the tracking ID comes in. So the tracking ID is tied to your website URL,
not necessarily the map specific. And also, I've put an SAID in here as well to uniquely identify that map. So and then finally, add the layer to the map just like you would any other time. So I'm just going to jump to find my cursor again.
I'm not sure which layer this is, but there's a new layer. And then I can go into. So when the layer loads for the first time, so Sliptix, take a step back.
So Sliptix registers your site. So you go to the website, you're going to see Sliptix's site in there, but there'll be no maps. And as soon as the layer loads for the first time, it registers that map in Sliptix. And then you can go through the reporting page later. So I can find it.
So I registered this earlier before the presentation. There's zero maps at the time loaded. So there's my AB test. It's been loaded once. And then I can start getting into analytics. So if I go down to, well, in this case, I haven't moved anywhere yet.
My cursor again. So there, it registers that layer, specific layer. I'm not sure what that one says.
Can anyone read that under something or other? So we're tracking the average speed loads, how many times it's been loaded, the number of activities that the user does on the map while that layer is loaded,
averages, max, means, that kind of thing there for that. And then you can change day to switch to hourly or set a range or whatever. So if I go back in again, I'm not sure if that's the same layer, so I'll do it again. So we've got a couple different.
So then it just keeps, starts tracking the information. And then from here, it's like any other analytics. You know, you step back for a while, let it do its thing, come back later, and start looking at what's going on. And then you start seeing, in this case, for the AB test, you might want to track the user engagement.
How engaged are they with that specific layer? Are they looking at it, oh, yeah, that's nice, and then leaving? Or are they spending some time on it? But then you look at the case, well, they're spending time on it. Is it confusing because they have to zoom around and look around because the layer's not clear? But that's a whole other map psychology
of why they're not doing it. But we're tracking the what. So we're in the early stages of this now. And back to the case of Dan's case, it will also track the number of activities at specific zoom levels as well.
So you can see, is this zoom level busy? Zoom level 20 never sees anyone. So it kind of gives you an indication for the caching to make your caching better as well to keep track of that. So that's showing you between? Yeah, I'm not sure. Yeah, I got the, it's just small.
But it basically starts showing you hot zones of where the activity is. Right now, it is a heat map. It's just I only have one point or two points or something. So that's how many, that's zoom level 13. So it displays the most active zoom level
to start with. And then let me go back, find my cursor again. Only have the one zoom level in this case. So I didn't zoom in enough. But it will list all the zoom levels that it has been at. And then what, how many, the counts for each zoom level. Don't need iTunes.
So to kind of summarize things up, tracking map elements is going to help make your maps better. It's going to make it from good to great.
If you're interested, start tracking simple things to start with. Like I said, track the map movements. Track layer load times. Track the tools. Start with that, and then extend your collection from there. Because you're going to start asking more questions. And then you're going to have to find out how to answer those questions. Well, you might want to start tracking other stuff
on your map. You might want to start tracking map clicks, or just in general, the overall app, like the buttons, which buttons people are clicking. Well, you start binding to events and stuff like that. So Sliptix itself, we haven't done that piece yet. But it's basically to come.
And these ones aren't necessarily, there's lots of options out there. You either use one, or you use a combination. You use a combination of Google Analytics and Sliptix, or whatever you want. But I think to take anything away from this, make the informed decision.
I think that's the ultimate goal. Questions? We're very early on it right now. So we're sorting out development-wise. And then we haven't sorted out a fee. But we've been kind of throwing around free to start
to a certain level, depending on how much usage, and then pay after. But we're still kind of working on that. You had some ID, and what was it?
SPID, or SAID for identifying the maps. Could you also use that? Could you give 10 different maps in your system the same SAID if you wanted to combine the results? Or could you automatically, or could the SAID, say, be identifying a user account?
In fact, when you load a map for a given user, you can see what maps a specific user sees, or how much this user does versus this other user. The SAID could be anything. It could be, you know, it's up to you to,
we call it an ID, but it's kind of more of a label. How do you want to label it? There is, I'm trying to think. I'm just looking at ways to aggregate the data in sensible ways if it's not just, if you have one, each map is not used by, if you have, each map is specific to one person,
potentially, but you have lots and lots of maps. Like I said, we're super early on this development, and we're looking for any feedback. So if anyone's interested in giving what they would like it to do, or suggest features, or beta test, or, you know, go to this website,
slipdicks.com, there's a kind of a sign up there. You can leave a note in there if you're interested in giving a, basically kicking the tires and giving it a spin, so. If anyone else has questions, maybe after? Afterwards. Yeah, if you guys want to just hit me up. Sorry. Thank you. Thank you.