Using Data and AI To Improve Your Fitness

Welcome to the webinar. This is Richie. Now I got to say I am particularly excited about today's session because I've set myself a New Year's resolution of being able to do a pull up. Like just one, you know, felt like a fairly modest goal but at the end of the day I'm a middle aged man with a desk job. I'm gonna need quite a lot of help with this. So please do let us know if you've got any New Year's resolutions. So tell us in the chat if you're feeling particularly brave. But whole point of today we're talking about how data and AI can help you achieve these fitness goals. So it's going to help you on a sort of personal level on how you can do things better fitness wise. But also just the how do you go about using data and AI in these contexts in general. So we're going to dive into some of the, the tools and techniques because frankly there's a lot of cool stuff you can do with data for tracking fitness. There's a lot of cool stuff you can do with AI for customizing workouts, things like that, predicting performance. So lots of use cases that we're going to discover today. Now I've got two guests for you, both from the, from Zing Coach, which is an AI powered fitness platform. So first up we have Alexei Korov. He's the chief product and technology, chief product and technology officer and also one of the co founders. So he runs the team which is building the, the personalized fitness platform and he's got over a decade of experience as a technology executive. He's also a serial entrepreneur, having previously founded and been CEO of Gentleminds and Xenia, which is an AI yoga teacher app. We also have Dennis Sokolov, he's the head of research and development. So Dennis is a seasoned professional with 15 years of experience in building AI solutions. He's also a co founder of Xenia and now he's yeah, working in research and development for Zing. So basically he works on the hyper personalization of personal training using AI. So with that uh, let's find out how to use data and AI to get fit. Uh, I believe Alexei, you're going first.

