Валидация номера телефона: 4 метода, recall и цены

Валидация номера телефона (англ. phone number validation) — это процесс проверки телефонного номера на корректность формата, статус активности SIM-карты и наличие в коммуникационных сервисах. По глубине проверки выделяют четыре уровня: format-валидация (синтаксис), HLR-lookup (статус SIM у оператора), social-lookup (профиль в мессенджере) и reverse-lookup (ФИО владельца).

Базовый стандарт всех этих операций — ITU-T E.164, международная рекомендация по формату телефонных номеров: знак «+», код страны, национальный номер, не более 15 цифр в сумме. Все четыре метода работают с E.164 как с входным форматом. Каноническая реализация format-валидации — open-source библиотека google/libphonenumber от Google.

В практике B2C-маркетинга, антифрода и OSINT валидация — обязательный первый шаг любой работы с базой номеров. Без неё бюджет уходит на отправки в мёртвые SIM, репутация отправителя падает у мессенджера, а KPI кампании занижается из-за «шумных» данных.

• ~40%
  холодной базы — мёртвые SIM

  По нашей выборке 1.2M номеров

• 100×
  разница в цене между шагами

  Format → HLR → social → reverse

• $0.002
  минимальная цена social-lookup

  MAX через CheckMaxApp

• 100%
  recall у фирменного движка

  Если профиль публичен

Без валидации маркетолог платит CPM/CPC за пустые отправления и портит репутацию отправителя у мессенджера. Стоимость одной проверки в 100–1000 раз меньше стоимости одного «слепого» сообщения — поэтому ROI валидации почти всегда положительный.

Ниже — расширенная таблица со всеми ключевыми измерениями. Latency указан как медиана у крупных провайдеров; цены — диапазон по рынку 2026 года.

Полная статья про каждый метод: HLR-lookup, MAX и social-lookup, антифрод-стек.

На уровне API ответы разных методов отличаются принципиально. Ниже — типовые JSON-ответы, нормализованные к одному запросу +79161234567.

Format (libphonenumber)

{
  "input": "+7 916 123-45-67",
  "valid": true,
  "e164": "+79161234567",
  "country_code": 7,
  "country_iso": "RU",
  "number_type": "MOBILE",
  "national": "9161234567"
}

HLR-lookup (Twilio Lookup V2, упрощённо)

{
  "phone_number": "+79161234567",
  "valid": true,
  "line_type": "mobile",
  "carrier": {
    "mobile_country_code": "250",
    "mobile_network_code": "01",
    "name": "MTS",
    "type": "mobile"
  },
  "active": true,
  "roaming": false
}

Social-lookup (CheckMaxApp /v1/check)

{
  "phone": "+79161234567",
  "is_registered": true,
  "messenger": "max",
  "profile": {
    "first_name": "Иван",
    "last_name": "Петров",
    "bio": null,
    "last_seen_bucket": "today"
  },
  "checked_at": "2026-05-22T09:14:21Z"
}

Format-валидация — это первый и самый дешёвый шаг. На Python используют библиотеку phonenumbers — официальный Python-порт google/libphonenumber. Установка: pip install phonenumbers.

import phonenumbers
from phonenumbers import (
    NumberParseException, is_valid_number,
    format_number, PhoneNumberFormat, region_code_for_number,
    number_type, PhoneNumberType,
)

def validate_e164(raw: str, default_region: str = "RU") -> dict:
    try:
        parsed = phonenumbers.parse(raw, default_region)
    except NumberParseException as exc:
        return {"valid": False, "error": str(exc)}

    if not is_valid_number(parsed):
        return {"valid": False, "error": "invalid"}

    return {
        "valid": True,
        "e164": format_number(parsed, PhoneNumberFormat.E164),
        "country_iso": region_code_for_number(parsed),
        "country_code": parsed.country_code,
        "is_mobile": number_type(parsed) == PhoneNumberType.MOBILE,
    }

# usage
print(validate_e164("+7 916 123-45-67"))
# -> {'valid': True, 'e164': '+79161234567',
#     'country_iso': 'RU', 'country_code': 7, 'is_mobile': True}

После format-валидации передаёте чистый E.164 в HLR и social-lookup. Не делайте платный lookup для номеров с format-ошибкой — это пустые запросы и потерянный бюджет. Аналогичные библиотеки есть для Java, JS/TS (libphonenumber-js), Go (nyaruka/phonenumbers) и Ruby (phony).

