-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trackPageView is showing the same PageView duration for all pages #781
Comments
@ranjitkrishnan - did you provide the same name that you used in startTrackPage() for stopTrackPage(). You do not need to use trackPageView() if you are using startTrackPage() + stopTrackPage() |
@jpiyali I might have messed up the name. After removing the trackPageView and calling startTrackPage and stopTrackPage(), i am getting things somewhat right. Do I need to set overridePageViewDuration as true in this usecase. Currently my issue is that the pageView event is not starting from 0ms. It is starting somewhat in the middle as the screenshot below. The Dependencies are starting correctly. |
overridePageViewDuration is to enable you to provide a manual measurement. The timeline depends on where you are firing the startPageView(). Are you firing this early enough in the page? |
Also, overridePageViewDuration is applicable only to trackPageView() api |
I am calling the startTrackPage on route change itself. Isnt the PageViewDuration supposed to be the time interval between start and stop calls ? What i am seeing is that the timeline start from the PageViewduration property. Say if the PageViewDuration is 1.5 sec, the timeline of the pageview call starts at 1.5 seconds and end at 3 seconds. Not sure if this observation is correct. See the screenshot below |
@OsvaldoRosado - what is referenced as 0 in the graph above (is it earliest timeline for a specific set of related events?). For automatic pageview tracking, the telemetry is sent after; how do you capture start time of the page for this view above? @ranjitkrishnan - yes this should be the time between start and stop page. From the screenshot, it looks like page view duration is being reported as 3.3 seconds which maps to time difference. So, two questions,
|
The gantt chart sets 0 to the earliest start time in the operation (usually equal to the set of telemetry sharing an operation id, ignoring extenuating circumstances). The transaction details view is aware of how different versions of different SDKs collect telemetry. For JS SDK, timestamps are adjusted for timeline purposes by subtracting duration from the telemetry time, to accommodate for #628 |
Additional note to above: It looks like this adjustment only happens for dependency telemetry from JS SDK. Should this happen for pageviews as well? The first screenshot in this thread doesn't look like adjustments are needed (unless those ajax calls should have happened after the end of the pageview event, not during) |
@OsvaldoRosado The first screenshot in the thread was captured by calling trackPageView method which was giving wrong pageView duration for SPA as there is no page load here and was showing the same page view duration for all pages. As suggested by @jpiyali , i have changed to use startTrackPage() and stopTrackPage() where i was calling startTrackPage on the route change and stop when the page is completely loaded after all the ajax calls. I am getting the duration correctly but it is not correctly positioning in the gantt chart. |
@ranjitkrishnan Got it. I'm just trying to understand if the SDK behavior is such that a start time calculation adjustment needs to happen for all page views, or just ones recorded using start/stop. (And if the latter, how the UI is supposed to know this is the case). @jpiyali Any thoughts? |
Referencing PR #804 to fix issue around dependency time tracking. Fix will be available only in Javascript SDK beta version 2.0.4 |
not sure now this will be help full still, set the below property. and see the refUri is not capturing for me, any help ? |
So, I've been having similar problems in an SPA, and decided to try to single-step the code that's built in version 2.2.2, and hosted in https://az416426.vo.msecnd.net/scripts/b/ai.2.js, I think I see the following:
EDIT: The example below is a good way to track page views backwards, it seems. I'm leaving it here so that you can see how broken it is, and my next attempt in the subsequent post. So, I was able to get the SDK to log correct durations (although the portal shows it as page load time, not duration), by putting the following into my base Razor view file:
And then the following at the beginning of the JS call that issues an Ajax call and loads the partial view with content:
I lifted the trace ID code out of the SDK implementation, as it's private, and exposed it in a helper function:
Sorry for the wall of text, but I AM seeing correct durations with this using trackPageView. I believe based on this that startTrackPage and stopTrackPage would be a better solution for SPAs, as they seem to be much lighter weight. Hope this is helpful. |
OK. So, I "solved" the problem in reverse in my previous post. I have to play fewer games with squirreling values away, and get better metrics, if I do this: In my .cshtml base, bookend the page with a
and
In my Ajax helper, before submitting the request:
And in my request complete handler:
So, I get good page loads/durations out of App Insights now! I also get Here's the problem, though: Changing the traceID, as the docs suggest for SPAs, works brilliantly for separating details of different page views. And when you stop tracking a view, the SDK logs a metric for the PREVIOUS page visit time - great - the problem is the previous view was loaded on a different traceID, and you've changed it for the current view, so it gets logged as the operation ID of the PageVisitTime metric. In other words, the metric will be correct based on request name and URL, but if you try to correlate it based on operationID, it will align with the SUBSEQUENT page view, because you changed it. Or am I doing this wrong, also? It's hard to tell. I'm not using Angular or React plugins, because we're not using a formal SPA framework. I like this SDK, but it feels a little broken for SPAs at the present time. I'll have to go back and basically implement my own PageVisitTime tracker in order to get metrics that line up. And, once again, I apologize for the wall of text. I think, though, that it's important to see the thought process of ordinary developers like myself, because documentation and examples live in multiple pages (GitHub, as well as docs.microsoft.com), they're not always current, and folks like me wind up having to reverse-engineer the documentation from the code. |
And, I'm back. I think this solves the problem "correctly" for my use case. No wall of text. Just the changes. I am hijacking appInsights.properties to track my own "previous view". View : disable page visit tracking, and start tracking the page:
View $(document).ready:
Ajax request setup:
Ajax request complete:
|
We were having issues with pageview where its "eventTime" in appinsights was actually the end of the event, while in dotnet core appinsights the eventTime seems to be the start of the event.. I tested this by setting the startTime of a dependency telemetry manually with the correct value with a matching pageView request. Here B is the correct time, since it aligns with the backend services timestamps, while A is the incorrect pageview time which is perfectly off by its duration. Managed to fix this by adding a TelemetryInitializer and overriding the .startTime property to follow the AJAX codepath shown as resolved for this issue #628.
Note that I also overrode dependency values, since the auto tracking of FETCH calls were also wrong for us. They would start in appinsights a duration time after what our downstream services reported. |
@mRowlinson27 VERY nice find... I've created a new issue for this specific bug. |
Hi @h0wXD, looking at your workaround and the actual code for the Where the And in both cases the |
RE: @h0wXD and for others
if you try setting envelop.time in a telemetry initializer it will get overwritten. but in the telemetry initializer you can set
|
Thanks @pl-jcarter that is a REALLY good catch!!! -- BUT!!! We recently (Monday Feb 7, 2022) identified a change with the backed "Portal" that "stopped" adjusting the envelope.time for the PageView (to "fix" the reported time) by the duration (effectively subtracting the duration from the envelope.time) based on the version of the SDK being used.
So a couple of things are now in progress.
|
Hello everyone, I'm using version: 2.8.1 in a spa written with angular 13.3.0. Using the configuration:
To get around the problem, i disabled the enableAutoRouteTracking and started using the function: startTrackPage and stopTrackPage.
however I noticed a behavior where the operation_name was coming invalid, it always came the name of the first page accessed, example below: As the overview screen aggregates by the property (operation_Name) the display was wrong, to work around the problem in addition to calling the function: startTrackPage I also needed to set the name of the operation:
That way, I managed to get around it and apparently everything is working perfectly. But I have a question, shouldn't the name of the operation_Name property take into account the value of the name that we set in the method call (startTrackPage)? |
The stopTrackPage takes 2 arguments that are key The So I think if you pass the url as the 2nd argument (as well) this should work |
@MSNev I tried using the second parameter and it didn't work either, the only way I found was as in the example above. |
@Karlie-777 can you please investigate this a bit more as I believe the start / stop should work in this case and please provide any other context you have for tracking page view times for SPA's |
@renandegrandi If I am understanding it correctly, you are mentioning that |
@Karlie-777 I understand your position, and in fact it will solve the problem, but you don't believe if we are identifying the operation through the parameter |
@renandegrandi The |
@Karlie-777 I don't think this can cause problems, because I use the insights sdk for workerservices, and in it we can provide the name of the operation through the method: |
@renandegrandi so the |
We are using Application Insights to instrument an Angular 6 SPA. In route change, we are calling trackPageView. But the same duration is shown in all the pages. I have seen a similar issue raised before for this
#570
I tried using startTrackPage() and stopTrackPage() method as per that suggestion. But i am confused on the usage of this method. Do i need to still call trackPageView() method when calling start and stop method.
When calling start and stop methods, without using trackPageView, i didnt get an page view tracking. When used with trackPageView(), it came as another pageView entry within the main event as the screenshot below.
I may be doing something wrong here. Can you please let me know on how to use this.
The text was updated successfully, but these errors were encountered: