AgTech без хайпа: как мы строим систему, которая доводит агронома от симптома на поле до решения

Автор: Олег Линьков, Webformula (webformula-agro.ru ^[1])

Агросектор — одна из самых недооценённых ниш для прикладного AgTech. Здесь нет хайпа вокруг LLM на каждом шагу, зато есть жёсткие ограничения, которые делают задачу интересной с инженерной точки зрения ^[2]: сезонность с точностью до недель, географическая распределённость, аудитория с низкой толерантностью к нерелевантному шуму и предметная область, где ошибка ^[3] в данных стоит реального урожая.

Я двенадцать лет занимаюсь digital в агро и последние годы — построением систем, которые работают на стыке предметной агрономии и продуктовой инженерии. В этой статье — без маркетинга, только архитектура и продуктовая логика ^[4] — разберу, как устроены три вещи: автоматизация сезонности в рекламных кампаниях, система поддержки решений (DSS) как алгоритмическое дерево, и триггерные коммуникации на базе погодного API. И почему в этой нише источник данных важнее модели.

Часть 1. Как мы автоматизировали сезонность

Проблема: спрос — это функция от региона и фенофазы

Наивная модель рекламной кампании — «крутим равномерно весь сезон». В агро она ломается о то, что спрос здесь не константа, а функция от двух переменных: региона и фазы развития культуры.

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

Решение: кампания как объект с временным окном и регионом

Мы перешли от плоской структуры к модели, где базовая единица — не «кампания вообще», а связка (продукт × регион × временное окно). Каждая такая единица имеет дату активации и деактивации, привязанную к фенологическому календарю региона, а не к календарным месяцам.

Принцип декомпозиции, который оказался критичным для аналитики: одна сущность = один продукт = одна посадочная страница. Это даёт атрибуцию на уровне отдельного препарата — видно, какой продукт в каком регионе конвертит, и можно перераспределять бюджет на основе данных, а не интуиции ^[5]. Альтернатива — агрегированная кампания, из которой невозможно вынуть per-product метрики — это потеря наблюдаемости системы.

Структурно это похоже на feature flags с расписанием: каждая (продукт × регион)-единица включается и выключается по своему триггеру, а оркестрация следит за тем, чтобы бюджет перетекал от закрывающихся окон к открывающимся. Бюджет в системе — не статическая смета, а поток, который следует за фронтом фенофаз, идущим с юга на восток.

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

При этом бюджетом управляют не один, а два контура с разным горизонтом:

• Макро-контур (GDD). Сумма активных температур говорит, что фенофаза наступила и окно применения препарата открылось. Это открывает кампанию в регионе на 2–3 недели — горизонт самого окна.

• Микро-контур (spray weather). Внутри открытого окна погодный API проверяет условия день в день: ветер выше ~5 м/с снесёт препарат, дождь смоет — в такие дни техника в поле не выйдет физически. Оркестратор ставит открутку бюджета на паузу в дни, когда обработка невозможна, и возобновляет, когда погода позволяет. Зачем платить за показы рекламы препарата сегодня, если трактор всё равно не выедет?

Этот второй контур — то, что обычно упускают: макро-окно говорит «пора в принципе», микро-окно — «можно именно сегодня». Бюджет кампаний сдвигается по карте динамически — по факту наступления фазы и с поправкой на погоду опрыскивания, а не по дате в плане.

Лучший визуальный пруф такой системы — дашборд с картой, где граница «окна применения» продукта физически движется по регионам во времени. Это наглядно показывает, что сезонность не настроена руками, а оркестрируется единым движком.

Наблюдаемость: что мы логируем и зачем

Ключевая метрика качества трафика в сети — процент отказов по площадкам. Здоровый диапазон — до 40–45%; выше — сигнал, что часть инвентаря мусорная (дешёвые мобильные приложения, кликбейт-сайты). Мы держим автоматизированный pipeline чистки: регулярный отчёт по площадкам → фильтр по условию показы > N AND целевые_действия = 0 AND отказы > threshold → добавление в блок-лист. Это рутинная операция, которую имеет смысл автоматизировать, а не делать руками раз в квартал.

Отдельная тема — корректность событий в аналитике, и здесь кроется самый дорогой баг ниши, чисто инженерный по природе.

Баг, который дороже всех: цель на показ вместо отправки

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

