We use RUM in conjunction with Session Replay quite frequently. Its important to understand how our users are interacting with our product and ensure that the processes of supplying payment is clear and simple.
Use Case 1 - Customers paying their Policy in Full!
After taking Monday off, I came in Tuesday where my Supervisor confronted me with an issue that he had. He explained to me that while making his typical monthly payment on his account, the system automatically paid his remaining balance and it instantly hit his checking account which actually didn't have enough to cover the payment. AS you can imagine he scrambled to his banking app to move funds so that that additional fees would not be charged due to lack of funds. I have to say we all got quite a laugh about it but it peaked our interest as to what transpired in the transaction.
We immediately jumped into the session replay of his session. We also opened up another tab and looked at a similar transaction a week or two ago. We found that the Wed Dev Team had pushed a UI change. While this change appeared to just update the overall "feel/look" of the web page, they actually changed the function of the button so many customers were use to clicking for their monthly payment.
Previously users would select the "Pay my Bill" button and they would make their monthly payment. After the update, that button, while still visually the same, actually initiated the Pay in full transaction. As we investigated further we found a little link under the button that stated "Customize my payment" and it was determined that the users who intended to make their monthly payment actually needed to select the link under the button that they were so accustom to using.
Because of Rum and Session replay we were able to watch the users and understand where they falling into the "pay in full" trap. We provided the details to the web developers who rolled back the change. We also created a customer journey dashboard that would target things such as issues with supplying payments, and the number of paid in full customers vs the number of monthly installment customers. AS you can imagine, we saw a huge spike in full payment customers shortly after the change. All of this data allowed us to Provide Immediate feedback to the developers to ensure our customers have a clear and concise transaction.
Use Case 2 - Customers having issues making Payments
We continued to review user sessions and watch user transactions on our payment portal and found multiple pain points for customers. One user spend 30+ mins trying to make their payment. I give them props, as I wouldn't have messed with it for 15 mins let alone 30+ as they did.
After Reviewing the session replay we found the user was on an IOS mobile device. The user got an error that stated values are missing on the form. the user scrolled up and verified the payment, even went as far as adding a new card for payment, but was still getting the error. The user continued to review and review the data for the next 27 mins, all while the user needed to scroll up just a little bit further to the "Phone Number" cell which was required. We captured this data and sent it to our user experience team as well as our web UI developers who ended up removing the phone number requirement field.
User Experience issues as detailed above, lead us to create a dashboard that focuses on user experiences that falls outside of the norm and well as showing the rate of change.
Granted you cant always solve these issues like people putting in the wrong zip code, or providing a payment amount that is more then the due amount. But it is important to collect, review and understand a customer journey and see where it can be optimized.
Use Case 3 - "we block 90% of the world"
As we started our Dynatrace journey we were poking around the platform and found a bunch of European countries hitting our site. We noticed that Users in Russia were trying to get a Policy and of course the system would fail to look their code up as it wasn't defined as a Zip Code in the USA. We continued to watch these transactions over the course of a few weeks. It very well could be that these users from other Countries had malicious intent.
Later on in the month we were required to attend a presentation and training by our security division. During this session the team make a statement that really stood out. "We block 90% of the world" I started to think about what Dynatrace was showing me. It peaked my interest, is Dynatrace not giving me the right data? If were blocking everyone but USA locations, why are we seeing foreign counties such as Great Britain, Australia, Russia, Ukraine, Slovakia, and so on?
After the training/presentation I met up with a security team member and told him that I just wanted to validate the data Dynatrace was providing me. I showed him the Countries that were hitting our site as well as their transactions. To which he replied, "Well we do block everyone but the USA, but.... that part of the tool is broken and the vendor is working on it, so we haven't been blocking anyone." that was the validation we needed and our security team started to become even more interested in the Dynatrace Platform. Within weeks they all had access to Dynatrace and were actively reviewing sessions and looking for any malicious transactions. Security stated "Dynatrace gives us even more data that what our core monitoring app provides, its simple to use and really fills in the gaps where our main tool is lacking."
Overall Dynatrace has been a huge success, and these wins have been even published as usecases sharing our methods and processes to help maximize the use of the platform within an organization.
-Chad
Karolina_Linda
