RuStore уличили в наборе функций, который для стор-аппа выглядит очень тяжело: скрытый трекинг, фоновые установки, сбор device-идентификаторов и попытки тащить телеметрию про экранное время и фото-каталог.
Если это подтвердится на независимом разборе, картина такая:
1) стор перестаёт быть только точкой дистрибуции;
2) появляется отдельный слой data collection поверх обычных разрешений Android;
3) у бизнеса и ops возникает вопрос уже не про UX, а про контроль за данными и риски для корпоративных устройств.
Для martech это хороший пример того, как «инфраструктурный» продукт быстро превращается в data-platform без прозрачной рамки. В стеке это всегда больно: пользователь не понимает, что собирается, юристы спорят с продуктом, а техкоманда потом разгребает доверие и MDM-политики.
Если вы строите мобильный канал, здесь стоит смотреть не на громкость новости, а на три вещи: какие permissions реально запрашиваются, что уходит в сеть, и можно ли это отключить на уровне парка устройств 🔍
Если это подтвердится на независимом разборе, картина такая:
1) стор перестаёт быть только точкой дистрибуции;
2) появляется отдельный слой data collection поверх обычных разрешений Android;
3) у бизнеса и ops возникает вопрос уже не про UX, а про контроль за данными и риски для корпоративных устройств.
Для martech это хороший пример того, как «инфраструктурный» продукт быстро превращается в data-platform без прозрачной рамки. В стеке это всегда больно: пользователь не понимает, что собирается, юристы спорят с продуктом, а техкоманда потом разгребает доверие и MDM-политики.
Если вы строите мобильный канал, здесь стоит смотреть не на громкость новости, а на три вещи: какие permissions реально запрашиваются, что уходит в сеть, и можно ли это отключить на уровне парка устройств 🔍
Китайский рынок запусков сейчас похож не на «гонку за Falcon 9», а на параллельный A/B-тест нескольких архитектур сразу.
Сразу несколько гос- и частных команд строят многоразовые носители с возвратом первой ступени, вертикальной посадкой и повторным использованием ключевых узлов. Но важен не сам факт «копии Falcon 9», а стратегия: вместо ставки на один стандарт Китай распараллеливает разработку и проверяет разные связки — конструкцию, двигатели, топливо, схемы посадки.
Для martech здесь есть знакомая логика: не собирать один «идеальный» стек, а держать несколько контуров и быстро сравнивать их по стоимости ошибки, срокам внедрения и готовности к масштабу. 🚀
Сильная сторона такого подхода — ускоренное накопление практики. Слабая — выше сложность управления и риск распыления ресурсов. Но в отраслях, где цена технологического отставания высока, скорость обучения часто важнее аккуратной унификации.
Сразу несколько гос- и частных команд строят многоразовые носители с возвратом первой ступени, вертикальной посадкой и повторным использованием ключевых узлов. Но важен не сам факт «копии Falcon 9», а стратегия: вместо ставки на один стандарт Китай распараллеливает разработку и проверяет разные связки — конструкцию, двигатели, топливо, схемы посадки.
Для martech здесь есть знакомая логика: не собирать один «идеальный» стек, а держать несколько контуров и быстро сравнивать их по стоимости ошибки, срокам внедрения и готовности к масштабу. 🚀
Сильная сторона такого подхода — ускоренное накопление практики. Слабая — выше сложность управления и риск распыления ресурсов. Но в отраслях, где цена технологического отставания высока, скорость обучения часто важнее аккуратной унификации.
Supabase — это open source-альтернатива Firebase, но на базе PostgreSQL. Для martech-стека это важно не “потому что модно”, а потому что появляется управляемая слойка данных: auth, storage, realtime, serverless-функции и SQL в одном контуре.
Куда встраивать:
- быстрые MVP для CRM-кабинетов, личных аккаунтов, партнёрских порталов;
- backend для no-code/low-code автоматизаций;
- промежуточный слой между продуктом и DWH/CDP, когда нужен контроль над схемой и доступами.
Чем полезен на фоне Firebase:
- SQL вместо закрытой модели данных;
- проще интегрировать с BI, сегментацией и кастомной логикой;
- меньше vendor lock-in, больше гибкости в данных.
Где боль:
- это не “готовая CDP из коробки” и не замена полноценному backend-проектированию;
- при росте нагрузки придётся внимательно следить за индексами, миграциями и правами доступа ⚙️
Для команд, которые строят AI- и automation-слой вокруг данных, Supabase стал заметно практичнее: нейросетям проще генерировать запросы и CRUD-логику под PostgreSQL, чем разбираться в закрытых SDK.
Куда встраивать:
- быстрые MVP для CRM-кабинетов, личных аккаунтов, партнёрских порталов;
- backend для no-code/low-code автоматизаций;
- промежуточный слой между продуктом и DWH/CDP, когда нужен контроль над схемой и доступами.
Чем полезен на фоне Firebase:
- SQL вместо закрытой модели данных;
- проще интегрировать с BI, сегментацией и кастомной логикой;
- меньше vendor lock-in, больше гибкости в данных.
Где боль:
- это не “готовая CDP из коробки” и не замена полноценному backend-проектированию;
- при росте нагрузки придётся внимательно следить за индексами, миграциями и правами доступа ⚙️
Для команд, которые строят AI- и automation-слой вокруг данных, Supabase стал заметно практичнее: нейросетям проще генерировать запросы и CRUD-логику под PostgreSQL, чем разбираться в закрытых SDK.
Автоматические SMS о снижении цены — редкий пример полезной martech-механики без «магии AI»: простая триггерная коммуникация, которая может вернуть пользователя в воронку с очень понятным ROI.
Что здесь происходит по схеме:
1) товар добавляют в вишлист;
2) система хранит текущую/последнюю цену;
3) при снижении цены отправляет SMS с триггером на возврат.
Куда встраивать: в e-commerce стек на WordPress это обычно ложится поверх CMS + корзины/каталога + API-сервиса рассылок. Плюс нужен слой событий: wishlist event, price change event, message trigger.
Почему SMS, а не только email/push:
- SMS быстрее и выше шанс увидеть сообщение сразу;
- хорошо работает для срочных промо и дефицитных SKU;
- но дороже, поэтому важна строгая фильтрация: только релевантные товары и значимое снижение цены.
Практический вывод для martech-стека: такая механика — не про «ещё один канал», а про связку данных о намерении + ценовой динамики + триггерной доставки. Именно на этом обычно и строится экономия на ретеншене 📩
Что здесь происходит по схеме:
1) товар добавляют в вишлист;
2) система хранит текущую/последнюю цену;
3) при снижении цены отправляет SMS с триггером на возврат.
Куда встраивать: в e-commerce стек на WordPress это обычно ложится поверх CMS + корзины/каталога + API-сервиса рассылок. Плюс нужен слой событий: wishlist event, price change event, message trigger.
Почему SMS, а не только email/push:
- SMS быстрее и выше шанс увидеть сообщение сразу;
- хорошо работает для срочных промо и дефицитных SKU;
- но дороже, поэтому важна строгая фильтрация: только релевантные товары и значимое снижение цены.
Практический вывод для martech-стека: такая механика — не про «ещё один канал», а про связку данных о намерении + ценовой динамики + триггерной доставки. Именно на этом обычно и строится экономия на ретеншене 📩
«Простая фича» — это обычно ловушка.
История про дверь в игре хорошо ложится и на martech: логин, подписка, согласие на cookies, восстановление пароля, выход из сценария, показ прогресса — всё это кажется мелочью, пока не начинаешь раскладывать на состояния, правила и edge cases.
Для CRM/CDP это особенно знакомо:
- один экран входа = несколько источников идентификации
- одна кнопка = разные права, сегменты и ветки автоматизации
- одно “согласен” = юридика, триггеры, персонализация и хранение данных
Именно здесь чаще всего ломаются стеки. Не в «магии AI», а в стыках: кто создает событие, кто его валидирует, где дедупликация, что делать при лаге, как не сломать upstream-автоматизацию.
Хороший martech-менеджмент — это не вера в простые решения, а привычка задавать 20 вопросов до того, как “зальем в прод” 🚪
История про дверь в игре хорошо ложится и на martech: логин, подписка, согласие на cookies, восстановление пароля, выход из сценария, показ прогресса — всё это кажется мелочью, пока не начинаешь раскладывать на состояния, правила и edge cases.
Для CRM/CDP это особенно знакомо:
- один экран входа = несколько источников идентификации
- одна кнопка = разные права, сегменты и ветки автоматизации
- одно “согласен” = юридика, триггеры, персонализация и хранение данных
Именно здесь чаще всего ломаются стеки. Не в «магии AI», а в стыках: кто создает событие, кто его валидирует, где дедупликация, что делать при лаге, как не сломать upstream-автоматизацию.
Хороший martech-менеджмент — это не вера в простые решения, а привычка задавать 20 вопросов до того, как “зальем в прод” 🚪
100+ проектов в Excel — это обычно не про экономию, а про скрытую цену: статусы расходятся, дедлайны живут в переписке, а сводка собирается вручную.
Кейс исследовательского центра «Дом Фармации» здесь показателен: вместо таблиц они перевели управление в систему задач, чтобы видеть портфель проектов в одном окне.
Что важно для martech/ops-команд:
1) Excel терпит до тех пор, пока проектов мало и зависимостей почти нет.
2) Как только появляются параллельные процессы, роли, согласования и контроль сроков — нужна система с единым источником правды.
3) Самая дорогая ошибка — не миграция, а отсутствие нормальной модели данных и статусов.
Для CMO и martech-менеджера логика та же, что и в CRM/CDP: сначала структура и правила, потом автоматизация. Иначе вместо прозрачности получаете «цифровой Excel» 🧩
Кейс исследовательского центра «Дом Фармации» здесь показателен: вместо таблиц они перевели управление в систему задач, чтобы видеть портфель проектов в одном окне.
Что важно для martech/ops-команд:
1) Excel терпит до тех пор, пока проектов мало и зависимостей почти нет.
2) Как только появляются параллельные процессы, роли, согласования и контроль сроков — нужна система с единым источником правды.
3) Самая дорогая ошибка — не миграция, а отсутствие нормальной модели данных и статусов.
Для CMO и martech-менеджера логика та же, что и в CRM/CDP: сначала структура и правила, потом автоматизация. Иначе вместо прозрачности получаете «цифровой Excel» 🧩
Codex перестаёт быть полезным, когда ему в пятый раз приходится объяснять одни и те же правила проекта: как гонять тесты, где лежат проверки прав, какие alias-модули нельзя тащить обратно и что уже решили в прошлых обсуждениях.
Под это и сделали Hermes Codex Plugin: локальная память на SQLite вместо простыни промпта. Логика простая:
- складываем rules, summaries и прошлые решения в базу;
- ищем по ним через FTS5;
- в Codex отдаём только короткий релевантный фрагмент контекста.
С точки зрения martech-стека это очень знакомый паттерн: не «умнее AI», а нормальная retrieval-обвязка вокруг модели. По сути, это мини-RAG для дев-команд — чтобы не раздувать prompt budget и не кормить модель шумом.
Где ценность:
1) меньше повторов в командной работе;
2) ниже риск, что модель забудет локальные правила;
3) дешевле и стабильнее, чем пихать всё в контекст вручную.
Похоже на маленький, но практичный слой knowledge management поверх AI-инструмента. Именно такие штуки обычно и дают эффект — без магии, зато с экономией контекста 🧩
Под это и сделали Hermes Codex Plugin: локальная память на SQLite вместо простыни промпта. Логика простая:
- складываем rules, summaries и прошлые решения в базу;
- ищем по ним через FTS5;
- в Codex отдаём только короткий релевантный фрагмент контекста.
С точки зрения martech-стека это очень знакомый паттерн: не «умнее AI», а нормальная retrieval-обвязка вокруг модели. По сути, это мини-RAG для дев-команд — чтобы не раздувать prompt budget и не кормить модель шумом.
Где ценность:
1) меньше повторов в командной работе;
2) ниже риск, что модель забудет локальные правила;
3) дешевле и стабильнее, чем пихать всё в контекст вручную.
Похоже на маленький, но практичный слой knowledge management поверх AI-инструмента. Именно такие штуки обычно и дают эффект — без магии, зато с экономией контекста 🧩
Советский «кодовый замок» — это не про удобство, а про отказоустойчивость на минималках.
Что важно:
1) Это не домофон и не CRM с UI. Это автономный электронный СКУД для объектов, где связь и сервис были роскошью.
2) Логика простая: вводишь код — получаешь доступ. Меньше компонентов, меньше точек отказа, но и почти ноль гибкости.
3) По сути это железный предок современных PIN-кодов, только без аналитики, логов и интеграций с чем-либо вообще.
Почему он «суровый»:
— кодовый механизм делали так, чтобы переживать плохую эксплуатацию;
— ставили там, где подъездные системы были не нужны или недоступны;
— ремонт и обслуживание были максимально приземлёнными: без облака, без прошивок, без vendor lock-in.
Если смотреть глазами martech-архитектора, это классический пример «one task, one box»: одна функция, одна схема, одна боль. Только в отличие от современных no-code-решений, здесь no-code был не фичей, а единственным вариантом 🔧
Что важно:
1) Это не домофон и не CRM с UI. Это автономный электронный СКУД для объектов, где связь и сервис были роскошью.
2) Логика простая: вводишь код — получаешь доступ. Меньше компонентов, меньше точек отказа, но и почти ноль гибкости.
3) По сути это железный предок современных PIN-кодов, только без аналитики, логов и интеграций с чем-либо вообще.
Почему он «суровый»:
— кодовый механизм делали так, чтобы переживать плохую эксплуатацию;
— ставили там, где подъездные системы были не нужны или недоступны;
— ремонт и обслуживание были максимально приземлёнными: без облака, без прошивок, без vendor lock-in.
Если смотреть глазами martech-архитектора, это классический пример «one task, one box»: одна функция, одна схема, одна боль. Только в отличие от современных no-code-решений, здесь no-code был не фичей, а единственным вариантом 🔧
Перед внедрением DWH чаще всего ломается не стек, а предпроект.
Если обследование сделано формально, команда быстро уходит в «космические замки»: красивые схемы, но бюджет уже считает сарай.
Что важно проверить до старта:
1) какие бизнес-задачи закрывает хранилище: отчетность, сквозная аналитика, ML, витрины для CRM;
2) какие источники реально доступны и в каком качестве;
3) кто владелец данных и кто отвечает за метрики;
4) где узкое место — интеграции, моделирование, права доступа, нагрузка.
Полезный принцип: сначала карта данных и процессов, потом архитектура. Иначе DWH превращается в дорогой набор коннекторов без понятной ценности.
Для CMO и martech-команд это особенно критично: если заранее не зафиксировать use cases, BI и персонализация будут строиться на разных версиях «истины» 📊
Главная экономия в таких проектах — не на инженерах, а на ясности требований до запуска.
Если обследование сделано формально, команда быстро уходит в «космические замки»: красивые схемы, но бюджет уже считает сарай.
Что важно проверить до старта:
1) какие бизнес-задачи закрывает хранилище: отчетность, сквозная аналитика, ML, витрины для CRM;
2) какие источники реально доступны и в каком качестве;
3) кто владелец данных и кто отвечает за метрики;
4) где узкое место — интеграции, моделирование, права доступа, нагрузка.
Полезный принцип: сначала карта данных и процессов, потом архитектура. Иначе DWH превращается в дорогой набор коннекторов без понятной ценности.
Для CMO и martech-команд это особенно критично: если заранее не зафиксировать use cases, BI и персонализация будут строиться на разных версиях «истины» 📊
Главная экономия в таких проектах — не на инженерах, а на ясности требований до запуска.
ЦБ 19 июня снова пересмотрит ключевую ставку: сейчас она 14,5%, а консенсус рынка — снижение до 14%. Некоторые аналитики не исключают и более резкий шаг — минус 1 п.п.
Что это значит для martech-стека:
1) Деньги дешевеют — у компаний появляется чуть больше пространства для инвестиций в CRM, CDP, automation и data-инфраструктуру.
2) Но это не сигнал «покупать всё подряд»: бюджеты по-прежнему будут резать там, где нет понятного эффекта в выручке, retention или cost savings.
3) Сильнее всего выиграют решения с коротким payback: триггерные коммуникации, персонализация, интеграции и инструменты, которые снимают ручной труд.
📉 Для CMO и martech-ops это, скорее, окно для точечных апгрейдов стека, чем для большого пересборa. Сейчас хорошо продаются не обещания роста, а понятная экономика: сколько сэкономили, что автоматизировали, где сократили time-to-launch.
Что это значит для martech-стека:
1) Деньги дешевеют — у компаний появляется чуть больше пространства для инвестиций в CRM, CDP, automation и data-инфраструктуру.
2) Но это не сигнал «покупать всё подряд»: бюджеты по-прежнему будут резать там, где нет понятного эффекта в выручке, retention или cost savings.
3) Сильнее всего выиграют решения с коротким payback: триггерные коммуникации, персонализация, интеграции и инструменты, которые снимают ручной труд.
📉 Для CMO и martech-ops это, скорее, окно для точечных апгрейдов стека, чем для большого пересборa. Сейчас хорошо продаются не обещания роста, а понятная экономика: сколько сэкономили, что автоматизировали, где сократили time-to-launch.
Хороший техлист для onboarding-а в команду, даже если речь не про Java, а про любой martech-стек.
Автор собрал 5 вещей, которые обычно недооценивают в первый год работы разработчика:
1) люди и коммуникация,
2) работа с задачами,
3) code review,
4) тесты,
5) чистый код и архитектура.
Что здесь важно для CMO / martech-менеджера: почти все боли в CRM/CDP/automation возникают не из-за «плохого кода», а из-за провалов в процессах вокруг него. Когда в команде нет нормального онбординга, ревью и соглашений по качеству, стек быстро превращается в набор костылей. 🤝
Полезная рамка:
— онбординг снижает зависимость от одного «героя»;
— понятные задачи уменьшают переделки;
— code review защищает интеграции и данные;
— тесты критичны там, где есть триггеры, сегменты и синхронизации;
— архитектурная дисциплина экономит бюджет на поддержке.
Если у вас в martech-команде «всё работает, пока никто не трогает» — это как раз сигнал смотреть не только в код, но и в процессы вокруг него.
Автор собрал 5 вещей, которые обычно недооценивают в первый год работы разработчика:
1) люди и коммуникация,
2) работа с задачами,
3) code review,
4) тесты,
5) чистый код и архитектура.
Что здесь важно для CMO / martech-менеджера: почти все боли в CRM/CDP/automation возникают не из-за «плохого кода», а из-за провалов в процессах вокруг него. Когда в команде нет нормального онбординга, ревью и соглашений по качеству, стек быстро превращается в набор костылей. 🤝
Полезная рамка:
— онбординг снижает зависимость от одного «героя»;
— понятные задачи уменьшают переделки;
— code review защищает интеграции и данные;
— тесты критичны там, где есть триггеры, сегменты и синхронизации;
— архитектурная дисциплина экономит бюджет на поддержке.
Если у вас в martech-команде «всё работает, пока никто не трогает» — это как раз сигнал смотреть не только в код, но и в процессы вокруг него.
API-интеграции часто ломаются не на «сложной логике», а на банальном DX: разработчик видит `invalid_request` и дальше уходит в гадание. Для martech-стека это не мелочь — каждый лишний раунд с поддержкой удлиняет time-to-first-value и повышает риск, что интеграцию просто бросят.
Хороший API сообщает не только факт ошибки, но и контекст: что сломалось, в каком поле, какой ожидается формат, как это исправить. По сути, это тот же RFC 9457, но в практическом виде: машинно читаемо, предсказуемо, без загадок. Чем скучнее и стабильнее поведение API, тем лучше для ops-команды и внедрения у клиента. 🤖
Полезный ориентир для продукта: считать не только количество ошибок, но и время до первого успешного запроса. Если его можно сократить шаблоном ответа, примерами payload и понятными кодами — это часто дешевле, чем расширять саппорт или писать очередной «guide for beginners».
Хороший API сообщает не только факт ошибки, но и контекст: что сломалось, в каком поле, какой ожидается формат, как это исправить. По сути, это тот же RFC 9457, но в практическом виде: машинно читаемо, предсказуемо, без загадок. Чем скучнее и стабильнее поведение API, тем лучше для ops-команды и внедрения у клиента. 🤖
Полезный ориентир для продукта: считать не только количество ошибок, но и время до первого успешного запроса. Если его можно сократить шаблоном ответа, примерами payload и понятными кодами — это часто дешевле, чем расширять саппорт или писать очередной «guide for beginners».
Хороший код не спасает плохую архитектуру — и в martech это особенно видно.
Можно собрать аккуратную форму, красивый UI и даже “правильные” компоненты. Но если под капотом:
— логика размазана по слоям,
— интеграции живут отдельно от доменной модели,
— данные о клиенте собираются в разных местах без единого правила,
то через 2–3 года любой новый кейс превращается в раскопки. В CRM/CDP это выглядит так же: вроде всё работает, но любое изменение в сегментации, триггерах или атрибуции ломает соседний процесс.
Практический вывод простой:
1) хороший код = читаемость и поддержка здесь и сейчас;
2) хорошая архитектура = возможность без боли добавлять новые каналы, поля, сценарии и источники данных;
3) если система зависит от “того самого человека, который помнит, как это устроено”, это уже технический долг, а не продуктовая гибкость.
Для martech-команды вопрос не в том, писать ли “аккуратно”, а в том, можно ли потом это масштабировать без переписывания ядра. 🧩
Можно собрать аккуратную форму, красивый UI и даже “правильные” компоненты. Но если под капотом:
— логика размазана по слоям,
— интеграции живут отдельно от доменной модели,
— данные о клиенте собираются в разных местах без единого правила,
то через 2–3 года любой новый кейс превращается в раскопки. В CRM/CDP это выглядит так же: вроде всё работает, но любое изменение в сегментации, триггерах или атрибуции ломает соседний процесс.
Практический вывод простой:
1) хороший код = читаемость и поддержка здесь и сейчас;
2) хорошая архитектура = возможность без боли добавлять новые каналы, поля, сценарии и источники данных;
3) если система зависит от “того самого человека, который помнит, как это устроено”, это уже технический долг, а не продуктовая гибкость.
Для martech-команды вопрос не в том, писать ли “аккуратно”, а в том, можно ли потом это масштабировать без переписывания ядра. 🧩