DevTools

July 9, 2022

Not everything is what it seems on the surface when it comes to software. Sometimes, it may look calm and functional, but under the surface is a chaos of errors and breakages. Think about it like a duck, floating elegantly on a pond to the normal observer. But under the surface, the fish see what is really happening; the flippers are flapping, keeping that feathery body from sinking. 

When it comes to software, it’s crucial to give developers the snorkel to see what’s happening underneath the surface. 

PlayerZero’s snorkel is the DevTools feature; the interaction between the UI and the backend is a crucial aspect of getting to the bottom of problems. DevTools are where we take our biggest step out of the cross-functional aspect of communicating issues, directly into the engineering specific. 

Submarine shedding light into the depths of the ocean

Barriers to understanding full user context

More often than not, when an engineer is delivered an issue, they open up a new browser and repeat the steps with the DevTools open to better understand the state of the application underneath the hood. Unfortunately, this process comes with dependencies that. if not met, will derail any attempt to address the problem:

“I don’t have the steps, now what?”

“It’s working on my computer. I don’t see the issue.”

“Who was the user? Can we get them on a zoom call?”

Delivering DevTool context directly to the developer

What data we capture

Our goal is to give you the experience of sitting next to the user with DevTools open leading up to the moment they run into an issue. So, we brought the following directly into the PlayerZero report:

  • Console Logs
  • Session Storage
  • Local Storage
  • Network Calls (Including headers, payload, requests and responses)

PlayerZero captures the state of each of these properties over time. 

DevTools GIF


This means that as you flip through DevTools, you can see how your network log changed in relation to the actions that were happening, or how localstorage mutated after your user logged in. Every piece of information is captured and logged so that you can easily understand the scope and mutation of dev tool data over time. Think of it like an audit log of retroactive information found only in the user's browser.

How we capture data

Due to our unique Private by Default approach to data acquisition, all of this data is cached locally and only leaves your computer with explicit consent. This means if you ever want to create a report detailing the issue you just ran into, you can always do that looking backwards.

By injecting a PlayerZero recorder script into your website or by adding a chrome extension to your browser, you are adding listeners and observers that capture information about every console log, every interaction, and every network call as they happen. But again, all of that data stays on the end user’s computer until they choose to share it with your team. When the user runs into an issue and decides to make an upload, all the data from the last 10 hours of interaction gets packaged up and sent to PlayerZero. 

Network GIF

Think about all the times that you’ve had to ask or wanted to ask for an HAR file with all XHR/fetch data, but are instead left trying to recreate an issue yourself. PlayerZero intercepts and packages all of that information so that you can see exactly what was happening when the user ran into an issue. 

Not only do we make sure that your users’ data never leaves their computer without their consent, we also have basic sensitive data protection in place. By default, we replace credit card numbers, emails, phone numbers, and other typically PII defaults with placeholder values in the network responses and inputs that your users interact with before sending it to our servers. You can also always increase the scope of which values you would like to mask in the network responses by specifying they keys and the replacement values in the Data Collection settings.

PII Filtering UI

Conclusion:

Let’s lighten the load when it comes to sourcing the context necessary to solve issues. It’s difficult enough to balance multiple projects and stakeholders while also trying to unearth issues that are affecting our users. We’re bringing you what you need to be able to dig deeper and root cause the issue, without any of the additional effort. 

Written by:
Matt Kasner
Additional Articles

DevTools

July 9, 2022

Not everything is what it seems on the surface when it comes to software. Sometimes, it may look calm and functional, but under the surface is a chaos of errors and breakages. Think about it like a duck, floating elegantly on a pond to the normal observer. But under the surface, the fish see what is really happening; the flippers are flapping, keeping that feathery body from sinking. 

When it comes to software, it’s crucial to give developers the snorkel to see what’s happening underneath the surface. 

PlayerZero’s snorkel is the DevTools feature; the interaction between the UI and the backend is a crucial aspect of getting to the bottom of problems. DevTools are where we take our biggest step out of the cross-functional aspect of communicating issues, directly into the engineering specific. 

Submarine shedding light into the depths of the ocean

Barriers to understanding full user context

More often than not, when an engineer is delivered an issue, they open up a new browser and repeat the steps with the DevTools open to better understand the state of the application underneath the hood. Unfortunately, this process comes with dependencies that. if not met, will derail any attempt to address the problem:

“I don’t have the steps, now what?”

“It’s working on my computer. I don’t see the issue.”

“Who was the user? Can we get them on a zoom call?”

Delivering DevTool context directly to the developer

What data we capture

Our goal is to give you the experience of sitting next to the user with DevTools open leading up to the moment they run into an issue. So, we brought the following directly into the PlayerZero report:

PlayerZero captures the state of each of these properties over time. 

DevTools GIF


This means that as you flip through DevTools, you can see how your network log changed in relation to the actions that were happening, or how localstorage mutated after your user logged in. Every piece of information is captured and logged so that you can easily understand the scope and mutation of dev tool data over time. Think of it like an audit log of retroactive information found only in the user's browser.

How we capture data

Due to our unique Private by Default approach to data acquisition, all of this data is cached locally and only leaves your computer with explicit consent. This means if you ever want to create a report detailing the issue you just ran into, you can always do that looking backwards.

By injecting a PlayerZero recorder script into your website or by adding a chrome extension to your browser, you are adding listeners and observers that capture information about every console log, every interaction, and every network call as they happen. But again, all of that data stays on the end user’s computer until they choose to share it with your team. When the user runs into an issue and decides to make an upload, all the data from the last 10 hours of interaction gets packaged up and sent to PlayerZero. 

Network GIF

Think about all the times that you’ve had to ask or wanted to ask for an HAR file with all XHR/fetch data, but are instead left trying to recreate an issue yourself. PlayerZero intercepts and packages all of that information so that you can see exactly what was happening when the user ran into an issue. 

Not only do we make sure that your users’ data never leaves their computer without their consent, we also have basic sensitive data protection in place. By default, we replace credit card numbers, emails, phone numbers, and other typically PII defaults with placeholder values in the network responses and inputs that your users interact with before sending it to our servers. You can also always increase the scope of which values you would like to mask in the network responses by specifying they keys and the replacement values in the Data Collection settings.

PII Filtering UI

Conclusion:

Let’s lighten the load when it comes to sourcing the context necessary to solve issues. It’s difficult enough to balance multiple projects and stakeholders while also trying to unearth issues that are affecting our users. We’re bringing you what you need to be able to dig deeper and root cause the issue, without any of the additional effort. 

Follow us on Twitter
Sign up for our newsletter.
Get the latest articles delivered straight to your inbox.
Share
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Additional Articles