Okay, and with that, I'd like to start the next talk.
It is once again going to be a talk by Thomas Persson, and I'm once again going to do a
small introduction.
He is a business developer at Digitalist Sweden, and he has worked with Tracking Digital Analytics
since 2010, and has been a contributor to open source since 2007.
Tracking SBA applications is something that often leads to bad data and frustrations.
In his talk, Tracking SBA Applications with Matomo, Thomas wishes best practices and demo
how to make it work.
Thank you.
All right, thanks.
Let's see how this goes, fourth presentation for two days now, hope my voice don't crack
too much.
All right, so yeah, generalists and working for Digitalist, we are an open source loving
organizations that provides expertise around Matomo, for instance, we sell a SaaS service
and help our clients with consulting around Matomo.
We're also developing plugins for Matomo.
So in this presentation, I will talk about single page applications, and let's start
by answering the question, or actually, it's not me answering, I think it's a Google in
this case, or a Wikipedia descriptions, but what is a single page application?
So let me read it out loud, a single page application is a web application or a website
that interacts with the user dynamically, rewriting the current web page with new data
from the web server, instead of the default method of a web browser loading entirely new
pages.
So what does this really mean?
Let's look at the next page.
And hopefully, we can see a little bit of an example of this little video we play.
So in this case, this is a single page application, and what's significant here is that we're
rewriting the page in comparison to this one, you can see that the whole page is reloading
and you can see that little refresh, I'm going to do it again.
So up on the left hand, you can see that now we're not reloading the page, we're just quickly
rewriting the URL, but it's not really happening, but when I switch to the Matoma org website,
we can see that the actual whole page gets refreshed.
So that's the main difference where we're dynamically loading data into the browser
without actually refreshing the browser in the traditional way.
So examples of frameworks for single page applications are Angular or React or Vue.js,
there are a lot more examples, but these are probably the biggest three frameworks.
As you might know, Angular is used in Matoma to create the widgets and we're actually switching
over to Vue now, which I think is a nice move.
So I think that is supported from 4.5 and I've seen that the interface has been starting
to be rewritten in Matoma.
So actually when you go into the Matoma interface to load different reports, you can actually
see a single page application in place.
We are refreshing Matoma's interface without actually reloading the whole page.
All right, so when it comes to tracking these applications or working with them in general,
it requires us to, because page views is kind of the fundament of web analytics or the internet
or the web, I should say, not the internet, but the web is basically based on page views
and links and since we don't really have that, we need to fake these page views.
Normally, when you refresh a page, you have a browser event called page view and that's
actually what we refer to when we track page views.
So instead of doing that, we need to use another event happening in the browser when we reload
the page.
So if I go back to this little page and I click on the link, we can still see that this
one has changed the URL.
So we are having an event called history change and that's the event we will start using instead
of the traditional page view event.
Yeah, an application can look like this.
You start to create a URL structure that matches a real website, but you're not really refreshing
the website.
One example is to add the hash sign and then apply new URLs and it's more correct to call
it a context in the application than a real URL, but in this case, we're not having the
hash but we're actually rewriting the URL so it looks like a real URL.
So basic tracking in Matomo has to be done differently.
So instead of using the traditional page view event in the Tag Manager, we need to use the
history change event.
I will demo this soon as well.
And of course, you will need to add the Tag Manager script to your application and then
you create the standard tag of the type page view, but you use the history event instead
of the page view event.
So let's have a look at how that might be displayed.
So I actually have both examples here in this setup.
I have this one which I call the just page view and we have a trigger called page view
on this one and then I have the virtual page views or virtual page views and here I'm using
the trigger called history change.
So if you're familiar with the Tag Manager, you can go into the traditional one and we're
having a trigger here and if I edit this trigger, it's of the type page view and nothing really
different there.
But for this page view, I'm having the history change event and let's go and look instead.
Let's just start from scratch.
If you have an empty container, you need to click this one and you actually have an event
further down here prepared in the Matomo tag when you call the history change.
So you can just use that, give it a name and start using it.
I want to create a duplicate here because I already have it in place, but that's basically
what you need to do.
Depending on how well your single page application is written, you might end up in different
problems and I will talk a little bit more about that, but first look at the example
we have here.
So I actually have the tracking going on under the hood.
So when I click on different URLs here, you can see in my network console that I'm actually
sending data to Matomo.
So let's see what happens.
I will refresh and look at the visitor log for my particular instance.
So what you can see here is that I'm actually getting the full URLs and it seems like I
get the tracking going on when I just switched the context and I also have some title coming
in here.
So depending on what I'm looking for, beach, beach pictures seems to be matching this and
the URL.
So that seems to correct, but actually this application wasn't really written in a correct
way from a web perspective.
So I had to do some customizations to get this to work and we look into what that is.
So by default, when I send the page view, you can, yeah, actually the first page view
is the normal tracking and let's have a look at that, the page view and oh, sorry, I should
look at the tag.
So looking at the page view, you can see that the title and the URL is something we can
tweak, but I don't do that right now and that means that by default, Matomo will just fetch
the page title, which is a head attribute up here.
So the page title is SPA demo, which is this one up here.
But when I click the different URLs, it seems like the page title is never changed.
It's constantly saying just SPA demo.
So to manage that and to get correct reporting, as I actually have down here, you can see
that the title is likely changing.
I have to do some custom configurations because the application is not correctly written.
The correct way for the developers to do this would actually be to rewrite the page title
on every new load, but that doesn't happen.
So in my virtual page view, I fix this by having a look, I've created a custom variable
and I actually read the H2 element into that variable instead.
We also have to fix this in a virtual page view.
We have to fetch an element called the history hash new URL.
And this is actually a built-in variable in the Matomo Tag Manager.
Further down here, you have a lot of history related variables that you can use.
So in this case, the hash new URL, this one, I think it is, history new URL, yes, actually
contains the new rewritten URL.
So that's nice.
If I don't have anything, sometimes I've seen applications where you don't really have a
correct title that you can actually read or an element on the page.
One thing you might want to do is to just get the last piece of the URL and send that
as a title.
So you at least get something more correctly describing the page.
And to do so, you would create another variable and read the last part of the URL and send
that instead.
But in this case, I could use the H2 tag.
We can have a look at that one as well.
So I'm creating a variable of the type DOM.
And with a CSS selector, I can just pick H2 and it will read it out.
You obviously have to test this for your site because actually a page can have multiple
H2.
So it could be a bit dangerous to just do it that way.
But for this particular case, it works pretty well.
So common challenges, as I said, the new page title is not set on history change.
Sometimes we don't even have URLs rewritten at all.
You might have single page applications that doesn't rewrite the URL.
But you still want tracking.
Maybe the only thing being rewritten here is the H2.
In that case, you could actually fake that as well.
I would go to the tag because sometimes you just want to understand how users behave even
though your application is poorly written.
So in that case, you could go in here, you could use the H2 and send that in as a URL,
for instance, to at least fake or simulate that you're tracking the correct behavior.
The best way is, of course, to ask the developers to rebuild the applications.
But sometimes that will take time or be able to do in a few months or something like that.
So it can be a quick workaround to actually set it up in your application.
Another thing that can be a bit tricky is event tracking because sometimes these applications
are dynamically reloading and it's hard to do it in a traditional way.
So in more advanced examples, I've actually been setting up, let's see, let's see where
I have that, these are the configurations, yes.
So this was actually written in Swedish, but that doesn't matter.
But you can actually do that by pushing, this requires more advanced setups, but in some
cases, you have so much logic going on in your single page application.
So instead of controlling all these things in the Tag Manager, you rather set up custom
events in the Tag Manager and just waits for your application to send events like this
on the left side and push data into your single application.
This is also the way to do it with custom events.
So if you're, for instance, having forms submitted in your application or something like that,
you can actually ask your developers to use this MTM push event, custom event, it would
say, and then you would send event category name and actions and value into Matomo and
pick it up and post that.
I've been doing a few of those implementations as well.
Yeah, so let's see, no, that's not the correct description.
But actually, it was quite fast, this presentation.
Let's see if there are questions and open up for that.
Yeah, thank you.
So if there are any questions, please type them up now.
I hope that was to some use, at least I'm pretty sure it was.
There seem to be no questions though, at least up until now.
So let's do it the traditional way, I will be checking the chat.
So please write questions there and I will have a look and try to write it down.
The last tip could maybe be to, there is actually a single page application tracking guide,
because it can be pretty complicated.
Okay, so now we got one.
Ask the tag manager to capture custom variables, I guess, or I don't really, I don't know if
I want to capture custom variables, you shouldn't actually use custom variables, but I'll show
you what to do in the configuration variable, you have something called custom dimensions.
That's actually the feature you should use instead of custom variables.
Custom variables are deprecated in Matomo.
So what you can do here is if you have a custom dimension, you basically set the index number
you have from creating it, and then you use the variable here to send whatever data you
want to send.
So if you have some meta tags on the page containing the tag of the page or whatever,
you can set custom dimensions this way.
So I hope that answers that.
He did add something to it, he said, to me, it looks like you're pushing custom variables
to tag manager.
So I don't know if that's specific.
But then I think I know what he means, because we're pushing to, how should I explain this?
You can, maybe I should actually do some drawing here too, but I don't.
So there are two ways to tag manager can actually, let's check, I can maybe do this example.
Let's create a custom event.
We create a custom event called test, and we're actually getting the way to send custom events
down here.
So we can use this code.
So if we have the custom event called test, create a new trigger, and we can then execute
some code when this happens.
So let's create a custom HTML tag, and it's important in your coding, sorry, we should
do this, then we do that on the custom event called test, and we create a new tag.
So I'm just trying to explain the basic here.
So I will do that, I will go to the application, and I will open the console.
And now I can send this custom event, and we call it test.
And hopefully this will trigger my code firing the alert.
So in this case, I didn't send any data to Motomo, but we can actually use the custom
events here to send whatever data into Motomo and handle it.
So this would actually be what your single page applications fire under the hood.
So if you go back and look at my application here, I would do something like this.
So in this case, I have a custom event called custom page view, and I'm setting these two,
I need to create these variables to catch this.
But I can fire this to Motomo, and then I need to have a custom event, custom page view event,
and then I can set up two variables that with data layer variables called custom URL.
Let's try this and see if I can do this.
Let's create a custom variable called, it should be of the type data layer, custom URL
like that, and then we need to create a custom title, so I will create a data layer variable.
Where do we have it?
Here we go.
Custom URL.
Okay.
Oh yeah, I did not already create it.
I forgot that it was a title I was supposed to, okay, it didn't copy and paste correctly.
Do it again.
Custom title, now it's correct, variable.
So now we have these, we have a trigger, we need to create the trigger called custom page
view, so create a new trigger of the type custom event like this, or custom page view.
So now I have a trigger that can listen to this.
And lastly, now I want to set up a new analytics type, I will send a page view, I will pick
up my custom title and my custom URL, and I will fire it on the custom page view event
that I will manually fire, create this tag, publish it, and then I will go to my page
and just reload it so I get the new version of the Tag Manager, and then let's just go
back to history and let's see if this works.
If I go to the network console now, I should have something collecting this, maybe I didn't,
oh yeah, there it is.
Let's look at the tracking later on as well.
My URL and my title.
So going to the single page application now, I've been actually able to, yes.
So here we have it.
So looking at the application again, this is what you would do, you will have your single
page application control this instead of doing it in the Tag Manager basically.
So you're just having this middle layer taking care of the data and sending it.
The same solution would work for event tracking.
In that case, you would create another tag of the type Matomo and you would go to event
and then create variables to contain category, action, name, and value, and then of course
create another event to listen to it.
That was maybe the more advanced example, but sometimes this is actually what you want
to do because single page application are often maintained and quite tricky and sometimes
you simply have better control of the event handling and the data in the application.
Usually in an application you have something called routing, for instance, and then it's
pretty easy to attach these functions into the application to get the page tracking correctly.
You could actually send page view data directly to your Matomo, you don't have to use the
Tag Manager.
However, I prefer using the Tag Manager as a middle layer here because that gives us
the option to actually manage things in between, even though it's possible to directly send
page view data in, it's actually pretty nice to have this middleman because then if there
are problems, for instance, you can start writing exceptions or blocking things or whatever.
It's pretty nice actually to do it that way.
Any other questions?
Okay.
Thank you.
We've got one more, which is, is the SPA event recorded as a page view?
The SPA event, okay, I think that was what I showed.
I hope that, so the event tracking was what was just displayed.
Okay.
Then hopefully it was answered correctly.
If there's still a question open, I'm pretty sure it's going to be asked again soon.
Yeah, there are new questions coming in now, so hang on.
Yeah.
Yes, seems to be the case.
Just a bit more typing.
Nope.
If that's all the questions, then I would like to thank you once again for another great
talk.
Thanks.