Дальше включается обратная связь, которая делает проблему хуже: алгоритм оптимизации рекламной площадки обучается на этом событии и начинает приводить трафик, максимизирующий именно показы формы — то есть людей, которые открывают и уходят. Метрика растёт, бизнес-результат стоит. Классический case оптимизации не той функции (proxy metric вместо true objective).

Правильная событийная модель — три раздельных события с разной семантикой и ценностью:

form_view        → ценность ~0   (показ формы)
form_input_start → low           (начал заполнять)
form_submit_ok   → target        (успешный сабмит, подтверждённый бэкендом)

Оптимизатор должен обучаться строго на form_submit_ok, желательно с серверной валидацией события (server-side), чтобы исключить накрутку клиентских срабатываний. Это базовая гигиена событийной аналитики, но в агро-проектах она нарушена примерно в половине аккаунтов, которые мы аудировали.

Часть 2. DSS как алгоритмическое дерево

От лид-формы к decision support

Стандартный паттерн лидогенерации — «email в обмен на PDF» — в B2B-агро имеет околонулевую конверсию: профессиональная аудитория не отдаёт контакт за брошюру. Рабочая альтернатива, которую отработали на агрорынках Индии и Бразилии, — заменить пассивную форму на интерактивный инструмент, который решает прикладную задачу пользователя. Это класс систем DSS (Decision Support System).

Важный для инженеров тезис: DSS не обязан начинаться с ML. Большинство полезных кейсов — это детерминированное дерево решений, формализующее экспертную логику агронома. ML (компьютерное зрение для диагностики по фото) — это верхний уровень, к которому переходят, когда накоплены данные и есть метрики, оправдывающие сложность.

Архитектура MVP: decision tree

Базовый определитель проблемы и подбора препарата — это конечный автомат / дерево решений:

root
 ├─ культура?
 │   ├─ пшеница
 │   │   ├─ симптом? (пятна на листе / налёт / ...)
 │   │   │   ├─ бурые пятна → [фаза?] → рекомендация: фунгицид X (норма, срок ожидания)
 │   │   │   └─ ...
 │   └─ ...

Узлы — вопросы, рёбра — ответы, листья — рекомендации с привязкой к регламенту. Реализуется как декларативная структура (JSON/YAML с правилами) + интерпретатор. Никакого обучения ^[6], полная детерминированность и объяснимость — что для предметной области с ценой ошибки в виде потерянного урожая критично: пользователь и регулятор должны видеть, почему выдана конкретная рекомендация.

Но навигация от корня «Пшеница → Лист → Пятна» не должна быть единственным входом. Опытный агроном не хочет кликать пять верхнеуровневых вопросов — он уже знает, что у него ржавчина, и хочет сразу туда. Поэтому поверх дерева нужен полнотекстовый поиск как шорткат: нечёткий поиск (fuzzy matching) или простой векторный поиск по базе вредных объектов. Пользователь пишет «ржавчина» — система перебрасывает его сразу на нужный узел в середине дерева (deep link), минуя верхнеуровневые ветвления. Дерево остаётся способом структурировать логику и вести новичка, а поиск даёт прямой доступ к узлу для того, кто знает, что ищет. Это два входа в один граф, а не два разных интерфейса.

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

Нормализатор данных: главная грязная работа

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

• Норма расхода «0,2–0,4 л/га» — это диапазон или два правила? В регламенте за разными концами диапазона часто стоят разные условия (тип почвы, степень засорённости, фаза). ETL-слой должен не схлопывать диапазон в число, а сохранять его с привязкой к условию применения.

• Баковые смеси и совместимость — отдельная сущность со своими ограничениями, которую нельзя вывести из карточек отдельных препаратов.

• Привязка к фазам. Мы тегируем регламенты по шкале BBCH, чтобы движок мог отсекать рекомендации, которые физически невозможно выполнить в текущую дату: если культура уже прошла фазу, в которую разрешён препарат, лист дерева для неё гасится. Без этого DSS будет советовать обработку, которую уже поздно делать.

Иными словами, между «источником истины» и «деревом решений» стоит ETL-pipeline нормализации, и качество всей системы определяется именно им. Это не вспомогательный скрипт, а полноценный слой.

Версионирование данных: Госкаталог — живой документ

