LakedApp

GTM Engineer: кто это и чем отличается от дата- и аналитик-инженера

2026-09-15T10:00:00+02:00

Термин «GTM Engineer» ввела компания Clay в 2023 году, и с тех пор он закрепился в таких компаниях, как Cursor, Lovable и Webflow — пишет сама Clay в своём блоге. По данным ZoomInfo Pipeline (со ссылкой на анализ Bloomberry по 1000 вакансий), число открытых позиций GTM Engineer выросло на 205% год к году, публикуется около 100 новых вакансий в месяц, а вилки зарплат — от $85 000 у junior до $241 000 у senior. Сам Bloomberry явно не указывает географию выборки, но цифры в долларах, а среди упомянутых работодателей — Vercel, OpenAI, Ramp и Clay, то есть речь по сути о рынке США.

Что реально делает GTM Engineer

В гайде Clay GTM-инжиниринг определён как «практика построения автоматизированных revenue-систем с помощью AI, данных и автоматизации workflow — вместо ручного ведения go-to-market». Единица работы — не отдельная задача, а система, которая работает на масштабе.

Clay описывает три последовательных уровня работы:

Фундамент данных — чистые, дедуплицированные записи в CRM.
Моделирование данных — скоринговые модели, ICP-атрибуты, исследовательские данные.
Активация данных — данные запускают конкретные revenue-действия (роутинг лида, персонализированный аутрич, кампания).

Практический пример из гайда Clay: workflow отслеживает сигналы о раунде финансирования, подтягивает новую компанию в Clay, обогащает её фирмографикой и контактами, скорит по ICP, генерирует персонализированную первую строку письма через LLM — и отправляет лучшие аккаунты в CRM и outbound-последовательность.

Apollo.io в своём описании роли выделяет пять зон ответственности: обогащение данных и контроль их качества, скоринговые модели, автоматизация workflow (роутинг лидов, триггеры последовательностей), настройка AI-агентов для исследования и генерации контента, и аналитика/дашборды.

Какие навыки нужны

Clay формулирует это так: GTM-инженер — «гибрид: наполовину человек с коммерческим мышлением, наполовину билдер» (источник). Продакшен-код не обязателен — нужна, по формулировке гайда, «готовность разобраться в инструменте методом тыка» (источник). При этом Apollo.io в списке технических навыков называет SQL, JavaScript/Python для кастомных интеграций, работу с API и дата-хранилищами, настройку CRM и prompt engineering для AI-оркестрации.

Стек, который называет Clay: CRM (Salesforce), дата-хранилище (Snowflake/BigQuery) и «движковый» слой — сам Clay, который в одном месте закрывает обогащение, скоринг, исследование и активацию.

Это не то же самое, что GTM Analyst

Название похоже, но роли разные — и GTM Analyst появился гораздо раньше. По разбору вакансий productroadmap.ai, go-to-market (strategy) analyst занимается анализом рынка и поведения покупателей, ценообразованием и позиционированием продукта, конкурентной разведкой и финансовым моделированием — это стратегическая, исследовательская роль без кода и автоматизации. GTM Engineer, наоборот, почти не формирует стратегию сам — он реализует уже принятые гипотезы в виде работающих систем. Если упростить: GTM Analyst отвечает на вопрос «что делать на рынке», GTM Engineer — «как это автоматизировать».

GTM Engineer vs RevOps

Прежде чем сравнивать — что такое RevOps, если вы слышите про эту роль впервые. По определению Salesforce, revenue operations — «стратегический фреймворк, который объединяет всю revenue-активность компании»: маркетинг, продажи, customer success и часто финансы работают по единым процессам и на одном технологическом стеке вместо разрозненных отделов с несовместимыми данными и целями. На практике RevOps-команда сводит данные о выручке воедино, интегрирует CRM/маркетинговые/ERP-системы, автоматизирует рутину вроде передачи лида между отделами или выставления счетов и следит, чтобы все revenue-команды двигались в одном направлении. Это уже устоявшаяся, стандартная должность в большинстве B2B-компаний — в отличие от GTM Engineer, которая появилась только в 2023 году.

Это ближайшее и самое частое сравнение с GTM Engineer — многие GTM-инженеры начинают именно в RevOps. Clay формулирует разницу так: «RevOps поддерживает существующий процесс работающим. GTM-инжиниринг меняет сам процесс». Salesforge.ai раскладывает это по осям:

	RevOps	GTM Engineer
