Короткий домен Telegram перестал работать

Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.

➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat

🧠 Ещё больше инсайтов → в канале AFF.top

Как BigQuery помог ритейлу увидеть, что «дешёвый» канал на самом деле съедает LTV

В 2026 году в e-com и retail всё чаще смотрят не на первую покупку, а на то, что происходит через 30, 60 и 90 дней. У крупной сети с омниканальными продажами была типичная проблема: performance-каналы отчитывались по last-click (последний клик), CRM жила отдельно, офлайн-чеки — отдельно, а лояльность считали в BI «по ощущениям».

**Контекст.** Канал привлекал трафик с хорошим CPA (стоимость привлечения), но у маркетинга не было ответа: это действительно «дешёвый» источник или просто источник разовых покупателей? По данным за квартал, 42% новых клиентов приходили через один из performance-каналов, но их повторная покупка через 60 дней была на 19% ниже среднего по базе.

**Задача.** Собрать единую картину: первый визит, заказ, возврат, повторная покупка, офлайн-покупка, участие в программе лояльности и влияние кампаний на LTV (пожизненную ценность клиента). Без ручных выгрузок и еженедельных сводных таблиц.

**Решение.** Все сырые события из сайта, приложения, CRM и касс свели в BigQuery. Дальше сделали три слоя:
— нормализация идентификаторов клиента;
— объединение онлайн- и офлайн-покупок в единую цепочку;
— расчёт когорты по первому источнику трафика и поведению на горизонте 30/60/90 дней.

Отдельно построили витрину для attribution (атрибуции) по принципу first touch + assisted conversions, а не только last-click. Это важно в эпоху privacy-first, когда классическая цепочка касаний видна не полностью, и опираться только на последний клик становится опасно.

**Результат.** Оказалось, что канал с самым низким CPA давал:
— на 14% меньше повторных покупок за 90 дней;
— на 11% ниже средний чек второй покупки;
— на 8% хуже вклад в валовую маржу после возвратов.

После перераспределения бюджета в пользу двух каналов с более высоким CPA, но лучшим LTV, общий CAC вырос всего на 6%, зато выручка от повторных покупок за 90 дней — на 17%. Для команды это был важный сдвиг: перестали покупать «дешёвый трафик», начали покупать будущую выручку.

**Урок.** Если маркетинг в BigQuery не связывает первый клик, повторную покупку и офлайн, он оптимизирует не рост, а шум. В 2026 году выигрывает не тот, кто показывает самый низкий CPA, а тот, кто умеет доказать вклад канала в LTV и маржу.

— @BigQuery4MarketingPro

Youtube тестирует поиск с AI

YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

🧠 Ещё больше инсайтов → в канале AFF.top

Тег-менеджер не заменяет IT-отдел: что маркетологу делать самому, а что нет

— **Разделяйте зоны ответственности до установки GTM.** Маркетинг заводит теги и dataLayer-события, IT отвечает за инфраструктуру: выкатку контейнера, версионирование, CSP-политики (Content Security Policy — политика безопасности контента) и доступы. Без этого соглашения любой «быстрый» тег через месяц превращается в технический долг.

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

— **Не выкатывайте контейнер без процесса релизов.** Даже при «самообслуживании» маркетинга нужны среды (dev, prod), код-ревью хотя бы на уровне пары глаз, журнал изменений и план отката. Без версионирования вы не докажете аудиторам и самим себе, какой тег сломал воронку.

— **Контролируйте технический долг тегов по расписанию.** Раз в квартал удаляйте неиспользуемые триггеры и переменные, сверяйте список пикселей с актуальным медиапланом, проверяйте порядок активации (Tag Sequencing). Накопившийся мусор замедляет загрузку и размывает данные в BigQuery.

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

— **Используйте серверный GTM (server-side tagging) как точку совместной работы.** Перенос обработки запросов на сервер маркетинга снимает нагрузку с IT на edge (сетевом периметре) и одновременно требует их участия в DevOps (настройке серверов, логирования, проксирования). Это новая общая зона, а не повод отказаться от взаимодействия.

— **Платите за качество данных временем IT, а не бюджетом на костыли.** Самописные события, ручные выгрузки и таблицы «для своих» появляются там, где аналитик не смог получить ресурс разработчика. Считайте эти затраты — они почти всегда дороже пары часов IT в спринте.

