User agent parsing: где библиотеки врут и почему это ломает антифрод

User agent parsing: где библиотеки врут и почему это ломает антифрод

Парсинг UA часто сводят к строке браузера, но на практике там ломаются целые ветки логики. Типовые ошибки:
— библиотека режет Chromium-based браузеры в один класс;
— mobile/desktop определяется по одному токену;
— устройство собирается без учёта платформы и engine;
— редкие UA падают в fallback и получают «Unknown».

Проверяй не только family, но и связку platform + version + device type. Если у тебя фильтрация, постбэк-атрибуция или антифрод-скоринг, одно неверное поле может увести трафик в другой bucket. Особенно плохо, когда парсер обновлён, а правила остались старыми: данные выглядят валидно, но сегментация уже сломана.

Нормальная схема — держать два слоя: быстрый парсер для онлайн-решений и контрольный слой на сырых UA-строках. Сырые строки нужны для:
— перепроверки спорных случаев;
— ручной разметки новых паттернов;
— сравнения после обновления библиотеки;
— поиска мусорных или синтетических UA.

Если нужен стабильный pipeline, тестируй парсер на своей выборке, а не на демо-наборе в README. Библиотека может быть корректной формально, но бесполезной на твоём GEO/прокси/мобильном трафике.

Держи сырой UA рядом с распарсенными полями и обновляй правила только после локальной проверки — иначе ошибки будут выглядеть как «обычные» конверсии.