Отправная точка	Существующий процесс: «что мешает воронке»	Чистый лист: «какую систему построить»
Владеет	Роутинг лидов, SLA, прогнозирование, документация процессов	Дата-пайплайны, архитектура стека, API-интеграции, автоматизация
Навыки	Бизнес-операции, финмоделирование, Salesforce/HubSpot, SQL для отчётности	SQL, Python, проектирование API, работа с данными
Метрика успеха	Эффективность воронки, соблюдение SLA, точность прогноза	Аптайм систем, надёжность интеграций, точность данных, покрытие автоматизацией

GTM Engineer vs Data Engineer vs Analytics Engineer

Здесь стоит опереться на первоисточники самих этих ролей, а не только на маркетинг GTM-инжиниринга.

Data Engineer. По определению Splunk, дата-инженер «проектирует, строит и поддерживает масштабируемые системы и пайплайны данных», которые позволяют компании собирать, хранить и обрабатывать большие объёмы данных. Ключевые зоны: архитектура данных, сбор и валидация данных из разных источников, автоматизация процессов, инфраструктура для дата-саентистов и аналитиков. Инструменты — Python/Java/Scala/SQL, Hadoop/Kafka, облачные платформы, Airflow.

Analytics Engineer. Роль оформилась около 2018 года в сообществе вокруг dbt (тогда ещё Fishtown Analytics) — облачные хранилища (Redshift, BigQuery, Snowflake) и сервисы загрузки данных (Stitch, Fivetran) удешевили хранение и упростили извлечение, а бизнес-пользователям стало не хватать умения работать с сырыми данными напрямую. По определению dbt Labs, аналитик-инженер «предоставляет конечным пользователям чистые датасеты, моделируя данные так, чтобы пользователи могли сами отвечать на свои вопросы» — пишет трансформации (в основном на SQL через dbt), тестирует данные, документирует и поддерживает структуру хранилища. Разница с дата-инженером в том же посте dbt: дата-инженер строит инфраструктуру и пайплайны, аналитик-инженер — трансформацию и документацию поверх уже собранных данных.

GTM Engineer. В отличие от обеих ролей, единица работы — не датасет и не пайплайн, а revenue-система целиком: от данных до конкретного действия (письмо, звонок, запись в CRM), которое двигает сделку. GTM-инженер может использовать SQL и API так же, как дата- или аналитик-инженер, но конечный получатель его работы — не аналитик и не дашборд, а sales/marketing-процесс, и метрика — не качество данных сама по себе, а встречи и сделки.

	Data Engineer	Analytics Engineer	GTM Engineer
Что строит	Пайплайны и инфраструктуру данных	Трансформации и чистые датасеты поверх хранилища	Автоматизированные revenue-workflow
Для кого	Дата-саентисты, аналитики, вся компания	Бизнес-пользователи, self-service BI	Sales, marketing, RevOps
Основной инструмент	Airflow, Spark/Hadoop, облачные хранилища	dbt, SQL	Clay, CRM, API-интеграции, LLM
Метрика	Надёжность и доступность данных	Качество и документированность датасетов	Пайплайн, встречи, сделки

Коротко

GTM Engineer — не замена дата- или аналитик-инженеру и не более технична, а функционально версия RevOps, ориентированная на скорость и revenue-эффект: она использует тот же набор инструментов (SQL, API, дата-модели), что и инженерные роли в данных, но продукт работы — не датасет, а работающий кусок go-to-market процесса. Роль молодая (2023 год) и пока не стандартизирована так, как data/analytics engineering — поэтому конкретный набор задач у GTM-инженера сильно зависит от компании, в отличие от куда более устоявшихся ролей дата- и аналитик-инженера.

Источники: Clay — GTM Engineering (блог), Clay — The Complete Guide to GTM Engineering, Apollo.io — GTM Engineer Job Description, ZoomInfo Pipeline — What Is GTM Engineering?, Salesforge.ai — GTM Engineering vs RevOps, Salesforce — What Is Revenue Operations (RevOps)?, productroadmap.ai — What Is a Go-To-Market Strategy Analyst Job Description?, dbt Labs — What is analytics engineering?, Splunk — The Data Engineer Role, Explained.

Память AI-агентов: рабочий фреймворк вместо зоопарка терминов

2026-09-14T10:00:00+02:00

Если почитать несколько материалов про память AI-агентов подряд, немудрено запутаться: один источник называет три вида памяти, другой — четыре или пять, третий вообще обходится без слова «тип» и говорит про «compaction» и «note-taking». При этом почти все так или иначе отсылают к одной и той же научной работе — CoALA (Sumers, Yao, Narasimhan, Griffiths, 2023).