Источник истины не статичен. Регистрации препаратов отзывают, нормы и сроки ожидания меняют, появляются новые культуры. Если ETL отработал один раз и забыл — вчерашняя легальная рекомендация сегодня превращается в нелегальную, а система этого не замечает. Это недопустимо в нише с юридической ответственностью.

Поэтому ETL работает не в режиме разового парсинга, а в режиме отслеживания дельт (diff): периодический разбор Госкаталога → сравнение с предыдущей версией → реакция ^[7] на изменение. Но реакция не должна быть слепо-радикальной. Соблазн «нашли diff — каскадно снесли все листья с этим препаратом» опасен: изменение нормы расхода с 0,2 на 0,15–0,2 — это тоже diff, но он уточняет рекомендацию, а не делает её нелегальной. Рубить пол-дерева из-за уточнения или опечатки регулятора нельзя.

Правильный паттерн — Human-in-the-loop через Review Queue. При обнаружении дельты ETL не трогает прод автоматически, а переводит затронутые узлы в статус Needs Review и формирует очередь задач для агронома-эксперта. До апрува система ведёт себя по типу изменения: при некритичном уточнении продолжает отдавать старую, ещё валидную версию ветки (grace period), при потенциально опасном (отзыв регистрации) — временно скрывает только затронутый препарат, не ломая остальные ветки.

Но тут возникает бутылочное горлышко: перед сезоном Минсельхоз может выкатить обновления по сотням препаратов разом, и агроном просто захлебнётся в Review Queue, а система встанет. Поэтому перед очередью стоит Triage-слой, сортирующий дельты по критичности:

• Breaking changes (отзыв регистрации, запрет культуры, изменение класса опасности) отрабатывают автоматически и мгновенно — затронутые листья снимаются с выдачи без ожидания человека. Здесь безопасность важнее точности: лучше временно убрать валидную рекомендацию, чем секунду отдавать нелегальную.

• Soft changes (уточнение нормы расхода, расширение списка вредителей, косметические правки формулировок) уходят в Review Queue к агроному в штатном порядке.

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

Верификация ввода: «бурые пятна» у всех разные

Слабое место любого дерева на словесных симптомах — субъективность ввода. «Бурые пятна» новичок и эксперт классифицируют по-разному, и текстовая навигация легко заводит в неверную ветку. Два механизма, которые это смягчают:

• Фото-эталоны на узлах. На каждом шаге выбора симптома показываем эталонное изображение из справочника вредных объектов — пользователь сравнивает своё поле с картинкой, а не интерпретирует абстрактную формулировку. Резко снижает ошибку ввода.

• Контрольные уточняющие вопросы вместо одного: не «бурые пятна?», а серия дизъюнктивных признаков — «есть ли налёт на нижней стороне листа?», «какая форма края пятна — резкая или расплывчатая?», «есть ли хлоротичный ореол?». Это превращает один субъективный выбор в пересечение нескольких более объективных признаков и повышает точность ветвления.

Negative constraints: запреты важнее рекомендаций

Для защиты урожая обратные правила часто критичнее прямых. Дерево должно нести не только «применить X», но и слой ограничений-исключений:

constraint: NOT apply(препарат_X) IF температура > 25°C
constraint: NOT mix(препарат_X, препарат_Y)
constraint: NOT apply(препарат_Z) IF фаза > BBCH_N

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

Но самый сложный и самый важный constraint — антирезистентная ротация химических классов (FRAC/HRAC). Дерево, построенное только на связке «симптом → препарат», физически опасно для поля. Если DSS дважды за сезон посоветует препараты с одним механизмом действия, патоген или сорняк выработает резистентность — и защита перестанет работать на годы вперёд, причём на всём севообороте. Чтобы этого не допустить, у системы должна быть память ^[8] об истории обработок поля. Логика такая:

constraint: NOT recommend(препарат) IF chem_class(препарат) ∈ history(поле, текущий_сезон)

Если месяц назад на этом поле применялся, скажем, стробилурин (FRAC группа 11), движок обязан заблокировать в текущей выдаче все препараты этого класса — даже если по Госкаталогу они идеально подходят под симптом. Система должна предложить препарат другого механизма действия для ротации. Без этого DSS своими же руками плодит резистентные популяции — то есть приносит вред под видом помощи. Именно здесь связка «симптом → препарат» превращается в «симптом + история поля → препарат с учётом ротации», и именно это отличает агрономически грамотную систему от наивного определителя. Заметьте: этот constraint требует той самой сущности «поле» с историей, о которой ниже, — без неё антирезистентная логика невозможна в принципе.

