What my app's analytics say about when teens actually doomscroll (it's not during class)

I'm Ayumu, and I build minulo on my own. It's an iPhone app that opens 10 social networks (Instagram, YouTube, TikTok and others) with Reels, Shorts and the other short-video feeds hidden, while DMs and the rest still work. It's React Native with Expo, a WKWebView for each network, and the Screen Time API to lock the official apps when someone wants a break.

A lot of my users turned out to be teenagers, mostly in Korea. Korea now has a law restricting phones in schools, and Japanese schools often collect phones or ban them in class. So I wondered when my younger users were actually scrolling. I had assumed a good part of it would be at school. My own numbers said otherwise.

Before the numbers, the usual caveat: this is a small, young app. Everything below comes from my app's anonymous event data, a few hundred users, and most of the time-of-day numbers are from Korea and Japan over the last 30 days. It shows what happened in my app. It doesn't say anything about teenagers in general, and none of it is evidence that one thing causes another.

What I measured

Three things, all in PostHog:

• Age band. Onboarding asks one optional question: how old are you? The answer (under 17, 18–24, 25–34, 35+, or no answer) is stored as a property on later events. It's self-reported and I can't verify it.
• When people open a social network inside minulo. Every time someone opens Instagram, YouTube and so on in the app, it sends a service_opened event. I bucket those by local hour.
• Blocks and the paywall. When a block starts and ends, and when someone sees the purchase screen or buys.

Since some of these users are 17 or younger, I want to be clear about what is and isn't collected. I don't have names, emails or accounts. GeoIP is turned off, so the country comes from the device's locale setting. Events don't contain what anyone watched or who they messaged. Everything in this post is an aggregate over a group, and I only looked at counts and percentages, never at single people.

When teens open social apps: mostly after school

The table below covers users who said they were under 17 and whose device locale is Korean or Japanese. In the last 30 days that's about 80 people (58 in Korea, 22 in Japan). Each cell is the share of their social-network opens that fell in that time window, in local time. Korea and Japan share a time zone, so one clock works for both.

Local time	Under 17, weekdays	Under 17, weekends	18–24, weekdays	25–34, weekdays
00:00–05:59	11.6%	21.7%	20.0%	6.9%
06:00–07:59	5.9%	4.0%	2.6%	4.0%
08:00–15:59 (school hours)	18.9%	42.3%	29.5%	57.1%
16:00–18:59	22.5%	7.3%	19.7%	14.2%
19:00–21:59	18.7%	16.0%	16.4%	13.6%
22:00–23:59	22.3%	8.7%	11.8%	4.2%

What stood out to me:

• On weekdays, only about 19% of under-17 opens happened between 8:00 and 16:00, roughly the school day. From 16:00 to midnight it was 64%.
• On weekends the same group looks completely different: 42% falls in those daytime hours, and 22% comes after midnight.
• University-age users (18–24) open things during the day more (30%), and 20% of their weekday opens come between midnight and 6:00.
• 25–34 is the only group where most use is during working hours.

So in my data, teenage weekday scrolling sits after school and in the evening. That fits with how schools in Korea and Japan already handle phones: they're often collected in the morning or not allowed in class. The school day is already covered. The hours after school aren't.

A peer-reviewed study from England points the same way, from a much better data set than mine. The SMART Schools study (Goodyear et al., The Lancet Regional Health – Europe, 2025, PMC11984610) compared 1,227 students aged 12 to 15 in 30 secondary schools, some with strict phone rules and some with relaxed ones. Students at strict schools used their phones about 0.67 hours less during the school day and social media about 0.54 hours less, but their total time on weekdays and weekends was not different, and neither were wellbeing, sleep or grades. Longer phone and social media time overall was linked with worse outcomes. The authors concluded that the evidence doesn't support school bans in their current form on their own, and that total daily use needs to come down. It's a cross-sectional study, so it shows associations, not effects.

How long a block lasts: about one study period

minulo can lock the official Instagram (or YouTube, TikTok...) app for a while with Screen Time, so tapping the icon out of habit doesn't drop you into the full feed. Over the last 30 days, almost everyone started blocks right away from the in-app tab rather than scheduling them, and the average length was:

• under 17: 74 minutes
• 18–24: 82 minutes
• 25–34: 80 minutes

Blocks started from the home screen run longer, 97 to 120 minutes.

People seem to use it as a one- or two-hour focus session. That's close to the length of a typical self-study period at a Korean or Japanese cram school, which is around 80 to 90 minutes. I'm not claiming that's why, but it's a useful length to design around.

Over 60 days, 83% of users who said they were under 17 started at least one block. That's the highest of any age group (18–24 was 76%, 25–34 was 73%).

"I want this, but I can't pay"