Uh, thank you for the intro, Richard. So uh, let's start with a brief context uh, about our company and our product to better understand what kind of product problem are we solving. So in Zynq, our main goal is to build the product that will be close to Real Coach, as close as possible because for us and from our experience, we are working in this fitting space for a long time. And to be honest, currently most of the products on the market it's content libraries and currently with all of the wearables we have a lot of data about user and the user performance and user abilities. And even when user interact with our app we have a lot of data and based on it and currently we already see that it's kind of expectations from user on the market. In case of fitness it's the same. It's to provide a truly personalized approach to provide workout plans and routine that is tailored to your goal and your abilities. So and we believe that currently market in case of fitness is underserved. That's why we decided to build product Zync. And we are focusing on different aspects of fitness coaching. And if we're speaking about technical approach, we have three big pillars. First of all, as I already briefly mentioned, it's personalization. So we have our own recommender system that create personalized workout plans. Every workout is fully tailored to your goal, it's your own weights and each rep are fully personalized. And the second pillar for us it's let's say eyes of our coach. We use computer vision to interact with our users in real time. And it helps us to get more data about their real performance. So it works like you need to put the phone on the floor and then in real time using our algorithm based on convolution neural networks recognize movements of user in real time and provide feedback. And also it help us to estimate how good exercise are performed. And also it help us to understand abilities of the user. Currently we use it in tests and I will elaborate a little bit more about this data later. So we have a fitness test and we have a flexibility test. It help us to refine level of user and then we use this information in our recommender system. And the last but I think also important part for us it's conversational part. So it's based on LLMs. But if you. But for us it's important to build not product that will just answer question of the user. For us it's not about question answering system but for we want to also replicate real code. So and in this case the most important aspect for us it's motivation and habit building. And in case of habit building it's quite challenging because first of all you need to decide from that perspective what is moment of habit. And else I will provide later more details about one of our project that help us to identify this kind of moments and who is for us is active users and who is not. And also for us it's not like three different systems, everything should work together. That's why currently we have put a lot of efforts in connecting our conversational part and recommender part because pretty common user scenario for us as even goals of user can look pretty close but for example lose weight. But in reality approach for them can be quite different. For example one user wants to lose 50 kilos and another one just want to be a little bit leaner before beach season and want to lose two kilos. And it's quite different approach and we need to incorporate all of this previous experience of user and expectations and preferences workout routine because users usually do not like some kind of exercise. And we also need to take into our consideration and we currently working on connection on getting feedback from user from our conversational part and incorporating all of this information to our commander Denise also will elaborate a little bit more about it later about data that we have. So currently we have first of all data about our zinc workouts. When we're speaking about zinc workouts it's not only exercise that user completed but and weights and reps that was logged, but also any exercise replacement. Because for us it's also important when user want to switch some of the exercise before or during the workout. Or it can be even a different structure of workout for example with supersets or without it or if user for example wants to build custom workout. So we have workout that we recommend by ourselves to user but also every user has ability to build workout by themselves and we also need to take this information into consideration to provide better experience. Also we have data from our test and I already mentioned fitness tests that help us to estimate the level of user better. But also we have body scanners that using user photo helped estimate percentage of lean mass body fat and so on. And we use it as also progress tracking system for our user. But also it help us to understand better user abilities and current conditions to provide more tailored experience in case of fitness test. It's also quite interesting about objective and subjective perception of user because level it's quite subjective because even it's not even clear when we ask user about their level in starting questionnaire what user particular answer is because it can be for example experience in the gym or with the fitness routines or it can be current let's say physical condition of users and it can be quite different. For example user have no experience in gym training but has quite good condition because of previous experience with other kind of sports. And we also to eliminate this kind of subjectivity, we created our own test that help us to estimate it. Currently it's just three exercises, push ups, squats and running plays. And we understand when user for example starts to be exhausting. So and also it part of calculation of our fitness score. Also we use in our system information from users dialogue with our AI assistant based on LLMs. And for us it's first of all we also can get more data about user. And sometimes user just update some data about them. And we just updated the user profile on our site. But also it's quite good source of feedback and we use these dialogues and feedback we usually categorize them. And also using by LLMs and then with the product team we understand what issues or request or user are more frequent and what we need to prioritize more. For example, in our case we realized after launching that it's about 35% of all of the conversation it's about nutrition. So and in this case we increased priority for our nutrition component. Also we use data about external workouts too because Zync also incorporate data if you are running for example even without Zynq app. But if we have a data in Apple Health or Google Fit we also use it. It updates our system of muscle freshness. And also it help us to calculate different metrics like activity metric that also current level of user activity. And also we get quite important data for us to estimate recovery and fitness level of user from users Apple health data. It's VO2 max and sleep data and volumes of each part you currently can see on the tails. And of course we have just data about user themselves from initial questionnaire. It's about their goal age and so on. And we also use this data inside our systems how generally our commander system works. Currently we do not have any let's say master system that just get all of the data and provide workout plan and workout for user. We have a lot of different subsystems that let's say predict or estimate different parameters that then we use in our recommendations. So currently in the slide you see that for example we have one model for exercise ranking it help us to understand which exercise are more suitable for our users. Also we incorporate data from our fitness tests. We have separate system that predict intensity for user because also elaborate a little bit more about it later. And based on it we can even predict heart rate of user during the workout. And also we have weights recommender system that for each exercise estimate user level. And if we need to increase weight for this particular exercise or not or we need to keep it on the same level or even we need to drop it. So this decision has been made by a separate subsystem and another one system that provides data for workout generation. It's muscle recovery estimation based on all of the activity of user inside Zynq or outside Zync. We estimate how sort of muscle of users to provide those exercise that will target more fresh muscles to make this routine more effective. And also we have feedback from user after workout, even during workout. And all of this information about accessory placement that we also incorporate after user completes workout. And we also use it inside our these subsystems. And let's say quick quiz about objective and subjective data when we speak about intensity. And it was not so obvious problem for us when we started because usually we had a lot of feedback from user. Oh, this workout is too easy for me. Can you increase intensity? Or it was too difficult. And usually it's very hard to understand how. Then we need to change workouts from our side to make it more difficult or make it a little bit easier. Because from our side we just have. Let's say at start we just have a strings with name of workouts and some kind of parameters for them. And for example I have a workout currently on the screen. And let's for example try to estimate how intensive this workout for user will be. I don't know Richie. And can we get answers from audience in the chat?

