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

PostHog без хаоса: как собрать события, чтобы потом не чинить аналитику месяцами

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

— Начните с 3 сущностей: user_id, session_id, event_name. Без них cohort-анализ и воронки быстро превращаются в спор о «потерянных» событиях.
— Именуйте события как действия: sign_up, add_to_cart, checkout_started. Не смешивайте шаг и результат в одном имени.
— К каждому ключевому событию добавляйте 2–5 параметров: source, plan, device, step, error_type. Этого хватает, чтобы резать воронку без лишних костылей.
— Не отправляйте все клики подряд. В PostHog ценность дает не шум, а повторяемые события, по которым можно считать конверсию и retention.

Главная ошибка — строить трекинг вокруг интерфейса, а не вопроса бизнеса. Если вам нужен ответ «где отваливается оплата», трекать надо checkout_started, payment_failed и purchase, а не каждый hover. Тогда можно быстро увидеть утечку и проверить гипотезу: форма, оффер, метод оплаты, скорость загрузки.

Для арбитража и продуктовых команд PostHog удобен тем, что в одном месте живут события, записи сессий и простые флаги. Но магия работает только если схема именования одна на команду и не меняется от проекта к проекту.

Итог: сначала рисуете воронку, потом список событий, и только потом идете в инструмент. Так PostHog становится не свалкой логов, а рабочей картой поведения.

Amplitude не спасает продукт. Он спасает только нормальную схему событий

Контекст: мобайл, SaaS, CPA-лендинги, подписки — везде одна проблема: в Amplitude начинают смотреть графики раньше, чем договорятся, какие события вообще считаются.

• Имена событий должны описывать действие, а не экран: signup_started, checkout_completed, а не screen_2_open
• Параметры — только то, что потом реально режется в сегменты: source, device, plan, offer_id, step
• Один и тот же action не должен называться по-разному у веба и мобайла

Самая частая ошибка — плодить события вместо свойств. Команда шлёт 40 ивентов на один сценарий, а потом не может собрать воронку без костылей. Вторая ошибка — нет единого user_id: один и тот же человек размазывается по anonymous, email и internal_id.

В Amplitude полезно сразу проверять 3 вещи: воронку по шагам, retention по когорте, а также связку source → activation → revenue. Если этого нет, дашборд превращается в музей красивых, но бесполезных чисел.

Начните не с отчётов, а с карты событий: 10–15 ключевых действий, 5–7 общих свойств и понятные правила именования. Тогда Amplitude начинает отвечать на вопросы, а не добавлять их.

Mixpanel ломают не события, а плохая схема именования и пустые свойства

Контекст: продуктовые команды, SaaS, мобайл, CPA-воронки. Mixpanel полезен не как «ещё один дашборд», а как слой для воронок, ретеншна и сегментов, если события описаны одинаково для всех экранов и каналов.

Что обычно делают неправильно:
— называют события по экранам: home_open, home_click, а не по действию;
— передают в свойство всё подряд, вместо 3–5 стабильных полей;
— смешивают user-level и event-level данные, из-за чего cohort-анализ начинает врать;
— считают конверсии без единого определения «активного» пользователя.

Рабочая схема для старта:
— событие = действие: signup_started, checkout_completed, offer_clicked;
— свойства = контекст: источник, устройство, тариф, шаг воронки, вариант креатива;
— идентификатор пользователя связывают сразу после логина, иначе ретеншн распадается на два графика.

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

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

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

Российские букмекеры в 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

Продуктовая аналитика ломается не на дашборде, а на плохом вопросе

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

Рабочая схема проще:
— одна цель на воронку: регистрация, активация, покупка или лид;
— один владелец у каждого события и параметра;
— одно имя на одно действие, без дублей вроде sign_up и signup;
— один набор обязательных свойств: источник, устройство, шаг, эксперимент.
Так аналитика не превращается в свалку.

Ещё одна типовая ошибка — мерить всё на уровне страницы, а не действия. Страница может быть той же, а поведение на ней разное: пользователь дочитал, нажал CTA, ушёл в чат или застрял в форме. События должны отвечать на вопрос «что сделал человек», а не «что он увидел».

Если воронка не читается за 30 секунд, значит, в ней лишние события или нет одной главной метрики. Начните с неё, а уже потом добавляйте детализацию.

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

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

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

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

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

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

Продуктовая аналитика ломается не на графиках, а на кривых вопросах

Чаще всего команда строит дашборд раньше, чем отвечает на 3 базовых вопроса: что считаем событием, где граница воронки и какая метрика решает спор. Без этого один и тот же рост может быть и улучшением, и шумом.

Соберите минимальный каркас:
— north star metric: одна метрика, ради которой вообще смотрят в продукт
— вход в воронку: один сценарий, без смешивания каналов и платформ
— событие-конверсия: только то действие, которое реально завершает шаг
— разрезы: источник, устройство, страна, новый/возвратный

