 Hello, and good morning, afternoon, evening, from wherever you are located. My name is Danny Skinenoni, and I work in product marketing here at Full Story. I speak for the team when I say we are truly happy to be here with all of you today. I am here to kick off our discussion around the challenges and opportunities of mobile app analytics and what that means for your app in 2023. And I have here with us Kevin Margeton and Matt Ware. Matt is our director of engineering and Kevin is a senior solutions architect here at Full Story, and I'll let them both introduce themselves. Hi everyone, I'm Matt Ware. Like Danny said, I'm the director of mobile at Full Story overseeing the development of our iOS and Android SDKs, as well as our React Native plugin. Before joining Full Story a year and a half ago, I spent the last decade plus working in native mobile. I've worked at places like Evernote, Verbo, HUB Digital for those Texans out there. I live in Austin with my wife Stephanie and our four kids. Kevin. Hey, Kevin Margeton here, solutions engineer for Full Story, specifically working with a native mobile apps team. Day-to-day basis, I help our customers realize and maximize the values of their digital endpoints, specifically the mobile application. On the flip side, however, my previous experience was in privacy, being a certified privacy professional against EU's most stringent privacy law, the GDPR. So when the two combine, it allows me to help our customers responsibly gather in-depth digital experience data from their endpoint, from the customers, with privacy in its core and in its mind. Now, a little bit about myself. I'm originally from the exact opposite part of the globe here in Indonesia, but currently residing almost quite literally right here right now in the Full Story Atlanta headquarters. And luckily, no kids yet. Good luck for Matt there. Awesome, thank you both. OK, on to the agenda. Agenda items one through five will be the bulk of our discussion moving through, again, the top five challenges and opportunities of mobile app analytics. We will include what is critical for you to consider when capturing user behavior and experiences, how our engineers have elegantly handled common digital experience intelligence or DXI problems, and what that means for the success of your app. From there, we will peek behind the curtain of our two experts, hearing their professional experiences and reviewing their real world use cases that can be solved with a mobile analytics or DXI platform. First, let's set the tone together. It is 2023 and I feel like what I'm about to say is a given, but we are becoming increasingly dependent on mobile apps to move throughout our days in this post pandemic world, the accelerated adoption of remote work, e-commerce and other digital technologies has led to an increased reliance on mobile apps, whether it's checking messaging apps for work, getting paper towels delivered because there isn't enough time in the day for a grocery store run or booking that much needed vacation, which I hope that we are all doing. We are constantly using the apps. And I'm not just talking about myself. So the average smartphone user opens 10 apps per day and 30 apps each month. I feel like this is just like shining a light on my experience. And furthermore, they spend 87% of their smartphone usage time on mobile apps. And really what that usage means is big money and big engagement for app owners. And according to Statista, mobile apps are expected to generate more than $935 million in revenue for 2023. So it is pretty safe to say that if you own an app, getting that app's user experience right is more important than ever. Users are also becoming more aware of what constitutes a good app experience. And they are keen to using only the latest and the greatest, therefore uninstalling apps that don't need their standards. And one of those standards is performance. Have you noticed your attention span decreasing? Same, same. And for me, that translates into expecting the apps that I use to be seamless, quick, without frustration. And according to our full story consumer survey, that tracks because most users, number one priority is being able to quickly accomplish what they open the app to do and that focus on a quick and seamless experience but gets the need for a well-attended app. It turns out that our fickleness when engaging with apps is not just anecdotal. So 75% of users are likely to leave an app after they encounter a problem or frustration without ever completing their intended action. That's a steep one strike in your house scenario. So expecting that's going to happen and outright planning for that is critical. Another one of those standards is privacy. So as users become more aware of the risks associated with sharing personal information online, app developers and owners really must be transparent and thoughtful about the data they collect and how it is used. And privacy staff booths can be costly, as I'm sure you've all seen in the news. A Google research study puts that pretty plainly. Users had a decrease in brand trust of 46% after experiencing an issue with a company and their personal data. That's a decrease in trust by almost half over just one negative experience. Mistakes are high. So succeeding in this highly competitive and privacy first market requires a deep understanding of users and how they interact with their apps. It's not just creating, deploying and tracking installs and daily active users and monthly active users. It's really understanding how users are engaging with the app, what features they find most important, what features they're looking for and where they might be experiencing issues. And if teams don't have this data, they really just don't have the answers to move forward. All that to say, delivering a superior app experience is critical to win in 2023. All right, mash bill is over. With that, I will hand it over to Kevin and Matt. Well, they'll take you through how to address the current market with the top five challenges and opportunities of mobile app analytics in 2023. Well, thank you very much, Danny. Without further ado, let's actually jump in to challenge number one, the web versus the mobile apps. Now, we all know the web technology, right? We sometimes kind of want to break it down into what called the good old web, the HTML, CSS, JavaScript, or in my own language, I'd like to call it the skeleton, the skin and the brain. Simple, simplistic. Every single web application at the end of the day boils down to this exact format. And that's exactly why tracking is a little bit easier, really straightforward, and you can get a lot from web browsing data. So basic. But it's like about mobile, though, a little bit. Now, unlike web analytics, mobile is more complex and a little bit more nuanced. Firstly, let's look at the two biggest platform that we have over here, the Apple's and the Android's, things that you see on a day-to-day basis. They do their own things with each platform, introducing their own languages. Call it the Swift, Objective-C, Java, Kotlin, and from there on, however, there are third parties attempting what they claim to be the hybrid, and I'm using air quotes here because they want to run on both platforms and they claim that they are the one because they can run on both platforms. But with these hybrid models, though, you can already see the complexity forming already, like what should we be using? Now, if you'd allow me a shameless plug a little bit here, one of those languages that got a little bit more nuanced is what we call the Swift UI, which is essentially the future of building mobile application, which we're excited to now support in our full-store SDK. Now, few limitation. The language still has its limitation and it's still nice and but its ease of use and market penetration is pretty clear. It is important for us to support the frameworks that are used the most and make the most sense for a well-developed mobile app. So we know supporting languages such as the Swift UI right here was going to be paramount to the future of app development. Let's talk about the opportunity here, though, for a second. When you think about a digital experience intelligence platform and all these app development frameworks that you're seeing right here, you want to choose a DXI tool that supports the latest and the greatest of the app development frontier. So that's challenge number one. Let's look at challenge number two over here, the fragmentation and the offline environment. I want to just double click a little bit here, the proliferation of different mobile devices and environments that make it difficult to get a consistent view of user behavior across platform, across dramatically speaking, time and space continue. Now, web analytics is straightforward. You need a broadband internet connection to begin with for things to work. You're comfortably sitting in your home or you're like standing in this fancy, standing mat that I'm on right now. And full story, for example, allows for a near-life experience on the web due to the simplicity, straightforwardness, reliability of web technology that we have. What about mobile though? Sometimes we're lucky to have a full bar of service and even then things are still not as quick as they should be. Even worse, you grab your phone, you jump out of subway, airplane, whatever that is, with no active or spotting internet connection. And guess what? You actually want to be on your apps at that point, keeping yourself entertained, keeping yourself busy, getting productive. Now, some companies trade off the completeness of their analytics to save bandwidth, especially those taking screenshots and videos as the foundation for mobile and DX analytics. This leaves us into what we call the Swiss cheese effect though. I want the full block of cheese. I don't want the holes in there. I want a full block. I want everything. And that's the tradeoff that sometimes we need to make on day-to-day basis. The opportunity that we must embark on today is finding the real balance between the completeness of your data while still being respectful. And that's actually the word here, respectful. Your customers are providing you with data, so we want to be respectful with their data caps, with their phone performance, and so on and so forth. So the result of that, on what we're thinking, how we should be approaching this, well, we'll build the suspense here and we'll kind of reveal that what we think will be a solution in a moment. But before, let's talk about the next challenge here real fast. Challenge number three is the real life of an app. Again, I'd like to compare this to the web, something that you're really, really familiar with, right? Changes can be made on the fly. You press a button, it launches into your data center, and off you go with the newer version of your website. Mobile apps on the other hand, well, you need to put it in a box. You need to tap it, you need to ship it to App Store and Play Store and essentially go all over again for any code level changes. And we actually kind of made a diagram here for kind of a little bit of visualization, right? Now, without the SDK version in the picture, we can already see the complexity. What is the latest version that your users are using? Who knows where the users are in going to update to the latest version? When was the last time you go into the App Store to check for updates? Well, I guess this isn't really the right crew to ask, but let's say one of your loved ones who isn't really tech centered, what version do you think they are? Well, guess what? The old ones. Now, users do have to update their apps to the latest version to get the best, most updated experience out of the app because if they don't have the latest and the greatest, it risk poor experience, which from our survey, 65% more likely to leave your app. Now let's add a little bit of a layer complexity in here, right? What does that mean for third party analytics that you have running in the background of your app? This means you want an SDK to be relatively small, nimble, and require minimal code level changes. This is one thing in particular that I like about Full Story as a DXI platform, unbiased, of course, but many changes, especially privacy ones, which is critical, which we're gonna cover in a second here, can be made via the web user interface. Longer in the days where you unpack the application, tweak in the codes and make changes just for some privacy focus. That means we can prioritize minimal code level changes once the SDK is implemented. So your team doesn't have to go through the rigmarole of what you see on this slide right here. Now, one thing that is actually very important, by the way, to differentiate and to denote here between our Full Story SDK and the code backdoor, because the difference is here, Full Story captures all the full amount of data that you can tweak and adjust after the fact, while code backdoor allows people to remotely have developers inject code to change how the SDK behaves, how the SDK works. That's effectively a Trojan pose though. So you're gonna be really, really careful in determining what kind of SDK you wanna put it inside your application. And I think Matt, do you wanna talk about the privacy concerns here? Thanks, Kevin. So as Kevin mentioned, privacy concerns, there are strict privacy laws and regulations around collecting and using mobile app data, which can make it challenging together and use data for analytics purposes. Protecting user privacy is just the beginning. You've seen the news, Apple spearheaded the privacy front, Google slowly trickling behind with their own safety section and Google Play. And with that, there are companies allegedly trying to circumvent those stop gaps, those who shall not be named. For privacy, I like to share about some recent happenings in mobile privacy, discuss the philosophical differences and truisms between web and native mobile, talk a little bit about how our mobile teams at Full Story are thinking about privacy and share about some interesting technical choices we've made at Full Story. You might be wondering, what are my users thinking about privacy? Is it on their minds? Do they really care? Is it worth the investment? Well, to users, privacy is pretty important. As you can see from these first three bullet points, consumers are concerned and wary of apps when it comes to their personal data. These numbers coming from a recent Pew research study respond to us with an overwhelming yes when we ask whether customers care. Sadly, app users don't feel like they have control over the data they give your app. They feel generally speaking that the risks of using an app don't always outweigh the benefits. And 79% say they're concerned with the way you will use their data that you give them. I don't think this is an issue of marginal concern. I think privacy is critical to get right. Keep in mind that when deploying apps via Google's Play Store and Apple's App Store, you have to abide by their terms of service, often pretty strict about protecting consumer privacy on what data can and can't be accessed. I wanna call out some recent trends in the mobile privacy space. So cross-app tracking. This is probably getting the most attention right now from Google and Apple. You've probably seen headlines related to this in the last year, mostly around how changes Apple is making to privacy will cut Facebook's revenue in half, et cetera, et cetera. What is it? Well, it's when advertisers and other entities create digital profiles of users based on activity in various different apps. That is, a bunch of app developers might all use a similar advertising SDK, and that SDK will gather information about a particular user from all the apps they use that have that SDK. The advertiser will create a digital profile to use to target that person with ads and products. So do you ever get that feeling that your phone is listening to you? Like you have a conversation with someone about Argentina and then all of a sudden you're seeing ads for trips to Argentina? I swear, I feel like I've had dreams sometimes and then I see ads for them. You can think cross-app tracking for that. Google and Apple have both required that apps declare whether they're doing this. Google is trying to change the way these types of SDKs can work through their SDK sandbox, which makes it so certain SDKs don't inherit the same permissions as the apps they run in and aren't even in the same process. It's been a big focus, but there is a lot more work to do. I also wanna call out GDPR. Companies are getting more and more aware of what personal information they have on individuals or data subjects. And end users are becoming aware of what protections are in place for them. A lot of work has been done on the web, but there is even more work to do on native mobile for app developers to improve. And finally, I wanted to call out just some of the improvements Android is making. As of Android 13, they require developers to get permissions to post notifications and they're starting to push one-time permission requests and proactively revoking permissions as well, where it is more obvious when an app has access to something sensitive and for how long to your users. So why is privacy especially important on native mobile? I think it's because of some of the reasons companies and end users get value out of their mobile apps. For websites, they're great at building an audience. When you're just starting out and you get a landing page up and start getting customers quickly, you can iterate quickly, deploying changes that go out to 100% of your user base immediately. For native apps, I think they really shine at engaging your customers. You have access to a lot of things about a user in a native app. Their location, even geofencing data when they leave an intern area, their contacts, calendars, call logs, and even health data. You have everything to build something really useful and magical to them. An end user is trusting you as an app developer a lot when giving you that kind of access. And if you betray that trust, if you aren't clear what data you have and how you're using it, then you might not make a magical experience. You might make a creepy one. What does this mean for digital experience intelligence platforms like Full Story that gather very similar data on your app users? Let's take a look at this image here. You see here in this image an x-axis of fidelity and a y-axis of bandwidth. Normally, we'd want up and to the right, yeah? Well, in the world of mobile app screen capture, we want high fidelity, meaning high reproduction of what the user saw, high reproduction quality, and we want low bandwidth, meaning low impact on the user's experience and data usage. Getting privacy wrong happens on this side of the diagonal line. It's the MP4s and JPEGs and PNGs. It's the oops, we captured this user sensitive information area. As you can see, the higher quality you get, the more taxing it is on the user's device and in turn, the user's experience. Now, getting privacy right puts us in this sweet spot, this unicorn spot where we preserve bandwidth for users while also delivering high quality reproduction for app owners. Super performance plus sharp playback. Admittedly, that's where full story is, mainly due to the proprietary way we capture. Never taking screenshots of the user's experience are actually recording their screens. We don't have to do what others do. We figured out a way to use the app's layers to work in our favor, resulting in benefits for both app owner and app user. Taking a step back, our team has developed a sort of checks and balances card to use when building for our customers. That's how our teams are thinking about privacy in the context of building an SDK. Number one, private information should never leave the device. Number two, we must execute redaction and preservation of sessions. Every new feature we build, we consider how would we surgically wipe certain parts of what we captured from our servers if information did accidentally get through to us that we weren't supposed to have, while still preserving all of the session data that that little piece of data was in. Number three, quality and value is still important. We need to give our customers reasons to love our product despite our staunch privacy, non-negotiable stances. Number four, performance is paramount and so is privacy. Number five, privacy is part of the requirements of all new features. I'd like to share an example of a privacy related solution to an engineering challenge. Playback fidelity, like I mentioned earlier, is the ability for us to show you a session that is very representative to what your users actually saw. A first solution to this problem is capturing images and video of what is on the screen. There's a big problem with that. How do you prevent private information from ever leaving the device? Honestly, you can't. The other big problem is that in order for it to really help you see what the end user saw, you need a high bit rate video, which is going to eat up your end user's battery and network bandwidth. So we took a different approach. We don't capture a video of the screen. We capture a representation of what happened. It's analogous to a drawing. The puppy on the left, it's a photo. You see pretty much what the puppy looks like, but if you need to change anything about the puppy, it's pretty tough once you're gonna Photoshop. The puppy on the right, it's a drawing. You can see how it represents almost exactly what a person sees when they look at the puppy, but it's easily changeable. If this puppy had a name tag with his name on it and he didn't want it to be in the picture, you could easily change that. You could give this dog a giraffe's neck if you wanted to. You could color it different colors if you wanted. Well, we developed that ideal state. Instead of screen recording, gathering screenshots, we observed and captured the changes within the view hierarchy. At five times a second, we're logging the delta within the size of the shapes and orders of the view objects on an end user screen as they interact with the customer app. We capture not a video, but how various components in your app are drawn. Then we can alter those drawings to hide private information but preserve what the user saw and high resolution. Another analogy is instead of a sledgehammer and the form of screenshots, we prefer using surgical knife to create replay. Because of that surgical knife execution, we can go in and redact anything that accidentally got through without having to delete all the other things that you care about. And we simply erase that part of the drawing. We don't blow away the whole session. And then it's gone from all of our backend and logs and it never existed. This is important because sensitive information on the user's device doesn't leave the device. Meaning we don't have to capture that info and then redact or remove. This is one of the reasons I love working at Full Story Mobile. We're inventing some really cool things. So it's like clean capture, elegant replay, happy users. I like it. So on to challenge six, performance. And performance and privacy are very intermingled, but performance, this is the difference between engagement and the uninstall. If an app isn't a performance, users won't use it. Again, I want to follow the same pattern as I did with privacy. Google has done some good research on performance and native apps. I think the data shows that there is a big upside to having a performance app, but also a steep downside. If your app is performance, users will keep it on their phone and if it's on their phone, it has a good chance of getting used. It has a good chance of getting new installs through word of mouth. If it isn't performance, then it'll likely get uninstalled. So here's what our team is thinking about in terms of performance. Think of these pieces like the building blocks of the performance DNA, drop frames, battery performance, networking, bandwidth, usage, startup time, app size, build time. We're not kidding. Who's gonna know? They're gonna know. If you have a slow app, customers have a great outlet for expressing their frustrations on native mobile with app store reviews, all of our favorite. It's a snowball effect and can erode your app's credibility. So how does rendering work on native bubble? If you have a 60-hurt device, which I know 120-hurt devices are getting more popular, which means for 60 hertz, you have 16 milliseconds to do a lot of things before the UI needs to render again. In this diagram, the OS has to finish all seven things represented by different color segments on the bars before 16 milliseconds represented by the green line. As you can see, you might only have a few milliseconds to run your code that has to run on the UI thread as the OS does all of its stuff and parts of full story have to run here too. So how do we keep making apps from skipping frames or scroll hitches as they call them on iOS? We do a lot of things. First, we try to reduce as much as possible what runs on the UI thread. But when we can't, we utilize advanced algorithms to more performantly scan the butchery. We use advanced caching designs. We also have ways to schedule an interrupt work that is taking too long on the UI thread so that we don't go over. Another challenge we have with performance is networking. How do we take what's on the device and get it to our servers without taking too much bandwidth? Well, let me explain a solution we utilize. For those on this call who may not be engineers, I'll use an analogy. Here on the left, we have a human baby with all its vibrancy and nuance that can be described by breaking it down into its DNA. It takes about 700 megabytes of A's, G's, C's and T's to describe a human in its DNA. You can write a book about what this human is like or make a movie, but it'll be a lot larger than 700 megabytes. This is analogous to an engineering technique we've used. We have to have some sort of serialization mechanism to describe what we have on the screen. Most developers use JSON. We want it to do much better. We went with flat buffers. Flat buffers are orders of magnitude more efficient in terms of memory usage and serialization speed. As you can see with the charts here, in this case, the smaller the better in terms of keeping light on bandwidth and CPU usage. With the amount of information Full Story is capturing and transmitting from a device without optimizing our tool choices and architecture, we would take up significant amounts of customers' data plans. As it is though, Full Story scans an app's UI every 200 milliseconds or about 300 times a minute. And we send less than 100 kilobytes of data during that span. Our network bandwidth utilization is wildly better than others on the market that use a heavier bandwidth sock like the JSON technique. But don't just take my word for it. In the spirit of transparency, in Full Story's network capture tab, Full Story even shows how much bandwidth we're using in your app by viewing the requests our SDK makes in the DevTools within Full Story of the app. So you can go in here and see it for yourself. And I'll pass it back over to Kevin. No, thank you very much, Matt. I really appreciate it. That was some great in-depth underhood details on how the SDK work. Now, given what Matt and the team built on day-to-day basis as a solutions engineer or solutions architect, what I love most about my job is seeing all the different ways customers are using mobile app analytics to the business's benefit. Now, I wanna pull back the cloak a little bit here and show you some of those example to spark inspiration in the work that you do and maybe even aspiration on where you can go with mobile analytics. Now, imagine a world where you have a slash time to resolution for a customer support. You know exactly what your customers are doing before even they contact your support. A world where you can forego a game of telephone. What did you do? What happened? When did that happen? Where did that happen between the customer, the support team? And don't forget to also include your engineers who would love to know the same information. Having worked in support myself in my previous life, when I didn't have to force the customer to reproduce the issue for us, which as you'll know, a huge time suck and can't waste a lot of time. It does also erode the customer experience though. So with all this benefit, I unlocked the ability to build as that trusted advisor relationship with the customer, knowing exactly what they're talking about. Imagine another world where you can do a research that is objective, cleaner and clearer with definitive result as well. No interviews, no surveys, which to be fair have their own place. But tend to be subjective for that, especially when you ask people being asked question, being monitored. Instead, you can test the edge on leisure asynchronously, which is a very key in this kind of life right now. Or even sometimes, retroactively, saving the effectively time, effort and ultimately money too. Not to mention, you have the complete data set that includes the logs from the device, the network activity like Matt showed you a little bit earlier. And oh, not to mention the visual proof in the form of a session replay that is privacy minded all in a single pane of glass. Now, when I started my presentation here, I did talk a lot about web, right? That's because we also do web on top of the mobile. And that exactly allows you to uncover all the different blind spots before they made a big impact. Now you have like a full end to end across platform analytics, right? This is very actually typical for a lot of companies that have blind spots specifically under mobile application. Because number one, it's hard to get this data right to begin with. Sometimes we have to deal with unsampled data, which I mentioned earlier, leads to a Swiss cheese effect. Sometimes we just can't even get that data to begin with. Now imagine, if you wanna get this data to an earlier stage in your development, beta testing, pre-release, or even when you're developing a brand new feature, call it on like test flight, right? For the iOS engineers out there. You probably wanna know earlier on how users are interacting not only with the platform that you're testing, but how they're affecting your existing web platform as well. And the keyword here I wanna emphasize on is earlier on. Segmentize the data, filter out the app version, filter out the campaigns, experiments, attributes, and you will then have the ability to measure them alongside your current production data and see for yourself how they stack up. Up next here, kind of sort of similar here with uncovering the blind spots, right? Shining a light on the unknowns. What I'd like to call like turning stones one step at a time. Now imagine you drop your keys on your web back home. You have to trace back the route powered only with your measly phone flashlight. Now imagine in a parallel scenario, the street is well lit with stadium-grade lights. You can probably already see the keys from afar, even on the corners where you don't expect them to be. That's exactly the power of AutoCapture. Long gone today is when you focus your search when you think, again, air code, things. Things are, AutoCapture tells you exactly where to look for to begin with. And if you forget something, well, here's the full set of data that you can look again at your leisure. So really, you're like, you know where to begin with and then you shine any blind spots along the way. Now, you built your product, you did some support, you're testing all the different feedback that user are using. But how do we get context on the customer feedback, right? Because sometimes users say, you know what, it'll be nice if this button is read. What button? I don't even know what you're talking about. Imagine if you have the full session replay, if you have the full contextual quantitative data that goes with the qualitative data. You know exactly what they're talking about. Hey, the app feels low. Where? Well, let me show you where. And these are the number. The app is lagging. There's an error message. Where? This is exactly where the app is doing there. So that's all the different five building blocks that we see here. We fulfill our customers' desires and needs on day-to-day basis. And in fact, double click a little bit here on the customer feedback. Matt, I think you have a personal experience with the feedback. Yeah, thanks, Kevin. So I did want to share this story because I feel like it really brings home how full story can help your development teams with mobile app development. So my first introduction to full story was when I worked at a well-known vacation rental company. We were releasing a new booking experience for hosts and it was a total redesign. Our current experience was janky, but our customers had gotten used to it. They depended on this janky experience to run their business and we depended on it for a large part of our revenue as well. That's why we allowed them to switch between the new and old experience at first as we worked out the kinks. When hosts would switch from the new to the old we'd pop up a feedback dialogue to them asking why they're switching back. As you kind of look like what you see on the left there. Oftentimes what they wrote didn't make any sense. That is until we added a link to their full story session and had it posted to a Slack channel. So that's kind of what this is mocking up here is just what we would see in our shared Slack channel and it would have a full story link as well as what feedback the user gave. Now when they said something like I clicked the thing and didn't see the quote we could actually see what they were clicking and why they expected it amazing. We also associated full story links with crash reports so we could easily see what customers were doing before their app crashed. The partnership between both quantitative analytics and our auto capture technology and qualitative insights with session replay solve my own real world issues in my past roles. This proved invaluable and is a big reason I work at full story today. Wow, Kevin, Matt, thank you so much for sharing your own personal experiences with building great apps and for all of the insights that you shared today such good stuff. So what we know now is that with the complexity of an app comes a great set of challenges and also opportunities and the importance with all of that comes the importance of getting the app experience right and relying on a mobile analytics or a DXI platform that understands and solves for those nuances was really what it takes to have a successful app. And a big thank you to all of our attendees for joining. If you do have any questions about what we discussed here today, feel free to email us if you wanna hear from you. And if you haven't already please join our first full story community. In the community, you can network with other customers get tips on creating better mobile app experiences sharing your experiences with others in your industry and so much more. This is a newly launched community so we would love to have you and I'll leave a few seconds here for you to snap the QR code if you'd like. Cool. And with that, thank you all so much for joining and I hope you have a great rest of your week.