Yeah, we can. There's not many people in the audience talking at the moment. There's a little bit of a delay before we get responses. But yeah, for everyone in the audience, please do answer the questions like how.

Yeah, okay, got it. Thank you. So but okay, it will be a little bit with delay but in general answer is is depends for whom it's intensive because for me this workout can be quite intensive. I don't know for Denise or Richie it will be just easy workout and they need to have a more difficult one. So this is our first problem, another one if we have two workouts, which of them is more intensive? And it's also quite a tricky question because even we will discuss that it's for this particular person. Then we need to have some kind of ranking for each of workouts. So and then we came up with the chart prediction system. So we estimated intensity based on metabolic equivalent. It's metric met. And we also in the recent public you can find compendium of different physical activities. And we took this as starting point. We labeled every exercise with a corresponding met and then based on this information we conducted some kind of research by ourselves. We gathered group of around 30 different users with the different let's say physical activity level and asked them to do different workouts. And we measured in parallel their heart rate. It was for us moment of creating baseline version. And based on it we at least was able to analyze patterns of the behavior. And then based on it we created model. Let's say more at first start rule based on these patterns that help us to create prediction of heart rate. So on the screen you see, for example predicted estimated heart rate and real. So usually difference was less than one heart rate level. Usually heart rate level it's about 20 heartbeats. And based on it we estimated time for each user for particular user. We also did some kind of tweaks based on user data like VO2, max height, weight, BMI and so on. And based on it we estimate the time in each zone, predicted time in each zone. And if user provided for example too much time by our prediction in red zone with a pretty high heart rate, then it will be quite intensive for this particular user. If it will be in some initial zone, it will be too easy. And our goal was to find those workouts that will be suitable for user needs right now. Because someone wants to have more challenging today and later, I don't know, more relaxing workouts. And the system may help us to have of let's say initial step in this space. And also we grabbed a lot of feedback after workouts for user. And it's quite important to build from scratch system and the product that help you to gather all of the feedback from user side. For example, you see a screen of intensity feedback and if you like this workout or not and based on it we currently have much more data and we are changing this rule based system on ML based predicted model. And a little bit more about feedback and gathering feedback to get it and incorporated system. We have several approach. First of all, it's a different kind of screens. It should be quite easy to interact with. Because if it's not like just one tab, user dropped very easily and we do not have feedback at all. Also we are experimenting on different approaches like Tinder, like swipes of workout cards. I already mentioned feedback in our conversational models that we also incorporated and using our prioritization. So everything is quite important and it's better to think how we will gather feedback and how the system will learn further from scratch. And it's some kind of for us setup moment for any functionality that we have. And another one thing about that I want to discuss it's about how to define engagement of user based on the data. For us, it was quite important to understand which user we can define as engaged and based on it. First of all, we need to define what is important for us as a business. Because based on it we also then evolve the system into our habit building approach and so on. And first of all, for us as for business, it's important metric is subscription retention. So we need to understand which user behavior and metrics and events impact more on subscription retention. Based on our case, initially it was quite obvious that it will be completion of workouts. But it wasn't obvious if it's workouts alone or it will be another kind of activity that also correlates good with subscription retention. To be short workouts provide better correlation. So to understand that, we just run multiple regression models with different metrics, but with the goal to predict subscription retention and user churn. And based on this model impact on subscription retention of workouts completion was significantly higher than any other metric. So we just decided proceed with workout completion as the main event. And then we had a goal to understand how many workouts we need how many workouts users need to do to be for us to be defined as active user. Then, based on user behavior, the churn rates and behavior inside the app and completion rates, we built model that you can see that currently metrics with the market transition probabilities for each state. So we have an active state. So it means that user currently doing workout in particular week. We have state of new user, we have a state of turned user. Then we have reactivated user. It's a user who was for us dormant or not active. And then we by activity or user by itself get back to activity again. And then we also have probability how it's possible that a user from this state will convert to active again. And this model help us a lot to understand and make prioritization for which metric we need to focus on which metric we need to focus on during our planning session. Because we cannot deal with every metric and try to improve everything. So we need to have a focus and based on it we create another one. I think so it's some kind of calculator of different states. So and based on it we can tweak probability of changing of based on our experience probability of conversion user from one state to another one. And based on these tweaks, we can estimate, for example, if we will improve conversion retention user instead of active by 5%, how many active users we will have in 12 weeks. And the same for other metrics too. And for us it wasn't for example pretty clear from the start but the best point of improvements was to keep user just active, not just convert them better from new users to active or to convert from dormant to active because for example for dormant user it's quite significant share of users but just keep them active. We create this model and you can see this chart and with a change of probabilities and metrics it can be rebuilt but it's quite useful tool to prioritization and elser. We took this model for example from Duolingo that they had not like exactly the same but similar approach to identifying the best points of improvements for their product. And I want to yield the floor to Denise and Denise will provide a little bit more details about our recommender system.