**Когда это пригодится:** при переходе на server-side контейнер, при аудите контейнера после смены подрядчика и при построении сквозной атрибуции в privacy-first эпохе, когда каждый лишний клиентский пиксель мешает и сбору, и производительности сайта.

— @BigQuery4MarketingPro

Z.ai анонсировала новую GLM-5.5

Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.

Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.

Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5

🧠 Ещё больше инсайтов → в канале AFF.top

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

🧠 Ещё больше инсайтов → в канале AFF.top

RevOps-метрики в 2026 всё чаще живут не в CRM, а в витринах: серверные события, разрезы по сегментам и инкрементальность. Вы реально сверяете маркетинговые отчёты с тем, что видит BigQuery, или «верите» BI-вычислениям?

Вопрос: что вы проверяете в BigQuery, прежде чем говорить о влиянии кампании на выручку?

ВАРИАНТЫ:
1. Каналы и атрибуция: дельта по окнам, без last-click-иллюзий
2. Качество данных: пропуски, дубликаты, соответствие справочникам
3. Инкрементальность: holdout/квази-эксперименты вместо корреляций
4. Согласование выручки: единая логика join с продажами и возвратами

— @BigQuery4MarketingPro

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

🧠 Ещё больше инсайтов → в канале AFF.top

Почему я перестал доверять одной атрибуции в маркетинге

В 2026 году главный риск для маркетолога — не нехватка данных, а вера в одну «правильную» модель. Я всё чаще вижу, как команды строят решения на last-click, потому что он удобный, или на MMM, потому что он «солидный», а потом удивляются, почему бюджет уходит не туда.

Моя позиция простая: **в маркетинге для бизнеса не бывает единственного источника правды**. Особенно когда путь клиента стал длиннее, а часть касаний вообще уходит в zero-click-среду: человек видит контент, читает AI-overview, возвращается через брендовый поиск и покупает спустя неделю. В такой картине last-click почти всегда переоценивает финальное касание, а MMM без качественной событийной базы начинает сглаживать важные детали.

В BigQuery я предпочитаю собирать не «отчёт ради отчёта», а рабочую систему проверки гипотез:
— смотрю вклад канала в первый контакт, в возврат и в выручку;
— сравниваю когорты по времени до покупки и повторной покупке;
— отдельно считаю effect holdout-подобные срезы, когда есть возможность;
— сверяю маркетинговые события с данными CRM и выручкой из учёта.

Один практический пример: в B2B-проекте почти 38% сделок, которые last-click отдавал поиску, начинались с экспертного контента и возвращались через брендовые запросы. Если бы мы оставили только last-click, то урезали бы верх воронки и потеряли бы вклад контента в RevOps-цепочку.

Я считаю, что задача аналитика в маркетинге сегодня — не выбрать «любимую» модель, а построить **согласованную картину**: где есть спрос, где его создают, и где канал реально ускоряет выручку. BigQuery как раз хорош тем, что позволяет не спорить про теории, а проверять их на своих данных.

— @BigQuery4MarketingPro

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

🧠 Ещё больше инсайтов → в канале AFF.top

Событийный маркетинг (Event-based modeling) против пакетной обработки (Batch processing)

В эпоху, когда классическая атрибуция по последнему клику уступает место Privacy-first подходам (подход с приоритетом конфиденциальности), понимание архитектуры данных в BigQuery становится критическим навыком.

Пакетная обработка — это регулярная загрузка данных в хранилище, например, раз в сутки. Это удобно для подготовки отчетности по вчерашним KPI (ключевым показателям эффективности).

Событийный подход подразумевает передачу каждого действия пользователя (просмотр, клик, оплата) в реальном времени. В BigQuery это реализуется через потоковую запись (Streaming insert).

Ключевое отличие:
— Пакетная модель эффективна для обучения моделей маркетингового микса (MMM), где высокая частота обновления не требуется.
— Событийная модель критична для RevOps (управление выручкой), когда необходимо мгновенно реагировать на поведение клиента для удержания (Retention) или изменения стратегии продаж.

