ChatGPT ads внедрил функцию автосоздания креативов

OpenAI добавила в ChatGPT Ads автогенерацию креативов: вставляешь ссылку на сайт, ИИ анализирует лендинг и создаёт релевантный креатив. По ощущениям, такие материалы должны легко проходить модерацию, но пока неясно, насколько они поддаются правкам. Источник интересен ещё и тем, что вайт можно сгенерировать тут же через ChatGPT.

➡️ Читайте на сайте: https://aff.top/blog/chatgpt-ads-vnedril-funkciiu-avtosozdaniia-kreativov

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

В Google search console теперь можно добавлять соцсети

Google добавил в Search Console поддержку аккаунтов соцсетей: теперь можно отслеживать ключевые запросы, источники и географию переходов, показы и клики по ссылкам. Функция подключается там же, где и сайты, доступны четыре соцсети на выбор. Rollout постепенный — доступ получают не все сразу.

➡️ Читайте на сайте: https://aff.top/blog/v-google-search-console-teper-mozhno-dobavliat-socseti

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

Google стал помечать креативы, созданные ИИ

Google объявил, что начнёт помечать рекламные креативы, созданные нейросетями. Причина — ИИ-баннеры и видео стали слишком похожи на настоящие.

Формат и заметность маркировки будут зависеть от законов конкретного региона: где-то предупреждение появится прямо на креативе, где-то — в его информации.

Что это значит для арбитражников и когда правила …

➡️ Читайте на сайте: https://aff.top/blog/google-stal-pomechat-kreativy-sozdannye-ii

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

Компания 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

Как за 1 неделю собрать server-side событие покупки без потери данных

Если у вас уже есть сайт, CRM и рекламные кабинеты, но события теряются из-за блокировщиков, iOS и ограничений браузеров, начните с самого ценного события — покупки. Ниже схема, которую можно поднять за неделю.

1. Определите одно событие и один маршрут данных. Для первого этапа берите purchase: оно влияет и на оптимизацию рекламы, и на выручку. Маршрут должен быть коротким: сайт → сервер → аналитика → рекламные системы.

2. Зафиксируйте состав события. Минимум: order_id, сумма, валюта, timestamp, client_id, user_id, источник, статус согласия на обработку данных. Не тащите всё подряд: чем чище схема, тем меньше расхождений.

3. Поставьте server-side контейнер. Чаще всего это отдельный контейнер в GTM Server-Side или аналог на своём сервере. Его задача — принять веб-событие, проверить его и отправить дальше в нужные системы.

4. Настройте передачу идентификаторов. Важно передавать не только cookie, но и first-party идентификаторы: внутренний user_id, order_id, при наличии — email/телефон в хешированном виде. Это помогает связать сессии, которые браузер уже «потерял».

5. Добавьте проверку на дубли. Purchase должен уходить один раз. Используйте order_id как ключ идемпотентности: если событие пришло повторно, сервер его отбрасывает.

6. Сверьте данные с тремя источниками: сайт, CRM, рекламная платформа. Разница до 3–5% для старта допустима, но вы должны понимать, где именно она возникает: на отправке, на матчингe или на стороне кабинета.

7. Введите ежедневный контроль. Один отчет: число покупок, сумма, доля событий, ушедших с сервера, и доля ошибок. Через неделю у вас уже будет базовая картина, где теряются деньги.

**Смысл server-side не в моде, а в том, чтобы вернуть управляемость данным.** Начните с покупки, а не со всей воронки: так быстрее увидите эффект и не утонете в настройках.

— @ServerSideTrackingRuPro

Почему серверная аналитика — это фундамент вашей RevOps-стратегии

В 2026 году классическая воронка, где маркетинг отвечает за лиды (потенциальных клиентов), а отдел продаж — за закрытие сделок, окончательно уходит в прошлое. Мы перешли в эпоху RevOps (объединенного управления выручкой), где ценность маркетинга измеряется не количеством заявок, а вкладом в итоговую прибыль. И здесь серверная аналитика перестает быть просто техническим инструментом для обхода ограничений браузеров. Она становится «единым источником правды» для всех департаментов.

Когда мы настраиваем сбор данных на стороне сервера (server-side tagging), мы решаем главную проблему эпохи: фрагментацию пути клиента. В условиях, когда средний чек падает, а пользователь совершает десятки касаний с брендом, полагаться на стандартные куки-файлы (cookies) — значит сознательно искажать реальность. Вы теряете данные о пользователях, использующих блокировщики рекламы или жесткие настройки приватности, и в итоге получаете искаженную картину LTV (пожизненной ценности клиента).

Моя практика показывает, что компании, внедрившие серверную аналитику, фиксируют рост точности атрибуции (определения источника конверсии) на 15–20% в сравнении с клиентскими методами. Это дает возможность не просто «сливать» бюджет, а управлять удержанием (retention). Когда данные о поведении пользователя передаются в CRM напрямую с сервера, мы получаем возможность корректировать коммуникацию в реальном времени, не дожидаясь, пока рекламные системы «обучатся» на неполных данных.

— Отказ от last-click (атрибуции по последнему клику) в пользу MMM (маркетингового моделирования на основе данных) невозможен без чистого потока данных из серверного контейнера.
— В модели RevOps данные должны быть идентичны для маркетинга, продаж и службы заботы о клиентах. Серверный подход устраняет расхождения, которые возникают из-за блокировок на стороне браузера.
— Контент в эпоху нулевых кликов (zero-click) сложнее отследить. Серверная аналитика позволяет видеть реальный путь пользователя, даже если он не совершил целевое действие на первом же сайте.

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

— @ServerSideTrackingRuPro

Сервера, которые “путают” воронку: как я лечу разъехавшиеся события в first-party аналитике

Когда мы переходим с клиентских пикселей (или смешанной схемы) на server-side аналитика, самая частая боль звучит одинаково: «воронка стала хуже». При этом заказов не меньше, а в отчётах конверсия просела — иногда на десятки процентов. На практике причина почти всегда не в маркетинге, а в том, что события начали “жить” в разных мирах: разные таймлайны, разные ключи пользователя, разные правила дедупликации.

Моё рабочее правило: если воронка “сломалась” сразу после внедрения server-side, я не трогаю кампании и бюджеты. Я сначала проверяю, как именно собираются и сшиваются события на сервере.

1) Самая частая ошибка — двойные события с разными “верситетами”
На клиенте событие могло отправляться с одного источника, а в server-side вы добавили ещё один маршрут (например, ретрай, параллельные трекеры, расширение из тег-менеджера + прямой event API). В результате одно и то же действие попадает в систему дважды, но с разными параметрами: один раз — с user_id, второй — только с client_id.

Я обычно начинаю с простого теста: беру событие “Sign Up” (или “Add to Cart”) и строю частоту по связке ключей:
— client_id + session_id
— user_id + session_id
— только user_id
Дальше сравниваю распределение во времени (до/после) и смотрю, где появился второй “хвост”. Если второй хвост есть — это не “органика ухудшилась”, а схема матчинга ключей стала несовместимой.

2) Тайм-ауты и очереди: события не исчезают, но меняют порядок
В server-side часто добавляют буферизацию, повторные отправки (retry) и очереди для устойчивости. Это улучшает надёжность доставки, но создаёт новый класс артефактов: событие “purchase” может прийти раньше “view_product”, потому что оно отправляется позже по пользовательскому пути, но раньше доезжает до сервера (или наоборот).

Мой приём: я храню для каждого события два времени:
— event_time (время действия в браузере/приложении)
— received_time (время прихода на сервер)
И дальше строю проверку монотонности: для одной сессии “view → add → purchase” разница event_time должна соответствовать ожидаемому порядку чаще, чем сейчас. Если монотонность упала — проблема в транспортной логике, а не в воронке.

Наблюдение из практики: при первой попытке server-side иногда получается, что 3–7% purchase-событий оказываются “раньше” своих предшественников по event_time (из‑за несогласованного часового пояса/смещения или сериализации). Это не звучит страшно, но для расчётов конверсии в “строгих” последовательностях даёт заметный эффект.

3) Дедупликация должна быть не “по событию”, а по смыслу
“Дедуплицируем по event_name + timestamp” — плохая стратегия. Timestamp часто округляется, имеет дрожание из-за сетевых задержек, а один и тот же timestamp может встречаться в разных сценах.

Я перехожу на дедупликацию по детерминированному fingerprint (отпечатку) события:
— user_key (user_id или client_id, что доступно)
— event_type
— source (внутренний роутинг/канал)
— параметр-идентификатор (например, order_id, transaction_id, item_id+quantity+price или request_id)
И делаю окно допустимой повторяемости (например, 10–30 минут) по received_time. Тогда ретраи не ломают аналитику, а реальные повторные действия остаются.

4) Контракт события важнее “магии тегов”
В 2026 году выигрывает тот, кто мыслит как инженер: фиксирует схему данных, контракты и инварианты. В first-party аналитике нельзя жить “как получится”: если вы меняете параметры события, меняется семантика. Если вы меняете ключи атрибуции — меняется всё.

Поэтому я ввожу минимальный “контроль качества” на стороне сервера:
— обязательные поля (user_key, session_key, event_id / request_id)
— допустимые типы/форматы
— проверка полноты (процент событий без ключей)
— алерты на скачки долей “пустых” user_id и на рост событий без идентификаторов
…

Российские букмекеры увеличили закуп трафика с мобильных приложений

Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.

По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…

➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii

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

Mia Khalifa стала амбпссадором 1win

Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».

Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.

Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…

➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win

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

Короткий домен 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