No-code для агрономов: кто на самом деле пишет правила

Главный архитектурный принцип масштабируемости: дерево решений не захардкожено в коде — оно вынесено в управляемый агрономами слой. Инженер строит движок-интерпретатор, а правила (узлы, ветвления, рекомендации, ограничения) задаёт агроном-эксперт через админку — по сути, предметный DSL или визуальный конструктор. Это развязывает две роли: разработчику не нужно понимать фитопатологию, агроному не нужно уметь программировать. Без этого разделения система не масштабируется — каждое изменение регламента превращалось бы в задачу для разработчика, а их сотни за сезон.

Но свобода редактирования графа экспертом — это прямой путь к логическим тупикам. Агроном добавил запрет на баковую смесь — и половина веток повисла: дойти до листа стало невозможно. Поэтому конструктор обязан иметь защиту от дурака на уровне архитектуры, и решается это через CI/CD для дерева решений. Каждое изменение правил в админке запускает синтетические тесты — по сути, unit-тесты для графа:

• отсутствие висячих узлов (dead ends) — из каждого узла есть путь хотя бы к одному валидному листу;

• достижимость листьев — нет рекомендаций, к которым невозможно прийти ни по одной ветке;

• непротиворечивость запретов — negative constraints не блокируют все пути разом, не конфликтуют между собой.

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

Слой данных как главный актив

Здесь ключевой архитектурный вывод ниши: в AgTech источник данных важнее алгоритма. Точное дерево решений поверх выверенной базы регламентов даёт больше ценности, чем красивая ML-модель поверх непроверенных данных. Мы держим структурированную базу вредных объектов и регламентов (болезни, вредители, сорняки, привязка к препаратам, нормам, фазам BBCH) — и именно она, а не интерфейс, является ядром системы. Контентный SEO-актив и движок DSS питаются из одного источника данных: то, что для поисковика выглядит как статья, для DSS — это узлы и листья дерева.

Эволюция ^[9] к ML выглядит так: накапливаем размеченные данные (фото поражений + подтверждённые диагнозы) через тот же детерминированный инструмент → когда датасет достаточен, добавляем CV-модель для распознавания по фото как ещё один способ войти в дерево (вместо ручного выбора симптома — классификация изображения). Дерево решений и валидация по регламенту остаются; меняется только способ навигации к узлу.

Часть 3. Триггерные коммуникации на погодном API

Логика: фенология и погода как источник событий

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

Архитектура триггерной рассылки:

[Погодный API] --polling--> [Rule Engine] --event--> [Notification Service] --> [Telegram Bot API]
       |                          |
   гео-данные              правила риска
   по регионам         (модели по культурам)

• Источник: API погодного сервиса, опрос по гео-сегментам (регионы/районы присутствия аудитории).

• Rule Engine: правила вида if влажность > X AND температура ∈ [T1,T2] в течение N часов → риск(септориоз) = high для региона R. Но пороговые эвристики if T > X — это нижний уровень. Реальная агрономическая модель оперирует накопительными метриками: суммой активных температур (Growing Degree Days) для прогноза фазы развития культуры и вредителя, гидротермическим коэффициентом (ГТК Селянинова) для оценки риска грибных болезней. Это не мгновенный порог, а интеграл по времени — движок аккумулирует погодные данные за период и считает производные показатели, по которым уже срабатывает правило.

Критично: GDD считается не абстрактно по региону, а как матрица (метеостанция × культура × базовая температура). Базовая температура у культур разная — у кукурузы около 10 °C, у озимой пшеницы около 5 °C, — поэтому «100 градусо-дней для кукурузы» и «100 для пшеницы» соответствуют совершенно разным стадиям развития. Если движок считает тепло одной формулой на всех, фронт фенофаз разъезжается с реальностью, и за ним разъезжается всё, что от него зависит — и риск-модели, и активация кампаний. Поэтому параметризация по связке культура/сорт — не опция, а условие корректности.

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

Важно, что два контура (макро-GDD и микро-spray-weather) — это не единый процесс, а два разных воркера с разной частотой и разным TTL кэша, и смешивать их в один пайплайн нельзя:

• Макро-воркер (GDD) опирается на исторические суточные агрегации (T_min, T_max за сутки) и пересчитывается раз в день по cron. Фенофаза не меняется по часам — суточного шага достаточно, а данные долгоживущие.

• Микро-воркер (spray weather) работает с краткосрочным почасовым прогнозом (ветер, осадки на ближайшие 24–48 часов), опрашивает API часто и имеет короткий TTL — почасовой прогноз устаревает за несколько часов.

Это две разные базы, две частоты опроса и два горизонта актуальности. Архитектурно их разделение обязательно: попытка считать «погоду опрыскивания» с суточной частотой даст устаревший прогноз и выпущенные в поле в неподходящий день обработки, а пересчёт GDD каждый час — бессмысленная нагрузка.

• Notification Service: дедупликация (не слать один алерт дважды), троттлинг (лимит частоты на пользователя), сегментация по культурам в профиле подписчика.

• Доставка: Telegram Bot API как основной канал — он покрывает аудиторию, работает с мобильного в полевых условиях и не требует установки дополнительного ПО.

Микроклимат против метеостанции: предел точности

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

Архитектурно это означает, что система должна быть готова к источникам данных лучшего разрешения: интерполяция между станциями с поправкой на рельеф, а в перспективе — приём данных с полевых IoT-датчиков (температура, влажность листа) как более точного входа в тот же rule engine. Модель рисков остаётся, меняется только разрешение входных данных — от региональной сетки к конкретному полю.

Почему Telegram, а не привычные каналы

С инженерной точки зрения Telegram Bot API даёт всё нужное: webhook-и, inline-кнопки для навигации по тому же дереву DSS прямо в чате, возможность принимать фото (вход для будущей CV-диагностики), стейт-машина диалога. Это естественная среда выполнения для DSS-фронтенда — пользователь получает алерт по погоде и тут же, в том же интерфейсе, проваливается в определитель проблемы.

Но здесь всплывает суровое ограничение предметной области: в поле часто нет связи. Агроном стоит в центре участка в 40 км от ближайшей вышки — и серверный Telegram-бот в этот момент бесполезен. Это не мелочь, а архитектурная развилка:

• Online-режим (бот) хорош для предупреждений и работы из офиса/машины, но не для диагностики непосредственно на проблемном участке.

• Offline-first клиент (мобильное приложение с локальной БД дерева решений и фото-эталонов) решает полевой сценарий: агроном проходит определитель без сети, результат и фото кешируются и синхронизируются с сервером, когда связь появится. Дерево решений тут большое преимущество перед ML-подходом: детерминированную логику и компактную базу регламентов реально упаковать в локальную БД на устройстве, тогда как CV-модель тяжелее и часто требует сервера.

Но offline-режим порождает проблему синхронизации: агроном обследовал поле без сети, а в это же время другой сотрудник внёс изменения по тому же полю из офиса — чей вариант победит, когда планшет поймает сеть? Наивная локальная БД просто перезатрёт данные. Поэтому запись идёт по паттерну event sourcing: данные пишутся не как изменяемое состояние, а как иммутабельный лог событий (timestamp, координаты, фото, результат прохода дерева, автор), который при появлении сети просто дописывается (append-only) на сервер. Конфликта ^[10] перезаписи не возникает в принципе — есть два события по одному полю с разными метками времени и авторами, а итоговое состояние вычисляется из лога. Ничего не теряется, история обследований поля восстановима целиком.

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

Про email как канал: вопреки ожиданиям, он в агро живой — open rate доходит до ~24,5% (отраслевые бенчмарки, CUFinder), но работает только в режиме сервисных уведомлений (предупреждения, регламентные изменения), а не промо. С точки зрения системы это ещё один notification-канал с той же event-моделью, просто с другим транспортом и SLA по латентности.

Интеграция с CRM и аналитикой

Замыкание контура. Сигналы из DSS и триггерной системы — это высококачественные данные о намерении, которые имеет смысл прокидывать в CRM:

• Пользователь прошёл дерево до листа «фунгицид от фузариоза» → в CRM формируется сигнал с контекстом (культура, проблема, регион, фаза).

• Это меняет приоритизацию работы полевого менеджера: вместо холодного обхода — контакт по тёплому сигналу с известным контекстом задачи.