Yeah hi everyone, my name is Denis and I will tell you a little bit about our like data processing architecture and a couple of stories about evolution of our cloud documentary system, web documentation systems, how we evaluate our solutions and then give a short summary. I want to give you a little bit of context first because I guess it is really important to understand the main idea that I'm trying to convey. First of all, we're a startup and it means that we have a small team and we want to be as efficient as possible and we want to bring users value as soon as possible because it is extremely important to always remember that we're building a product that real people use to solve their problems. And sometimes the main thing is that we should understand what users really need and want as soon as possible. And it means that we should start to interact with users and collect their data and feedback as soon as possible. So let's start the first thing. Our data processing pipeline currently is pretty straightforward. We don't use any stream processing. Our main data processing happens in batches because our critical events like workout completions happen usually once per day for our users. So batch processing is more than enough. We used Postgres as our main database and Snowflake as our data warehouse and we use AirByte to sync data between those things and we use DBT for data modeling and running our airflow via stonemat jobs. And recently we have incorporated Feast as our feature store because we found that we are starting to have more and more machine learning models and ensuring consistency between training and inference pipeline started to take more time so we decided to invest more time into the feature storage. But I guess the main point here is that we didn't have all these things when we Started and this is the evolution and for example, the features store. We added it after we built the system for two and a half years and it worked fine without it. So no need to invest in some infrastructure, pretty many rigors. This better to understand the problems that you have first. And then I would like to tell you about the how our workout recommender system evolved. We started with a small number of exercises and only a single workout type. We started with home workouts, and at the very start we only had basically a predefined number of workouts. The next iteration was we had workout templates crafted by our fitness experts. I guess you can see like an example of what it looked like. So it was like around 50 different workout structures with muscle groups. And we had an algorithm that filled these templates with random exercises. So we generated a database of workouts and then we had a search algorithm that when user requested a workout, we just search for this database and gave user the most relevant work workout. And this approach worked great for a pretty long time. But the system evolved. We wanted to make workouts more and more personalized. We added new features, we added new equipment, we added new workout types, added new exercises. And this process started to take really long time. And we started to feel that this approach is not longer scalable because adding new parameter results in exponential database growth. And when this workout database starts to approach like hundreds of thousands of workouts, we decided to rebuild it and replaced it with on demand workout generation. So it works like this. We have as a core an algorithm based for code generation that takes around 40 parameters. It is implemented in Python, and on top of it we have machine learning components that basically generate this set of parameters. And it allows us to be on one hand to control the implementation pretty well. Because one of the things that we want to make sure is that workouts that we generate align with fitness protocols and they are safe. But on the other hand, we want to make sure that they are personalized for the user. And we want to make sure that the parameters that we choose are the best. So users completely like this workouts. And generally speaking, this approach is the architecture itself itself. We find it very useful in the sense that we can work and replace the different components one by one. So, for example, currently we have basically the same architecture that we had previously, where we generate workout template and fill it with exercises. But the thing is, currently like previously we had predefined workout templates, currently we generate it with algorithms and the next step we will try to generate it with like machine learning. For example large language models. And next I will I give you a short overview on what are the benefits of fixed library versus on demand generation. So why it is a lot easier to start with fixed library. It is a lot easier to control edge cases because you basically just pre generate a library and you can go through it and see what workouts you have there. And you can for example pre compute recommended workouts for different users based on different parameters. It's basically all the benefits of this approach, but it starts to take a really long time and if you find some bug, you have to basically regenerate the whole database or you have to be very smart to try to select a portion of the workhorse that you regenerate. That is not very easy unfortunately. And yeah, it is not very scalable because you have to generate in advance codes for each parameter combination. On demand generation on the other hand allows for very fast system updates because you just roll out new version of code, new version of model and the user starts to get new workouts. It's a lot easier to make experiments this way. But it is harder to integrate ranking models because if you generate like a single workout you have nothing to rank. So the obvious next step is to generate multiple candidates on demand and then rank them. You just need to make sure that you can generate workouts faster so latency doesn't suffer. So yeah. Another illustration of this approach of building like a general architecture of some algorithm that accepts a set of parameters and then having another system that generates this set of parameters is how our workout plans are generated in our system. Workout plan is a schedule of workout parameters that we generate for the user for the week ahead. This workout type target muscles like workout intensity. And the same approach we used at first we had expert crafts plan and we have only 28 workout plan templates for each fitness goal and training frequency. It worked okay and it gave users the ability to choose the workout plan that is suitable for their goal. But as Alexei mentioned, we want to grow and to be more flexible and to support different like more precise goal definition for the user and make it more personalized and more effective for them. So currently we changed our code plan generation to use LLMs and here it is Pretty interesting illustration because on one hand it is pretty easy to set.

