Готовим базу компаний в Google Таблицах к импорту в CRM

Импорт базы, собранной наспех, почти всегда заканчивается одинаково: часть контактов задваивается, часть email отбивается bounce с первого письма, а сегментация приходится делать заново уже внутри CRM. Тридцать минут в Google Таблицах перед импортом экономят часы разбора ошибок после. Разбираем практикум: какими функциями нормализовать колонки, найти дубли и мусорные адреса, и как разметить сегменты так, чтобы CRM приняла базу с первого раза.

Зачем вообще готовить базу до импорта, а не чистить её в CRM

CRM умеет многое, но не умеет угадывать намерение: если в колонке с email оказался телефон, а название компании в одной строке написано «ООО Ромашка», а в другой — «Ромашка ООО», система либо отклонит запись, либо примет её как есть, размножив по факту один и тот же контакт под двумя разными карточками. Ошибки такого рода дешевле поймать глазами и функциями таблицы, пока данные ещё в понятной табличной форме, чем распутывать их потом внутри интерфейса CRM.

Есть и более практическая причина: разослать первую волну по неочищенной базе — значит гарантированно получить всплеск bounce на мусорных и мёртвых адресах в первые же минуты после старта. Для домена, который делает рассылку малыми объёмами, как в адресном B2B-аутриче, скачок bounce rate в первой волне — прямой удар по репутации отправителя, который скажется на доставляемости всех последующих писем, даже качественных.

Практикум ниже рассчитан на Google Таблицы без надстроек и плагинов — только встроенные функции, которые работают в любом аккаунте без дополнительных прав.

Шаг 1: нормализация колонок

Первая задача — привести данные к единому формату внутри каждой колонки, прежде чем что-либо искать или удалять. Название компании часто приходит в разных регистрах и с разным порядком слов организационно-правовой формы: функция ПРОПИСН или СТРОЧН приводит регистр к единому виду, а простая формула замены («ООО »&ПОДСТАВИТЬ(A2;"ООО";"")) выносит организационно-правовую форму в начало у всех строк одинаково.

Email нормализуется через СТРОЧН (домены и локальные части регистронезависимы для сравнения, но визуально должны быть в одном регистре) и ОБРЕЗПРОБЕЛЫ, которая убирает случайные пробелы в начале и конце ячейки — незаметная на глаз проблема, которая ломает сравнение на дубли и точное совпадение при импорте.

Телефоны стоит привести к единому формату вручную через формулу с ПОДСТАВИТЬ, убирающую скобки, дефисы и пробелы, оставляя только цифры с кодом страны — CRM почти всегда ожидает предсказуемый формат номера, а не как получится.

• СТРОЧН(A2) — приводит email и текстовые поля к нижнему регистру для корректного сравнения.
• ОБРЕЗПРОБЕЛЫ(A2) — убирает невидимые лишние пробелы, которые ломают точное совпадение.
• ПОДСТАВИТЬ(A2;"-";"") — нормализует телефоны и другие поля с переменными разделителями.
• ПРОПНАЧ(A2) — приводит имена и должности к единому регистру первой буквы.

Шаг 2: находим и убираем дубли

Точные дубли по email ищутся простой связкой: в отдельной колонке формула СЧЁТЕСЛИ(диапазон_email; текущая_ячейка) больше единицы отмечает все повторяющиеся строки, включая первое вхождение — это удобнее, чем встроенное удаление дублей, потому что перед удалением можно посмотреть, какая из повторяющихся строк полнее по данным, и оставить именно её, а не первую попавшуюся.

Похожие, но не идентичные дубли — частая проблема с названиями компаний: «ООО Ромашка», «Ромашка», «Romashka LLC» могут описывать одну и ту же компанию, но не совпадут ни в СЧЁТЕСЛИ, ни во встроенном удалении дублей. Здесь помогает сортировка по алфавиту с последующим визуальным просмотром соседних строк — большинство таких дублей физически оказываются рядом после сортировки по названию, и их проще заметить глазом, чем автоматизировать полностью.

После того как дубли найдены, стоит не удалять их бездумно, а решить, какую запись оставить: обычно это та, где больше заполненных полей — есть телефон, должность контактного лица, актуальный статус. Удаление менее полной записи в пользу более полной сохраняет данные, а не просто сокращает список.

