Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google стал помечать креативы, созданные ИИ
Google объявил, что начнёт помечать рекламные креативы, созданные нейросетями. Причина — ИИ-баннеры и видео стали слишком похожи на настоящие.
Формат и заметность маркировки будут зависеть от законов конкретного региона: где-то предупреждение появится прямо на креативе, где-то — в его информации.
Что это значит для арбитражников и когда правила …
➡️ Читайте на сайте: https://aff.top/blog/google-stal-pomechat-kreativy-sozdannye-ii
🧠 Ещё больше инсайтов → в канале AFF.top
Google объявил, что начнёт помечать рекламные креативы, созданные нейросетями. Причина — ИИ-баннеры и видео стали слишком похожи на настоящие.
Формат и заметность маркировки будут зависеть от законов конкретного региона: где-то предупреждение появится прямо на креативе, где-то — в его информации.
Что это значит для арбитражников и когда правила …
➡️ Читайте на сайте: https://aff.top/blog/google-stal-pomechat-kreativy-sozdannye-ii
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Компания Meta выпустила Muse Spark 1.1
Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.
Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.
Но главный вопрос — насколько она реально сильна на фоне к…
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1
🧠 Ещё больше инсайтов → в канале AFF.top
Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.
Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.
Но главный вопрос — насколько она реально сильна на фоне к…
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1
🧠 Ещё больше инсайтов → в канале AFF.top
Событийные кастом-обработчики в Google Tag Manager: чек-лист для BI/дата-слоя
Если ваш BI страдает от “кривых” событий (разные названия, пропуски параметров, дубль-трекинг), кастомные event listeners в Google Tag Manager — самый белый способ стабилизировать поток данных, не разрывая вёрстку и не плодя зоопарк тегов.
1) Разведите “событие страницы” и “событие модели данных”
— В GTM слушайте именно системный сигнал (например, пользователь инициировал действие), а параметры сразу нормализуйте под ваш датасет (единые поля: action, object, value, source_channel).
— Цель: чтобы downstream (дашборды, витрины, отчёты) не зависели от того, как фронт “сказал” событие.
2) Подключите кастомный обработчик через event-слушатель, а не через цепочки PageView
— Делайте обработку на уровне GTM logic: событие приходит → валидируете обязательные поля → отправляете в Data Layer/втягиваете в ваш тег.
— Так вы избегаете ситуации, когда PageView-триггеры начинают маскировать реальное поведение.
3) Закрепите схему параметров (контракт) и проверяйте её до отправки
— Перед отправкой в GA/серверные события (или в ваш трекинг-слой) проверьте: типы, наличие ключей, допустимые значения.
— Добавьте “fail-safe”: если параметр пустой — не отправляйте или отправляйте null по согласованным правилам.
4) Сводите названия событий к единому словарю
— Прямо в обработчике делайте маппинг: UI-сигнал/локальные имена → каноническое имя события (например, “lead_submit”, “request_pricing”, “download_pdf”).
— Это снижает количество несовместимых измерений в BI и упрощает Topical Authority вашего внутреннего знания (команда начинает говорить одним языком).
5) Учитывайте privacy-first атрибуцию: не полагайтесь на last-click в метриках
— Используйте события как входные данные для расчётов, а не как единственный источник “истории” пользователя.
— Для ценных событий (MQL/SQL, старт диалога с CSM, повторное действие) планируйте серверную/агрегированную схему и инкрементальность (MMM или incrementality) в модели выручки.
6) Настройте отладку: тестируйте “до” и “после” трансформаций
— В GTM Preview/дебагер проверяйте: что именно прилетает в Data Layer, какие параметры добавляются/заменяются кастом-обработчиком.
— Отдельно проверьте дубли: одно действие не должно генерировать два события в разных тегах.
7) Документируйте обработчики как часть BI-словаря
— Для каждого кастомного события: источник сигнала, контракт параметров, примеры payload, владелец и частота изменения.
— В 2026 это особенно важно: AI-overviews и “zero-click” повышают требования к качеству собственной аналитической экспертизы — ваши события должны быть надежной основой.
когда это пригодится: при внедрении/рефакторинге event-трекинга под дашборды, где сейчас не сходятся метрики между GTM, аналитикой и витриной данных.
— @MarketingAnalyticsRoomPro
Если ваш BI страдает от “кривых” событий (разные названия, пропуски параметров, дубль-трекинг), кастомные event listeners в Google Tag Manager — самый белый способ стабилизировать поток данных, не разрывая вёрстку и не плодя зоопарк тегов.
1) Разведите “событие страницы” и “событие модели данных”
— В GTM слушайте именно системный сигнал (например, пользователь инициировал действие), а параметры сразу нормализуйте под ваш датасет (единые поля: action, object, value, source_channel).
— Цель: чтобы downstream (дашборды, витрины, отчёты) не зависели от того, как фронт “сказал” событие.
2) Подключите кастомный обработчик через event-слушатель, а не через цепочки PageView
— Делайте обработку на уровне GTM logic: событие приходит → валидируете обязательные поля → отправляете в Data Layer/втягиваете в ваш тег.
— Так вы избегаете ситуации, когда PageView-триггеры начинают маскировать реальное поведение.
3) Закрепите схему параметров (контракт) и проверяйте её до отправки
— Перед отправкой в GA/серверные события (или в ваш трекинг-слой) проверьте: типы, наличие ключей, допустимые значения.
— Добавьте “fail-safe”: если параметр пустой — не отправляйте или отправляйте null по согласованным правилам.
4) Сводите названия событий к единому словарю
— Прямо в обработчике делайте маппинг: UI-сигнал/локальные имена → каноническое имя события (например, “lead_submit”, “request_pricing”, “download_pdf”).
— Это снижает количество несовместимых измерений в BI и упрощает Topical Authority вашего внутреннего знания (команда начинает говорить одним языком).
5) Учитывайте privacy-first атрибуцию: не полагайтесь на last-click в метриках
— Используйте события как входные данные для расчётов, а не как единственный источник “истории” пользователя.
— Для ценных событий (MQL/SQL, старт диалога с CSM, повторное действие) планируйте серверную/агрегированную схему и инкрементальность (MMM или incrementality) в модели выручки.
6) Настройте отладку: тестируйте “до” и “после” трансформаций
— В GTM Preview/дебагер проверяйте: что именно прилетает в Data Layer, какие параметры добавляются/заменяются кастом-обработчиком.
— Отдельно проверьте дубли: одно действие не должно генерировать два события в разных тегах.
7) Документируйте обработчики как часть BI-словаря
— Для каждого кастомного события: источник сигнала, контракт параметров, примеры payload, владелец и частота изменения.
— В 2026 это особенно важно: AI-overviews и “zero-click” повышают требования к качеству собственной аналитической экспертизы — ваши события должны быть надежной основой.
когда это пригодится: при внедрении/рефакторинге event-трекинга под дашборды, где сейчас не сходятся метрики между GTM, аналитикой и витриной данных.
— @MarketingAnalyticsRoomPro
RevOps-метрики в дашборде: как я собираю «сверху вниз» вместо набора KPI
В 2026 я всё чаще вижу одну и ту же проблему в BI: дашборд превращается в витрину метрик, которые «вроде важные», но не отвечают на главный вопрос бизнеса — что именно двигает выручку и почему. Особенно в B2B, где связка лидогенерации MQL/SQL уже не даёт того эффекта, который от неё ожидают. Маркетинг всё сильнее становится частью RevOps (общей ответственности маркетинга, продаж и customer success за выручку), а значит и измерять нужно не активность по воронке, а экономику результата.
Моё правило для RevOps-дашборда: сначала проектирую агрегатную модель, потом только под неё подбираю метрики и визуализации. Не наоборот.
1) Начинаю не с воронки, а с единицы стоимости
Для меня единица стоимости в B2B почти всегда одна из двух:
— «выручка на аккаунт/контракт» (в зависимости от модели продаж)
— «маржинальная выручка на сделку/портфель»
Дальше я задаю вопрос: какие события в данных гарантированно коррелируют с ростом этой единицы? Обычно это не «количество лидов», а:
— прогресс по qualification (качественные сигналы, а не факт контакта)
— скорость прохождения стадий, где есть деньги на горизонте (time-to-next-step)
— удержание/расширение (expansion) и повторяемость потребления (для продуктовых договоров)
2) Собираю KPI как систему уравнений, а не как список
В классическом отчёте часто есть разрозненные KPI: CAC, конверсии, pipeline coverage, MQL/SQL. В RevOps это ломается, потому что нет общей логики «маркетинг → продажа → успех → деньги».
Я делаю так:
— верхний уровень: **Net Revenue** (чистая выручка) и её маржинальная компонента
— средний уровень: contribution марктинга/CS в Net Revenue через интерпретацию влияния (не через last-click, а через согласованные окна и инкрементальность где возможно)
— нижний: объясняющие драйверы (доля аккаунтов с нужным fit, конверсия в нужный next-step, удержание, расширение)
Да, это сложнее, зато дашборд перестаёт быть «складом цифр» и становится инструментом диалога между функциями.
3) Делаю один «сквозной» разрез, который всё объединяет
В B2B чаще всего сквозную идентификацию ломают: то всё на lead-уровне, то на deal-уровне, то на подписке/контракте. Я закладываю один главный разрез — Account (аккаунт) или Contract (контракт) — и уже к нему подтягиваю:
— маркетинговые касания и их агрегаты (количество релевантных касаний, источники тем/контента)
— активность продаж (steps, встречи, stage duration)
— success-активности (onboarding milestones, usage, health score)
Ключ: один разрез — один «ключ правды». Тогда обсуждения не превращаются в спор о том, что считать конверсией.
4) Отдельно: почему я не верю одному числу «конверсия»
В privacy-first реальности и при уходе от простого last-click почти любая одиночная конверсия становится контекстно-неполной. Поэтому я в дашбордах держу «конверсию с условиями»:
— конверсия в next-step при наличии fit-сигналов
— конверсия при корректном SLA обработки (время ответа/передачи)
— конверсия по когорте входа (например, месяц старта кампании или месяц первого релевантного взаимодействия)
Это не просто красиво — это предотвращает ложные выводы. Когда у команды проседает pipeline, всегда есть риск свалить причину на маркетинг, хотя на деле провал в скорости реакции или в сегментации.
Наблюдение из практики (цифра)
На одном из внедрений мы сравнили два BI-способа описания воронки:
— «витринный» подход: лиды → MQL → SQL → deal
— RevOps-логика: аккаунты → прогресс по qualification-стадиям → контракт → расширение
В первом случае команды объясняли падение квартала тем, что «мало MQL». Во втором — выяснилось, что MQL были, но доля аккаунтов с нужным fit-сегментом уменьшилась, и ключевой эффект был не в объёме касаний, а в качестве попадания (агрегация по источникам тем и триггерам квалификации). Как результат, корректирующие действия пошли не в увеличение лидов, а в пересборку message-to-audience (соответствие послания аудитории) и в фильтры handoff. В метриках это отразилось как снижение потерь на стадии qualification и сокращение stage duration.
…
В 2026 я всё чаще вижу одну и ту же проблему в BI: дашборд превращается в витрину метрик, которые «вроде важные», но не отвечают на главный вопрос бизнеса — что именно двигает выручку и почему. Особенно в B2B, где связка лидогенерации MQL/SQL уже не даёт того эффекта, который от неё ожидают. Маркетинг всё сильнее становится частью RevOps (общей ответственности маркетинга, продаж и customer success за выручку), а значит и измерять нужно не активность по воронке, а экономику результата.
Моё правило для RevOps-дашборда: сначала проектирую агрегатную модель, потом только под неё подбираю метрики и визуализации. Не наоборот.
1) Начинаю не с воронки, а с единицы стоимости
Для меня единица стоимости в B2B почти всегда одна из двух:
— «выручка на аккаунт/контракт» (в зависимости от модели продаж)
— «маржинальная выручка на сделку/портфель»
Дальше я задаю вопрос: какие события в данных гарантированно коррелируют с ростом этой единицы? Обычно это не «количество лидов», а:
— прогресс по qualification (качественные сигналы, а не факт контакта)
— скорость прохождения стадий, где есть деньги на горизонте (time-to-next-step)
— удержание/расширение (expansion) и повторяемость потребления (для продуктовых договоров)
2) Собираю KPI как систему уравнений, а не как список
В классическом отчёте часто есть разрозненные KPI: CAC, конверсии, pipeline coverage, MQL/SQL. В RevOps это ломается, потому что нет общей логики «маркетинг → продажа → успех → деньги».
Я делаю так:
— верхний уровень: **Net Revenue** (чистая выручка) и её маржинальная компонента
— средний уровень: contribution марктинга/CS в Net Revenue через интерпретацию влияния (не через last-click, а через согласованные окна и инкрементальность где возможно)
— нижний: объясняющие драйверы (доля аккаунтов с нужным fit, конверсия в нужный next-step, удержание, расширение)
Да, это сложнее, зато дашборд перестаёт быть «складом цифр» и становится инструментом диалога между функциями.
3) Делаю один «сквозной» разрез, который всё объединяет
В B2B чаще всего сквозную идентификацию ломают: то всё на lead-уровне, то на deal-уровне, то на подписке/контракте. Я закладываю один главный разрез — Account (аккаунт) или Contract (контракт) — и уже к нему подтягиваю:
— маркетинговые касания и их агрегаты (количество релевантных касаний, источники тем/контента)
— активность продаж (steps, встречи, stage duration)
— success-активности (onboarding milestones, usage, health score)
Ключ: один разрез — один «ключ правды». Тогда обсуждения не превращаются в спор о том, что считать конверсией.
4) Отдельно: почему я не верю одному числу «конверсия»
В privacy-first реальности и при уходе от простого last-click почти любая одиночная конверсия становится контекстно-неполной. Поэтому я в дашбордах держу «конверсию с условиями»:
— конверсия в next-step при наличии fit-сигналов
— конверсия при корректном SLA обработки (время ответа/передачи)
— конверсия по когорте входа (например, месяц старта кампании или месяц первого релевантного взаимодействия)
Это не просто красиво — это предотвращает ложные выводы. Когда у команды проседает pipeline, всегда есть риск свалить причину на маркетинг, хотя на деле провал в скорости реакции или в сегментации.
Наблюдение из практики (цифра)
На одном из внедрений мы сравнили два BI-способа описания воронки:
— «витринный» подход: лиды → MQL → SQL → deal
— RevOps-логика: аккаунты → прогресс по qualification-стадиям → контракт → расширение
В первом случае команды объясняли падение квартала тем, что «мало MQL». Во втором — выяснилось, что MQL были, но доля аккаунтов с нужным fit-сегментом уменьшилась, и ключевой эффект был не в объёме касаний, а в качестве попадания (агрегация по источникам тем и триггерам квалификации). Как результат, корректирующие действия пошли не в увеличение лидов, а в пересборку message-to-audience (соответствие послания аудитории) и в фильтры handoff. В метриках это отразилось как снижение потерь на стадии qualification и сокращение stage duration.
…
Почему один дашборд почти всегда врет
Я много раз видел одну и ту же ошибку: компания строит «единую правду» в BI, а потом спорит не о решении, а о том, какой столбец считать правильным. На бумаге дашборд должен ускорять управление. На практике он часто превращается в музей KPI, где красиво видно всё, кроме сути.
Моя позиция простая: **хороший дашборд не показывает бизнес целиком, он отвечает на один управленческий вопрос**. Если вопроса нет, BI начинает разрастаться в витрину метрик. И чем больше в ней графиков, тем меньше вероятность, что ими кто-то реально пользуется.
В 2026 это особенно заметно. Когда атрибуция уходит в сторону server-side, MMM и инкрементальности, привычный last-click перестаёт быть опорой. Но вместо зрелой аналитики многие команды просто добавляют ещё один слой визуализации. В итоге маркетинг смотрит на CAC, sales — на pipeline, продукт — на retention, а руководство — на выручку. Все правы, но никто не связан общей логикой.
У меня лучше всего работают дашборды, которые собраны по принципу:
— один экран = одна управленческая роль;
— одна роль = 3–5 решений, которые человек реально принимает;
— каждая метрика должна вести к действию, а не к обсуждению формулы.
В одном B2B-проекте мы сократили число «главных» метрик с 18 до 6. Парадоксально, но после этого выросло не только число открытий дашборда, но и скорость согласования бюджета. Причина была не в дизайне. Мы просто убрали шум и оставили те показатели, по которым команда могла спорить предметно.
Я считаю, что зрелый BI — это не про визуализацию. Это про дисциплину мышления. Если дашборд не помогает быстрее принять решение, значит, это не инструмент управления, а дорогая декоративная панель.
— @MarketingAnalyticsRoomPro
Я много раз видел одну и ту же ошибку: компания строит «единую правду» в BI, а потом спорит не о решении, а о том, какой столбец считать правильным. На бумаге дашборд должен ускорять управление. На практике он часто превращается в музей KPI, где красиво видно всё, кроме сути.
Моя позиция простая: **хороший дашборд не показывает бизнес целиком, он отвечает на один управленческий вопрос**. Если вопроса нет, BI начинает разрастаться в витрину метрик. И чем больше в ней графиков, тем меньше вероятность, что ими кто-то реально пользуется.
В 2026 это особенно заметно. Когда атрибуция уходит в сторону server-side, MMM и инкрементальности, привычный last-click перестаёт быть опорой. Но вместо зрелой аналитики многие команды просто добавляют ещё один слой визуализации. В итоге маркетинг смотрит на CAC, sales — на pipeline, продукт — на retention, а руководство — на выручку. Все правы, но никто не связан общей логикой.
У меня лучше всего работают дашборды, которые собраны по принципу:
— один экран = одна управленческая роль;
— одна роль = 3–5 решений, которые человек реально принимает;
— каждая метрика должна вести к действию, а не к обсуждению формулы.
В одном B2B-проекте мы сократили число «главных» метрик с 18 до 6. Парадоксально, но после этого выросло не только число открытий дашборда, но и скорость согласования бюджета. Причина была не в дизайне. Мы просто убрали шум и оставили те показатели, по которым команда могла спорить предметно.
Я считаю, что зрелый BI — это не про визуализацию. Это про дисциплину мышления. Если дашборд не помогает быстрее принять решение, значит, это не инструмент управления, а дорогая декоративная панель.
— @MarketingAnalyticsRoomPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Российские букмекеры увеличили закуп трафика с мобильных приложений
Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.
По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…
➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii
🧠 Ещё больше инсайтов → в канале AFF.top
Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.
По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…
➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Mia Khalifa стала амбпссадором 1win
Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».
Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.
Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…
➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win
🧠 Ещё больше инсайтов → в канале AFF.top
Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».
Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.
Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…
➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from КРАВЧЕНКО
Дорогие коллеги и партнеры,
Наш маршрут конференций за последние недели, получился особенно насыщенным.
Со стендами PoshFriends мы побывали на MAC и GGate, а затем продолжили встречи уже в полях iGB Live в Лондоне.
В Ереване увиделись с любимыми SEO-командами, попробовали местные вина, обменялись новостями и зарядились энергией УБТ-команд.
В Тбилиси обсуждали тренды, новые связки и совместные планы, встречались с действующими партнерами и знакомились с новыми. А за настроение на стенде отвечала Черемша, которая чуть не стала маскотом одного из наших продуктов. С этой задачей, кажется, справилась лучше всех.
В Лондоне все было уже по-деловому. Провели серию встреч с топ-партнерами, обсудили Японию, бурж и новые точки роста. География интересов растет, планы становятся амбициознее. Воротники, как выяснилось, нагладили не зря.
Спасибо всем, с кем удалось увидеться на этом маршруте. За открытые разговоры, новые идеи, доверие и планы, которые постепенно превращаются в реальные проекты.
Конференционный сезон продолжается. Скоро увидимся снова.
Всегда ваши, Команда Posh Friends 🤝
Наш маршрут конференций за последние недели, получился особенно насыщенным.
Со стендами PoshFriends мы побывали на MAC и GGate, а затем продолжили встречи уже в полях iGB Live в Лондоне.
В Ереване увиделись с любимыми SEO-командами, попробовали местные вина, обменялись новостями и зарядились энергией УБТ-команд.
В Тбилиси обсуждали тренды, новые связки и совместные планы, встречались с действующими партнерами и знакомились с новыми. А за настроение на стенде отвечала Черемша, которая чуть не стала маскотом одного из наших продуктов. С этой задачей, кажется, справилась лучше всех.
В Лондоне все было уже по-деловому. Провели серию встреч с топ-партнерами, обсудили Японию, бурж и новые точки роста. География интересов растет, планы становятся амбициознее. Воротники, как выяснилось, нагладили не зря.
Спасибо всем, с кем удалось увидеться на этом маршруте. За открытые разговоры, новые идеи, доверие и планы, которые постепенно превращаются в реальные проекты.
Конференционный сезон продолжается. Скоро увидимся снова.
Всегда ваши, Команда Posh Friends 🤝
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Короткий домен Telegram перестал работать
Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.
➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat
🧠 Ещё больше инсайтов → в канале AFF.top
Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.
➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat
🧠 Ещё больше инсайтов → в канале AFF.top
Как собрать дашборд LTV-по-сегментам, когда нет CRM-данных
Шаг 1. Определи сегменты по среднему чеку.
Разбей все покупки на 3-4 корзины: до 1000 ₽, 1000-5000 ₽, 5000-20000 ₽, свыше 20000 ₽. Это черновая сегментация, не нужно ждать маркетинговых гипотез. Границы корзин подбирай так, чтобы в каждой оказалось не меньше 15% базы, иначе данные будут шуметь.
Шаг 2. Собери когорты по месяцу первой покупки.
Для каждого сегмента построй когортную таблицу: строки — месяц первой покупки, столбцы — номера месяцев жизни (M0, M1, M3, M6, M12). В ячейках — кумулятивный средний LTV на пользователя. Считай именно средний, а не сумму, чтобы когорты разного размера были сравнимы.
Шаг 3. Раздели повторные покупки и реактивации.
LTV сегмента «средний чек 1000-5000 ₽» через 6 месяцев — это одно, а вклад тех, кто вернулся после паузы — другое. Вынеси реактивации (заказы после 90+ дней молчания) в отдельный столбец. Это покажет, какой сегмент растёт за счёт возврата, а какой — за счёт органики.
Шаг 4. Наложи стоимость привлечения.
К когортной таблице добавь строку CAC (стоимость привлечения клиента) по каждому сегменту на M0. Считай ROMI на каждом горизонте: (LTV - CAC) / CAC. Это превратит «средний чек сегмента» в ответ на вопрос «куда вкладывать бюджет».
Шаг 5. Сделай лёгкий фильтр, а не дашборд на 50 графиков.
Один лист: когортная таблица + линейный график LTV vs CAC по сегментам + сегментный срез (выпадающий список). Всё. В BI-систему это переносится, только когда команда начнёт реально пользоваться таблицей хотя бы раз в неделю.
Шаг 6. Назначь ритуал обновления.
Один раз в неделю, в один и тот же день, один и тот же человек. Без ритуала таблица устареет за месяц и перестанет восприниматься как инструмент.
Ошибка, которая съедает результат: сравнивать сегменты по выручке, а не по маржинальности. Сегмент с высоким средним чеком может давать меньше прибыли, если маржа на эти товары 5% против 25% в другом сегменте. Маржу добавляй отдельной строкой сразу, иначе будешь пересчитывать полквартала.
— @MarketingAnalyticsRoomPro
Шаг 1. Определи сегменты по среднему чеку.
Разбей все покупки на 3-4 корзины: до 1000 ₽, 1000-5000 ₽, 5000-20000 ₽, свыше 20000 ₽. Это черновая сегментация, не нужно ждать маркетинговых гипотез. Границы корзин подбирай так, чтобы в каждой оказалось не меньше 15% базы, иначе данные будут шуметь.
Шаг 2. Собери когорты по месяцу первой покупки.
Для каждого сегмента построй когортную таблицу: строки — месяц первой покупки, столбцы — номера месяцев жизни (M0, M1, M3, M6, M12). В ячейках — кумулятивный средний LTV на пользователя. Считай именно средний, а не сумму, чтобы когорты разного размера были сравнимы.
Шаг 3. Раздели повторные покупки и реактивации.
LTV сегмента «средний чек 1000-5000 ₽» через 6 месяцев — это одно, а вклад тех, кто вернулся после паузы — другое. Вынеси реактивации (заказы после 90+ дней молчания) в отдельный столбец. Это покажет, какой сегмент растёт за счёт возврата, а какой — за счёт органики.
Шаг 4. Наложи стоимость привлечения.
К когортной таблице добавь строку CAC (стоимость привлечения клиента) по каждому сегменту на M0. Считай ROMI на каждом горизонте: (LTV - CAC) / CAC. Это превратит «средний чек сегмента» в ответ на вопрос «куда вкладывать бюджет».
Шаг 5. Сделай лёгкий фильтр, а не дашборд на 50 графиков.
Один лист: когортная таблица + линейный график LTV vs CAC по сегментам + сегментный срез (выпадающий список). Всё. В BI-систему это переносится, только когда команда начнёт реально пользоваться таблицей хотя бы раз в неделю.
Шаг 6. Назначь ритуал обновления.
Один раз в неделю, в один и тот же день, один и тот же человек. Без ритуала таблица устареет за месяц и перестанет восприниматься как инструмент.
Ошибка, которая съедает результат: сравнивать сегменты по выручке, а не по маржинальности. Сегмент с высоким средним чеком может давать меньше прибыли, если маржа на эти товары 5% против 25% в другом сегменте. Маржу добавляй отдельной строкой сразу, иначе будешь пересчитывать полквартала.
— @MarketingAnalyticsRoomPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Youtube тестирует поиск с AI
YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.
Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.
Что это значит для поиска на YouTube и когда новинка дойдёт до других…
➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai
🧠 Ещё больше инсайтов → в канале AFF.top
YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.
Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.
Что это значит для поиска на YouTube и когда новинка дойдёт до других…
➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai
🧠 Ещё больше инсайтов → в канале AFF.top
Смерть классической атрибуции и переход к маркетинговому моделированию
В 2026 году продолжать уповать на модель атрибуции по последнему клику (last-click) — это все равно что пытаться измерить температуру в комнате, глядя на выключенный термометр. Мы десятилетиями строили отчеты на основе куки-файлов, но эпоха приватности и браузерных ограничений окончательно превратила эти данные в шум.
Для маркетинг-аналитика сегодня критически важно переключиться с учета «кто кликнул» на оценку «что изменилось в бизнесе благодаря инвестициям». На первый план выходит маркетинговое моделирование (Marketing Mix Modeling, MMM). Это не попытка угадать вклад каждого канала, а математическое обоснование влияния медиа-инвестиций на итоговую выручку, учитывающее внешние факторы: сезонность, макроэкономику и даже активность конкурентов.
Наблюдение из практики: в одном из B2B-проектов, с которыми мы работали в прошлом квартале, отказ от попыток трекинга каждого перехода в пользу эконометрического моделирования показал неожиданный результат. Оказалось, что 30% лидов, которые система по старой привычке списывала на «прямой трафик», на самом деле генерировались агрессивным контент-маркетингом и экспертными материалами, которые в «чистой» аналитике выглядели как бесполезный шум.
Что это меняет в работе аналитика:
— Перестаем требовать от систем аналитики идеальной точности в связке «пользователь-событие». Это физически невозможно в 2026 году.
— Фокусируемся на инкрементальности (приросте) — учимся измерять не просто объем конверсий, а то, сколько из них *дополнительно* получено благодаря конкретной кампании.
— Внедряем серверную передачу данных, чтобы сохранить хотя бы часть первичной информации, но используем её как вспомогательный, а не единственный источник истины.
Ключевой навык аналитика теперь — не умение настроить очередной пиксель, а способность объяснить стейкхолдерам (заинтересованным лицам), почему отчет в BI-системе больше не показывает точную цепочку действий пользователя. Мы переходим от роли «сборщиков данных» к роли «архитекторов доказательств». Если вы продолжаете спорить с отделом продаж о том, с какого рекламного объявления пришел клиент, вы тратите время на вчерашний день. Нужно обсуждать общую ответственность за выручку в рамках управления доходами (RevOps), где аналитика — это фундамент для принятия решений о распределении бюджета, а не отчет для оправдания затрат.
— @MarketingAnalyticsRoomPro
В 2026 году продолжать уповать на модель атрибуции по последнему клику (last-click) — это все равно что пытаться измерить температуру в комнате, глядя на выключенный термометр. Мы десятилетиями строили отчеты на основе куки-файлов, но эпоха приватности и браузерных ограничений окончательно превратила эти данные в шум.
Для маркетинг-аналитика сегодня критически важно переключиться с учета «кто кликнул» на оценку «что изменилось в бизнесе благодаря инвестициям». На первый план выходит маркетинговое моделирование (Marketing Mix Modeling, MMM). Это не попытка угадать вклад каждого канала, а математическое обоснование влияния медиа-инвестиций на итоговую выручку, учитывающее внешние факторы: сезонность, макроэкономику и даже активность конкурентов.
Наблюдение из практики: в одном из B2B-проектов, с которыми мы работали в прошлом квартале, отказ от попыток трекинга каждого перехода в пользу эконометрического моделирования показал неожиданный результат. Оказалось, что 30% лидов, которые система по старой привычке списывала на «прямой трафик», на самом деле генерировались агрессивным контент-маркетингом и экспертными материалами, которые в «чистой» аналитике выглядели как бесполезный шум.
Что это меняет в работе аналитика:
— Перестаем требовать от систем аналитики идеальной точности в связке «пользователь-событие». Это физически невозможно в 2026 году.
— Фокусируемся на инкрементальности (приросте) — учимся измерять не просто объем конверсий, а то, сколько из них *дополнительно* получено благодаря конкретной кампании.
— Внедряем серверную передачу данных, чтобы сохранить хотя бы часть первичной информации, но используем её как вспомогательный, а не единственный источник истины.
Ключевой навык аналитика теперь — не умение настроить очередной пиксель, а способность объяснить стейкхолдерам (заинтересованным лицам), почему отчет в BI-системе больше не показывает точную цепочку действий пользователя. Мы переходим от роли «сборщиков данных» к роли «архитекторов доказательств». Если вы продолжаете спорить с отделом продаж о том, с какого рекламного объявления пришел клиент, вы тратите время на вчерашний день. Нужно обсуждать общую ответственность за выручку в рамках управления доходами (RevOps), где аналитика — это фундамент для принятия решений о распределении бюджета, а не отчет для оправдания затрат.
— @MarketingAnalyticsRoomPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
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
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
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Telegram запустил собственный сервер для ботов
Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.
Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.
Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…
➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov
🧠 Ещё больше инсайтов → в канале AFF.top
Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.
Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.
Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…
➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov
🧠 Ещё больше инсайтов → в канале AFF.top
Preflight (OPTIONS) в server-side GTM: чек-лист перед запуском
Если вы ведёте события через server-side Google Tag Manager (GTM), важно помнить: для некоторых HTTP-вызовов браузер сначала отправляет preflight-запрос методом OPTIONS. Он нужен, чтобы “проверить”, что сервер умеет обработать нужный тип cross-origin (межсайтового) запроса. Если сервер не отвечает корректно — ваши события не уйдут, и это будет выглядеть как проблема трекинга, а не как настройка CORS.
Чек-лист действий перед релизом:
— Зафиксируйте, какие запросы уходят
Проверьте в DevTools/логах server-side endpoint: действительно ли есть OPTIONS перед POST/PUT с событиями. Убедитесь, что речь не про “пустые” фоновые вызовы, а именно про ваш трекинг.
— Проверьте обработку OPTIONS на стороне сервера
В конфигурации endpoint должна быть обработка OPTIONS (обычно ответ 200/204). Если сервер возвращает ошибку или не имеет маршрута — preflight “провалится”, и клиент не отправит основной запрос.
— Настройте корректные CORS-заголовки именно под нужные методы
Убедитесь, что сервер в ответе на preflight указывает разрешённые методы (например, POST) и что ваш browser-to-server вызов соответствует требованиям. Проблема часто в том, что разрешили GET, а фактический event идёт POST.
— Разрешите нужные заголовки (allowed headers) для вашего payload
Если в запросе используются нестандартные заголовки (например, auth/хедеры, связанные с сериализацией), сервер должен вернуть их в allowed headers. Иначе основной запрос блокируется браузером.
— Проверьте статус ответа и кеширование preflight (max-age)
Если preflight отвечает корректно, но слишком “часто” дергается — вы получаете шум в логах и рискуете утопить производительность. Настройте max-age там, где это допустимо политиками вашей инфраструктуры.
— Проведите тест “как браузер”, а не только curl-ом
curl может не воспроизвести поведение браузера по preflight. Проверяйте в сценарии, который реально выполняет ваш сайт: тот же домен, тот же тип запроса, тот же режим кросс-источников.
— Добавьте мониторинг отказов preflight в аналитике/логах
В server-side логах выделите случаи OPTIONS с ошибочным статусом и сохраняйте причину (что вернул сервер, какие заголовки). Это ускорит диагностику, когда “пропали события” и атрибуция просела.
когда это пригодится: перед внедрением server-side трекинга или после смены доменов/прокси/CDN, когда события вдруг начинают “не доходить” без явной ошибки в GTM.
— @MarketingAnalyticsRoomPro
Если вы ведёте события через server-side Google Tag Manager (GTM), важно помнить: для некоторых HTTP-вызовов браузер сначала отправляет preflight-запрос методом OPTIONS. Он нужен, чтобы “проверить”, что сервер умеет обработать нужный тип cross-origin (межсайтового) запроса. Если сервер не отвечает корректно — ваши события не уйдут, и это будет выглядеть как проблема трекинга, а не как настройка CORS.
Чек-лист действий перед релизом:
— Зафиксируйте, какие запросы уходят
Проверьте в DevTools/логах server-side endpoint: действительно ли есть OPTIONS перед POST/PUT с событиями. Убедитесь, что речь не про “пустые” фоновые вызовы, а именно про ваш трекинг.
— Проверьте обработку OPTIONS на стороне сервера
В конфигурации endpoint должна быть обработка OPTIONS (обычно ответ 200/204). Если сервер возвращает ошибку или не имеет маршрута — preflight “провалится”, и клиент не отправит основной запрос.
— Настройте корректные CORS-заголовки именно под нужные методы
Убедитесь, что сервер в ответе на preflight указывает разрешённые методы (например, POST) и что ваш browser-to-server вызов соответствует требованиям. Проблема часто в том, что разрешили GET, а фактический event идёт POST.
— Разрешите нужные заголовки (allowed headers) для вашего payload
Если в запросе используются нестандартные заголовки (например, auth/хедеры, связанные с сериализацией), сервер должен вернуть их в allowed headers. Иначе основной запрос блокируется браузером.
— Проверьте статус ответа и кеширование preflight (max-age)
Если preflight отвечает корректно, но слишком “часто” дергается — вы получаете шум в логах и рискуете утопить производительность. Настройте max-age там, где это допустимо политиками вашей инфраструктуры.
— Проведите тест “как браузер”, а не только curl-ом
curl может не воспроизвести поведение браузера по preflight. Проверяйте в сценарии, который реально выполняет ваш сайт: тот же домен, тот же тип запроса, тот же режим кросс-источников.
— Добавьте мониторинг отказов preflight в аналитике/логах
В server-side логах выделите случаи OPTIONS с ошибочным статусом и сохраняйте причину (что вернул сервер, какие заголовки). Это ускорит диагностику, когда “пропали события” и атрибуция просела.
когда это пригодится: перед внедрением server-side трекинга или после смены доменов/прокси/CDN, когда события вдруг начинают “не доходить” без явной ошибки в GTM.
— @MarketingAnalyticsRoomPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google картинки станут конкурентом Pinterest
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top
Смерть модели атрибуции по последнему клику в 2026 году
Мы долго держались за last-click (атрибуцию по последнему клику), потому что это был самый простой способ обосновать бюджет перед руководством. Посмотрел в отчёт, увидел конверсию после рекламного объявления — поставил галочку. Но в 2026 году эта метрика стала опасной иллюзией. В эпоху, когда путь пользователя включает бесконечные AI-обзоры (искусственный интеллект, формирующий ответы в поисковиках), прямые заходы и социальные доказательства автора, полагаться на последний клик — значит сознательно обрезать инвестиции в верхние этапы воронки.
На практике я вижу, как компании, внедряющие MMM (моделирование маркетингового микса), кратно выигрывают у тех, кто до сих пор верит в линейку. Когда мы начали сравнивать данные серверной аналитики с результатами работы математических моделей, обнаружилась закономерность: около 30% конверсий, формально приписанных прямому трафику, на самом деле инициированы контентными охватными кампаниями, которые были запущены за месяц до покупки.
Главная сложность сейчас не в инструментах сбора данных, а в смене парадигмы. Переход к RevOps (общей ответственности маркетинга, продаж и поддержки за выручку) заставляет нас пересобрать отчетность.
— Вместо поиска «того самого» объявления, мы считаем инкрементальность — прирост выручки, который случился бы без конкретной кампании.
— Вместо борьбы за цену лида, мы инвестируем в Topical Authority (авторитетность бренда в тематике), которая дает органический приток через доверие, а не через манипуляцию поисковой выдачей.
— Мы перестали наказывать каналы за «отсутствие кликов», если видим положительную корреляцию между их активностью и ростом LTV (пожизненной ценности клиента).
Аналитик сегодня — это уже не тот, кто умеет выгружать данные из рекламных кабинетов. Это архитектор, который объясняет бизнесу, что отсутствие клика в конкретной сессии не означает бесполезность маркетинга. Мы уходим от измерения кликов к измерению влияния на принятие решения. Если вы продолжаете оценивать эффективность по старым лекалам, вы просто отдаете долю рынка тем, кто уже научился видеть длинный след пользователя в системе.
— @MarketingAnalyticsRoomPro
Мы долго держались за last-click (атрибуцию по последнему клику), потому что это был самый простой способ обосновать бюджет перед руководством. Посмотрел в отчёт, увидел конверсию после рекламного объявления — поставил галочку. Но в 2026 году эта метрика стала опасной иллюзией. В эпоху, когда путь пользователя включает бесконечные AI-обзоры (искусственный интеллект, формирующий ответы в поисковиках), прямые заходы и социальные доказательства автора, полагаться на последний клик — значит сознательно обрезать инвестиции в верхние этапы воронки.
На практике я вижу, как компании, внедряющие MMM (моделирование маркетингового микса), кратно выигрывают у тех, кто до сих пор верит в линейку. Когда мы начали сравнивать данные серверной аналитики с результатами работы математических моделей, обнаружилась закономерность: около 30% конверсий, формально приписанных прямому трафику, на самом деле инициированы контентными охватными кампаниями, которые были запущены за месяц до покупки.
Главная сложность сейчас не в инструментах сбора данных, а в смене парадигмы. Переход к RevOps (общей ответственности маркетинга, продаж и поддержки за выручку) заставляет нас пересобрать отчетность.
— Вместо поиска «того самого» объявления, мы считаем инкрементальность — прирост выручки, который случился бы без конкретной кампании.
— Вместо борьбы за цену лида, мы инвестируем в Topical Authority (авторитетность бренда в тематике), которая дает органический приток через доверие, а не через манипуляцию поисковой выдачей.
— Мы перестали наказывать каналы за «отсутствие кликов», если видим положительную корреляцию между их активностью и ростом LTV (пожизненной ценности клиента).
Аналитик сегодня — это уже не тот, кто умеет выгружать данные из рекламных кабинетов. Это архитектор, который объясняет бизнесу, что отсутствие клика в конкретной сессии не означает бесполезность маркетинга. Мы уходим от измерения кликов к измерению влияния на принятие решения. Если вы продолжаете оценивать эффективность по старым лекалам, вы просто отдаете долю рынка тем, кто уже научился видеть длинный след пользователя в системе.
— @MarketingAnalyticsRoomPro
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Россияне не смогут покупать стейблкоины
Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.
Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.
Что это значит для обычных пользователей и когда правило заработает — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny
🧠 Ещё больше инсайтов → в канале AFF.top
Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.
Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.
Что это значит для обычных пользователей и когда правило заработает — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny
🧠 Ещё больше инсайтов → в канале AFF.top
23-24 июля встречаемся в Лимассоле! 🔥
Команда AdsCard врывается на Conversion Conf в статусе HOOKAH LOUNGE SPONSOR! Мы готовим для вас идеальное пространство для неформального общения и обсуждения серьезных дел.
Ищете платежное решение, которое не подведет в самый ответственный момент? Хотите масштабировать свои рекламные кампании без головной боли? Давайте обсудим это в расслабленной атмосфере.
Что ждет вас в нашей лаунж-зоне?
0️⃣ Поделимся инсайдами и свежими кейсами по заливу с наших карт на самых требовательных источниках.
0️⃣ Обсудим наши эксклюзивные условия для команд и расскажем, как получить максимум от нашего сервиса.
0️⃣ Познакомим с топами индустрии, угостим дымным кальяном и просто отлично проведем время.
Присоединяйтесь к нам, чтобы совместить приятное с полезным: качественный нетворкинг и эффективные платежные решения.
📍 Где искать: Parklane Hotel, HOOKAH LOUNGE от AdsCard
Ждем всех на Conversion Conf для незабываемого ивента и крутых знакомств! До встречи! 😎
Команда AdsCard врывается на Conversion Conf в статусе HOOKAH LOUNGE SPONSOR! Мы готовим для вас идеальное пространство для неформального общения и обсуждения серьезных дел.
Ищете платежное решение, которое не подведет в самый ответственный момент? Хотите масштабировать свои рекламные кампании без головной боли? Давайте обсудим это в расслабленной атмосфере.
Что ждет вас в нашей лаунж-зоне?
Присоединяйтесь к нам, чтобы совместить приятное с полезным: качественный нетворкинг и эффективные платежные решения.
📍 Где искать: Parklane Hotel, HOOKAH LOUNGE от AdsCard
Ждем всех на Conversion Conf для незабываемого ивента и крутых знакомств! До встречи! 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Замер dwell time: отскок из Google назад в выдачу через GTM
Потеря посетителя, который вернулся в поисковую выдачу через кнопку «Назад», — это сигнал несоответствия страницы запросу. Стандартная аналитика не фиксирует такой отскок (браузер не отправляет событие при возврате). Решение — ловить событие `pageshow` или `popstate` через GTM и замерять время между входом с реферером google.com и моментом ухода по back-button. Ниже — чек-лист для реализации.
— Настрой триггер в GTM на событие `pageshow` (или `popstate`) с проверкой `event.isTrusted` — это отсекает программные вызовы и ловит только действия пользователя.
— Запиши в переменную время первого попадания на страницу (через `performance.timing.navigationStart` или локальный `sessionStorage`), а при возврате из SERP сравнивай его с текущим — получишь чистый dwell time.
— Убедись, что реферер при входе содержит `google.com` (или другой поисковик) и отсутствует query-параметр `?gclid` — так ты отсекаешь платный трафик и фокусируешься на органике.
— Отправляй событие в Google Analytics (event: `serp_back`, значение — время в секундах) и дополнительно пиши в свою BI-систему через Data Layer — потом сможешь строить распределение по страницам.
— Проверь поведение в разных браузерах: `pageshow` срабатывает при загрузке из bfcache (back-forward cache) в Chrome, а `popstate` — при изменении истории; для надёжности вешай оба обработчика, но дедуплицируй флагом.
— Добавь фильтр по таймингу: отсекай визиты короче 2 секунд (технические «отскоки» без чтения) — фокус на тех, кто успел изучить страницу, но всё равно вернулся.
Когда это пригодится: всегда, когда нужно объективно оценить качество контента под запрос — метрика «время до возврата в выдачу» точнее обычного отскока (bounce rate) показывает, насколько страница закрыла интент пользователя, особенно в эпоху AI-обзоров и снижения CTR органики.
— @MarketingAnalyticsRoomPro
Потеря посетителя, который вернулся в поисковую выдачу через кнопку «Назад», — это сигнал несоответствия страницы запросу. Стандартная аналитика не фиксирует такой отскок (браузер не отправляет событие при возврате). Решение — ловить событие `pageshow` или `popstate` через GTM и замерять время между входом с реферером google.com и моментом ухода по back-button. Ниже — чек-лист для реализации.
— Настрой триггер в GTM на событие `pageshow` (или `popstate`) с проверкой `event.isTrusted` — это отсекает программные вызовы и ловит только действия пользователя.
— Запиши в переменную время первого попадания на страницу (через `performance.timing.navigationStart` или локальный `sessionStorage`), а при возврате из SERP сравнивай его с текущим — получишь чистый dwell time.
— Убедись, что реферер при входе содержит `google.com` (или другой поисковик) и отсутствует query-параметр `?gclid` — так ты отсекаешь платный трафик и фокусируешься на органике.
— Отправляй событие в Google Analytics (event: `serp_back`, значение — время в секундах) и дополнительно пиши в свою BI-систему через Data Layer — потом сможешь строить распределение по страницам.
— Проверь поведение в разных браузерах: `pageshow` срабатывает при загрузке из bfcache (back-forward cache) в Chrome, а `popstate` — при изменении истории; для надёжности вешай оба обработчика, но дедуплицируй флагом.
— Добавь фильтр по таймингу: отсекай визиты короче 2 секунд (технические «отскоки» без чтения) — фокус на тех, кто успел изучить страницу, но всё равно вернулся.
Когда это пригодится: всегда, когда нужно объективно оценить качество контента под запрос — метрика «время до возврата в выдачу» точнее обычного отскока (bounce rate) показывает, насколько страница закрыла интент пользователя, особенно в эпоху AI-обзоров и снижения CTR органики.
— @MarketingAnalyticsRoomPro
**Дашборды без владельца: почему отчёты перестают открывать**
Заметил устойчивый паттерн в работе с клиентами и в разговорах с коллегами по MarTech. Отчёт в Looker или Power BI собирается, раз в месяц (а иногда и раз в неделю) выгружается в PDF, уходит в рассылке стейкхолдерам — и дальше его не открывают. Никто.
При этом сам дашборд технически живой: данные обновляются, метрики считаются, алерты настроены. Но владельца у него нет. Маркетинг сделал для прода, прода смотрит свою воронку, финансы — свою. Дашборд как отчётный артефакт, а не как рабочий инструмент.
Отсюда и расхождение в цифрах между командами: у каждого своя версия правды, потому что каждый смотрит в свою таблицу, а в общий отчёт заглядывают только в момент квартального обзора.
Ещё одно наблюдение: самые полезные дашборды в 2026 — это не те, где больше всего графиков, а те, за которыми закреплён один человек с правом редактировать и обязанностью отвечать на вопрос «а почему цифра упала». Без владельца любой отчёт через три месяца превращается в мусор.
У вас тоже так? Или уже нашли формат, где дашборд реально живёт, а не висит как обязательство на отчёт?
— @MarketingAnalyticsRoomPro
Заметил устойчивый паттерн в работе с клиентами и в разговорах с коллегами по MarTech. Отчёт в Looker или Power BI собирается, раз в месяц (а иногда и раз в неделю) выгружается в PDF, уходит в рассылке стейкхолдерам — и дальше его не открывают. Никто.
При этом сам дашборд технически живой: данные обновляются, метрики считаются, алерты настроены. Но владельца у него нет. Маркетинг сделал для прода, прода смотрит свою воронку, финансы — свою. Дашборд как отчётный артефакт, а не как рабочий инструмент.
Отсюда и расхождение в цифрах между командами: у каждого своя версия правды, потому что каждый смотрит в свою таблицу, а в общий отчёт заглядывают только в момент квартального обзора.
Ещё одно наблюдение: самые полезные дашборды в 2026 — это не те, где больше всего графиков, а те, за которыми закреплён один человек с правом редактировать и обязанностью отвечать на вопрос «а почему цифра упала». Без владельца любой отчёт через три месяца превращается в мусор.
У вас тоже так? Или уже нашли формат, где дашборд реально живёт, а не висит как обязательство на отчёт?
— @MarketingAnalyticsRoomPro