Up.

Prompt that will generate you something, but you need to have a pretty good understanding of how will you evaluate and how you will work with it. And this is why it is at least in our opinion, always good to start with some baseline as we did. So you have something to compare your more advanced solution to. And this baseline allowed us to set up a regression test suite so we can run offline evaluations for our LLM generated plans and see that we didn't drop any quality metrics. Next I will give a very quick overview of our other system. And I guess here the main takeaway that I want you to note is that seemingly simple systems sometimes are not that simple in fact because they have a lot of different moving parts. And also to reiterate, you never know when starting to build a system like which components will you need to effectively solve user problems. So it is very very useful to start as simple as possible. Weight recommender system like it has pretty simply defined task you need for each exercise with weight to recommend some weight to the user to complete and to build the system. We started with just a simple spreadsheet where we built basically linear regression model where we fine tuned the parameters by hand. And it allowed us to experiment very very quickly to see how and which features do we want to use and how will they affect the final predictions. Then we moved to code and on a very high level, like on the next slide, I have a simple overview on how the system works. Have a user profile and we estimate muscle group levels. Then we use them to estimate 1 rep max for each example exercises. And based on 1 rep max we give weight recommendation. And when user logs weight and effort, we fine tune the muscle group level and estimate like 100 max weight. And we wanted to like it on, on the surface it sounds pretty simple, but when you want to really fine tune it, it becomes quickly becomes a lot more complex. For example, we want to make sure that we use this information as efficient as possible. Because for example, if user logged some exercise like bench press, it is obvious that it should affect other weight recommendations. And for example, if user says that they were struggling to complete some exercise, we should also take this into account. And then we also want to give users some way to track their progress and all this results. We wanted to build the system in such a way that on one hand it is efficient and simple. On the other hand we wanted to make it as precise as possible. So yeah, as I mentioned, we first started with a set of mathematical models and algorithms. And then we decided to replace components Y by one by machine learning. And we started with one rep max prediction and can tell you little bit how it is currently implemented. So for every time user blocks an exercise, we record an event that states which amount of repetition test weights we recommended and which amount user completed. And we Use this information along with some user profile data and exercise features to train simple gradient boosting model. And it resulted in like 5% improvement of recommendation weight. Recommendation accuracy also which the things that I skipped, but they are also really important in real system is that we want to make sure that the predictions of the system are safe. So we also implement clipping of the model outputs and we log all the predictions and monitor outliers. For example, if the weight that we recommend differs a lot from what user actually logged, we take a look and investigate why this discrepancy is so high. So yeah, next I will tell you a little bit about the stack Score. It is a feature that we introduced recently and it allows user to see the progress in weight training. And one of the important things here is that it was basically the user interface for our internal data points that we already had this muscle group levels. And I think one thing that I want to note here is that when you design a system, it is always good to make it as interpretable as possible. Because on one hand it allows you as a developer to better understand if it works as intended, because you can just see if these parameters make sense. And on the other hand, it allows to build nice features for the user without a large amount of modifications. Right. And for the final part, I want to tell you a little bit about. In my opinion, one of the most important parts that allows us to progress and it is the system evaluation, monitoring. It is very important to invest in tools because especially for us, because we have a small number of developers and we want to be as efficient as possible and not waste time on some bugs and regressions. So we have a pretty big suite of tests. One of the things, for example that we measure is that we have a tool that allows us to replace a number of workout generation requests from production. And it allows us to measure the different metrics that we defined and why it is useful. First of all, it allows us to avoid regressions. For example, if we make some changes to our system, we can make sure that we didn't introduce any bugs. On the other hand, it allows to very quickly see if we make improvements. Also very important thing, as also Alexei mentioned, we have a lot of subsystems that work together to generate a workout. And sometimes it is hard to understand, for example, if you see some bug, some strange behavior, which system contributes to this. This is why we have a set of, we call them simulators. This basically some set of tests that emulate simple user behavior and see and check that the system performs as intended by Checking very, very basic invariants. And it may sound obvious in some sense, but even the simplest checks like ensuring that if user performs the recommendation the way it grows helps to find bugs in places which for example for exercises that are rarely predicted or for some combination of parameters that you didn't expect when you developed it. And also it helps to make sure that you also don't have regressions. And also another thing that is really really important is that you should not only look at aggregated metrics, but conduct the reviews by yourself. And especially it is useful with experts when you see that the final recommendations and you take a look at the user profile and their workout history and which workouts are recommended and this invaluable source of improvements for the system. Also we have like on the other hand for online metrics we strive for to keep them as the amount of metrics as short as possible because it is usually important to see like to have this like couple of key metrics. We use Snowflake for log analysis. If we have some things that we need to dive deep, we use Hex. It is basically like Jupyter notebook on steroids. This very good for building automated reports and Grafana for basic metrics like endpoint error rate performance. Yeah, and one thing that I wanted to note is that it is really important like I think every machine learning developer has some random seed like not random seed, random number generator somewhere in the system. It's very important to use seeded randoms and to log the seed weights and make sure that the system gives reproducible results. It will help you a lot to debug problems if you have them. And regarding the product metrics and like overall progress, one of the most important product metrics that we have as also highlighted is the retention like workout retention. Because basically all of our efforts come to one point. We want our users to continue working out and we have made a pretty good improvement year on year. We have improved the code retention by 25%.