Типичная ошибка — пытаться строить сквозную аналитику только на пакетных выгрузках. Это приводит к разрыву в данных при расчете LTV (пожизненной ценности клиента) в динамике.

Пример: если e-com проект фиксирует брошенную корзину событийно, BigQuery успевает инициировать отправку персонального предложения через CRM до того, как пользователь уйдет на сайт конкурента. В пакетной модели это действие было бы зафиксировано только на следующее утро, когда интерес клиента уже угас.

— @BigQuery4MarketingPro

AI-часть в продажах и маркетинге: 3 подхода, которые можно разложить в BigQuery

Этот обзор нужен маркетологам и RevOps-связке, когда вы пытаетесь понять, где AI реально помогает воронке (в терминах: качество лида, скорость реакции, конверсия в MQL/SQL и выручка), а где остаётся красивой витриной. В 2026-м ценность не в «генерации текста», а в измеримости: что улучшилось в данных, и можно ли это доказать без last-click.

AI-ассистенты для менеджеров (помощь на встречах/в CRM) — для команд B2B, которые ведут сделки через звонки и встречи — сильная сторона: ускоряют работу с репликами и поддерживают сценарии выявления потребностей (логика “задавай больше правильных вопросов”, а не “говори о продукте”) — слабая сторона / минус: часто внедряют как “обучалку”, но без метрик качества диалога и без связки с конверсией в CRM (получается эффект “стало удобнее разговаривать”, а не “стало лучше продавать”)

AI-агенты для “inbound-видимости” и агентных воркфлоу — для маркетинга, который пережил просадку классического inbound и теперь ищет контроль над каналами и намерением — сильная сторона: помогают перестроить процессы так, чтобы команда видела, что именно даёт сигнал (контент, запросы, действия на сайте) и быстрее запускала гипотезы — слабая сторона / минус: есть риск превратить агентность в черный ящик; без выгрузок событий в единую модель данных вы не сможете проверить причинность и воспроизвести результат

AI для атрибуции и доказательства прироста (incrementality-логика вместо “на кого списали”) — для RevOps и аналитики, которым нужна privacy-first атрибуция и контроль эффекта — сильная сторона: позволяет измерять вклад кампаний через тесты/модели прироста, а не только через цепочки касаний — слабая сторона / минус: требует дисциплины данных (события, охват, когорты, калибровки), иначе AI будет подгонять историю под метрику, которую вы сами неправильно собрали

Как выбирать — начните с вопроса “какая бизнес-метрика улучшится и как мы это докажем в BigQuery”: если нет схемы событий → CRM-этапов → выручки/retention, любой AI останется скорее удобством, чем инструментом роста.

— @BigQuery4MarketingPro

Почему в BigQuery я сначала строю не отчёт, а модель вопроса

Я много раз видел одну и ту же ошибку: маркетолог приходит в BigQuery за «дешёвым отчётом», а уходит с таблицей, которая выглядит умно, но не отвечает ни на один бизнес-вопрос. В 2026 это особенно заметно: данных стало больше, а ценность сместилась от объёма к точности решения.

Мой подход другой. Сначала я формулирую, **какое решение будет принято по результату запроса**. Если ответа на это нет, запрос почти наверняка лишний.

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

Один практический пример: в B2B-проекте мы сравнили три отчёта по лидогенерации. Классический отчёт по MQL показывал рост на 18%, но когда я собрал данные в BigQuery по этапам RevOps-воронки, выяснилось, что до оплаты доходит не больше, а меньше заявок. Формально маркетинг «побеждал», по факту — перегревал верх воронки. После пересборки логики отчётности команда сократила лишние кампании и перераспределила бюджет в пользу каналов, которые давали не лиды, а выручку.

Поэтому мой принцип простой: **в BigQuery я проектирую не таблицу, а управленческую модель**. Это особенно важно сейчас, когда:
— SEO уходит в сторону тематического авторитета, а не набора запросов;
— в B2B MQL и SQL теряют смысл без привязки к выручке;
— last-click всё чаще врет в privacy-first мире.

Если запрос нельзя связать с действием, экономией бюджета или ростом LTV, я его не делаю. BigQuery не должен быть складом красивых цифр. Он должен быть машиной для принятия решений.

— @BigQuery4MarketingPro