Универсального «один метод на всё» не существует — нужная комбинация зависит от бизнес-задачи. Ниже — пять типовых стеков, отлаженных на проектах наших клиентов.

На анонимизированной выборке 1.2 млн номеров из B2C-баз клиентов CheckMaxApp мы получили следующую структуру по уровням валидации:

Главный вывод: ~40% холодной базы — мёртвые номера. Если вы льёте рассылку без валидации, треть бюджета уходит в пустоту, и это до учёта «активных-но-не-в-MAX» (≈21% разрыв между HLR и social-lookup).

Бенчмарк recall у social-lookup сервисов

Контрольная выборка 5 000 номеров с заведомо известным статусом (зарегистрирован в MAX / нет):

Recall (полнота) — доля действительно зарегистрированных профилей, которые сервис нашёл. Формально: recall = TP / (TP + FN), где TP — найденные положительные, FN — пропущенные положительные.

Для маркетолога recall = «сколько денег я недозаработаю». Если в моей базе 100k номеров и реальная penetration MAX 70%, то у меня 70k потенциальных читателей. Сервис с recall 70% найдёт только 49k из них — 21k живой аудитории я просто не увижу, не отправлю им сообщение и не получу конверсию. На дистанции это десятки тысяч долларов разницы.

CheckMaxApp гарантирует recall=100% благодаря фирменному движку проверки — мы не зависим от сторонних REST-API мессенджера и не теряем номера на rate-limit. Технические детали — в материале «100% accuracy engine», а как это влияет на last seen — в «Что такое last seen в MAX».

В российской юрисдикции валидация попадает под закон 152-ФЗ «О персональных данных». Ключевые ограничения:

• Format-валидация — не персональные данные, разрешена без согласия.
• HLR — не персональные (только статус SIM), но требует договор с оператором/агрегатором.
• Social-lookup — публичный профиль (имя, last seen) формально не «персональные данные», но требует уведомления Роскомнадзору при массовой обработке.
• Reverse — требует правового основания (расследование, KYC, согласие).

Подробный разбор — в отдельной статье про 152-ФЗ. Технический формат номеров стандартизирован в RFC 3966 (URI for telephone numbers) и упомянутом выше ITU-T E.164.

• Что такое валидация номера телефона простыми словами?+

  Валидация номера телефона (англ. phone number validation) — это процесс проверки телефонного номера на корректность формата, активность SIM-карты и наличие владельца в коммуникационных сервисах. Минимально это синтаксический разбор по стандарту ITU-T E.164, максимально — обогащение профилем владельца из мессенджеров.
• Зачем валидировать номер, если он уже в E.164?+

  Format-валидация лишь проверяет синтаксис: правильная ли длина, разрешённый ли префикс оператора, корректный ли код страны. Она не отвечает на ключевые бизнес-вопросы: активна ли SIM сегодня, существует ли владелец, пользуется ли он мессенджером MAX/Telegram/WhatsApp. Для этих ответов нужны HLR и social-lookup.
• Какой метод выбрать для маркетинга в мессенджерах?+

  Для рассылок в мессенджеры — social-lookup. Например, CheckMaxApp (Max Checker) для MAX, Telegram API для Telegram, WhatsApp Business для WhatsApp. Для голосового обзвона — связка format → HLR. Для холодного email phone-валидация не поможет, нужны email-валидаторы (NeverBounce, ZeroBounce, Kickbox).
• Можно ли совмещать несколько методов валидации?+

  Да, и часто это обязательно. Каноническая последовательность: format → HLR → social-lookup. Это даёт три уровня уверенности: «синтаксис ок», «активная SIM», «реальный человек в мессенджере». Каждый следующий уровень в 10–100 раз дороже предыдущего, поэтому отсев на ранних шагах экономит бюджет.
• Reverse phone lookup — это то же самое, что валидация?+

  Нет. Reverse phone lookup — это получение информации о владельце по номеру (ФИО, адрес, паспортные данные). В РФ массовый reverse часто построен на серых базах и попадает под 152-ФЗ. CheckMaxApp возвращает только публичный профиль из мессенджера MAX (имя, фамилия, BIO), что юридически устойчивее и безопаснее.