And.

The thing is it is hard to especially in a startup environment to like attribute this improvement between like UI improvements, bug fixes and our workout recommendation improvements. Of course we perform A B tests to see if our features improve the target metrics. But like for especially for high level metrics like workout retention, for us it is really hard to estimate and conduct like absolutely 100% proper A B tests with like negative tests and like other types because for us it would mean that we will need to split our audience and we risk getting negative feedback. So usually we measure the impact by Some proxy metrics and improvements of our system are more targeted. So yeah, I guess this is it. So here are the main takeaways. Start as simple as possible because you never know how users will interact with this system. On the other hand, you should think forward and try to anticipate which data will you need to monitor and to improve your system in the future, invest in a good evaluation pipeline because it is always good to have some confidence that the improvements that you make are really improvements and not introducing any regressions and kind of obvious but I wouldn't. It is very important to mention it. LLMs help to improve the market a lot and try to use them, try to integrate it into your pipelines if you didn't and try to experiment with them. They are a little bit tricky to work with because it is hard to ensure consistency. But for prototyping it is extremely useful. Yeah. So I guess this is it. Thank you.

Thank you both. That was very, very fascinating stuff. Yeah, really cool. So we've got a few questions from the audience before we get to those then for everyone in the audience. We've got plenty of time for questions so please do ask them in the chat. Now I've got a couple of questions for you both to begin with. So I'm curious if after collecting all this data on your users, whether you've found anything interesting about like what users care about like what are the most popular goals and yeah, what else have you learned about your users?