Дальше проверьте качество трекинга. Если событие можно отправить дважды, если название шага меняется между лендингом и приложением, если часть действий живёт только в client-side — отчёт будет врать даже при идеальной модели. В таких местах лучше сначала чинить схему событий, а не строить новый BI-экран.

Хорошая аналитика отвечает не на вопрос «сколько было кликов», а на вопрос «на каком шаге теряем деньги и что менять первым».

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

Amplitude ломает не данные, а плохую схему событий: как не утонуть в хаосе

Amplitude полезен тогда, когда у событий есть единый словарь. Если назвать одно и то же действие как button_click, cta_tap и promo_press, воронка расползётся, а cohort-анализ начнёт спорить сам с собой.

Базовое правило: одно событие = одно намерение пользователя. Для него фиксируйте:
— action: что сделал
— object: с чем сделал
— context: где и в каком сценарии
— value: только если это реально нужно для сегментации

Не плодите события под каждый экран, если шаг одинаковый. Лучше держать event taxonomy вокруг бизнес-действий: sign_up, lead_submit, checkout_start, purchase. Экран — это свойство, а не отдельный смысл.

В Amplitude чаще всего ошибаются в двух местах: передают слишком много параметров и не разделяют product и marketing events. В итоге отчёты красивы, но ответ на вопрос «где просели пользователи» приходится собирать вручную. 📉

Сначала опишите 10–15 ключевых событий, потом проверьте их на воронке и retention. Если событие нельзя объяснить за 10 секунд новому аналитику, его лучше переименовать или удалить.

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

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

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

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

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

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

PostHog для продукта и CPA: какие события собрать, чтобы не утонуть в лишнем шуме

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

Минимальный набор событий:
— page_view / landing_view
— signup_start / lead_submit
— checkout_start / purchase
— activation_step_completed
— refund / churn, если это подписка
Параметры держите стабильными: source, campaign, device, offer, plan, step, value. Одно событие = одно действие, а не «всё, что произошло на странице» 📊

Главная ошибка — смешивать продуктовые и маркетинговые события. Если в одном event_name живут и клик по CTA, и успешная оплата, воронка становится нечитабельной. Второй провал — пустые properties: без campaign и step потом не собрать cohort-анализ, сегменты и ретеншн по источникам.

Что делать на практике: сначала соберите воронку в 4–6 шагов, потом добавьте retention, а уже после — кастомные сегменты и алерты. Если событие нельзя использовать в отчёте через месяц, его, скорее всего, не нужно трекать.

Начните с простого дерева событий и не расширяйте схему, пока не появится вопрос, на который она должна ответить.

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

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

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

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

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

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

Продуктовая аналитика ломается не из-за графиков, а из-за кривой схемы событий

Если события названы как попало, дашборды превращаются в шум. Для старта хватает простого каркаса: 1) одно действие = одно событие; 2) имя в формате глагол_объект; 3) параметры не дублируют название, а добавляют контекст.

Для лендинга и CPA это обычно: view_page, click_cta, submit_form, lead_sent, purchase. У каждого события должны быть свои обязательные поля: source, campaign, device, page, offer_id. Без этого cohort-анализ и разбор воронки быстро упираются в вопрос «а где именно просело?».

Частая ошибка — смешивать пользовательское действие и результат системы в одном событии. Например, form_submit и form_success лучше не склеивать: первое показывает намерение, второе — факт прохождения. Тогда видно, на каком шаге теряются люди, а не только итоговая конверсия.

Ещё один полезный принцип: не хранить в названии события бизнес-логику, которая меняется. Лучше передать её параметром. Тогда A/B-тест, новый оффер или другой источник трафика не ломают всю историю метрик.

Если хочется меньше хаоса, начните не с дашборда, а с таблицы событий: что отправляем, когда, с какими параметрами и кто это проверяет. Именно там обычно прячется половина проблем.

Heap полезен не тем, что «собирает всё», а тем, что быстро показывает, где ломается воронка

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

Что стоит сделать сразу:
— выделить 5–10 ключевых событий: view, click, lead, submit, purchase, signup;
— для каждого события заранее описать обязательные свойства: source, campaign, device, page, step;
— не тащить в Heap всё подряд: лучше 20 чистых событий, чем 200 «на всякий случай»;
— отдельно проверить идентификацию пользователя: anonymous → known должен склеиваться без провалов 🔧

Главная польза Heap — ретроспективный анализ. Если событие не завели в момент запуска, его можно восстановить по логам кликов и DOM-элементам, но только если заранее понятно, что считать целевым действием. Иначе вы потом будете спорить не о конверсии, а о том, какой именно клик был «тем самым».

Если Heap у вас стоит, начните не с дашборда, а с карты событий и 3–4 ключевых воронок. Тогда инструмент будет отвечать на вопросы команды, а не создавать новый слой хаоса.