How We Keep Trackers Out of a Kids' App (and How You Can Check for Yourself)

Is my kid's app really tracking them?

Probably, yes. This is not paranoia. In a 2020 study in JAMA Pediatrics, researchers logged the network traffic of the apps that 124 young children actually played. Of the 451 apps involved, 303 of them, about two thirds, sent persistent identifiers to third-party companies. Those identifiers are the raw material ad networks use to build a profile of a person over time.

The problem is not new or small. A 2018 analysis of 5,855 popular free children's apps found that most were potentially in violation of COPPA, the U.S. children's privacy law, largely because of the third-party ad and tracking kits bundled inside them.

So when a parent squints at a colorful, free kids' app and wonders what the catch is, that instinct is correct. The usual catch is that the child's attention, or the child's data, is the thing being sold. fruutium is built so it can't be. Below is exactly how, and how you can check each claim without taking our word for it.

What "no trackers" means here

Four plain guarantees:

• No ads anywhere in the app. Not on the lessons, not in the games, not in the shop.
• No tracking or analytics kits on any screen a child or a signed-in family sees. No Google Analytics, no Facebook pixel, no Mixpanel, no Hotjar, none of it.
• The only thing we measure is a count of visits to our public marketing pages, and that count is cookieless and cannot identify anyone.
• A parent sets up the account, consents first, and can delete everything later.

The rest of this post is the machinery that keeps those true even on a bad day when someone on our team makes a mistake.

The check that fails our own deploy

Here is the part most companies don't have. Every time we publish an update, an automated script scans the finished app before it is allowed to go live. It reads through the code looking for the fingerprints of known trackers: Google Analytics, Google Tag Manager, Facebook's pixel, Mixpanel, Amplitude, Hotjar, and a list of others. If it finds even one of them, the publish stops. The update does not ship. We can't skip the check by forgetting, because it runs on its own, every single time.

This matters because the honest risk was never that we wake up one morning and decide to sell your kid out. The risk is that a developer adds a helpful-looking library that quietly phones home, and nobody notices in review. The scan is there to catch our own future mistake. It treats "a tracker got in" as a broken build, the same way a typo that crashed the app would be.

You can't run our publish process, but you can see its result, which is the next section.

Why the browser itself won't let the app phone home

We don't only promise the app behaves. We tell your web browser to enforce it. Every page fruutium serves arrives with a Content-Security-Policy, which is a whitelist the browser obeys. It names the exact short list of servers the app is allowed to talk to: Google's Firebase, which stores your account and runs the app, the cookieless visit counter, and the newsletter signup box on our public pages. Everything else, including every ad and tracking network on the internet, is blocked by the browser before a single byte leaves your device.

How to check it yourself: open fruutium in a browser, open the developer tools (right-click the page, then choose Inspect), go to the Network tab, and reload. You will see every place the app connects. None of them are ad or analytics companies. If you are comfortable reading response headers, look for the one named Content-Security-Policy; it spells out the whole whitelist in plain text.

The one thing we count, and where

We are not going to pretend we measure nothing. We use Cloudflare Web Analytics to count visits to our public marketing pages, so we can tell whether a blog post is reaching anyone. We name it plainly because the entire point of this post is honesty. Cloudflare Web Analytics uses no cookies and no client-side storage, and it does not fingerprint you by IP address or device. It cannot follow a person from page to page or build a profile.

It also only runs on public pages. The list of pages allowed to load it is an explicit allowlist in our code that denies everything by default. The moment you log in, or land on any screen where a child's profile exists, the counter simply is not loaded at all.

Consent first, age instead of birthdate, a PIN we can't read

Before fruutium stores anything about a child, a parent has to set up the account and check a real parental-consent box. This is not a screen you click past. Our database itself refuses to save a child's profile unless the consent record is attached to it, so child data cannot be created without a parent having agreed first.

We also ask for a child's age, as a number, and never their date of birth. Age is all we need to pick the right learning track. A birthdate is extra personal data with no purpose here, so we don't collect it. You will see this yourself during signup: it asks how old, not born when.

The parent PIN that gates the grown-up settings is scrambled with a one-way function called Argon2id, on your own device, before it is ever saved. We store the scramble, never the digits. Even we can't read your PIN back.

You can delete all of it

From Settings, a parent can remove one child's profile, or delete the whole account, which erases the family's profiles, the account record, and the sign-in itself. The delete-everything path is deliberately as reachable as signup was. You don't have to email us and wait, and you don't have to explain why.

What we give up, and what is still imperfect

None of this is free for us, and it would be dishonest to pretend otherwise.

Because we run no analytics inside the app, we are partly flying blind. We can't see which lesson a kid quit on or which game fell flat. Most companies would watch that behavior and tune the app around it. We can't, so we improve more slowly, from parents who write in to tell us what worked and what didn't. We think the trade is worth it. It is still a real cost.

We also don't build all of this from bare metal. fruutium runs on Google's Firebase and Cloud infrastructure, which means Google holds the data on our behalf as a processor, the same arrangement behind a large share of the apps already on your phone. We do not hand your family's data to Google for advertising, and the whitelist above blocks ad networks outright. But the servers are theirs, and you deserve to know that instead of hearing a we-own-the-whole-stack story that would not be true.

And deletion is not instant everywhere. When you delete your account, it is gone from our live database right away. The backups and low-level logs our infrastructure providers keep roll off on their own schedule over the following weeks, rather than vanishing the same second. We won't claim otherwise.

One more honest note about who "we" are. fruutium is built by a small team of high schoolers. We are explaining the mechanics in this much detail precisely because we can't hand you a famous brand or a decade of reputation. What we can do is show our work and let you check it.

Where this fits

Keeping trackers out is one reason to trust an app with your kid. Whether the app actually teaches anything is another. We looked at the evidence on that in Does Gamified Learning Actually Work for Kids?. If you are comparing options, The Best Nutrition Apps and Websites for Kids walks through how to vet any children's app for ads, tracking, and consent, including the ones we don't make.

fruutium teaches kids about nutrition, movement, sleep, and mindfulness through lessons and games a parent sets up and oversees. The core learning loop is free, there are no ads, and nothing you build in it will be taken from you. See how it works at fruutium.web.app.