Сама статья предлагает четыре типа памяти: working (рабочая — то, что активно прямо сейчас, в текущем шаге), semantic (факты), episodic (события), procedural (правила и навыки — включая как явно написанный код, так и неявные знания в весах модели). Дальше мы группируем их немного иначе, чем в оригинале, — не потому что CoALA ошибается, а потому что для инженерного решения полезнее смотреть на вопрос с двух разных сторон одновременно.

Разброс объясним: большинство материалов смешивают в один список два независимых вопроса:

Что запоминается (факт? событие? правило?)
Как и где это возвращается модели (прямо сейчас в промпте? в файле на диске? через поиск?)

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

Ось 1: что хранится

Тут действительно есть три содержательные категории, и они устойчиво повторяются от источника к источнику:

Тип	Вопрос	Пример
Факт (semantic)	Что верно?	«Пользователь предпочитает Python»
Событие (episodic)	Что произошло?	«В прошлый раз деплой упал из-за забытой env-переменной»
Правило (procedural)	Как действовать?	«Перед деплоем всегда проверяй env-переменные»

# Одна и та же структура для всех трёх — просто разные схемы записи
fact    = {"type": "fact",    "key": "language_pref", "value": "python"}
episode = {"type": "episode", "task": "deploy", "outcome": "failed",
           "reason": "missing env var", "date": "2026-09-01"}
rule    = {"type": "rule",    "trigger": "before_deploy",
           "action": "check env vars"}

Как уже говорилось во вступлении, у CoALA working memory — равноправный четвёртый тип наравне с этими тремя. Мы намеренно переносим её на Ось 2, потому что для инженерного решения важнее не «какой это тип контента», а «оно уже физически лежит в промпте или нет» — так ближе к тому, как эту развилку приходится решать на практике. Дальше по тексту working memory обсуждается именно там.

Ось 2: как и где это возвращается модели

Здесь путаются сильнее всего. Ключевая мысль, которую явно формулирует Anthropic в своём разборе context engineering: модель не «помнит» ничего, что физически не лежит в промпте прямо сейчас. Хранение — это ещё не память. Память — это то, что реально попало в контекстное окно.

Отсюда три механизма:

Working memory — то, что уже в промпте (system prompt, история диалога, только что вызванный tool result).
Persistent storage — файл, база, memory store: место, где информация живёт между сессиями, но модель её не видит, пока кто-то её туда не положил обратно.
Retrieval — активный шаг «достать нужный кусок из storage и вставить в working memory». Поиск по смыслу, точный лукап или просто чтение файла по известному пути.

# Псевдокод в духе "structured note-taking" из поста Anthropic
def turn(user_message, working_memory, store):
    # 1. Retrieval: что из storage релевантно прямо сейчас?
    relevant = store.search(user_message, top_k=3)
    working_memory = compact(working_memory) + relevant

    # 2. Модель отвечает, видя только working_memory
    response = call_model(working_memory + [user_message])

    # 3. Что стоит сохранить обратно в storage?
    if worth_remembering(response):
        store.write(extract_memory(response))

    return response, working_memory

Retrieval — не четвёртый вид содержимого, а способ доставки любого из трёх типов из Оси 1. LangChain формулирует это почти дословно в документации Deep Agents: в таблице параметров памяти «Information type» (semantic/episodic/procedural) и «Retrieval» (загружено в промпт по умолчанию / читается по требованию) — это два разных столбца, отвечающих на два разных вопроса, а не пункты одного перечня.

Особые случаи: parametric и prospective

Parametric memory (знания в весах модели) — по классификации CoALA это implicit-форма процедурной памяти; explicit-форма той же процедурной памяти — как раз написанные правила из «rule» выше. Но для инженерной практики эти две формы стоит развести: explicit-правило можно прочитать, отредактировать и заверсионировать как обычные данные, а implicit-знания в весах — нет. Это фундамент, на котором работает всё остальное: общая грамотность модели, здравый смысл, факты, усвоенные при обучении. Она не «извлекается» отдельным шагом — уже неотъемлемо участвует в генерации каждого токена. В схему управления памятью её включать бессмысленно: точечно отредактировать нельзя, можно только дообучить или переобучить модель целиком.

