When you click into the detail view of individual segments, what’s the little stars icon for? It seems to get rid of a lot of the individual segments, but what is it actually doing?
Also, why do some entries have only a couple of blue dots on the map, while others have dozens? Are those each an individual segment? How does the app decide to break up segments?
Good questions! Two related things going on:
The stars (
) icon — “Cleanup samples.” Each visit or trip is built from lots of individual location readings, and each reading carries its own guess at what you were doing (walking, stationary, driving…). Those guesses can be noisy — a stop picks up a few stray “walking” readings, or a walk gets the odd “stationary” one — and that noise is what chops one stop or trip into lots of little segments.
Tapping the stars button tells Arc “this whole thing really was just a stay / a walk / a drive”: it confirms the readings to match, marks any stray outliers as bogus, and reprocesses. A segment is just a run of consecutive readings of the same type, so cleaning up the noise collapses all those fragments back into one (or a few) clean segments. As a bonus, those confirmations also feed Arc’s on-device activity-type learning, so it gets a little better at similar situations next time.
The map markers + segments. Good instinct — yes, those are the individual segments themselves. A couple of them means the period stayed clean and consistent; lots of them means it got chopped into many little segments because the activity type kept changing from one reading to the next (walk → stop → walk shows as three). So a “noisy” stretch ends up with lots of segments — which is exactly what the Cleanup button collapses back down.
Hey @claude .
But why does “Cleanup samples” so often stop working, even though there’s clearly still work to be done? For example, a series of stationary segments with a duration of 0 seconds (first screenshot).
To clarify: I parked my bike during the first stationary event, which took a few minutes, and then walked into the building (second screenshot).
Even hearth rate and trip speed suggesting a different kind of activity:
Now for the really interesting part: Even according to Arc’s own metrics, every incorrectly classified cycling segment is more likely to be walking or stationary instead (see the following five screenshots). However, Arc seems to favor previous activities instead. Why?
I noticed this as well. Most of my trips are by car, so many trips ends up being classified as car even when the speed and duration suggest otherwise. I also had some situations where after a flight, some walking/bus trips at the destination were classified as airplane.
Hey @midor — genuinely good detective work, and your reading of the metrics is right as far as it goes. There are two internal details you couldn’t see from the outside, and together they explain everything — including why the cleanup button “gives up.”
1. Cleanup never overrides a sample you’ve already confirmed. It only touches unconfirmed samples (in a visit it sets those to stationary), and deliberately leaves confirmed ones exactly as you set them — by design, so a cleanup tap can’t quietly undo your own corrections. So the button isn’t failing; it’s refusing to touch confirmed samples.
2. Those cycling segments are confirmed. When that ride became Cycling — whether you changed its type or ran cleanup on it — every sample got stamped confirmed-cycling, except ones that were confidently stationary, which are deliberately spared. Those spared samples are almost certainly the little 0-second “Stationary” blips you see surviving between the cycling runs — not leftover work, but genuine still-moments the system protected.
The part you couldn’t have caused yourself: some samples from the end of the ride — where you’d parked and walked in — were pulled into the adjacent visit automatically as Arc tidied the trip/visit boundary (edge-stealing; if you’d moved them they’d already be stationary). They arrived carrying their confirmed-cycling stamp, and the visit’s cleanup can’t override it. That’s also why “Arc favours previous activities”: the per-type scores you’re seeing (normalised to 100 — Walking 63, Cycling 3) are the raw classifier’s opinion, but a confirmed type always wins over it.
So your analysis was spot-on — the only invisible pieces were the confirmed-vs-unconfirmed rule and the stationary-preservation behind it.
@lmpinto — two different mechanisms here:
Car where the speed/duration seem wrong. Arc’s activity models train on your own confirmed history, per local area — so a car-heavy history nudges ambiguous trips toward car, most of all in newer or less-travelled areas where there’s little local data and the call leans on your broader (also car-heavy) regional model. The lever is confirming the mislabelled ones; each correction trains the local model to do better there.
Walking/bus after a flight reading as airplane. Most likely the post-landing leg got bundled into the same timeline item as the flight, so the item’s single overall type shows as airplane (the dominant type wins the item’s label) even though the walking/bus underneath is classified fine. Bus has an extra trap near airports: the local model there is full of taxiing-aircraft data, which in the raw signals (speed, accelerometer) looks a lot like a bus — so a bus leg in that area is easily pulled toward airplane.
If you’d rather keep them split: before confirming, find the brief stop at the arrival gate and extract it as its own visit with a place on it (a private “Gate” or “Arrivals” works if Google Places lacks one) — that makes the short stop “stick” rather than be absorbed, splitting the one item into flight → visit → walk. (If you’re instead seeing individual walking samples themselves tagged airplane in the per-segment view, that points elsewhere — but the bundled-item explanation is the likelier one.)
@lmpinto Just adding to what @claude said there, I often see something similar to what you describe at airports, after arriving. What I’ll see is the time at arrival gate then walking into the airport getting all bundled together into a single item, when really it should be three separate ones (eg airplane → gate → walking).
So I personally deal with that by going into that single trip item’s segments view and extracting out the stationary bit at the gate to a “Gate 123” place I’ve added. (I’ve got a whole bunch for various airports! Occasionally actually interesting to see the visit counts for each).
That then ensures that confirming the airplane item won’t clobber the walking samples on entering the airport.
Oh there’s also a curious data quirk on arrival at airports. For some reason the stationary data inside the airplane at the gate is often terrible quality, jumping all over the place. This is I suspect why the items often get merged together, instead of there already being a clean visit for the gate.
My hunch is that it’s a combination of the GPS/GNSS out the airplane windows worsening due to not being near the windows anymore while prepping to get off the plane, and also the airport’s wifi hotspots jostling for attention, putting wifi hotspot triangulation into play. It almost always results in a complete mess of data on my phone, for those few minutes.
@matt Yes, I also had experienced the airport transition situation. What I did find strange that at the time, the wrong labeling persisted for some days after arriving. I corrected most of the items, but I was able to find one still wrong. This is on 1.3.3, but with data imported from the old Timeline app:
Is this perhaps the same situation with my “wrong” car trips? If the classifier cannot determine what is happening, it uses some “default” activity: at home, “car”, after a flight, “airplane”. I’m not sure, perhaps leaving the samples “unknown” would be a better approach?
In any case, I understand that I need to confirm samples for the local model to get better results. I have started to do this more regularly, but I am still getting some unexpected results. For example, I have for some months been confirming my usual daily trips, but I still got something like this yesterday:
This is at home, where the GPS is very noisy.
I know that the goal is for the classifier to learn that this is noise, but will it learn eventually? Considering that I have 4 years of data history, which I wasn’t very diligent cleaning up, is this affecting the process?
I have some ideas that would address this use case, but I am not sure if they would be worth the added complexity.
A dedicated “home place” feature, with an explicit “arrived”/“leaving” button, would probably be the ideal solution. However, it does not really fit with the app’s “turn it on and forget it” philosophy.
Another approach could be a multi-select confirmation workflow: I could select all visits that I know belong to the same location, and the app could automatically merge the periods between them into one stationary activity.
@lmpinto — good questions, and there are really two different things tangled together here, so let me pull them apart.
The mislabelled trip. This one I can’t fully pin down from the screenshot alone — it’s the kind of case where we’d need a bit more to be sure. The likeliest story: in an area where Arc has relatively little confirmed history from you, an ambiguous stretch (and yours looks like mixed ground movement, some of it at vehicle speeds) ends up leaning on Arc’s coarser, region-wide models — and if your wider-region history is flight-heavy, those can tug it toward airplane. So the useful thing to know: is that part of NYC somewhere you spend a lot of time with plenty of confirmed trips, or more of an occasional/arrive-and-leave place? That tells us whether the local model there has much to go on. Either way, correcting those segments is the lever — each correction teaches the model for that area — and the gate-extraction trick from earlier keeps flight and walk cleanly split when they do get bundled at an actual airport.
Your read that “it falls back to a default” is close, with one tweak: there’s no fixed default. It’s the dominant pattern of your own history in that area winning the ambiguous calls — car around home, airplane near the airport. Same mechanism, two different areas; the classifier always settles on its best guess for each sample, so the useful move is improving that guess rather than there being an “undecided” state to leave it in.
The home examples are a different beast entirely — that’s not misclassification, it’s GPS drift. Those short “trips” (a 290 m, 21-minute one at 0.8 km/h; a 32 m, 52-second one) are your phone’s reported position wandering while you’re actually sat still — and the “Car” label is just that same dominant-pattern by-product riding on top. The real issue is they’re being recorded as trips at all. Arc has a system that learns each place’s drift signature and suppresses it — but it can only learn from samples that are inside the visit for that place. Right now those drift samples are sitting outside it, as separate trip items, so the system never sees them. The fix is to clean them up: convert them to stationary and assign them to your home place, which folds them into the visit — and that’s exactly what feeds the drift learning, so it gets better at swallowing that noise there over time. You can actually watch this happen: Settings → Debug Info has a Drift Profile section showing the learned profile for whatever place you’re currently in (sample count, average/max drift, a per-direction breakdown) — so at home you can see it fill out as you tidy those up. (How are you handling them at the moment — just changing the type, or converting to stationary and assigning the place?)
On whether your 4 years of un-cleaned history is holding it back — it isn’t. The activity models only learn from samples you confirm, and the drift system only from samples inside your visits, so the old un-tidied stuff is simply inert, not poisoning anything. What moves the needle is the cleanup you do from here: confirming the mislabelled trips, and folding the home drift into the right visit.
For the short ones, I change to stationary and assign to the home place. For the longer ones, I sometimes split them and mark the farther points as bogus; should I keep doing this, or is it better to leave them as they are to help build the drift profile?
@lmpinto — good news: what you’re already doing is right, and there’s no trade-off to worry about. Both approaches keep those samples inside the home visit, and the drift profile learns from whatever’s inside the visit — so marking the far ones bogus feeds it just as much as making the near ones stationary. You’re not starving the profile either way.
Two mechanics that should reassure:
So keep doing both — stationary for the near ones, split + bogus for the far ones, whichever feels right per spot. As long as they end up inside the visit, the profile’s learning from them.
