- [Narrator] In this tutorial,
I'll show you how to take advantage
of the usage analytics features
in Azure Monitor Application Insights
to get visibility into the behavior
and usage patterns of users accessing your apps.
Application Insights provides the APM capabilities
in Azure Monitor by tracking server response times,
application performance metrics
and failures, performing availability
testing, dependency tracing,
and much more.
Additionally, usage information is also collected to augment
these monitoring capabilities
and the type of usage data
I'm referring to here consists
of statistics on the numbers of users, sessions, events,
and also contains browser version, OS version
and location info
all coming from browser side, JavaScript instrumentation.
First, I'll look at the usage info available
in the context of monitoring my application.
In my day to day operations,
I typically look at availability,
performance, failures, and alerts.
I'll start by investigating failures
that took place over the last several hours.
This blade shows failures group by operations,
dependencies, exceptions, and roles.
And on this screen among other criteria,
I can filter by operation
and exception type.
These filters limit my dataset to
a subset of operations
that will be shown under the drill into section.
And in this example,
it's about 140 operations
that match my previous selections.
Now, I can select a single sample operation
to see it's end-to-end transaction view.
This view includes a Gantt chart showing
where my transaction spent its time
and includes things like the exception details
and the Call Stack.
But what I'd really like to point out
is the usage information that will be available
in the related item section
in the bottom right.
You can see a timeline of page views
and events just for this session that the transaction
is a part of showing any other events
or page views.
And you can get a similar timeline view
for the user showing other events performed
and other pages viewed by the user.
You can also see what happens before
and after this type of request
and User Flows.
I'll cover User Flows in much more detail later on,
but basically it's a flow diagram of sessions
and what took place before
and after the operation
that we drilled into.
Or lastly, for this part of the demo,
you can see all the telemetry for the user session,
including standard page views,
custom events, properties,
and attributes, dependencies,
and much more.
This type of information is available
end-to-end transaction view
whether you started in the failures blade
as I did,
or if you got there from the application map
or the performance blade,
Another workflow where usage information is very valuable
is when responding to performance degradation
on outage event,
as part of the response to that event,
I want to know
how many users were affected.
So this leads us to smart detections.
These are automated warnings about performance problems
and failures in your app.
And depending on the type
of detection displayed,
as I'm showing here,
there'll be a count of the affected users
to help you gauge the extent or impact
on your users.
In the first detection,
hundreds of users were affected,
but in this other example,
only six users were.
I'll now move on to the performance blade
to show how browser side instrumentation can also provide
insights into commonalities across load transactions.
First, I'll switch this toggle
to the browser selection,
and this view shows all browser operations
sorted by date duration
and response time.
I can select a request by name
and select a range of durations in the histogram
over in the top right.
Based on these selections,
the Insight shown below will update
to reflect things like trends in performance,
but also includes groups
of transaction by common properties,
including those properties coming
from our browser site instrumentation items
such as geographic location,
browser version, and OS version will be listed here.
You can also easily navigate to user views
from the application map.
The app map shows all
of your app components group by instances,
it shows the dependencies between them,
but it also shows availability tests.
And most importantly,
for this demo client-side information,
I can use this to pivot from my app map
to the stats collected on the users
of the app.
Now, that I've covered some places
where this usage info is available
in the context of App Insights investigation experiences.
I'd like to focus on some of the out
of the box, basic workflows,
starting with usage analysis views,
but these views,
we want you to be able
to answer common usage questions,
such as which webpages
and features were the most popular by numbers of users,
sessions and events.
Where do users typically drop out of a website
or a business funnel, how often,
and at what time
intervals the users return.
And additionally, we can also investigate
if there's a correlation
or relationship between end user experience.
For example, how long a page takes the load
and user behavior;
does the user remain engaged and return?
With this type of information available to you,
you can better determine when
and where to assign development resources
and align your development strategy
with the desired business outcomes.
Before I jump into user experience,
just one quick note and how the data
that we're about to view is examined and collected.
User and session IDs
are automatically identified
by the default service site agent or SDK,
and are mapped to the corresponding page views
collected by the JavaScript
instrumentation on the client-side.
This is used to track user activity.
For most web apps,
this process has done automatically using browser cookies,
but if your user IDs are not automatically identified
with our default instrumentation,
you can manually send back the user IDs
and session IDs and telemetry from code
and even track authenticated users.
To start I'll return to that App Insights blade,
and navigate to events under usage.
These usage stats include out of the box,
lots of detailed by default
items like the number of page views
and requests, page titles, URLs,
the browser version,
the operating system version,
the application and even geographic information.
But you can take things a step further
to view custom events and properties.
If these have been implemented in code using the SDK
on the server-side by client-side, JavaScript, for example,
if a user clicks on a specific button
to access a page or upload or submit a file
that can be considered a custom event,
or as a second example,
you can send back custom e-commerce attributes,
such as status silver, gold, platinum,
or so on.
As part of your page payload.
So you can analyze usage
and performance by the user tier.
Now we'll step through the options available under usage,
for each of these items listed here,
I'll discuss the type of questions
that can be answered.
First, I'll start with users.
The type of question answered here is
how many users viewed a specific set of pages
or performed a specific set
of user defined events over a chosen time frame?
Additionally, the user count shown here can be displayed
or split by any of the properties
that we talked about earlier.
For example, how many users during the last day
or 24 hours clicked on the create new ticket button.
I'll choose to display
this over time,
in one hour intervals before I go ahead
and split by state or province.
From here, I have some options
I can choose to switch my visualization
from a bar chart to stacked area chart.
And we also have the option to pin this view
to a dashboard or viewer edit the query used
to create this view in log analytics, or
we can reuse the query in a workbook.
Lastly, I can scroll down
and I can evaluate meeting my users.
This will give me the option to choose random users
or look at the most active users
to see similar details
like we saw before at the end
of the end-to-end transaction view
on the actions performed by that one user.
Next, I'll move on to sessions.
The question answered here is how many sessions
in a chosen time frame included a set of pages
or events that we get to define.
For example, during the last 24 hours,
how many sessions included hitting the homepage?
First, also like my time range
and then also like my page of interest.
But this time around I'll apply
two splitting options.
I'll also add a second split by operating system.
And this time I'll leave the default bar chart
as my visualization.
And we also have the option here of directly pending
this view to a dashboard
or reusing the underlying query.
Now, move on to events,
recall that events here referred to the out
of the box page views
that we tracked by page title
or user-defined customer events
that you've created using our SDKs.
This view answers questions such as how many times or
instances was a specific event
performed during the selected time frame,
but it also has the options to change the splitting
and modify the visualization just as I did
in the last two demos.
As an example for the last seven days,
how many times was the edit ticket button clicked by user,
but this time I'll split the application version.
This is useful when we're monitoring mobile apps,
where users are responsible
for completing their own upgrades.
These events statistics can also be used
as a starting point for grabbing a sample
and performing a deep dive investigation.
So I can drill down to the end-to-end transaction view,
which shows all of the dependencies
and where the time is spent,
and if there are any errors.
This is usually one of the final steps
in a performance or failure investigation,
but you can also quickly get to this point
from the usage views, using events.
Moving on to funnels.
These allow you to understand
how users progress through a series of steps
on your app or website.
The basic question answered here,
is what are the conversion rates as you just navigate from
one page on the website to another?
The most common use case for funnels
applies to e-commerce transactions
where a business evaluates,
how many users go from,
let's say the homepage to the sale link
to the item list to add to cart, to checkout.
But this approach can also be used on any user
defined combination of pages or events
propose the series of steps that you expect
the users to follow,
then view the percentage of traffic
that actually goes through those steps.
For this demo I'll use homepage as step one,
tickets as step two,
and then we'll add detail as step three.
Now, once we've entered the steps of the funnel,
we can go ahead and save it
and evaluate the results.
We can see the count of users at each step
and the percentage that's been converted that move on
to the next step.
Insights on the right here,
allow me to see what happened before
and after each step,
when I select the step
in the funnel itself.
Now we'll move on to some advanced usage analytics
in contrast to funnels,
which are very narrowly focused
and highlight conversion rates around
some expected behavior.
User Flows offer a more generic picture
of where users go next.
Instead of specifying a series of steps,
User Flows requires only the first entry point
to construct the entire visualization
for the subsequent series of pages
and events that were used.
I'll go ahead and set my previous steps to zero,
and now the homepage
will become my first entry point.
From here you can get a quick high level view
of all the user paths
from many sessions at the same time.
This view allows you to discern
where do users go next from a specific set
of pages on your site
onto the next step?
Where do users typically leave your site?
Where do you have dropouts
or sessions ending?
And are there any places
where users perform the same set of actions repeatedly
or loop through the same set of pages over
and over again?
This type of diagram
is called a Sankey diagram,
typically used in engineering to show the flow
or consumption of some resource,
but they're also gaining popularity
within APM teams
for displaying user sessions or flows
or breaking up and identifying processing time.
From here, I'll move on to retention.
Retention shows a sliding four week window,
the percentage of users that return to your site
or app or returned a specific page or event
in the app.
The questions answered here,
are: How often do users return to your site?
What's your repeat user rate?
Which pages on your site are the stickiest
or have the highest adoption rate?
Let's look at users who use tickets
and then returned to the tickets page over the last month.
In general, we can see that just over a third of users
who hit the ticket page
return the following week.
You have some flexibility here.
You can change the starting and returning events
to anything you'd like to view this type
of metrics in the list and this table
with the return rates over the last four weeks.
Finally, we'll spend a moment on Cohorts.
These allow you to define a set of users
or sessions by selecting some predefined parameters
where you can actually use KQL queries
for more detailed definition,
neither case you can use cohorts as inputs
to the users,
sessions, and events views
that we've shown earlier.
This gives you greater flexibility
in analysis by pre-populating just the users
of interest before you continued
with creating the custom charts, graphs,
and making other selections like we showed before.
Here, I'll edit one of the existing templates
to create my own definition of engaged users.
An engaged user is
someone who's used the app for a certain number
of days within a specific time window,
but I'm only concerned with users
that have been editing tickets.
So I'll add additional filters to limit this,
to my engaged user set
that have either edited the page
or clicked the edit button.
Once this is saved,
I can reuse it an events to see what
are the actions these users have done in common.
Many of the workflow shown earlier have been very dynamic
and require the operator
to navigate the UI,
making selections and drilling down where appropriate.
However, we have a number of predefined workbook templates
that highlight interesting usage information
in the form of interactive reports.
I'll navigate over to my workbooks gallery
to show you some of what's available.
There are workbooks available for failure analysis,
evaluating performance and usage, retention,
as well as business hypotheses.
But I would like to focus on Application Performance Index.
This workbook is based on Apdex
and open standard for measuring
and comparing end user experience by setting up minor
and major thresholds.
As shown here,
the minor threshold is defined by variable T.
And the major threshold
is four times T, four T .
Users that experience a response time between zero
and T are set to be satisfied.
Those are response time for routine T and four T
are described as tolerating.
And those with response time above four T are considered
to be frustrated.
One of the benefits of this workbook
is that you get to set the range
of operations you'd like to filter on
and the value that you want to use
for your threshold.
Here I'll set my operation
as the report index request
and I'll set my threshold T to one second.
So in my case,
users with response time of less than one,
we'll consider them satisfied between one
and four seconds would be tolerating
and above four seconds,
we consider them to be frustrated.
With these thresholds set,
it looks like most of my users
are gonna fall in the satisfied bucket
with only a few dozen users
moving over to the tolerating
and the frustrated bucket.
Hence, the great Apdex score of 0.9.
Apdex is on a scale of zero to one.
So we're really close to perfect here.
Also keep in mind that these workbooks
are completely customizable
and we have the full flexibility
of the underlying log analytics platform.
Here, I've drilled into log analytics
and we can see the existing query.
We can edit this query
or write entirely new ones
to modify or to create new workbooks from scratch.
Thanks for watching this tutorial
on the usage analysis capabilities
of Azure Monitor Application Insights.
These features help you understand how people use your app
and provide the basis for data driven decisions
and upcoming development cycles.