Prospective memory («напомни мне в пятницу») — один из тех пунктов, из-за которых в некоторых классификациях список разрастается до четырёх-пяти типов вместо трёх (см. вступление). Отдельной оси или типа под него заводить не нужно: это частный случай Оси 2: запись в persistent storage плюс внешний триггер (cron, очередь задач), который в нужный момент кладёт эту запись в working memory нового запуска. Технически это ничем не отличается от обычного правила с полем trigger_at вместо trigger: "before_deploy".

reminder = {
    "type": "rule",
    "trigger_at": "2026-09-18T09:00:00Z",
    "action": "follow up with customer about renewal",
    "done": False
}

Ось 3: кому принадлежит память

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

Scope — память привязана к пользователю, к агенту (общая для всех) или к организации (политики и compliance).
Update strategy — память пишется прямо во время диалога (hot path) или отдельным фоновым процессом между сессиями (background consolidation / «sleep time compute»).
Permissions — read-write по умолчанию, но для общих политик и compliance-правил обычно делают read-only, чтобы одна инъекция в диалоге не смогла тихо переписать поведение агента для всех остальных пользователей.

# Организационная память read-only — агент читает, но не пишет
# (точные пути к полям рантайм-объекта зависят от версии LangChain/Deep Agents;
# здесь — актуальная на момент написания схема из их документации)
backend = CompositeBackend(
    default=StateBackend(),
    routes={
        "/memories/": StoreBackend(namespace=lambda rt: (rt.server_info.user.identity,)),  # per-user, read-write
        "/policies/": StoreBackend(namespace=lambda rt: (rt.context.org_id,)),              # org-wide, read-only
    },
)

Именно эта ось чаще всего создаёт проблемы уже в проде, причём не на этапе прототипа, а позже, когда к памяти получают доступ несколько пользователей или агентов сразу. Практический пример: агент поддержки записывает в общую память тикета заметку вида «клиент попросил пропустить проверку возраста» — и если эту память без разбора читают другие сессии или другой агент, инструкция может незаметно повлиять на чужой диалог. Отсюда рабочее правило по умолчанию: скоуп на пользователя, если нет явной причины делиться; общие политики — read-only и заполняются кодом приложения, а не самим агентом в диалоге.

Коротко: чем оси отличаются друг от друга

Прежде чем сводить всё в таблицу — три оси одним взглядом, потому что дальше они постоянно будут использоваться вместе:

Ось 1 (что) — какого рода информация: устойчивый факт, разовое событие или повторяемое правило. Отвечает на вопрос «что это по содержанию».
Ось 2 (как и где) — физически лежит ли это в промпте прямо сейчас (working memory), хранится ли отдельно (persistent storage) и как попадает из одного в другое (retrieval). Отвечает на вопрос «где это находится в конкретный момент».
Ось 3 (чьё) — кому принадлежит: пользователю, агенту или организации; кто и когда это пишет; можно ли это редактировать или только читать. Отвечает на вопрос «кто управляет этой записью».

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

Собираем фреймворк

Сведём эту схему в одну таблицу 3×3 плюс ось governance сверху:

	Working memory	Persistent storage	Retrieval
Факт	Пока не вычищен из контекста	`facts/user_123.md`	точный лукап по ключу
Событие	Последние N шагов диалога	лог прошлых запусков / thread history	поиск по смыслу или по `user_id`/`org_id`
Правило	Часть system prompt	`procedures/deploy_checklist.md`	обычно читается целиком, не ищется

Для каждой ячейки отдельно решается: кто владеет этой памятью (user / agent / org) и когда она пишется (hot path / background).

Практический алгоритм при проектировании памяти агента:

Что это — устойчивый факт, разовое событие или повторяемое правило?
Переживёт ли это конец сессии? Если нет — working memory достаточно, ничего сохранять не нужно.
Как модель это найдёт в следующий раз — по точному ключу, по смыслу, по времени, или файл просто всегда читается целиком?
Кто владеет этой информацией — конкретный пользователь, агент в целом, или организация? Нужен ли read-only, чтобы защититься от инъекций через shared state?
Когда это пишется — сразу в диалоге, или можно отложить в фоновую консолидацию, чтобы не тратить латентность на каждый ход?

Ответьте на эти пять вопросов для каждого вида информации — и получится архитектура памяти агента, а не список абстрактных «типов».

Пример: агент поддержки клиентов

Три кандидата на «память» из одного диалога с клиентом SaaS-продукта:

«Клиент на тарифе Pro, оплата продлевается 2026-11-01» — факт. Переживёт сессию → хранится в facts/customer_{id}.md или в таблице CRM; скоуп — пользователь, read-write; пишется в hot path сразу после ответа billing API; находится по точному ключу customer_id.
«За последний месяц клиент три раза жаловался на медленную загрузку отчётов» — событие. Переживёт сессию → лог тикетов; скоуп — пользователь (или agent, если паттерн нужно эскалировать на команду продукта); пишется в hot path при закрытии тикета; находится поиском по смыслу или по customer_id + временному окну.
«Возврат денег оформляется только через форму X, вручную — нельзя» — правило. Это не про конкретного клиента, живёт дольше любой сессии → policies/refunds.md; скоуп — организация, для агента read-only; пишется только кодом или командой поддержки; читается целиком как часть system prompt при любом обращении к теме возвратов.

Три записи выглядят одинаково — «что-то, что стоит запомнить», — а инфраструктура и права у них разные. Ради этого и стоит разводить содержимое (Ось 1), способ доставки (Ось 2) и владение (Ось 3) отдельно: одна табличка «тип памяти» без этих осей не подскажет, где хранить и кто может писать.

Почему термины расходятся даже у профессионалов

Область молодая и быстро меняется: устоявшегося стандарта нет, а термины во многом заимствованы из когнитивной психологии — удобная метафора, но не точная модель для программной архитектуры. К тому же каждая компания описывает память под свой продукт: LangChain — под LangGraph/Deep Agents, Anthropic — под контекстное окно Claude, IBM — как обзорный учебный материал. Поэтому одни и те же слова получают разный вес и разную вложенность, а из в общем-то простой идеи «сохрани данные, потом достань нужный кусок обратно» вырастают списки из четырёх, пяти, семи пунктов — не обязательно потому, что кто-то ошибается, а потому что каждый список отвечает на свой практический вопрос и рассчитан на свою аудиторию.

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

Источники: CoALA (Sumers et al., 2023), Anthropic — Effective context engineering for AI agents, LangChain — Memory for Deep Agents, LangChain — Memory for agents (blog), IBM — What is AI agent memory?.

Чек-лист: 7 вопросов перед миграцией на Google Cloud

2026-09-02T10:00:00+02:00

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

Кто владеет данными после переноса? Роли и права доступа в BigQuery/IAM должны быть определены до миграции, а не подгоняться постфактум под то, как всё исторически было устроено.
Как считается совокупная стоимость — не только вычисления, но и хранение, исходящий трафик и слот-часы BigQuery при пиковой нагрузке?
Что происходит с существующими пайплайнами — переписываются под управляемые сервисы (Dataflow, Composer) или переносятся как есть на Compute Engine?
Есть ли план отката, если что-то пойдёт не так на середине переноса, а не только "бэкап на всякий случай"?
Как валидируются данные после переноса — построчное сравнение, контрольные суммы, сверка агрегатов?
Кто отвечает за мониторинг и алерты в новой среде с первого дня, а не после первого инцидента?
Совместим ли CI/CD с целевой инфраструктурой, или релизный процесс придётся выстраивать заново?

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

Как мы ускорили дата-пайплайн в 10 раз

2026-08-20T10:00:00+02:00

Проблема

Ночной пайплайн собирал события из нескольких источников в BigQuery и каждую ночь занимал около 6 часов — время, за которое стоимость Slot-часов и риск не успеть к утренним отчётам росли параллельно. Схема не менялась почти год, но объём данных вырос почти в 5 раз.

Диагностика

Профилирование показало три конкретные причины:

полное пересчитывание витрин вместо инкрементальной загрузки;
один гигантский DAG в Airflow без параллельных веток;
отсутствие партиционирования и кластеризации на исходных таблицах.

Что изменили

Партиционирование по дате и кластеризация по ключу события — сканирование сузилось до нужного окна вместо полной таблицы.
Инкрементальная загрузка вместо полного пересчёта: обрабатывали только новые и изменённые записи.
Разбили DAG на независимые ветки, которые Airflow теперь исполняет параллельно, а не последовательно.

Результат

Пайплайн стал укладываться в 35–40 минут — то есть почти в 10 раз быстрее — а стоимость обработки в BigQuery упала примерно на 60%, потому что каждый прогон сканирует на порядок меньше данных.

Если у вас похожая картина — ночной пайплайн, который со временем "распух" вместе с объёмом данных — обычно это тот же самый набор причин. Расскажите о своей задаче, обсудим, что применимо у вас.