So in case of our learnings about users and most popular goals it's quite obvious. So it's about losing the weight but in different ways. As I said, it's not like something common that I want to lose weight, I don't know for 20 kilos or 10 kills and so on. It's a lot of nuances because it's not about goals, it's also about your background because if you are busy mom. So it's one background and one workout plan and cadence of workouts. If you're, I don't know a guy who want to lift weights and at the same time lose weight. So it's quite challenging because you are getting muscle mass and at the same time you need to somehow to reduce body fat. I think the most challenging part is help user to understand its real goal because even with the to be lean usually for our audience is to gain muscles and then to lose weight something like to be more leaner. So and it's like two different something sub goals that you need to do in different steps and you need to communicate it with user.

Okay.

And the most I think important in our period there, most of users works well with the new year resolutions because for us it's let's say high season because engagement of users in January 30 higher than any another month during the year.

Okay, that is fascinating. Yeah. So everyone's really keen for at least a few weeks at the start of the year and then I guess things tail up after that.

All right, add a couple of stories. And also from our previous experience, it is also extremely interesting to look through the user database and user activity and see different outlier users because sometimes you never expect to find what you see in real world. For example, like in our previous startups, we also seen that like for example, some users that like very particular feature a lot. Like in Zinc, for example, we have users who have passed fitness test like hundreds of times or users who complete workout every day for two years. And this is really sometimes interesting to observe.

Absolutely. That's a pretty good streak. Two years of exercising every day. Yeah, that's impressive stuff. And Jeff, things about like what are the most popular workouts or combinations of workouts then like what are one of the most popular exercises people do?

I think the most popular exercise for gym goers, as I remember it's bench press. So it's I think also quite obvious, at least for us was. And for home workouts, I think maybe Denise will remind me. But it's something around jumping jacks and so on because it's incorporated usually in every routine as part of the cardio for your home workouts. And it's not so hard as burpees and so on. It's quite easy to understand what to do.

I feel like no one likes burpees. So yeah, jumping jack makes a bit more pleasant. Sorry, Dennis, I interrupted.

Yeah, yeah, I think, I think it is something like jumping jacks or some core exercise. I don't remember exactly what it is, to be honest, but yeah.

Okay. All right, nice. Okay, let's go to some audience questions. So Ken was asking, how many iterations have you done so far? What are the key learns if you can start all over. So I think this is referring to the fact that you said, said you start off with like the, the template workouts and then you iterated and had the. The sort of. The generated ones. Yeah. Can you talk them through? Like.

Yeah.

How things changed and, and what would you do differently?

I think it's like if we are speaking about like large iteration, like about change of paradigm. It's like what the three Times currently for us it's third changing of paradigm how we working with the user data. But in case of each state it's hundreds of experiments so it's different in each subsystem and so on. We did it a lot.

Yeah, that's the thing. You. You got to keep experimenting constantly to. To keep things going. All right.

