Событийные кастом-обработчики в 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
Forwarded from AffPapa! Клуб спящих бизнесменов! Потрачено!
МАККГРЕГОР! Не только лишь одни синие как оказалось умееют играть в амбасадоров :-) Если вы понимаете
Суть простая, Мак Грегор хуйнул ставочку, и вроде бы хуйня, но все мы понимаем что это значит и это работает на всех нас!
Амбассадор 1xBet сделал прогноз на $100 000 на точный счет финала WCMUC2026: Испания v Аргентина – 2:3. Коэффициент – 36. Потенциальный выигрыш – $3,6 миллиона! На мой взгляд вообще похуй какой именно прогноз он сделал, тут важен сам факт, это без проблем используется во всех крео!
Думаю не надо объяснять что Конор это пиздец какой триггер для игроков и соц. пруф! Самый известный спортсмен мира сделал прогноз на главный матч года, а значит миллионы болельщиков будут следить не только за финалом, но и за его выбором. Используй этот инфоповод, чтобы подтолкнуть аудиторию к собственному прогнозу!
В финале WCMUC2026 победитель будет только один, а вот в борьбе за трафик может победить каждый и урвать свой кусок! Используй, хули сидеть!
Тыкай, там интиресно!
Суть простая, Мак Грегор хуйнул ставочку, и вроде бы хуйня, но все мы понимаем что это значит и это работает на всех нас!
Амбассадор 1xBet сделал прогноз на $100 000 на точный счет финала WCMUC2026: Испания v Аргентина – 2:3. Коэффициент – 36. Потенциальный выигрыш – $3,6 миллиона! На мой взгляд вообще похуй какой именно прогноз он сделал, тут важен сам факт, это без проблем используется во всех крео!
Думаю не надо объяснять что Конор это пиздец какой триггер для игроков и соц. пруф! Самый известный спортсмен мира сделал прогноз на главный матч года, а значит миллионы болельщиков будут следить не только за финалом, но и за его выбором. Используй этот инфоповод, чтобы подтолкнуть аудиторию к собственному прогнозу!
В финале WCMUC2026 победитель будет только один, а вот в борьбе за трафик может победить каждый и урвать свой кусок! Используй, хули сидеть!
Тыкай, там интиресно!
Почему у BI отчётов “падает” доверие: растёт доля метрик, которые нельзя честно объяснить. В 2026 это особенно видно в кросс-канальных дашбордах, где в одном графике смешаны last-click, server-side атрибуция (по сути, другая логика) и экономическая модель типа MMM. Пользователь видит расхождение, но не понимает, как оно возникло. Моё мнение: проблему нужно фиксить не “доп. графиком”, а публичным договором на уровне BI — какие данные, какая методика, какая неопределённость и где это влияет на решения.
— @MarketingAnalyticsRoomPro
— @MarketingAnalyticsRoomPro