Для того чтобы при выгрузке данных из CRM-систем не появлялось никаких неожиданностей, необходимо иметь представление о том, по каким принципам функционирует выгрузка и какие данные отбирает для загрузки. Скорее всего вы уже слышали про термин «инкрементная загрузка», но повторим его на всякий случай.
Инкрементная загрузка данных — это процесс добавления новых записей или обновления существующих без полной перезагрузки всей информации. В отличие от полной загрузки, где все данные из источника выгружаются и загружаются в целевую систему, инкрементная загрузка работает только с теми данными, которые изменились с момента последней загрузки.
Это значит, что когда мы выгружаем сделки из CRM за последнюю неделю, то в соответствии с принципом инкрементной загрузки мы получим только те сделки, которые были созданы или изменены за эту неделю. Если какая-то активная сделка была создана ранее, но никаких изменений в ней не происходило – в выгрузке ее не окажется.
Как вы догадались, это необходимо для оптимизации нагрузки на API CRM и других систем, участвующих в выгрузке и хранении данных. Если ежедневно запрашивать у CRM всю историю ее работы, скорее всего это приведет к скорой блокировке с ее стороны – это просто нерационально.
Если описывать грубо, алгоритм выгрузки mybi connect запрашивает у CRM список измененных сущностей за определенный период – это может быть период, выбранный пользователем для исторической загрузки, или последние 2 дня в случае автоматического ежедневного обновления БД. Существует отдельный атрибут «дата изменения», который, как правило, видно в интерфейсе, и он является «триггером» для попадания сущности в этот список в случае ее создания или внесения каких-то изменений в течение запрашиваемого периода. Далее алгоритм загрузки получает все поля и связанные сущности (информации о том, что именно изменилось чаще всего нет, поэтому выгружается всё) и либо добавляет новые строки в соответствующие таблицы этой сущности, либо сначала удаляет старые записи, а потом добавляет новые. Именно поэтому в журнале работ пользователи могут видеть как добавление, так и удаление строк.
Теперь давайте взглянем на «другую сторону монеты», а точнее, на обратный эффект данного принципа. Одним из частых обращений в поддержку является вопрос про резкий скачок расхода строк выгрузки, за которым следует и рост стоимости использования сервиса. Пользователи наблюдают перезагрузку большого количества сделок, хотя такого прироста новых нет. Причина, как правило, кроется в массовых изменениях, которые пользователи делают сознательно или бессознательно в своих CRM. Алгоритму выгрузки не важно, насколько «значимые» изменения в сделке произошли – если дата поменялась, то это повод обновить сделку. Самые распространенные примеры:
- Пользователь добавил или удалил поле для сделки или контакта – может привести к перевыгрузке всех сделок или контактов;
- Пользователь массово поменял ответственного менеджера у сделки – все эти сделки перезагрузятся. Некоторое время назад с аналогичной проблемой к нам обратился пользователь, который удалил старого менеджера из CRM – он вел сделки в 2020-ом и 2021-ом годах: из-за того что менеджер у этих сделок поменялся – все они выгрузились в БД, хотя не были нужны.
- Массовое перемещение сделок между этапами приведет к аналогичному эффекту.
- Стоит внимательно отнестись к работе внешних виджетов, пользователи сообщают что часто именно они приводят к частым изменениям и перевыгрузкам данных.
- И, наконец, беседы – вот такое объяснение получили от пользователя после его исследований в прошлом месяце, орфография сохранена:
У нас в настройках раньше стоял пункт 2 (скрин ниже) и все было ок, мы попробовали поставить пункт 3, это привело к тому, что когда клиент начинал нам писать в вазап, во все его исторические сделки прогружалась беседа, сообщения начинали двигать дату изменения по сделке. А у нас по клиентам может быть более 1000 сделок. Соответственно кол-во измененных сделок стало расти в геометрической прогрессии. Мы по итогу закрыли все беседы через сейлсбот и в настройках вернули пункт 2. Сейчас кол-во измененных сделок и расход строк пришел в норму. Отсюда вывод, что если в настройках выбирать пункт 3 и по клиентам огромное кол-во сделок, то это приводит к массовым изменениям по сделкам и космическому расходу строк.
Конечно, это далеко не полный список, только наиболее частые случаи, о которых нам сообщают пользователи. В целом, мы со стороны сервиса видим только конечный результат в виде большого количества обновленных строк и не знаем, какие именно действия пользователя в CRM привели к такому эффекту. И зачастую, к сожалению, и сам пользователь, который обращается в поддержку, занимается аналитикой и выгрузкой и не знает о каких-либо массовых изменениях, которые решили внедрить в отделе продаж.
В самих изменениях нет ничего страшного – они нацелены на позитивный эффект, как правило. Плохо, когда действия не согласованы, а их последствия неизвестны. В случае с аналитикой и выгрузкой данных это приводит к необоснованным затратам. Порядок должен быть не только в настройке и использовании CRM, но и в таких, казалось бы, мелочах.
К сожалению, мы не можем порекомендовать единственный оптимальный способ поведения, чтобы такой ситуации избежать – все зависит от ситуации. Как минимум, стоит поделиться этой информацией с ответственным за CRM, чтобы изменения были согласованы.
Если вы замечаете периодические скачки в объемах выгрузки – стоит изучить работу скриптов и виджетов, которые могут в автоматическом режиме обновлять сделки.
Если вы запланировали и ожидаете какое-то массовое изменение в виду изменения настроек CRM – мы рекомендуем отключить автоматическую и периодическую загрузку данных в течение этого дня. Далее в зависимости от ваших расходов и необходимости в отражении этих изменений в отчетах можно выгрузить данные вручную за этот день, чтобы строки были потрачены только 1 раз, а не несколько за счет повторных перевыгрузок. Другой вариант – не выгружать данные за этот день и включить автоматическую загрузку через 2 дня, в этом случае строки не будут потрачены, но и изменения не будут выгружены. Однако, с активными сделками скорее всего продолжится работа отдела продаж, они продолжат меняться в CRM и будут обновляться в БД вместе со всеми изменениями, но не массово.
Выбор оптимального решения остается за пользователем: с одной стороны, важные показатели в отчетах могут стать неактуальными, с другой стороны, потребуется больше затрат на выгрузку всех изменений. Конечно, можно порекомендовать ничего не менять в CRM, но это тоже не выход – время идет, бизнес меняется и требует изменения в процессах.
Если вы обратили внимание на перерасход строк уже постфактум, после внедрения этих изменений – если они произошли вчера, рекомендуем отключить автоматическую загрузку для завтрашнего дня и включить чуть позже. Если же вы обратили внимание на перерасход сильно позже – к сожалению, с этим уже ничего не получится сделать, строки уже были потрачены. Останется только изучить что именно привело к массовым изменениям CRM и не допускать повторений.
Будем надеяться, что вы изучите эту статью до возникновения подобной ситуации.