This is the part that changes how I think about money. Over 60 days, among 248 users who said they were under 17, the purchase screen was viewed 462 times. 11 of them tapped to buy, and 8 ended up with a completed purchase or a started free trial.

In other words, the group that uses blocking the most almost never pays. On iPhone that isn't surprising. Many teenagers don't have their own payment method, and Ask to Buy sends the request to a parent. Per person, 25–34 was the age group most likely to pay in my data, though the numbers there are small too (8 people).

So "show the paywall more" is the wrong answer for this group. They already see it plenty.

What I'm changing because of this

Nothing here is shipped yet. This is the list I took away:

1. After-school and night presets. Right now a block mostly starts when someone taps "stop now". A one-tap preset for the hours that actually matter (after school until dinner, and late at night) matches the table better than anything aimed at the school day.
2. A default length of one study period. People already settle on about 75 to 80 minutes. Offering that as the default instead of making them pick is a small change.
3. Write for students, not just about doomscrolling. Most of my users are 24 or younger. The angle that fits them is "keep your group chats, lose the Reels while you study", not a general screen-time message.
4. Stop pushing teens toward a purchase they can't make. Hiding Reels and Shorts is already free in minulo. For under-17 users, the useful thing is probably to make the free part work well and think about who could pay on their behalf, such as parents or cram schools, rather than showing the paywall again.
5. Measure the source I'm missing. Onboarding asks where people heard about the app (App Store, AI assistant, social media, friend...). There's no "school or cram school" option, so I can't tell whether teachers are passing it around. That's one line to add.

The query

Here's the HogQL behind the time-of-day table, in case you want to do the same thing in your own PostHog project. Paste it into the SQL editor. {filters} is replaced with your project's test-account filter, so your own dev and review devices stay out.

select
  day_type,
  multiIf(h < 6, '00-05', h < 8, '06-07', h < 16, '08-15',
          h < 19, '16-18', h < 22, '19-21', '22-23') as slot,
  count() as opens,
  round(100 * count() / sum(count()) over (partition by day_type), 1) as pct
from (
  select
    toHour(toTimeZone(timestamp, 'Asia/Seoul')) as h,
    if(toDayOfWeek(toTimeZone(timestamp, 'Asia/Seoul')) >= 6,
       'weekend', 'weekday') as day_type
  from events
  where event = 'service_opened'
    and {filters}
    and toString(properties.age_band) = 'u17'
    and (toString(properties.device_locale) like '%-KR'
         or toString(properties.device_locale) like '%-JP')
    and timestamp >= now() - interval 30 day
)
group by day_type, slot
order by day_type, slot

A few notes from writing it:

• Convert the time zone before taking the hour and the day of the week. If you only convert the hour, a Saturday 1 a.m. in Seoul is still Friday afternoon in UTC and lands in the weekday bucket.
• toDayOfWeek returns 1 for Monday and 7 for Sunday, so >= 6 is the weekend.
• Swap 'u17' for '18-24' or '25-34' to get the other columns.
• This counts opens, not people. One heavy user can move a bucket, so check count(distinct person_id) next to it.

Limits

I'd rather list these than have someone else find them:

• Small sample. About 80 under-17 users in Korea and Japan for the time-of-day table, and 248 for the 60-day numbers. A few very active people can shift a percentage by several points.
• Self-reported age. Anyone can tap any answer, and older users who installed before the question existed have no age at all. Some under-17 users probably said 18–24, and the reverse.
• Locale is not location. Country comes from the device's language and region setting, not GPS or IP. 40 under-17 users had no usable region and are left out.
• Time zones. I used Seoul time for everyone with a Korean or Japanese locale, which is right for both countries as long as they're at home. Travelers are counted in the wrong hour. Public holidays in the 30 days count as weekdays.
• School hours are a guess. 8:00 to 16:00 is a rough window. Real schedules differ by school and grade, and "outside school hours" also includes lunch breaks and commutes in some places.
• Only my app. These are opens inside minulo, not total phone use. Someone who opens Instagram in the official app at lunch doesn't appear here at all.

If you run analytics on an app with younger users, I'd like to know whether your hours look the same, or whether this is something about my users in Korea and Japan.

The monthly data page I keep for minulo, with more of these numbers: https://minulo.app/en/reels-shorts-data-2026.html?ref=devto-1024b

Comments

[Dave Kurian]

Thanks for sharing the query. One thing in the day split: the after-midnight slot is bucketed by the calendar day of the open, so a Friday night session that runs past midnight puts its 22:00-23:59 part in weekday and its 00:00-05:59 part in weekend. Sunday night spills into weekday the same way. That could be part of why weekends show 22% after midnight while weekday evenings look so heavy. Shifting timestamps back by 6 hours before taking the day of week would keep one late session on one night. Do you know how much the weekend after-midnight share moves when you split it that way?