Шаг 3: отсеиваем мусорные и рискованные адреса

Прежде чем база уйдёт в рассылку, стоит отфильтровать явно нерабочие или рискованные email вручную функциями таблицы, не дожидаясь bounce на реальной отправке. Формула поиска по шаблону вроде ЕСЛИ(ЕЧИСЛО(НАЙТИ("noreply";СТРОЧН(A2)));"служебный";"") находит служебные адреса типа noreply, info без указания конкретного получателя, no-reply, mailer-daemon — для адресного B2B-аутрича это не целевые контакты, а технические ящики, письмо на которые не увидит ни один человек.

Отдельно стоит проверить синтаксическую валидность email простой формулой на наличие символа @ и точки после него в домене — это не заменяет полноценную SMTP-верификацию, но отсекает очевидные опечатки вроде «ivan@gmail,com» или «ivan@company» без домена верхнего уровня ещё на этапе таблицы, до того как эти адреса попадут в кампанию.

Стоит завести отдельную колонку-статус («годен», «проверить», «удалить») и явно проходить по строкам со статусом «проверить» глазами, а не полагаться только на формулы — автоматика хорошо ловит явный мусор, но пропускает случаи, требующие здравого смысла: например, личный email в корпоративном поле или устаревший адрес сотрудника, который сменил компанию.

Шаг 4: размечаем сегменты для будущей кампании

Сегментация делается прямо в таблице отдельной колонкой с тегами — отрасль, размер компании, роль контактного лица, источник, — а не разнесением базы по отдельным листам под каждый сегмент. Один лист с колонкой-тегом фильтруется мгновенно через встроенный фильтр или сводную таблицу под любую комбинацию критериев, а разбросанные по листам данные приходится синхронизировать вручную при любом изменении.

Тегов должно быть немного и они должны быть однозначными: если критерий сегментации допускает разночтения («крупная компания» без чёткого порога), разные люди, заполняющие таблицу, разметят одинаковые компании по-разному, и сегмент потеряет смысл при импорте. Лучше заранее зафиксировать пороги — например, размер по числу сотрудников или выручке — и свериться с ними перед разметкой, а не полагаться на интуицию по ходу заполнения.

Отдельная колонка под источник контакта (открытый сайт, отраслевая база, событие, рекомендация) не связана напрямую с сегментацией под кампанию, но экономит время позже: если конверсия по одному источнику окажется заметно ниже, будет видно сразу, а не после общего разбора всей базы. То же касается даты добавления контакта — без неё сложно понять, насколько актуальны данные к моменту отправки, особенно если база собиралась не за один присест, а докупалась и дополнялась в течение нескольких месяцев.

Финальный чек-лист перед импортом

Перед выгрузкой в CRM стоит пройти таблицу по короткому списку проверок, а не полагаться на то, что предыдущие шаги отработали идеально. Обязательные поля (email, название компании) не должны быть пустыми ни в одной строке — CRM либо отклонит такие записи, либо примет с пробелами, которые потом придётся искать вручную внутри системы, что заметно дольше, чем найти их в таблице через ЕПУСТО.

Формат файла и заголовки колонок должны соответствовать шаблону импорта конкретной CRM — расхождение в названии колонки на один символ иногда приводит к тому, что поле не сматчится и данные уйдут не туда, куда нужно. Стоит свериться с шаблоном заранее, а не подгонять структуру уже после ошибки импорта.

После загрузки в LDM стоит сверить количество импортированных записей с количеством строк в исходной таблице и выборочно проверить несколько карточек на корректность разбивки по полям — типовые расхождения на этом этапе почти всегда связаны с одной из проблем, разобранных выше: неочищенными дублями, несовпадением формата колонки или пустыми обязательными полями, которые легко было поймать функциями таблицы до отправки в систему.

Имеет смысл сохранить исходную таблицу как есть, до чистки, отдельной копией рядом с финальной версией — если импорт пойдёт не так, как ожидалось, будет с чем сравнить и откуда быстро восстановить недостающие строки, не собирая источники заново с нуля.

Вопросы и ответы