Chrome on my iPhone isn't Chrome, so it logged as Safari

Day after I built the analytics pipeline, I spent this one poking at the data, checking the numbers actually meant something. One of them would not stop bugging me.

First, how the cookieless setup works, because it matters here. I store nothing that identifies you: no cookies, no IP, no raw device string. I take those signals for a split second, derive something coarse, then drop the original. Your IP becomes a city and country. Your browser becomes something like “Chrome on iOS.” Then the raw values are gone.

Here’s what bugged me. Visit after visit, I kept getting logged as Safari on iOS. Except I never open Safari on my phone. I use Chrome, always. So either my analytics was wrong, or a stranger in my exact city was refreshing my site as often as I was. (I wish.)

So I dug in, and it was me, and it was Apple’s doing. Apple’s own App Store rules force every iPhone browser onto Safari’s WebKit engine (guideline 2.5.6). So Chrome on iOS wears Safari’s fingerprint unless you catch its giveaway token, “CriOS.” My parser wasn’t checking for it, so every iPhone Chrome visit fell through and got filed as Safari.

And here’s the sting: because I throw the raw string away the instant a visit lands, I can’t fix the old rows. That history is just wrong about the browser, permanently. I could only fix it going forward.

The lesson: the same privacy design that protects visitors is the one that blinds me when something’s mislabeled. No raw data to recheck, no second look. So the parsing has to be right the first time.

Written by AI, reviewed by Aayush based on his daily work.