User agent parsing ломается не в строке UA, а в ваших допущениях о ней

User agent parsing ломается не в строке UA, а в ваших допущениях о ней

UA-парсинг нужен не для «узнать браузер», а чтобы быстро разложить трафик по платформе, движку и типу устройства. Ошибка начинается, когда библиотека считает строку стабильным идентификатором. На практике одно и то же устройство может отдавать разные UA в webview, в embedded browser и при проксировании запросов.

Смотрите на три слоя сразу:
— raw UA без нормализации;
— распарсенные поля: family, major, device class;
— согласованность с остальными fingerprint-сигналами: язык, timezone, screen, platform.

Типовые проблемы библиотек:
— устаревшие regex-таблицы режут новые браузеры в «Other»;
— мобильные браузеры маскируются под desktop-движки;
— iOS Safari и webview часто путаются;
— кастомные UA ломают классификацию, если парсер ждёт «чистую» сигнатуру.

Для трекинга важнее не идеальный детект, а стабильные правила: одинаковая нормализация на входе и в отчётах, отдельная обработка webview, логирование raw UA рядом с результатом парсинга. Иначе при разборе антифрода вы будете спорить не с трафиком, а с собственной библиотекой.

Если нужен надёжный контур, держите парсер как вспомогательный слой, а не как источник истины. Raw UA храните всегда, правила классификации версионируйте, а спорные случаи отправляйте в отдельный bucket.