Yeah, I guess regarding the takeaways, I guess this like the main takeaways I think we highlighted on the last slide. I guess the most important thing is we should always try to bring system to the users as soon as possible. Even if you're like internal data scientists want to improve it and bring another 0.1% of model accuracy, you should resist and you should work as a team with your team members and release it because this, this is the most important part.

Ah yes. Yeah. There's definitely a temptation to try and make things as good as possible before you release them. But then you might find out the users don't like it anyway and it has to be deprecated. So yeah, I like the idea of getting things to use as quick as possible. All right, so Adam, ask. Oh, this is a sports question rather than data question? I think so. It's 1 RM. This is year one. One repetition maximum. I think so, yeah. Is this a good predictor of user's ability to lift a given weight? It says I can run a really fast 1km but I don't know if that's a good prediction in my marathon time.

In general. Yeah, it's quite good prediction because it's one rep max. It's weight that you can lift only once. So for example 70 kilos for bench press and you cannot lift it's more than one time. So. And for prediction, prediction of what weight recommend, for example for the same exercise for 10 reps it works quite good. So and there is good correlation for it.

Okay.

Also we predict 1 rep max for each exercise. So yeah, it is. It works well.

All right. I suppose it's a relatively short test to do as well. You only have to lift the weight once rather than if you ask people for their 10 rep max, it's going to take longer to get the data right. Okay. All right, so next question comes from Janice. Oh, Janice saying what do you think about AI generated video or workout content? Have you tried using AI versus real people in videos what you think people would prefer?

So in case of workout generation, for example for as a model to do demonstrate. It's a quite interesting approach because it will help to reduce cost on providing new Content and the increased number of exercise in our database quicker because for us it's currently shooting process of 100 workouts. It's quite time consuming and quite expensive process for us but in case of how users react on it. So it's quite interesting because recently we did user research and we wanted to understand what visual representation of our AI code should be. And we provided a lot of different options from I don't know, some kind of cloud of dots that interact with you to real person. Not like a real person that is AI generated but looks quite realistic. And it's around 75% of our users choose real human like coach because they feel from their feedback that this person like better know how to get fit because they look fit. So and it's more attached with their goals and so on. And we updated all of the avatars of in communication to this AI generated person and we have increase of conversion to start of conversation with our AI coach by 25%. So we had no any other experiments that provided us for this metrics. Such big uplift.

That's really interesting on how people react to a generated human or. Because I guess it's fine until you get like weird artifacts and someone with six fingers trying to lift weight. I think they're cheating somehow.

Yeah. Matter of time. So I think in a year or maybe two, it will work quite good.

Yeah. All right, super. One last question then before we wrap up. So Adam says if a user considers themselves very fit for the recommended workouts ranked too difficult by the users that affect ranking with workout or user metrics. Yeah. So I guess there's two problems here. The, the suggested workout can either be too hard or too easy. So how do you deal with either case?

Okay. I think Denise will answer anything.

Yeah. One thing that is important here is that currently we don't have like a predefined library of the workouts. So if user ranks some. Some workout is too difficult, it affects like only this user. So basically, yeah, the user metrics will be adjusted. I hope this, this answers the question.

Okay, so you got a bit of a feedback loop there so you can adjust things. All right, nice. Okay, with that, we're gonna have to wrap up. Thank you so much, Dennis. Thank you so much, Alexi. That was really fascinating stuff. Before everyone dashes off, I want to say we've got a load more webinars coming up. So tomorrow we've got a session on data and AI trends and predictions for 2025. On Friday, we've got a session on Power Bi on designing dashboards. Then next week we've actually got a series of three code along. So Tuesday's session is going to be on building your own fitness tracker. So you're not going to quite be able to build Zing, but we're going to do some very simple analysis using Python. So please do come back for that then. And yeah, we've got more code alongs all next week on AI assisted Python. So, yeah, please, those all right? Yeah. Thank you once again, Alexi and Dennis. Thank you to Reese Moderating. Thank you to everyone asked a question. Thank you to everyone who showed up today. See you all.