Ariel opened by explaining that onboarding is super important. If you take the time to do everything Ariel has been talking about for a long time to get more people to see your app and download it, but you are not converting them, that is problematic because they are dropping off.
Ariel had just worked with someone who was getting downloads through Apple Ads, but users were not converting nearly as well as they could. Ariel was 99% sure the issue was onboarding. It was not pricing, it was not the features, and it was not anything specific to the app. It was what users saw when they downloaded the app. If that is exactly what they expected, or if it is not, that is going to make it or break it.
Ariel explained that the livestream would look at onboarding screens submitted by viewers and look for tips or ways to improve them. With onboarding, there is not really a simple do this and succeed formula. Every user is different, every user group is different, and every niche is a little bit different. But there are fundamentals across really all apps. It is marketing and consumer behavior, and while those are fun, they are also tricky.
The Goal of Onboarding
Before reviewing the apps, Ariel explained that onboarding is one of those things where you think you know what you are supposed to do, and most people get it almost right. But if it is not right, it is not right. You can be almost right and make billions of dollars, unfortunately. That is not how this works.
It is really about optimizing the paywall and thinking about what you can do with your paywall. It is not about how to restructure your paywall from scratch. It is how to take what you have now, if you already have a paywall, and turn it into something that works for you.
What are the changes that you can make to make things much, much better?
Ariel said it is iterative, it is a process, and it is a great process. That is what Ariel likes to look at all the time: how to use that process to improve the existing paywall.
SheGlo
The first app Ariel reviewed was SheGlo.
The onboarding copy included:
Hey gorgeous.
Once you glow your apps unlock.
You are in the right place.
Build a healthier relationship with social media.
Practice daily self-love.
Stop comparing myself to others.
Make your commitment.
Let’s glow.
Ariel liked the colors and liked that it felt like what the app probably looks like, or at least what Ariel hoped the app looks like. Ariel also liked the lock and the idea of what was going on there.
The main issue was that Ariel was not entirely sure what was being locked. Ariel could guess because this is a popular concept that has become more popular over the last year or two: an app that forces you to do certain things before you can browse social media infinitely forever. It might be a time-based lock or something else, but Ariel imagined that was what was going on.
Reinforce What the User Came For
Ariel explained that, for many years, there was an expectation that when someone comes into your product, app, or anything you do, they already know what they are looking for so well that all you need to do is get them to the starting point.
That is almost correct in most cases. But for this kind of app, Ariel would test the first screen quickly and often. The line once you glow your apps unlock makes sense after thinking about it. But Ariel has said many times that you want to make people think less. You want to cater to their inner thoughts and get those inner thoughts out.
Once you have them, they are still not yours. They downloaded the app, but that does not mean they know exactly what they are going to do. If that were the case, you would not need an onboarding. You would just need a get started button. And we know that does not work for most apps. It works for some, but not most.
What Works in the SheGlo Onboarding
Ariel pointed out the things that worked:
The progress bar at the top.
The simplicity of the screen.
The fact that there was not much on the screen.
The focused design.
The signature or commitment moment.
Ariel said the progress bar is important because many people do not like feeling like they cannot get to what they want quickly. Unless your app is trying to do something totally different, it is important to show the user: I am not going to waste your time. I am just going to help you get started.
The onboarding is not the main dish. The main dish is the app the user downloaded and that you eventually want them to pay for.
Ariel also liked the signature. There is a whole philosophy around getting a user to commit to your app as early as possible in the onboarding. The more you get them to mentally say yes, I am going to do this, the more likely you are to get them to activate. Ariel was not sure how that translates to payment because it depends on the app and the commitment, but you want them to activate in the onboarding.
Activation means taking the action that will lead them to pay you, not necessarily paying you right away.
Ariel imagined that if you go through the App Store page, it probably tells you that this is an app that blocks Facebook, Instagram, TikTok, or another social app until you do something. But Ariel did not get that reinforcement instantly in the onboarding.
Even if someone downloaded an app expecting it to block social media until they do x, y, and z, the onboarding should reinforce that. Instead, Ariel had to infer it.
Ariel said the best reaction would be: yes, that is exactly what I needed. Once you have that, you are going to get activation. If the app has the features the user really wants, you are going to get the download. If you have a hard paywall, you are more likely to get a trial, especially when payment creates friction.
Ariel would test explaining exactly what the app does, while keeping the same simple, nice, minimalist feeling. Show the user how they would unlock Instagram and why they do not need to unlock Instagram.
Saying build a healthy relationship with social media is cool, but it requires brain cycles to understand that the real healthy relationship with social media is to use it less.
Ariel’s main advice was to reinforce very quickly that this is what the user wants, this is what they need, and this is what they downloaded.
Onboarding, Activation, and Hard Paywalls
Ariel then talked about the broader goal of onboarding.
Ariel has talked to a bunch of experts over the years, and each has a slightly different approach to what onboarding should do. It is hard to generalize because every app is different, every user is different, and every set of features is different.
In Ariel’s opinion, onboarding is not your marketing. Marketing gets the download. Once you have the download, now you need to activate the user. You need to get the user to use the one feature that you know you want them to use, even if they do not know instinctively that they should use it. Once they use that feature, they say: yes, that is exactly what I wanted, here is my 4.99 a week or my 12.99 a month, or whatever you charge. If the app gives value, everyone wins.
The idea of onboarding is to get the user to that moment and get the user to take action.
Ariel addressed the thought, why would someone download an app if they do not intend to do that? The reason is that it is hard, people are busy, and attention attracts all kinds of confusion.
Imagine the user downloads a social media blocker app, and then a push notification comes in saying someone on Instagram posted a new photo. The user thinks, let me just check this one photo before I activate the app that is going to block me from doing this. Maybe they do not come back for an hour because someone calls, they get an email, a friend says hi, work demands attention, or something else happens. Hours later, they may have no clue what all this was and they may not activate.
That is the challenge. You have to do it quickly and in a way that gets them to understand what they are doing.
Another option is to get them to pay or take real action, like leaving a rating, as quickly as possible. Ariel thinks that is more challenging.
Ariel said there are bigger thoughts on the state of subscriptions. A lot of people say hard paywalls convert better. Ariel is doing studies and experiments to make sure that is true across a wider set of apps, not just because someone said it. Ariel did not give advice yet, but said it is worth thinking about what hard paywalls will cause for future users. Ariel thinks we may be confusing users right now. Ariel was not saying not to use hard paywalls, because if it works, it works, and we are living for today. But it is something to be mindful of as more experiments are created and maybe better ways to convert are found.
Is the Paywall Part of Onboarding?
A viewer asked whether the paywall is part of onboarding if it is behind specific features. The viewer had changed a music editing app so people could explore using sample music, but adding custom music would show a paywall.
Ariel said no, in Ariel’s opinion, that paywall is not part of onboarding. If the onboarding gets users to activate and explore sample music, that is great. But if they want to take an action and a paywall appears, that is separate.
Ariel said more apps now show the paywall at the end of onboarding, even if the app has freemium features, and then also show it when there is a gated feature. Ariel is testing this and expects to have more information soon.
But Ariel would not consider a paywall that pops up on demand from the user as part of onboarding.
Should Sign-Up Come Before or After the Paywall?
A viewer asked about sign-up before or after the paywall. They could imagine users converting more after sign-up, but someone could also argue for a smoother onboarding without sign-up and with the paywall first.
Ariel said this depends on the app and the user.
Many B2B apps require a login and you cannot do anything in the app before you log in. For those apps, putting login in onboarding may be necessary. Even if there are freemium features, most B2B apps need the user account to do anything. If login is not part of onboarding, the app may be crippled and people will look for the signup.
B2C apps are very different. In some cases, you want people to get started and activate as quickly as possible, and logging in is not that quick.
With Login with Apple, Login with Google, and Login with phone, the experience is much smoother than it was five years ago, when users had to sign up with email, go to their inbox, get a number, put it into the app, or click a link and deep link back. That was a mess. Now the friction is smaller, but it is still friction.
Ariel would only add login early if you know for a fact that people will be looking for that login right after they download the app because that is how they intend to use the app.
For games, Ariel would not do login as quickly unless people are looking for it because logging in gives them their score from the web version of the game, a saved list, or something similar. If that is not the case, leave it until it is necessary.
As with everything else, Ariel would test it. It is hard to say generically that it works or does not work. It depends on the use case, the user, and the type of app.
WikiSleep: Bedtime Stories
The next app was WikiSleep: Bedtime Stories.
Ariel noted that Bedtime Stories is an interesting category. Ariel had been looking at this category for another app that Ariel was helping, whose onboarding Ariel thought needed to change.
The screenshots appeared to include:
We selected some stories for you.
Get better sleep.
It is time to sleep.
A login screen.
A subscribe screen.
The developer explained in chat that the screens were not in order. The flow was to download the app and get the user directly in, keep the content behind the paywall, and show the subscribe screen when they try to play it.
Ariel said the first screen looked less like onboarding and more like a curated getting-started experience inside the app because of the scroll, tab bar, and everything else on the screen.
Too Much Is Happening at Once
Ariel said that felt limiting. If Ariel landed on the first screen, there was so much going on that Ariel did not know where to look.
This is orange and I like this, and who does not want better sleep?
Modify my alarm.
Enjoy 7 days free.
There was a lot going on.
The point of onboarding is to activate the user, not show every feature.
The developer said in chat that because the app is sleepy, they wanted people in right away.
Ariel understood that, but said the assumption that when someone downloads an app they are ready to activate is not 100% true. Some users understand the features and may have seen the app in action on TikTok, from an influencer, or on YouTube. But depending on the app, the odds that someone comes in knowing exactly what they want to do and is ready to sleep may not be as high as someone downloading something they want to try.
Ariel also said the app may not be downloaded just before bedtime. If users download it midday, Ariel would bring them into something simple. The previous onboarding with one or two elements on screen, especially the lock and unlock concept, was strong because it showed exactly what would happen. It needed a little more description, but the simplicity was good.
Ariel said that if people are sleepy, let them sleep. Maybe use one or two slides, without dragging it on.
Ariel liked the colors, the character, the z’s, and the general feel. But Ariel would remove all non-activation actions.
On the screen, there were both explore now and modify my alarm. Both buttons felt equal, and also visually competed with other elements. Especially if the user is sleepy, they may not know what to do. Should they click one button, another button, or the free trial prompt?
Ultimately, Ariel said the app probably wants the action that pops up the paywall, not simply enjoy 7 days free. But the action needs to be obvious.
If the desired action is modify my alarm because that ties users into the app, then make that very clear. If the desired action is explore stories, then say explore stories now. If Ariel had not read the text, Ariel would not know what explore meant.
Think from the standpoint of someone who has no clue what this is, does not know how it will help them, and is browsing while asking, is this for me?
Clarifying the Desired Action
The developer clarified that modify my alarm was not the main desired action. The developer wanted people to explore the stories.
Ariel said this is exactly why being present in the live review helps. Ariel had assumed modify my alarm was the desired action because it looked important, but that was not the case.
Ariel would eliminate the competing elements from onboarding, not from the app itself. Ariel would test introducing another slide that says something like, hey there sleepyhead, we selected some stories for you to help you sleep better. Let users know why they should do this.
Ariel also said explore sounds big and important. If the user is sleepy, they may not want to explore a library. They just want to go to sleep. Ariel joked: please make me go to sleep, make me a bicycle clown.
The goal should be do not make me think. That applies to screenshots, custom product pages, and onboarding. Each has a different purpose, but they all get a user who does not know who you are to know who you are, then get a user who does not know what the app does to know that the app can do x. Not x and y and z and m and l. Just x, because that is what gets them to say: yes, that is what I needed.
Should WikiSleep Lock the Content Instead?
The developer asked whether it would make more sense to remove both cards and just have the content locked.
Ariel said there are two experiments:
A simple, straightforward slide that only focuses on the stories. Ariel would chop the bottom half of the page, center the story section, and leave the background because it is cool.
Open up the library and let people tap on stories. Maybe make one or two stories open, and when people tap on the rest, explain that this is how the app makes money, or really, this is how the user will get better.
WikiSleep Paywall
Ariel then looked briefly at the WikiSleep paywall.
Ariel said it looked like a standard template, done a little differently. Ariel personally thinks more information is worse in most cases, although it depends on the app and should be tested. Ariel did not see anything terrible. The colors worked, the theme worked, and the user knew what was happening.
But Ariel thought the amount of explanation might be overboard. That kind of detailed subscription explanation worked a few years ago when subscriptions were new and people did not know how they worked or how to cancel them. Ariel feels that has changed considerably. People are now willing to start a 9.99 weekly subscription without a trial by accident and not cancel it.
Ariel would rethink the space because it takes away room that could convince the user they can sleep better.
Ariel said many people cannot fall asleep instantly. Some take minutes, some take many minutes, some take hours. That is horrible, and everyone Ariel has talked to complains about it. Ariel personally puts Ariel’s head on the pillow and is out, mostly because Ariel goes to sleep really late. But for people with this problem, they will do anything to fall asleep.
Ariel did not see anything on the paywall screaming: I am going to help you sleep. That is all it needs: one thing.
Ariel thought the space was wasteful and would instead make a claim that the app will help the user sleep, and that the first seven days are free. Then show pricing and normal expected subscription details. But the key missing thing was the feeling of: I just want to go to sleep, and this is my solution.
Ariel said this could help reveal whether users are ready and just need a payment button, or whether they need an additional nudge to get them over the edge.
Socratic Owl: Homework Helper
The next app was Socratic Owl: Homework Helper.
Ariel thought this app might have been reviewed in a previous livestream. Ariel liked the presentation because the screens were numbered and animations were labeled. Ariel said numbering screens is a good idea. Ariel also appreciated labels showing when animations are used.
Ariel said animations can be critical in onboarding when the app does something the user may not be able to picture in their head.
The onboarding included:
Socratic Owl: Homework Helper.
A cool owl character.
2 million problems solved.
250 learners or a similar learner metric.
No more struggle with homework.
One app for all subjects.
Create custom subject folders.
Questions.
A data screen showing more questions solved.
Ariel noted that more students have been turning to AI to help them over the last couple of years.
The social proof screen with problems solved and learners is the kind of thing Ariel would put in screenshots to get someone to think: yes, this is for me. Ariel also liked it in onboarding. Reinforcing that this is the app for you is something to test.
Ariel would test with and without that screen because some users may think: yeah, yeah, I know you have a lot of users, let me just do my homework. But it is worth testing in more apps.
Value.
Value.
Feature.
Questions.
Data.
Ariel liked the questions and the data screen. Ariel asked whether the developer saw drop-off as soon as the app asked a question.
The question mechanism is great because it works like the signature from SheGlo: the user commits by answering. It is an easy commitment because the user is just saying why they are there, and most people know why they are there.
But some users do not want to answer any question. If drop-off after slide 4 is large enough, Ariel would change it, move it around, or use something like slide 7 instead.
Ariel really liked slide 7 because it showed the user they were going to get more questions solved. Like the sleep example, Ariel said WikiSleep could show how long it takes people who cannot fall asleep to fall asleep on their own and how much faster it is with WikiSleep. That chart alone could give a boost, even though getting or inventing that number is an implementation problem, not a marketing problem.
For Socratic Owl, the data screen reinforces that the user will get exactly what they want. Ariel repeated that the key is: I am going to get what I want.
What Socratic Owl Should Test
Ariel was less convinced by create custom subject folders early in onboarding. Maybe the user wants that eventually, but Ariel did not think users know they want it so early.
The onboarding is part teaching, part showing, part showing off, and part getting commitment. It is good, but Ariel thought it could be optimized a tiny bit.
No more struggle with homework sounds great. Most accurate answers also sounds great. Ariel thought those two value messages may be enough. The custom subject folders screen and some of the extra pieces may be unnecessary unless testing proves otherwise.
Ariel would shuffle the onboarding to bring more value up front. Ariel would test whether anything else is needed.
MealConde: Nigerian Recipes
The next app was MealConde: Nigerian Recipes.
Ariel noted that Nigerian Recipes is very specific.
Assuming the screens were in order, the onboarding included:
Create an account.
Verify your email.
Select your cuisine.
What is your goal?
Ariel immediately said that if the first screens were create an account and verify your email, the app probably drops 40% to 60% of signups who are looking for a recipe rather than something else.
This tied back to the earlier login discussion. If someone is thinking about a recipe, they can go to Google, open a browser, type Nigerian recipes or food recipes, and get many recipes. Those pages will be full of ads, hard to read, and will probably include a chef story first. Ariel has done this across many cuisines.
Someone coming to an app is probably trying to reduce that friction and just get a recipe. If the user is trying to get a recipe, the last thing they want to do is create an account. The last thing they want is to enter display name, email, password, confirm password, check a box, continue, and then verify email.
Ariel said: what is this, 1998?
That is a lot of friction, and if that is the order, Ariel thought the app was losing people.
Login and Recipe Apps
If the flow were flipped so users first selected cuisine and goals, then created an account, Ariel still thought the app would lose people because it is a recipe app. Ariel does not know if users see themselves as signing up for a recipe app.
Login with Apple or Google can make it considerably easier. If Ariel came to the app because of a TikTok video, or because someone Ariel knows talked about it, Ariel might log in with Apple, hide the email, and move on, or use Google because Ariel is already logged in. But if that is not the case, Ariel probably would not continue because recipes are available on Google.
The developer said in chat that onboarding is optional. Ariel asked what optional means. If it is optional, why do you need it? Is it helpful to get someone in? If it is not helpful, you probably do not need it.
If users see it, it could create friction. If users do not see it, then optimize whatever they do see.
Ariel said this is a good example of whether login is something to focus on. For this app, Ariel would hide login as deep as possible. Why does a user need to log in to a recipe app? Maybe if it is also needed on the web, but that was not explained.
It is an app on the phone, so why require login?
Ariel said to make it as easy as possible and do not make users think. Seeing four fields and a password to create is too much. A password generator may make it easier, but many people do not use password managers comfortably. Ariel said Ariel’s mom barely knows how to use her password manager, and she would be an ideal user because she might want to experiment with more cuisines. She would not go through all of that. She would say it was too complicated and go to Google.
That is exactly what the app should fight. The app should be the opposite. It should let Ariel’s mom, any mom, or anyone who is not a heavy iPhone user come in, find what they want, activate, and then figure out how to pay or move to the next stage.
What Works in MealConde
Ariel liked the simplicity of the right side of the onboarding:
Select your cuisine.
What is your goal?
Those screens were clean and easy to understand. Ariel looked at them and knew exactly what was happening. There was no need for the brain to cycle through ideas.
The screens were about personalization: what cuisine the user wants, what allergies they have, what goals they have. Ariel thought that was very good.
Ariel would not make these optional. This felt like part of the experience. The experience is great; Ariel just did not like the login.
Ariel liked that the questions were about the user and how the user would use the app better. The user does not feel interrogated. They are thinking about allergies, specific cuisines, whether they want to learn to cook, have something to eat, or show off to a girlfriend or wife.
Ariel said the right half was amazing and would use it. The left half should be hidden as much as possible.
Learn Thai Alphabet and Words
The next app was Learn Thai Alphabet and Words.
Ariel said this kind of language learning app makes onboarding especially important when demand is low, difficult to reach, or expensive. If it is hard to get people to find the app, then when you do get a download, you have to convert and activate it as quickly as possible.
The onboarding included:
Learn characters.
A skip option.
A 20% progress indicator.
Click on a character to view useful information about it.
Start with the basics of Thai by learning its alphabet.
Memorize words.
Continue.
Enable notifications.
Dive into characters.
Explore words.
Launch the app.
Ariel liked the skip and the 20% progress indicator. Ariel liked the overall flow and said it seemed like one of those things that just works. There may be visual details to optimize, but the main question is how to get the user to activate as quickly as possible.
The onboarding showed the app in action, showed more of the app in action, explained things, asked for notification buy-in, and then offered actions.
Ariel liked maybe later instead of skip for notifications. The user can skip it, especially if they have seen skip throughout onboarding, but maybe later plants a small idea that maybe they will do it later. The app can then make that easy.
Test Notifications Later
Ariel asked whether the developer had tried not enabling notifications as part of onboarding.
This was controversial a long time ago when push notifications were new and everyone tried to turn them on. Push notifications are a great mechanism for retention and getting people to use the app.
But Ariel wondered if notifications should be enabled after some kind of use. For example, eliminate the notification slide and instead, after users dive into characters or explore words, explain reminders and ask for notifications.
The only reason Ariel would test this is if there is a drop-off after the notification slide. Everything else looked good.
If the paywall comes at the end of onboarding, that changes the onboarding because it wants users to get started while also leading to a specific action.
Dive into characters.
Explore words.
Just launch the app.
Ariel asked what else the app can do besides characters and words. Clearly it can show characters or words. Ariel would try eliminating the launch the app button, even though that may sound scary.
You want to guide the user exactly where you know they need to go, even if they do not know it yet.
Ariel would look at drop-off on the notification slide. If it is high compared with other slides, Ariel would push the notification request later. Notifications help bring users back when they forget, but if they create friction at scale, wait until after activation.
Let users see one character or one word so they feel: I know this. Apps that teach music have figured this out. Learning a new instrument can feel difficult and overwhelming, so good apps reduce all friction. Learning a new language can also feel big. Users may think: I do not want another app sending me notifications; I will worry about this later. That is the enemy.
Ariel said the onboarding had strong elements: continue, skip, and progress percentage are showing up across more paywalls and onboardings, and Ariel thinks that is good.
Flashcard 3D
The last app reviewed was Flashcard 3D, described as tangible flashcards.
The onboarding included:
Continue with Google.
Continue with Apple.
Continue with email.
Select your native language.
Select your card color.
Words.
Quick tips.
Ariel immediately pointed out the login problem. A flashcards app is in a crowded category. The more friction you add, the easier it is for the user to say they do not want this and try something else, especially if they also have to pay later because many apps now have hard paywalls.
Ariel would test whether Flashcard 3D needs login up front. What is the value of the login? It was not explained. Why does the user need to log in? The app is on the phone. Ariel is not going to use it on the web. Hopefully it syncs to iPad or other iPhones through the Apple ecosystem.
Ariel would test eliminating the login.
Selecting native language is useful, but the app can probably read it from the device. Ariel was not sure it needed to be a step.
The goal is to make the process so easy that the user gets exactly what they want and nothing else. Additional features can come later as a bonus. But onboarding should focus on the one thing the user downloaded the app for.
Even if an app has many features, users usually have a specific intent. That is why custom product pages are so important. Apps with many features are niching down in their screenshots because that converts better. The same advice applies to onboarding.
There is a feature the user wants. Make sure they see it first. Login is not it. Selecting language is not it.
Select your card color might be cool, but Ariel did not know why it was part of onboarding.
The flow looked like a combination of setup and tutorial. Ariel would flip it: start with the tutorial. Show swipe up, flip, swipe down. Then ask how many cards the user wants and whether they care about color. Move login later, when it is needed.
Again, Ariel asked: why do I need to log in to an app that shows flashcards?
Final Takeaways
Ariel closed by saying the goal of looking at onboarding was to understand how to reduce friction and make the user think less.
That should be the goal of every onboarding. It does not mean onboarding needs to be shorter. If something is on the screen, if you are asking a question, showing a fact, or giving an animation, it should make sense. There should be a reason for it to exist, and that reason should be to drive activation.
If it is not driving activation, like a login screen, unless you have to log in to activate, do not do it.
Ariel said the advice was generic because Ariel does not know all the apps intimately. But the developers have analytics and know the drop-offs. If they do not, they should implement something that shows drop-off so they can see how many people download the app, how many actually use it, and where they drop off.
Ariel also noted that paywalls have become part of onboarding. Many aggressive onboardings put a paywall at the end. Some are hard, meaning the user must start a trial or make a payment for the app to work. Some can be dismissed. Ariel is testing both because Ariel does not know whether they fit across all apps, even though many people online say they do.
Ariel said it is worth experimenting with because you want to see what happens when you sell something really well in the screenshots, then in onboarding, and then ask for a free trial. If you do not ask, that does not push you to make the onboarding really optimized.
Ariel encouraged developers to try at least one thing discussed, submit an update, and share how it goes.
Ariel said the next livestream would be about Apple Ads because Apple Ads are the easiest way to get new downloads and ratings, which improve App Store Optimization. They are also the easiest way to take hard-earned cash and set it on fire if done wrong. Apple turns on a money-burning feature by default, and Ariel finds that frustrating.
The next session would cover how not to use that feature and how to structure Apple Ads whether you are a small developer or a big developer, whether your budget is 100 dollars a month, 5,000 dollars a month, or 500,000 dollars a month. The strategies are similar. Ariel planned to analyze real apps with real Apple Ads keywords, using Appfigures to see the Apple Ads keywords of any app for competitor intelligence.
Ariel ended by asking viewers to leave comments with questions, reminding anyone whose app was affected by technical issues that Ariel would look at it later, and saying Ariel would see everyone in a few weeks.
✨ This transcript was generated and enhanced by AI and may differ from the original video.
Tagged: