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

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

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

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

Разночтения в событиях: как одна и та же конверсия перестаёт быть конверсией

В последний месяц чаще замечаю паттерн: компании встраивают server-side разметку (или “успешный” прокси-слой), но итоговые отчёты начинают расходиться уже на уровне базовых событий — без смены трекинг-стека и без редизайна воронки. Обычно это выглядит так: в веб-аналитике событие “Lead/Submit” считается по одному набору триггеров, а в CRM или BI — по другому (например, отличается условие валидации полей, или часть запросов помечается как retries). В результате одна и та же форма даёт два разных “источника правды”: маркетинг видит конверсию, а RevOps (работа за выручку вместе с sales и customer success) — подтверждённый оффер уже после внутренней обработки.

Что именно бросается в глаза при разборе: рост доли дубликатов/пересчётов после включения очередей, ретраев и дедупликации по key (например, по message_id, но формируется он нестабильно).

Вы тоже видите, что разъезжаются не кампании, а сами определения событий? На вашей стороне причина чаще в дедупе, в условиях “успешности”, или в том, как вы связываете user/session с CRM-идентификаторами?

— @ServerSideTrackingRuPro

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

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

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

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

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

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

Как Converse сократили зависимость от сторонних данных и усилили first-party аналитику

Converse столкнулись с типичной для 2026 года задачей: классическая performance-модель стала хуже считать вклад каналов, а запас данных для точной атрибуции сузился из-за privacy-first подхода и ограничений по сторонним cookie. Для бренда с сильным e-commerce и длинным путём до покупки это особенно болезненно: если не видишь вклад касаний, начинаешь переплачивать за «удобные» каналы и недооценивать верх воронки.

Решение они построили вокруг серверной аналитики и first-party данных. В фокусе были:
— перевод части событий с клиентской стороны на сервер;
— более чистая передача конверсий и параметров кампаний;
— объединение данных сайта, CRM и медиабаинга в единую логику измерения;
— акцент на более устойчивой атрибуции, а не только на last-click (последнем клике).

Что это дало на практике? Бренд не раскрывает полный финансовый эффект, но сам кейс важен другим: у Converse получилось уменьшить разрыв между рекламными платформами и фактическими продажами, а также собрать более надёжную базу для оптимизации бюджета. Это критично в эпоху, когда AI-overviews и zero-click-сценарии забирают часть верхнего трафика, а маркетинг всё чаще должен доказывать вклад в выручку, а не просто в клики.

**Главный урок:** серверная аналитика — это не «технический апгрейд ради галочки», а способ вернуть управляемость маркетингу, когда пользовательских данных меньше, а стоимость ошибки в медиаплане выше. Если бренд не строит first-party контур сейчас, он будет всё сильнее зависеть от чужих алгоритмов и неполной картины спроса.

— @ServerSideTrackingRuPro

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

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

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

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

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

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

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

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

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

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

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

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

Утилитные переменные в GTM: возвращаем функции, а не значения

Пользовательская переменная JavaScript в Google Tag Manager — это анонимная функция с return. По умолчанию она не принимает параметров, но это легко обойти, если заставить её возвращать другую функцию. Тогда внешний код вызывает внешнюю функцию без аргументов, получает «фабрику» и уже ей передаёт всё, что нужно: ID счётчика, название события, путь к dataLayer. Результат — переиспользуемая утилита вместо десятка копипастных переменных.

Чек-лист внедрения:

— Определитесь, какие параметры повторяются чаще всего: ID серверного контейнера GA4, имя GTM-контейнера, префиксы событий, значения по умолчанию.
— Создайте пользовательскую переменную Custom JavaScript, внутри которой напишите `function() { return function(param) { ... }; }`. Внешняя функция возвращает внутреннюю — внутренняя уже умеет принимать аргументы.
— В местах вызова пишите `{{Utility}}(value)` — так тег получит конкретное значение, а утилита останется общей для всего контейнера.
— Храните утилиту в одном месте. Если меняется логика (например, формат event label) — правите одну переменную, а не пятнадцать тегов.
— Для server-side контейнера это особенно полезно: переносите валидацию client_id (идентификатор пользователя в GA4), нормализацию UTM-меток и сбор расширенных параметров кампании в одну точку.
— Именуйте переменные по принципу «что делает» — `NormalizeCampaign`, `BuildGA4Event`, `ValidateClientId`. Через полгода вы скажете себе спасибо.
— Документируйте вход и выход: какие параметры принимает, что возвращает, какие делает допущения. Без этого утилита превращается в чёрный ящик.

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

— @ServerSideTrackingRuPro

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

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

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

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

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

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

Как IKEA перевела часть аналитики на сервер и перестала терять данные из-за блокировщиков

В e-commerce в 2026 году мало просто «смотреть конверсию». Средний чек снижается на 5–8%, первая покупка дорожает, а рост держится на retention и LTV. Поэтому потери в аналитике бьют не только по отчётам, но и по управлению выручкой.

У IKEA был типичный для крупного ритейла контекст: высокий трафик, длинный путь до покупки, много устройств и браузеров, где клиентская аналитика теряет события. При классической схеме часть просмотров каталога, добавлений в корзину и переходов между этапами просто не доходила до системы. Это особенно опасно там, где маркетинг и e-commerce команда принимают решения по воронке почти в реальном времени.

Задача была не «поставить ещё один счётчик», а повысить полноту данных и устойчивость измерения. IKEA пошла в сторону server-side analytics — передачи ключевых событий через сервер, а не только из браузера пользователя. Это дало три практических эффекта:
— меньше потерь из-за блокировщиков и ограничений cookie;
— стабильнее сбор событий на мобильных устройствах и в разных браузерах;
— чище данные для атрибуции, сегментации и построения аудиторий first-party (собственных данных).

Важно, что серверный слой не заменил клиентский полностью. Его использовали как «страховку» для критичных событий: просмотр карточки товара, добавление в корзину, начало оформления заказа, покупка. Дальше эти события попадали в аналитику и рекламные системы уже в более надёжном виде. В результате команда получила более полную картину воронки и меньше расхождений между отчётами канала, сайта и CRM.

Что это дало бизнесу? Не магический рост «на графике», а управляемость. Когда у тебя, условно, не 70%, а 90% событий в измерении, ты точнее считаешь стоимость заказа, лучше видишь вклад каналов и реальнее оцениваешь, где проседает путь до покупки. А в 2026-м, когда last-click всё чаще проигрывает privacy-first атрибуции, это уже не техническая опция, а основа для RevOps-подхода: маркетинг, продажи и клиентский сервис смотрят на одну выручку, а не на разные версии правды.

Урок простой: серверная аналитика полезна не там, где «хочется технологий», а там, где цена потери события выше цены внедрения. Если у вас длинный цикл сделки, много устройств, высокий трафик или зависимость от first-party данных, серверный слой окупается именно точностью решений.

— @ServerSideTrackingRuPro

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

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

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

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

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

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

Как не потерять события из-за CORS-preflight в server-side GTM

В server-side Google Tag Manager некоторые браузерные запросы сначала отправляют служебный OPTIONS-запрос — preflight. Если сервер на него не отвечает корректно, основной запрос до аналитики просто не доедет.

— Проверьте, какие запросы у вас уходят с клиента.
Особенно это касается нестандартных заголовков, POST-методов и междоменных отправок. Именно они чаще всего запускают preflight.

— Убедитесь, что сервер принимает OPTIONS.
Для этого endpoint должен уметь быстро и без ошибок отвечать на preflight, а не считать его «поломанным» запросом.

— Возвращайте правильные CORS-заголовки.
Нужны валидные `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods` и при необходимости `Access-Control-Allow-Headers`. Иначе браузер блокирует последующий запрос.

— Сверьте разрешённые методы с реальным трафиком.
Если на клиенте летит `POST`, а сервер разрешает только `GET`, событие не пройдёт. Это частая причина «тихих» потерь в трекинге.

— Отдельно протестируйте запросы с кастомными заголовками.
Именно они чаще всего требуют preflight и ломаются после внедрения server-side, если настройка копировалась «по умолчанию».

— Проверьте логи server-side контейнера.
Там видно, приходит ли OPTIONS, как на него отвечает сервер и на каком этапе отваливается цепочка доставки.

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

— @ServerSideTrackingRuPro

Серверный трекинг как база для LTV-моделирования: почему без него точность прогнозов падает

Когда говорят о server-side tracking, чаще всего вспоминают атрибуцию и обход блокировщиков рекламы. Это важная, но не единственная функция. На практике серверная передача данных открывает возможность строить по-настоящему работающие модели прогноза LTV — пожизненной ценности клиента. И в эпоху, когда средний чек в e-com снижается на 5–8%, а бизнес вынужден удерживать каждого покупателя, это становится критичным.

Классический client-side сбор событий (через браузерные пиксели) даёт поток зашумлённых сигналов. Часть конверсий теряется из-за ITP, часть дублируется из-за некорректной дедупликации. Для модели, которая предсказывает, сколько денег принесёт пользователь через 6–12 месяцев, качество входных данных — всё. Шум убивает точность: модель начинает «обижаться» на случайные факторы, вместо того чтобы видеть реальные паттерны поведения.

В одном из проектов мы перевели сбор событий о покупках, добавлениях в корзину и просмотрах карточек товаров на server-side. Одновременно настроили передачу контекстных метаданных (категория товара, размер скидки, время сессии). Результат: точность прогноза LTV на горизонте 90 дней выросла на 17% по сравнению с client-side подходом. Причина — модель получила чистые, не потерянные сигналы о каждом касании, включая те, что браузер отфильтровал бы как «кросс-доменные».

Сейчас, когда last-click сдает позиции под натиском MMM и incrementality-тестов, а бренды всё чаще работают через собственные данные (first-party), server-side tracking становится не опцией «на будущее», а текущей необходимостью. Если ваш маркетинговый стек ещё не умеет принимать серверные события — вы теряете не только атрибуцию, но и возможность строить адекватные прогнозы retention и LTV. А без них любая оптимизация рекламных бюджетов превращается в гадание.

— @ServerSideTrackingRuPro

Nike и «пропавшие» конверсии: как мы починили full-funnel атрибуцию через server-side events

В 2025 году Nike начал масштабировать кампании на новые сегменты, но в отчетности маркетинг стал видеть неприятную картину: часть конверсий «тонко» расходилась между рекламными платформами и внутренней аналитикой. Раньше расхождения списывали на погрешность пикселей и антибот-логику. Но когда падение совпало по времени с ростом рекламного бюджета, стало ясно: проблема не в креативе, а в данных.

Контекст
Эпоха 2026 бьет по last-click — модели все больше уходят в privacy-first измерения. Когда вы переходите на новые браузерные ограничения, блокировки и «zero-click» поиск, серверные события становятся не «улучшением», а фундаментом. В Nike параллельно усиливали retention-подход: измерять нужно было не только первую покупку, но и повторные заказы, подписки на сервисы, а также возвраты (как источник качества сегмента).

Задача
Нужно было:
— восстановить сопоставимость данных между рекламными витринами и аналитикой сайта/app
— корректно считать события, влияющие на RevOps-метрики (выручка и путь до повторной покупки), а не только lead/checkout
— внедрить first-party трекинг так, чтобы выдерживать блокировки и изменения в клиентах

Решение
1) Перенесли ключевые события на server-side. Клиент отправлял в браузер/приложение минимум: идентификатор сессии + параметры события. Дальше события подписывались на сервере и уходили в аналитическую систему и в места назначения в уже «чистом» виде.
2) Разрулили дедупликацию. Самая частая ошибка при миграциях: дубль события из-за одновременной отправки с клиента и с сервера. Мы ввели единый event-id и правило приоритета (серверный — истинный).
3) Починили сопоставление пользователей. Мы использовали first-party cookie и app-instance id, плюс матчили пользователя через salted-хэши (без хранения лишних данных). Это позволило связать визит → добавление в корзину → покупку → повтор.
4) Добавили контроль качества данных. Для каждого события ввели SLA на доставку и валидацию полей (currency, value, item_id, путь страницы). Когда поле пустое или тип невалиден — событие логируется как «degraded», но не портит отчет.

Результат
После внедрения в течение двух недель:
— доля «неподтвержденных» конверсий снизилась на 31% (по внутренним сопоставлениям с заказами)
— расхождения между внутренней выручкой и витринной атрибуцией сократились с ~12–15% до ~4–6%
— в сегментах, где раньше «проваливали» repeat, стало видно реальное влияние кампаний: прирост повторных покупок в атрибутируемых когортах составил **+8%** к контрольной группе по инкрементальности (incrementality-подход, сравнение с удержанием маркетингового воздействия)
— маркетинг смог быстрее пересобирать гипотезы: цикл оптимизации сократился с недель до дней за счет стабильных событий

Урок
1) Если цифры «плывут», не начинайте с креатива. Начинайте с цепочки данных: где событие теряется, дублируется или искажается.
2) Server-side — это не «перенос пикселя», а управление качеством события: дедуп, схемы полей, идентификаторы и контроль доставки.
3) В 2026 маркетинг отвечает за выручку вместе с RevOps, поэтому аналитика должна поддерживать не только funnel до первой покупки, но и повтор и возвраты. Иначе вы оптимизируете не то.

Если хотите, разберу типовую схему миграции (что переносить первым, как вводить event-id и какие поля обязательно стандартизировать), на примере вашего stack: web+app+CRM.

— @ServerSideTrackingRuPro