То есть система не заменяет человека-консультанта, а служит для него системой раннего оповещения и обогащения контекста. Архитектурно это event-driven интеграция: DSS/бот эмитят события намерения → CRM их потребляет → роутинг на менеджера с собранным контекстом. Атрибуция при этом сквозная: от первого касания (поисковый запрос по симптому) через прохождение DSS до сигнала в CRM — единый трекинг идентификатора.

ROPO: почему онлайн-конверсия — это верхушка айсберга

Событие form_submit_ok — это не сделка. В агро сделки закрываются месяцами, в офлайне, через дистрибьюторов, после визитов и полевых испытаний. Это классический ROPO-эффект (Research Online, Purchase Offline): клиент изучает и выбирает в цифре, а покупает вне её, иногда через третье лицо. Фокусироваться только на онлайн-конверсиях здесь — значит мерить верхушку айсберга и принимать решения по обрезанным данным.

Сквозная аналитика в агро обязана дотягиваться до офлайн-этапов, и ключевое связующее событие — «визит представителя» в CRM. Сценарий, который замыкает контур: пользователь прошёл DSS → сигнал намерения с контекстом ушёл в CRM → к нему выехал полевой представитель с планшетом, где открыт тот же контекст → менеджер фиксирует визит и его исход. Это связывает цифровое касание с офлайн-продажей через дистрибьютора и даёт настоящую сквозную атрибуцию до чека, а не до клика.

Ключевая сущность — не юзер, а поле

И здесь принципиальная для агро поправка к модели данных. Везде выше я говорил «пользователь» — но в B2B-агро центральная сущность не человек, а поле (геополигон) и хозяйство. Менеджер едет смотреть не абстрактного юзера, а конкретный участок с конкретной проблемой на конкретной культуре. Поэтому контекст, который DSS собирает и передаёт в CRM, должен мапиться на земельный банк: профиль пользователя → хозяйство → поля с их координатами, культурами, историей обработок.

Практически это значит, что DSS на этапе сбора контекста привязывает проблему не только к региону, но и (опционально) к координатам или кадастровому номеру поля. Сигнал в CRM обогащается границами участка — кадастровыми или спутниковыми. И представитель выезжает с планшетом, где маркер стоит на конкретном поле, к которому привязан диагноз, а не просто с карточкой клиента. Это меняет и аналитику: история «проблема → рекомендация → визит → сделка» накапливается по полю, а не по человеку, что в агро гораздо ближе к реальной единице принятия решений.

Но возникает проблема холодного старта: в enterprise-сегменте полигоны берутся из FMIS холдинга, а откуда они у обычного пользователя в Telegram-боте? Поэтому флоу инструмента вне enterprise обязан начинаться с локализации поля. Первым шагом бот или приложение просят пользователя дать геопозицию участка: скинуть точку, отрисовать полигон на встроенной карте или загрузить готовый контур (Shapefile/KML). Это не формальность — без координаты ни GDD, ни spray weather физически не запускаются: движку нечего опрашивать в погодном API. Нет полигона или хотя бы точки — нет персонализированного AgTech, остаётся просто справочник. Геопривязка — это вход в систему, а не опциональная настройка где-то в профиле.

Headless DSS: крупный холдинг не поставит ещё одну приложуху

И финальное архитектурное требование, без которого система упрётся в потолок на enterprise-сегменте. Крупные агрохолдинги уже живут в своих FMIS (Farm Management Information System) — Cropwise, «История поля» и аналогах, где у них заведён весь земельный банк. Никто из них не будет вводить кадастровые номера в сторонний Telegram-бот или ставить ещё одно отдельное приложение. Для них наша «приложуха» — лишняя сущность.

Поэтому DSS должен быть готов работать в headless-режиме (API-first): дерево решений и риск-модели отдаются по API в чужой интерфейс. Холдинг забирает рекомендации и алерты прямо в свою FMIS, где уже есть его поля, культуры и история. Бот и offline-приложение — это наши собственные фронтенды для тех, у кого своей системы нет; но ядро (движок дерева, база регламентов, погодный rule engine) спроектировано как headless-сервис, к которому можно подключиться снаружи. Это разделение «движок отдельно, фронтенды отдельно» и открывает дверь к интеграциям верхнего B2B-уровня.

