Devin для кастомного трекинга полезен там, где есть повторяемая сборка, а не магия

Devin для кастомного трекинга полезен там, где есть повторяемая сборка, а не магия

Кастомный трекинг — это не только пиксель и события. Обычно там есть цепочка: TDS/redirect, postback, дедупликация, маппинг UTM, отправка в BI, алерты по поломкам. Devin хорошо заходит, когда задачу можно описать как набор файлов, API и проверок, а не как «почини мне аналитику».

Что можно отдавать агенту:
— собрать каркас сервиса для приема postback;
— написать парсер UTM/gclid/fbclid и нормализацию полей;
— сгенерировать тесты на потери конверсий и дубли;
— собрать скрипт сверки между CRM, трекером и рекламной платформой;
— оформить README и конфиг для ручного деплоя. 🧩

Где он ломается:
— когда нужно понять бизнес-логику атрибуции без явного ТЗ;
— когда есть зоопарк костылей в старом коде и нет тестов;
— когда требуется правка в production без ревью человека;
— когда надо разрулить спорные кейсы «какой источник главный». Тут агент пишет код, но решение должен принять байер или аналитик.

Хорошая схема — сначала дать Devin маленький изолированный модуль: один endpoint, один webhook, одна проверка целостности. Если он проходит это стабильно, расширяйте контур. Если с первого шага путает поля и формат событий, не масштабируйте.

Вывод: Devin ускоряет сборку трекинга, но не заменяет спецификацию. Чем точнее описаны события, источники и правила дедупа, тем меньше ручных правок на финале.