On-Device vs Cloud News Personalization

On-device vs cloud personalization is a question about where one file lives, not about how clever the ranking is. Both arrangements watch what you open, update a picture of your taste, and reorder the next batch; the cards on screen can be identical. What differs is whether a copy of that picture exists on a machine you cannot reach, and therefore whether anything survives after you uninstall.

This piece is about the location of the model and the checks that reveal it. It does not benchmark recommendation quality, and it does not cover paywalls or offline reading.

What is the difference between on-device and cloud personalization?

Cloud personalization sends the signals off the handset: a server receives your opens and skips, updates a profile attached to an account or a device identifier, and returns a ranking. On-device personalization keeps the loop on the phone: the update happens in the app's own storage, and no request carrying your behavior is ever made.

Everything else follows from that one difference.

	Cloud	On-device
Where signals go	A company server	The app's own storage
Needs an identity	Usually, to persist across sessions	No
Survives uninstall	Yes, until someone deletes it	No
Can be shared with partners	Yes, by policy decision	Nothing to share
Improves a global model	Yes	No
Cold start	Warm, borrowed from other readers	Cold, yours from scratch

The right-hand column has one genuine cost, and the honest version of this argument keeps it in view: a local model starts colder and is only as durable as the handset. The left-hand column has one genuine benefit, and it is bought with a durable file about you.

What does a cloud personalization profile actually hold?

Three things: a taste profile, an identity to hang it on, and a log of raw events — this card, this timestamp, this action. The identity is the reason so many cloud products want an account before they will "make the feed yours"; without one, the profile cannot follow you between sessions, let alone between devices.

The identity does not have to be an email address. Google's guidance on user data identifiers describes the advertising ID as a resettable identifier intended for ads, and notes that since a Google Play services update in late 2021 an app that requests it after you opt out "will receive a string of zeros instead". A device identifier is enough to hang a profile on. An account merely makes it sturdier — which is why an app with no login is a start rather than a finish.

Once events sit on a machine the company controls, sharing them is a policy decision rather than a technical one. A privacy policy that says the company "may share information with service providers to improve our services" is describing that path without drawing it. Cloud profiles are cheap to keep, so they are kept. Deleting the app does not delete them; closing the account might, after a delay, if you find the form.

What does "on-device" have to mean to count?

Three conditions, all of them checkable in a policy or a store listing, and the phrase is worthless if any one of them is missing.

The learning happens on the handset. Your keeps and passes update a file in the app's own sandbox, and the next ranking is computed from it without a round-trip.

The company does not receive the signals. Not "receives them anonymized". Not "receives them aggregated". Does not receive them, because there is no server in the path for them to land on.

Deletion is local. Android's storage documentation is explicit about what that buys you: app-specific storage is a location "the system prevents other apps from accessing", encrypted on Android 10 and higher, and "when the user uninstalls your app, the files saved in app-specific storage are removed". No ticket, no thirty-day window.

On-device does not mean offline. Fetching headlines still needs a network, and opening a story still loads the publisher's page. Those requests go to newsrooms, not to a personalization backend, and the difference between the two destinations is the whole point.

Which claims get confused with on-device but are not?

Four, and they are worth naming because they are usually made in good faith by a marketing team that did not ask engineering.

• "Anonymized cloud personalization." The events still leave the phone and still accumulate in a company's database, where they can be retained, shared or subpoenaed. Anonymization is a property of a record that exists; on-device is the absence of the record.
• "We don't sell your data." Not selling is compatible with collecting, retaining and sharing with partners under a services agreement.
• "Your data is encrypted." Encryption in transit and at rest says nothing about who holds the key or how long the row lives.
• "No account required." Necessary and not sufficient. A device identifier will carry a profile perfectly well without one, which is the point of what still follows you after the login is gone.

A local model can feel every bit as pointed as a server-side one, so the feeling of being known proves nothing. The evidence is architectural: is there an account, is there a company server in the reading path, and does the policy describe a taste profile the company holds.

What can you check without reading the source code?

Four checks, in ascending order of effort. Nobody is going to hand you the model, and you do not need it.

1. Is there an account, and when is it demanded? A wall before the first headline suggests a profile meant to be durable. A local model has no use for that wall.
2. Does the app work with the network off, after a fetch? Preferences and a saved list that survive without a round-trip are stored locally. A spinner over your own settings is a tell. New stories still need a connection — that is fetching, not personalization.
3. What do the store listing and the policy say? On Android, the Data safety card declares collection, sharing and purpose per data type, and Google states that "you alone are responsible for making complete and accurate declarations" in its documentation for the form. Search the policy for server, profile and partners.
4. What happens when you delete the app? If nothing remains because nothing was sent, the model was local. If the answer is a deletion request, it was not.

Those four settle on-device vs cloud personalization for any reader on the store, including ours.

Where does GetMyNews keep its model?

On the phone, and the surrounding product is shaped by that choice. There is no account and no GetMyNews server: the handset fetches 92 public RSS feeds from 37 US newsrooms directly, so no machine of ours could train on what you open even if we wanted it to.

The model is a small set of additive weights — one per category, one per newsroom, one per topic, plus keyword affinities pulled from the headlines you kept — sitting in the app's own storage. A left swipe is weighted at 0.6 of a right swipe, because "left" is ambiguous and "right" is deliberate. Uninstalling removes the file; so does "Erase everything and start over" in Settings.

Max, the in-app assistant, is part of the same arrangement rather than an exception to it. It is a local rule parser: it reads a typed phrase, matches it against the app's own category, topic and keyword tables, and turns it into an add, boost or mute. It is not a hosted language model, and nothing you type into it is sent anywhere.

One thing does leave the handset, and describing on-device vs cloud personalization honestly means saying so. GetMyNews is free and ad-funded — a banner plus one full-screen ad about every 20 stories through Google AdMob — so its Play Data safety card declares app activity and the advertising identifier as collected and shared with Google for advertising. Your reading weights are not part of that: the only thing the app passes the ad SDK is the age bracket you chose at onboarding, and only to apply Google's teen treatment and cap the content rating for a minor. Consent is requested through Google's own form before the first full-screen ad, not at launch; declining gives non-personalized ads and gates no feature. The ad is not chosen from your taste file, because the taste file never leaves the phone — but an advertising identifier is in play, as it is in every ad-funded Android app.

If you are replacing a specific product rather than reasoning in the abstract, the account-free replacements for Google News is the practical version of this page.

FAQ

Is "anonymized cloud personalization" the same as on-device?

No. Anonymized events still leave your phone and still accumulate in a company's database, where they can be retained, correlated with other records, shared with partners or produced under legal process. On-device personalization produces no such database, which is a stronger guarantee than any promise about how carefully a database is handled. Absence is checkable; anonymization is a claim about process.

Can an on-device news app still show ads?

Yes, and most free ones do. What an on-device model changes is the input to the ad, not its existence: the ranking file that decides your next story stays on the handset, while the ad network works from the Android advertising identifier and your consent answer. An app that serves ads and claims nothing at all is measured is describing a product that does not exist.