Failure mode: ловушка закрытой рекомендации

Инженерно честный блок про то, как система деградирует. Если rule engine / дерево решений всегда сводит рекомендацию к продуктам одного вендора независимо от входных данных, пользователи это быстро детектируют — и доверие к инструменту обнуляется (подтверждается исследованиями барьеров внедрения agtech, 2021–2024). С продуктовой точки зрения это означает требование к системе: рекомендательная логика должна быть честной, включая ветки «обработка не требуется» и «подойдёт более дешёвое решение». Инструмент, который никогда не говорит «не покупай», теряет свойство, ради которого его внедряли, — доверие. Это не этическая ремарка, а функциональное требование к качеству DSS.

Итог: что здесь действительно инженерная задача

• Сезонность — это не «настройка рекламы», а оркестрация (продукт × регион × окно)-единиц с расписанием по фенокалендарю и перетеканием бюджета за фронтом фаз.

• Единый rule engine — рекламный оркестратор и агрономические триггеры питаются от одного погодного движка: GDD-фазы управляют и риск-моделями, и активацией кампаний. Маркетинг работает на тех же погодных моделях, что и агрономия.

• Два контура управления бюджетом — макро (GDD открывает окно на 2–3 недели) и микро (spray weather ставит на паузу в дни, когда ветер/дождь не дают выйти в поле).

• GDD параметризуется матрицей (метеостанция × культура × базовая температура) — иначе фронт фенофаз разъезжается с реальностью.

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

• Нормализатор данных — ETL из человекочитаемого Госкаталога в машинные правила с тегированием по BBCH — полноценный слой, а не скрипт.

• Версионирование через Review Queue (HITL) — Госкаталог живой; ETL ловит дельты, но инвалидацию листьев апрувит агроном, а не diff-алгоритм; до апрува grace period или скрытие только затронутого препарата.

• DSS начинается с детерминированного дерева решений, а не с ML; ввод верифицируется фото-эталонами и контрольными вопросами; листья валидируются против Госкаталога.

• Negative constraints (запреты по температуре, баковым смесям, фазам) имеют приоритет над рекомендацией.

• Антирезистентная ротация (FRAC/HRAC) — DSS обязана помнить историю обработок поля и блокировать повтор химкласса, иначе сама плодит резистентность; «симптом → препарат» превращается в «симптом + история поля → препарат с ротацией».

• No-code + CI/CD дерева — правила пишет агроном через DSL/конструктор, но каждая правка проходит синтетические тесты графа (висячие узлы, недостижимые листья, конфликт запретов) перед продом.

• Fuzzy search как deep link — поверх навигации от корня нужен нечёткий/векторный поиск по базе вредных объектов, перебрасывающий сразу на нужный узел; два входа в один граф.

• Данные важнее модели — выверенная база регламентов является ядром системы.

• Два воркера погодного движка — макро-GDD на суточных агрегациях (cron раз в день) и микро-spray-weather на почасовом прогнозе (частый опрос, короткий TTL) — разные базы, частоты и горизонты.

• GDD параметризуется матрицей (метеостанция × культура × базовая температура); spray-weather добавляет микро-контур паузы при ветре/дожде.

• Offline-first на event sourcing — в поле нет связи; локальная БД дерева на устройстве, запись append-only логом событий, что снимает конфликты синхронизации.

• ROPO и сквозная атрибуция — онлайн-конверсия это верхушка айсберга; событие «визит представителя» дотягивает аналитику до офлайн-сделки.

• Ключевая сущность — поле, а не юзер — контекст мапится на геополигон; флоу начинается с локализации (точка/полигон/KML), без неё погодные модели не запускаются.

• Headless / API-first — крупные холдинги не поставят ещё одно приложение; ядро отдаёт дерево и риск-модели по API в их FMIS (Cropwise и аналоги).

• Честность рекомендаций — функциональное требование: закрытая на одного вендора логика убивает доверие и обнуляет систему.

Агро — это ниша, где скучная инженерная дисциплина (чистые данные, корректные события, объяснимые деревья решений) бьёт хайповые подходы. Здесь выигрывает не тот, у кого моднее стек, а тот, у кого вернее источник истины и честнее логика.

Олег Линьков — основатель агентства Webformula, digital и AgTech в агросекторе. webformula-agro.ru ^[1]