• Что значит «recall» в контексте валидации номеров?+

  Recall (полнота) — доля действительно зарегистрированных профилей, которые сервис нашёл. Если в базе 100 реальных пользователей MAX, а сервис вернул 70 «зарегистрирован», recall = 70%. CheckMaxApp даёт recall=100% благодаря фирменному движку проверки — если профиль в MAX публичен, мы его обязательно вернём. Подробности — в материале «100% accuracy engine».
• Что такое стандарт E.164 и зачем он нужен?+

  ITU-T E.164 — международный стандарт нумерации, описывающий формат телефонных номеров: знак + (плюс), код страны (1–3 цифры), национальный номер (до 15 цифр всего). Пример: +79161234567. Все системы валидации работают с E.164 как с каноническим форматом — приведение к нему первый шаг любой обработки.
• Бесплатно ли можно валидировать телефонные номера?+

  Format-валидация — да, через open-source библиотеку Google libphonenumber (бесплатно, MIT/Apache 2.0 лицензия). HLR и social-lookup всегда платные, потому что требуют интеграции с операторами или мессенджерами. Самые дешёвые цены: HLR от $0.001, social-lookup для MAX от $0.002 у CheckMaxApp.
• Как валидация связана с антифродом?+

  На этапе регистрации валидация отсеивает виртуальные номера (VoIP), номера в нетипичных странах, неактивные SIM. Сильный антифрод-стек: libphonenumber → HLR (с флагом VoIP) → social-lookup (нет в мессенджере — подозрительно) → SIM-swap check (для финтеха). См. /use-cases/antifraud.
• Можно ли валидировать через REST API?+

  Да, у всех серьёзных сервисов есть REST. У CheckMaxApp — /v1/check (single) и /v1/batch (bulk до 10k номеров за запрос). У libphonenumber есть REST-обёртки (numverify.com, abstractapi.com). У Twilio Lookup V2 — единый REST endpoint, в котором можно запросить и формат, и оператор, и carrier info.
• Хранятся ли проверенные номера на сервере?+

  У CheckMaxApp — нет. Мы храним только хэш номера и факт проверки для биллинга, исходные E.164 не сохраняются после ответа клиенту. У некоторых конкурентов есть «история проверок» — обращайте внимание на это при выборе под GDPR/152-ФЗ. Подробнее — на /security и /privacy.
• Сколько времени занимает валидация большой базы?+

  Через CheckMaxApp batch API: 100k номеров ≈ 8–15 минут, 1M ≈ 1.5–2.5 часа. Бутылочное горлышко — не наша инфраструктура, а rate limits мессенджера. Для срочных проектов мы поднимаем pro-tier с увеличенным троттлингом по договорённости. См. /pricing и /api.
• Как часто нужно перевалидировать уже очищенную базу?+

  Оптимум — раз в 30 дней. За месяц 4–7% базы меняет статус: новые SIM регистрируются в мессенджерах, забытые номера уходят в неактивность, last seen дрейфует. Более частая валидация (раз в неделю) даёт прирост дельты <1% и ROI отрицательный. Более редкая (60+ дней) приводит к деградации hit-rate на 10–15%. Исключения: горячие лиды с трафика валидируются в real-time, реактивация старой базы — непосредственно перед запуском кампании. Полный разбор циклов для outbound — [тут](/blog/call-center-database-cleaning).
• Что делать с номерами, которые вернули `not_found` — выкидывать?+

  Нет. Стандартная политика: понизить приоритет, но оставить в ротации, и повторно валидировать через 30 дней. Причины: (1) свежие SIM (<14 дней) ещё не успели зарегистрироваться, (2) корпоративные АТС объективно `not_found` (это нормально), (3) сезонные колебания ±3–5% (декабрь–январь, август). Удалять имеет смысл только после 2–3 циклов `not_found` подряд и нулевой реакции на дозвоны или сообщения. Этим вы сохраняете 12–15% базы, которая в моменте не активна, но оживёт в течение квартала.

• github.com/google/libphonenumber — каноническая библиотека format-валидации (Apache 2.0).
• Twilio Lookup V2 API docs — индустриальный референс по HLR/carrier-lookup.
• ITU-T E.164 — международный стандарт нумерации.
• RFC 3966 — URI-формат для телефонных номеров (tel: scheme).

Автор материала: Max Checker Team, обновлено 22 мая 2026. По вопросам и опечаткам — пишите в поддержку.