Postback как инженерный интерфейс: как проектировать цепочку атрибуции, чтобы она пережила privacy и не сломала P&L
В 2026 году рекламная аналитика всё чаще напоминает распределённую систему: много источников сигналов, нестабильная доставка событий, разные часы на серверах и постоянная «доставка с задержкой» в модели атрибуции. В этой реальности postback — не «техническая кнопка в кабинете», а контракт между трекингом и бухгалтерией рекламного результата. Если контракт слабый, вы будете мерить не то, что покупает бизнес.
Ниже — практичный разбор, как проектировать postback так, чтобы вы строили воспроизводимую (и проверяемую) атрибуцию, а не случайный набор логов.
1) Postback — это не “отправить конверсию”, а определить границы истины
Тезис: постбек должен фиксировать *смысл события* и *границы данных*, иначе вы получите «конверсии» без причинно-следственной связности.
Пример: вы измеряете “лид” как факт отправки формы. Но в реальном процессе часть форм заполняют, не читая условия; часть лидов не доживает до квалификации; часть попадает в повторные контакты. Если в postback вы шлёте одинаковый payload для всех случаев (например, lead_created без признака источника страницы и без уровня согласия/валидности), то sales и RevOps (общая ответственность маркетинга, sales и customer success за выручку) не смогут сверить вашу цифру с CRM.
Практика проектирования:
— Разведите события по уровням: interest → lead (валидный контакт) → mql/SQL (квалификация) → revenue (факт выручки).
— В postback передавайте ключевые признаки, которые позволят построить соответствие “что именно считалось”: `event_type`, `offer_or_flow`, `consent_status`, `lead_quality`, `currency`, `value`.
— Закрепите, где происходит нормализация: либо сервером трекинга, либо upstream-событием (например, вашей бэкенд-логикой). Важно не “правильно отправить”, а одинаково вычислять во всех источниках.
2) Ключи (ID) и тайминг: причина исчезает, если событие “плавает”
Тезис: postback должен коррелироваться по стабильным ключам и поддерживать задержки, иначе вы теряете link между показом/кликом и результатом.
Пример: сценарий для e-commerce или B2B: пользователь открыл заявку с мобильного, затем вернулся через 6 часов из поиска и довёл до покупки/подписания. Кликовый идентификатор мог умереть (cookie/браузерная политика/очистка), а последний клик окажется другим. Если вы отправите postback только на основе текущей сессии или “самого нового” UTM, вы получите систематическое смещение: конверсии будут приписаны источнику, который просто сопровождал финальный шаг.
Практика:
— Используйте серверную привязку к событию на стороне вашего домена (server-side tracking): ключ для корреляции формируйте в момент клика/первого взаимодействия и продолжайте хранить в вашей инфраструктуре, а не в браузере.
— Добавьте поля времён: `client_event_time`, `server_receive_time`, `attribution_window_days`. Это позволит проверять задержки и строить корректные окна атрибуции.
— Если вы принимаете постбеки от нескольких платформ, поддержите дедупликацию: `event_id` (уникальный) и строгую политику повторов (например, “не принимай событие, если `event_id` уже есть”).
В инженерных терминах: корреляция должна быть идемпотентной. Тогда retries (повторы) не создадут “двойные конверсии”, а задержки не уничтожат смысл.
3) Инкрементальность и MMM: postback — вход в модель, а не конечная метрика
Тезис: постбек обеспечивает данные для измерения эффекта, но окончательная оценка должна учитывать смещение и смешение каналов.
Пример: last-click атрибуция в условиях privacy будет стабильно завышать “финальные” каналы и занижать роль прогрева (бренд/контент/ретаргетинг), особенно когда пользователи возвращаются позже. В 2026 это проявляется особенно заметно: средний чек в e-commerce снижается на 5–8% (покупатели экономят), а значит ценность “последнего шага” уменьшается — важнее вырастить LTV (пожизненную ценность) и удержание. Если вы смотрите только на доход атрибутированный postback’ом, вы будете ошибочно считать, что эффективность падает, хотя меняется структура спроса.
…
В 2026 году рекламная аналитика всё чаще напоминает распределённую систему: много источников сигналов, нестабильная доставка событий, разные часы на серверах и постоянная «доставка с задержкой» в модели атрибуции. В этой реальности postback — не «техническая кнопка в кабинете», а контракт между трекингом и бухгалтерией рекламного результата. Если контракт слабый, вы будете мерить не то, что покупает бизнес.
Ниже — практичный разбор, как проектировать postback так, чтобы вы строили воспроизводимую (и проверяемую) атрибуцию, а не случайный набор логов.
1) Postback — это не “отправить конверсию”, а определить границы истины
Тезис: постбек должен фиксировать *смысл события* и *границы данных*, иначе вы получите «конверсии» без причинно-следственной связности.
Пример: вы измеряете “лид” как факт отправки формы. Но в реальном процессе часть форм заполняют, не читая условия; часть лидов не доживает до квалификации; часть попадает в повторные контакты. Если в postback вы шлёте одинаковый payload для всех случаев (например, lead_created без признака источника страницы и без уровня согласия/валидности), то sales и RevOps (общая ответственность маркетинга, sales и customer success за выручку) не смогут сверить вашу цифру с CRM.
Практика проектирования:
— Разведите события по уровням: interest → lead (валидный контакт) → mql/SQL (квалификация) → revenue (факт выручки).
— В postback передавайте ключевые признаки, которые позволят построить соответствие “что именно считалось”: `event_type`, `offer_or_flow`, `consent_status`, `lead_quality`, `currency`, `value`.
— Закрепите, где происходит нормализация: либо сервером трекинга, либо upstream-событием (например, вашей бэкенд-логикой). Важно не “правильно отправить”, а одинаково вычислять во всех источниках.
2) Ключи (ID) и тайминг: причина исчезает, если событие “плавает”
Тезис: postback должен коррелироваться по стабильным ключам и поддерживать задержки, иначе вы теряете link между показом/кликом и результатом.
Пример: сценарий для e-commerce или B2B: пользователь открыл заявку с мобильного, затем вернулся через 6 часов из поиска и довёл до покупки/подписания. Кликовый идентификатор мог умереть (cookie/браузерная политика/очистка), а последний клик окажется другим. Если вы отправите postback только на основе текущей сессии или “самого нового” UTM, вы получите систематическое смещение: конверсии будут приписаны источнику, который просто сопровождал финальный шаг.
Практика:
— Используйте серверную привязку к событию на стороне вашего домена (server-side tracking): ключ для корреляции формируйте в момент клика/первого взаимодействия и продолжайте хранить в вашей инфраструктуре, а не в браузере.
— Добавьте поля времён: `client_event_time`, `server_receive_time`, `attribution_window_days`. Это позволит проверять задержки и строить корректные окна атрибуции.
— Если вы принимаете постбеки от нескольких платформ, поддержите дедупликацию: `event_id` (уникальный) и строгую политику повторов (например, “не принимай событие, если `event_id` уже есть”).
В инженерных терминах: корреляция должна быть идемпотентной. Тогда retries (повторы) не создадут “двойные конверсии”, а задержки не уничтожат смысл.
3) Инкрементальность и MMM: postback — вход в модель, а не конечная метрика
Тезис: постбек обеспечивает данные для измерения эффекта, но окончательная оценка должна учитывать смещение и смешение каналов.
Пример: last-click атрибуция в условиях privacy будет стабильно завышать “финальные” каналы и занижать роль прогрева (бренд/контент/ретаргетинг), особенно когда пользователи возвращаются позже. В 2026 это проявляется особенно заметно: средний чек в e-commerce снижается на 5–8% (покупатели экономят), а значит ценность “последнего шага” уменьшается — важнее вырастить LTV (пожизненную ценность) и удержание. Если вы смотрите только на доход атрибутированный postback’ом, вы будете ошибочно считать, что эффективность падает, хотя меняется структура спроса.
…
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Сбер запустит свой криптокошелёк
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Индия потребовала от Telegram удалять пиратский контент
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google ads меняет стратегию по конверсиям
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
Как мы уменьшили расхождение между рекламой и аналитикой с 18% до 4% на серверной схеме
В 2026 году главный риск в performance — не «плохой трафик», а сломанная атрибуция. Когда часть событий теряется в браузере, last-click (последний клик) начинает врать, а маркетолог видит рост CPC и падение ROMI без понимания причины.
Кейс из e-com бренда из fashion-сегмента уровня Lamoda. У них было три источника данных: пиксель в браузере, мобильная аналитика и CRM. На отчётах постоянно расходились цифры:
— в рекламном кабинете фиксировалось на 18% больше конверсий, чем в BI;
— 27% заказов терялись на этапе подтверждения оплаты;
— доля «непередаваемых» событий после перехода на iOS выросла почти в 2 раза.
Задача была не «поставить ещё один пиксель», а собрать измерение так, чтобы маркетинг мог принимать решения по выручке, а не по шуму.
Решение сделали в 4 слоя:
— серверный сбор событий через server-side (серверная схема) GTM;
— единый идентификатор заказа для сайта, приложения и CRM;
— postback (обратная передача конверсии) в рекламные системы по факту подтверждённой оплаты;
— валидация через сверку заказов: рекламная платформа → аналитика → ERP.
Отдельно пересмотрели окна атрибуции. Оставили короткое окно для performance-кампаний и добавили раздельную модель для повторных покупок, потому что в fashion на фоне снижения среднего чека на 5–8% удержание и LTV (пожизненная ценность клиента) стали важнее первой покупки.
Что получилось через 6 недель:
— расхождение между рекламой и BI сократилось с 18% до 4%;
— доля заказов, попадающих в отчёт с корректным source/medium, выросла до 96%;
— перераспределение бюджета по новым данным дало +11% к ROAS за квартал;
— доля «ложно эффективных» кампаний снизилась на 23%.
Главный урок простой: **пиксель — это не система измерения, а только один из датчиков**. Если у вас есть сервер, CRM и postback, можно собрать картину близко к выручке. Если нет — оптимизироваться будете не по продажам, а по артефактам браузера.
Для 2026 это уже базовая гигиена: privacy-first атрибуция, server-side и сквозная сверка важнее, чем попытка «дожать» ещё 3% кликов.
— @AdOpsRoom
В 2026 году главный риск в performance — не «плохой трафик», а сломанная атрибуция. Когда часть событий теряется в браузере, last-click (последний клик) начинает врать, а маркетолог видит рост CPC и падение ROMI без понимания причины.
Кейс из e-com бренда из fashion-сегмента уровня Lamoda. У них было три источника данных: пиксель в браузере, мобильная аналитика и CRM. На отчётах постоянно расходились цифры:
— в рекламном кабинете фиксировалось на 18% больше конверсий, чем в BI;
— 27% заказов терялись на этапе подтверждения оплаты;
— доля «непередаваемых» событий после перехода на iOS выросла почти в 2 раза.
Задача была не «поставить ещё один пиксель», а собрать измерение так, чтобы маркетинг мог принимать решения по выручке, а не по шуму.
Решение сделали в 4 слоя:
— серверный сбор событий через server-side (серверная схема) GTM;
— единый идентификатор заказа для сайта, приложения и CRM;
— postback (обратная передача конверсии) в рекламные системы по факту подтверждённой оплаты;
— валидация через сверку заказов: рекламная платформа → аналитика → ERP.
Отдельно пересмотрели окна атрибуции. Оставили короткое окно для performance-кампаний и добавили раздельную модель для повторных покупок, потому что в fashion на фоне снижения среднего чека на 5–8% удержание и LTV (пожизненная ценность клиента) стали важнее первой покупки.
Что получилось через 6 недель:
— расхождение между рекламой и BI сократилось с 18% до 4%;
— доля заказов, попадающих в отчёт с корректным source/medium, выросла до 96%;
— перераспределение бюджета по новым данным дало +11% к ROAS за квартал;
— доля «ложно эффективных» кампаний снизилась на 23%.
Главный урок простой: **пиксель — это не система измерения, а только один из датчиков**. Если у вас есть сервер, CRM и postback, можно собрать картину близко к выручке. Если нет — оптимизироваться будете не по продажам, а по артефактам браузера.
Для 2026 это уже базовая гигиена: privacy-first атрибуция, server-side и сквозная сверка важнее, чем попытка «дожать» ещё 3% кликов.
— @AdOpsRoom
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Codex внедрят GPT-5.6 Ultra
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Компания Meta выпустила Muse Image
Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.
Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.
Есть один вопрос, который интересует всех арбитражников: как это повлияет …
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image
🧠 Ещё больше инсайтов → в канале AFF.top
Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.
Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.
Есть один вопрос, который интересует всех арбитражников: как это повлияет …
➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image
🧠 Ещё больше инсайтов → в канале AFF.top
Postback как контракт: почему я перестал “просто пробрасывать” события
В 2026 я всё чаще вижу одну и ту же инженерную ошибку: postback воспринимают как техническую кнопку “отправь конверсию”, а не как договор между трекером, платформой и бизнес-метрикой. В результате мы получаем атрибуцию, которая “сходится по количеству”, но расходится по смыслу.
Моя позиция жёсткая: **postback должен быть инвариантным** относительно источника трафика и формата события на стороне рекламной системы. То есть одно и то же бизнес-событие (например, “SQL-сделка создана”, “пакет документов подписан”, “оплата прошла”) должно приходить в разные каналы одинаково: с одинаковыми ключами идентификации, одинаковыми правилами дедупликации и с одинаковой логикой “что считается успешным”.
Что я делаю на практике:
— Строю словарь событий “уровень бизнеса → уровень транспорта”. На уровне бизнеса: conversion_type, revenue_bucket, lead_stage. На уровне транспорта: client_id/server_id, time, event_hash, параметр качества (например, dedupe_key).
— Вводю “контроль версий” события: event_schema_version и обязательный набор полей. Если поменяли поле — считаем, что это новое событие до сверки.
— Дедупликацию переношу в серверную аналитику: postback может прийти дважды (ретраи, лаги, повторный апдейт лида), а атрибуция должна переживать это.
Одно наблюдение из реальной отладки (B2B, серверная связка CRM + ad platform):
когда мы оставили дедупликацию “на стороне приёмника”, расхождение по SQL составило около 6–9% по медиане недельного окна. После переноса дедупа на common-key (lead_id + stage + date_bucket) расхождение упало до 1–2%. Это не “маркетинговая магия”, это банальная математика: вероятность повторов не нулевая, а качество ключей важнее идеальной передачи “последнего клика”.
Почему это критично именно сейчас:
last-click всё сильнее выдавливают privacy-first подходы (server-side, MMM, incrementality). В такой архитектуре постбэк становится опорным узлом, и любое нестрогое трактование “события успеха” превращает модель в гадание по шуму.
Если хотите быстрый тест на зрелость вашей postback-схемы:
попробуйте зафиксировать один бизнес-кейс (один заказ/одна сделка) и проследить, сколько раз и в каких параметрах он уходит в платформу. Если вы не можете ответить “один кейс → одно событие → один dedupe_key” без ручной лог-охоты, значит контракт ещё не подписан — и атрибуция будет продолжать врать, даже когда цифры “похожи”.
Ядро мысли простое: **postback — это не канал связи, а часть измерительной системы**. Относитесь к нему как к интерфейсу: версия, инварианты, дедуп, контроль качества. Тогда серверная аналитика начинает работать как инженерная дисциплина, а не как набор надежд.
— @AdOpsRoom
В 2026 я всё чаще вижу одну и ту же инженерную ошибку: postback воспринимают как техническую кнопку “отправь конверсию”, а не как договор между трекером, платформой и бизнес-метрикой. В результате мы получаем атрибуцию, которая “сходится по количеству”, но расходится по смыслу.
Моя позиция жёсткая: **postback должен быть инвариантным** относительно источника трафика и формата события на стороне рекламной системы. То есть одно и то же бизнес-событие (например, “SQL-сделка создана”, “пакет документов подписан”, “оплата прошла”) должно приходить в разные каналы одинаково: с одинаковыми ключами идентификации, одинаковыми правилами дедупликации и с одинаковой логикой “что считается успешным”.
Что я делаю на практике:
— Строю словарь событий “уровень бизнеса → уровень транспорта”. На уровне бизнеса: conversion_type, revenue_bucket, lead_stage. На уровне транспорта: client_id/server_id, time, event_hash, параметр качества (например, dedupe_key).
— Вводю “контроль версий” события: event_schema_version и обязательный набор полей. Если поменяли поле — считаем, что это новое событие до сверки.
— Дедупликацию переношу в серверную аналитику: postback может прийти дважды (ретраи, лаги, повторный апдейт лида), а атрибуция должна переживать это.
Одно наблюдение из реальной отладки (B2B, серверная связка CRM + ad platform):
когда мы оставили дедупликацию “на стороне приёмника”, расхождение по SQL составило около 6–9% по медиане недельного окна. После переноса дедупа на common-key (lead_id + stage + date_bucket) расхождение упало до 1–2%. Это не “маркетинговая магия”, это банальная математика: вероятность повторов не нулевая, а качество ключей важнее идеальной передачи “последнего клика”.
Почему это критично именно сейчас:
last-click всё сильнее выдавливают privacy-first подходы (server-side, MMM, incrementality). В такой архитектуре постбэк становится опорным узлом, и любое нестрогое трактование “события успеха” превращает модель в гадание по шуму.
Если хотите быстрый тест на зрелость вашей postback-схемы:
попробуйте зафиксировать один бизнес-кейс (один заказ/одна сделка) и проследить, сколько раз и в каких параметрах он уходит в платформу. Если вы не можете ответить “один кейс → одно событие → один dedupe_key” без ручной лог-охоты, значит контракт ещё не подписан — и атрибуция будет продолжать врать, даже когда цифры “похожи”.
Ядро мысли простое: **postback — это не канал связи, а часть измерительной системы**. Относитесь к нему как к интерфейсу: версия, инварианты, дедуп, контроль качества. Тогда серверная аналитика начинает работать как инженерная дисциплина, а не как набор надежд.
— @AdOpsRoom
Forwarded from Я ЗЛОЙ, Я ГАНГСТА
This media is not supported in your browser
VIEW IN TELEGRAM
Хоменок потребовал, чтобы кардиналы уволили Иванова — новая драма из нижней аффилки.
Вспоминаем этого персонажа: в преддверии МАК и джигейт конф овнер Х6 Group Антон Хоменок назвал себя «инфлюенсером года» и заявил, что если не выиграет награды — значит, премии на конфах купленные. Как и можно было ожидать, умник ничерта не выиграл, но это унижение не помешало ему сделать предложение своей девушке на «коррумпированной» сцене джигеев.
Так вот, на конфе Хоменок посоветовал СЕО кардиналов уволить ЕЮ — мол, он фрик, с которым нельзя сотрудничать. Эта инфа разумеется дошла до Иванова — в ответ он предложил выкупить всю конторку кардиналов (их овнер пока не ответил). Вообще удивительно, с какой уверенностью Антоха даёт коллегам по сфере советы, не понимая базовые вещи (например, тот факт, что ЕЮ — вообще не наёмный сотрудник). Под конец Хоменок слился со стрима с Ивановым, заваливая его комплиментами — ожидаемое лицемерие, что тут скажешь.
К слову, когда ЕЮ спросил у Алексеева, уволил бы тот его, овнер приватов ответил, что скорее Иванов его уволит (что, может, и не так, но главному алкашу сферы всё равно было приятно).
🥴 — «инфлюенсер года», хуле
🤡 — типичный ЧСВшник без реальных достижений в сфере, такая лайф
😈 Я ЗЛОЙ, Я ГАНГСТА
Вспоминаем этого персонажа: в преддверии МАК и джигейт конф овнер Х6 Group Антон Хоменок назвал себя «инфлюенсером года» и заявил, что если не выиграет награды — значит, премии на конфах купленные. Как и можно было ожидать, умник ничерта не выиграл, но это унижение не помешало ему сделать предложение своей девушке на «коррумпированной» сцене джигеев.
Так вот, на конфе Хоменок посоветовал СЕО кардиналов уволить ЕЮ — мол, он фрик, с которым нельзя сотрудничать. Эта инфа разумеется дошла до Иванова — в ответ он предложил выкупить всю конторку кардиналов (их овнер пока не ответил). Вообще удивительно, с какой уверенностью Антоха даёт коллегам по сфере советы, не понимая базовые вещи (например, тот факт, что ЕЮ — вообще не наёмный сотрудник). Под конец Хоменок слился со стрима с Ивановым, заваливая его комплиментами — ожидаемое лицемерие, что тут скажешь.
К слову, когда ЕЮ спросил у Алексеева, уволил бы тот его, овнер приватов ответил, что скорее Иванов его уволит (что, может, и не так, но главному алкашу сферы всё равно было приятно).
🥴 — «инфлюенсер года», хуле
🤡 — типичный ЧСВшник без реальных достижений в сфере, такая лайф
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Китай планирует ограничить доступ к DeepSeek и GLM
Китай готовится ограничить публичный доступ к своим флагманским нейросетям — DeepSeek и GLM. Запрет по образцу США становится новой нормальностью.
Правительство рассматривает трёхуровневую систему: от стандартной регистрации для простых моделей до полного закрытия самых передовых — только для внутреннего использования.
Но есть один подвох, котор…
➡️ Читайте на сайте: https://aff.top/blog/kitai-planiruet-ogranichit-dostup-k-deepseek-i-glm
🧠 Ещё больше инсайтов → в канале AFF.top
Китай готовится ограничить публичный доступ к своим флагманским нейросетям — DeepSeek и GLM. Запрет по образцу США становится новой нормальностью.
Правительство рассматривает трёхуровневую систему: от стандартной регистрации для простых моделей до полного закрытия самых передовых — только для внутреннего использования.
Но есть один подвох, котор…
➡️ Читайте на сайте: https://aff.top/blog/kitai-planiruet-ogranichit-dostup-k-deepseek-i-glm
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from Я ненавижу арбитраж
ЕЮ покупает мусор недорого: 150к за Трафик Кардинал раз 🔨
По случаю Жениной "развязки" разгорелся небольшой сканадал.
Для медиа с тремя инсультами — это очень выгодное предложение. Больше не даст никто. 150к бачей — два🔨
Результаты пока неизвестны, публичные торги еще не начаты.
❤️ — я бы дал больше
😁 — Пусть Жека купит "X6Agency" и уволит Хоменока
😎 — 150к бачей — три. Продано
Я ненавижу арбитраж | Чат😠
По случаю Жениной "развязки" разгорелся небольшой сканадал.
На G GATE CONF маркетолог, визионер, трудоголик, филантроп Хоменок не стал лучшим инфлюенсером, да и вообще никем. Но тем не менее дал совет ребятам из ТК — уволить Иванова. Я поднял все архивы арбитражки, но так и не понял, кто его нанял. Единственное, что я знаю, но не могу доказать — когда-то ТК проплатили медийную поддержку от маэстро, чтобы тот перестал их публично унижать.
Естественно, Жекич тут же узнал об этом шкурном поступке Антона от Кустова Никиты (главреда ТК), обиделся, оскорбился и предложил 150к бачей за покупку медиа Traffic Cardinal. Видимо, побоялся, что попадет под сокращения.
Для медиа с тремя инсультами — это очень выгодное предложение. Больше не даст никто. 150к бачей — два
Результаты пока неизвестны, публичные торги еще не начаты.
❤️ — я бы дал больше
😁 — Пусть Жека купит "X6Agency" и уволит Хоменока
😎 — 150к бачей — три. Продано
Я ненавижу арбитраж | Чат
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AffPapa! Клуб спящих бизнесменов! Потрачено!
⚡️У кого каналы и кто продаёт рекламу - для вас не большое объявление!
Очень стараюсь собрать все арбитражные и смежных каналы, что бы сделать каталог цен на размещение там рекламы, если у вас есть канал, вы там продаёте рекламу, пожалуйста просто пришлите Давиду @AFFtop_connect ценик
Прям в таком формате, лишней хуйни не надо, ребята просто добавят ваш канал в публичный каталог, если конечно же вам вообще нужны реклы
Приватные каналы пока не принимают, с ними позже будут разбираться
Альфа версия https://tg.observer если кому то интересно
@Pacan
Очень стараюсь собрать все арбитражные и смежных каналы, что бы сделать каталог цен на размещение там рекламы, если у вас есть канал, вы там продаёте рекламу, пожалуйста просто пришлите Давиду @AFFtop_connect ценик
@username - XXX$
Прям в таком формате, лишней хуйни не надо, ребята просто добавят ваш канал в публичный каталог, если конечно же вам вообще нужны реклы
Приватные каналы пока не принимают, с ними позже будут разбираться
Альфа версия https://tg.observer если кому то интересно
🤔 Консоли Google Play и Apple Developer надо? Phoenix — 100% свой фарм с 2021-го. Забрать акки → @phoenix_seller_bot🤔
@Pacan
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
ByteDance выпустила Seedream 5.0 pro
ByteDance выпустила Seedream 5.0 pro — генератор изображений с послойным редактированием прямо внутри интерфейса.
Ключевая фича: выделяешь объект — он уходит на отдельный слой, двигаешь и масштабируешь независимо. Пустую зону можно дозаполнить промтом. Текст на изображениях без глитчей — нативно.
Для арбитражников это может быть удобным инструме…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-vypustila-seedream-5-0-pro
🧠 Ещё больше инсайтов → в канале AFF.top
ByteDance выпустила Seedream 5.0 pro — генератор изображений с послойным редактированием прямо внутри интерфейса.
Ключевая фича: выделяешь объект — он уходит на отдельный слой, двигаешь и масштабируешь независимо. Пустую зону можно дозаполнить промтом. Текст на изображениях без глитчей — нативно.
Для арбитражников это может быть удобным инструме…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-vypustila-seedream-5-0-pro
🧠 Ещё больше инсайтов → в канале AFF.top
Пиксель без сервера в 2026 году — это не аналитика, а версия истории для отчёта
Я всё чаще вижу одну и ту же ошибку: команда считает, что «пиксель стоит, значит данные есть». На практике это уже почти ложное чувство контроля.
Если у вас только клиентский пиксель, вы теряете часть событий из-за блокировщиков, ограничений браузеров, отказов в cookie и банальных сбоев загрузки. Для performance-маркетинга это особенно больно: вы оптимизируете не спрос, а его фрагмент. А потом удивляетесь, почему платный трафик «просел», хотя канал на самом деле просто стал хуже измеряться.
Мой рабочий вывод такой: **в 2026 году серверная аналитика — это не апгрейд, а базовый слой инфраструктуры**. Пиксель нужен для быстрого сигнала, сервер — для подтверждения факта. Только в связке они дают данные, на которые можно опираться в закупке.
Из практики: после перевода части событий на серверный сбор у одного B2B-проекта доля «потерянных» конверсий между рекламной платформой и CRM заметно сократилась. Не магия, а нормализация цепочки: событие фиксируется ближе к источнику правды, а не только в браузере пользователя. Это особенно важно, когда воронка длинная и решение принимается не в первый визит.
Но я бы не продавал серверную аналитику как универсальное лекарство. Она не спасёт плохую разметку, кривую CRM и пустые статусы сделок. Она лишь убирает один из главных шумов.
Если совсем коротко, моя позиция такая:
— пиксель нужен для скорости;
— сервер нужен для надёжности;
— postback нужен там, где есть строгая связка события и результата;
— а доверять стоит не каналу измерения, а системе, где событие можно проверить в двух местах.
В эпоху privacy-first атрибуции выигрывает не тот, у кого больше тегов, а тот, у кого меньше дыр в цепочке данных.
— @AdOpsRoom
Параллельный взгляд на тему — @DemandGenB2B
Я всё чаще вижу одну и ту же ошибку: команда считает, что «пиксель стоит, значит данные есть». На практике это уже почти ложное чувство контроля.
Если у вас только клиентский пиксель, вы теряете часть событий из-за блокировщиков, ограничений браузеров, отказов в cookie и банальных сбоев загрузки. Для performance-маркетинга это особенно больно: вы оптимизируете не спрос, а его фрагмент. А потом удивляетесь, почему платный трафик «просел», хотя канал на самом деле просто стал хуже измеряться.
Мой рабочий вывод такой: **в 2026 году серверная аналитика — это не апгрейд, а базовый слой инфраструктуры**. Пиксель нужен для быстрого сигнала, сервер — для подтверждения факта. Только в связке они дают данные, на которые можно опираться в закупке.
Из практики: после перевода части событий на серверный сбор у одного B2B-проекта доля «потерянных» конверсий между рекламной платформой и CRM заметно сократилась. Не магия, а нормализация цепочки: событие фиксируется ближе к источнику правды, а не только в браузере пользователя. Это особенно важно, когда воронка длинная и решение принимается не в первый визит.
Но я бы не продавал серверную аналитику как универсальное лекарство. Она не спасёт плохую разметку, кривую CRM и пустые статусы сделок. Она лишь убирает один из главных шумов.
Если совсем коротко, моя позиция такая:
— пиксель нужен для скорости;
— сервер нужен для надёжности;
— postback нужен там, где есть строгая связка события и результата;
— а доверять стоит не каналу измерения, а системе, где событие можно проверить в двух местах.
В эпоху privacy-first атрибуции выигрывает не тот, у кого больше тегов, а тот, у кого меньше дыр в цепочке данных.
— @AdOpsRoom
Параллельный взгляд на тему — @DemandGenB2B
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Создателя Telegram снова допрашивали
Павла Дурова снова допросили во Франции: встреча с следствием длилась более 6 часов.
Это уже не первый эпизод в деле, которое тянется с 2024 года: тогда основателя Telegram арестовали в аэропорту Ле-бурже и ограничивали в выезде до июня 2025.
Что именно выясняли на новом допросе — не раскрывают. Но давление на Telegram растёт, и в этой истории е…
➡️ Читайте на сайте: https://aff.top/blog/sozdatelia-telegram-snova-doprashivali
🧠 Ещё больше инсайтов → в канале AFF.top
Павла Дурова снова допросили во Франции: встреча с следствием длилась более 6 часов.
Это уже не первый эпизод в деле, которое тянется с 2024 года: тогда основателя Telegram арестовали в аэропорту Ле-бурже и ограничивали в выезде до июня 2025.
Что именно выясняли на новом допросе — не раскрывают. Но давление на Telegram растёт, и в этой истории е…
➡️ Читайте на сайте: https://aff.top/blog/sozdatelia-telegram-snova-doprashivali
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Cloudflare запустил функцию Drop
Cloudflare запустил Drop — сервис, который разворачивает временный сайт за несколько секунд прямо из zip-архива.
Без аккаунта можно создавать сколько угодно таких страниц, но ссылка живёт всего 1 час. Потом сайт придётся переносить в аккаунт.
Зачем это нужно арбитражнику и что можно успеть за это время — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/cloudflare-zapustil-funkciiu-drop
🧠 Ещё больше инсайтов → в канале AFF.top
Cloudflare запустил Drop — сервис, который разворачивает временный сайт за несколько секунд прямо из zip-архива.
Без аккаунта можно создавать сколько угодно таких страниц, но ссылка живёт всего 1 час. Потом сайт придётся переносить в аккаунт.
Зачем это нужно арбитражнику и что можно успеть за это время — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/cloudflare-zapustil-funkciiu-drop
🧠 Ещё больше инсайтов → в канале AFF.top
Server-side не спасает от плохой схемы событий
Я всё чаще вижу одну и ту же ошибку: маркетинг ставит серверную аналитику как «новый пиксель», а потом удивляется, почему отчёты всё равно расходятся с оплатой, CRM и медиа-кабинетами. Проблема обычно не в технологии. Проблема в том, что события изначально спроектированы как набор красивых названий, а не как измерительная система.
Мой практический вывод такой: **сервер-сайд (server-side) усиливает дисциплину, но не заменяет её**. Если у вас на клиенте один lead, на сервере второй, в CRM третий, а в postback улетает четвёртый — вы не внедрили аналитику, вы размножили шум.
Что я считаю обязательным:
— одно и то же событие должно иметь один смысл во всех системах;
— у каждого события должен быть владелец: кто создаёт, кто валидирует, кто потребляет;
— нужна таблица соответствий между пикселем, сервером, CRM и рекламной платформой;
— postback должен отвечать не за «что-нибудь отправить», а за конкретную бизнес-стадию: квалификация, оплата, возврат, повторная покупка.
В 2026 году это особенно заметно: last-click слабеет, privacy-first атрибуция требует чистых данных, а RevOps заставляет маркетинг говорить с продажами и клиентским успехом на одном языке. И если схема событий не склеена заранее, то никакая MMM-модель и никакой серверный контейнер не сделают из мусора сигнал.
Я обычно начинаю не с инструмента, а с вопроса: какое решение будет принято на основе этого события? Если ответа нет — событие лишнее. Если ответ есть — его уже можно проектировать в пиксель, сервер и postback без потерь смысла.
— @AdOpsRoom
Я всё чаще вижу одну и ту же ошибку: маркетинг ставит серверную аналитику как «новый пиксель», а потом удивляется, почему отчёты всё равно расходятся с оплатой, CRM и медиа-кабинетами. Проблема обычно не в технологии. Проблема в том, что события изначально спроектированы как набор красивых названий, а не как измерительная система.
Мой практический вывод такой: **сервер-сайд (server-side) усиливает дисциплину, но не заменяет её**. Если у вас на клиенте один lead, на сервере второй, в CRM третий, а в postback улетает четвёртый — вы не внедрили аналитику, вы размножили шум.
Что я считаю обязательным:
— одно и то же событие должно иметь один смысл во всех системах;
— у каждого события должен быть владелец: кто создаёт, кто валидирует, кто потребляет;
— нужна таблица соответствий между пикселем, сервером, CRM и рекламной платформой;
— postback должен отвечать не за «что-нибудь отправить», а за конкретную бизнес-стадию: квалификация, оплата, возврат, повторная покупка.
В 2026 году это особенно заметно: last-click слабеет, privacy-first атрибуция требует чистых данных, а RevOps заставляет маркетинг говорить с продажами и клиентским успехом на одном языке. И если схема событий не склеена заранее, то никакая MMM-модель и никакой серверный контейнер не сделают из мусора сигнал.
Я обычно начинаю не с инструмента, а с вопроса: какое решение будет принято на основе этого события? Если ответа нет — событие лишнее. Если ответ есть — его уже можно проектировать в пиксель, сервер и postback без потерь смысла.
— @AdOpsRoom
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Open AI выпустила ChatGPT-5.6 и ChatGPT Work
OpenAI выпустила ChatGPT-5.6 и ChatGPT Work: новая модель получила три версии и понятный прайс, а Work стал универсальным инструментом для кодинга, текстов, изображений и анализа данных. Вывод простой: экосистема ChatGPT усиливается, а фокус смещается на многофункциональные сценарии, где один продукт закрывает сразу несколько задач.
➡️ Читайте на сайте: https://aff.top/blog/open-ai-vypustila-chatgpt-5-6-i-chatgpt-work
🧠 Ещё больше инсайтов → в канале AFF.top
OpenAI выпустила ChatGPT-5.6 и ChatGPT Work: новая модель получила три версии и понятный прайс, а Work стал универсальным инструментом для кодинга, текстов, изображений и анализа данных. Вывод простой: экосистема ChatGPT усиливается, а фокус смещается на многофункциональные сценарии, где один продукт закрывает сразу несколько задач.
➡️ Читайте на сайте: https://aff.top/blog/open-ai-vypustila-chatgpt-5-6-i-chatgpt-work
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
SpacexAI выпустила Grok 4.5
xAI выпустила Grok 4.5 — новую версию флагманской нейросети, доступную в Cursor на всех тарифах и по API за $2 за миллион входных токенов. Бенчмарков пока нет, но модель в 4,2 раза экономнее по токенам на SWE Bench Pro и обучена на данных Cursor, что делает её сильным инструментом для разработки приложений.
➡️ Читайте на сайте: https://aff.top/blog/spacexai-vypustila-grok-4-5
🧠 Ещё больше инсайтов → в канале AFF.top
xAI выпустила Grok 4.5 — новую версию флагманской нейросети, доступную в Cursor на всех тарифах и по API за $2 за миллион входных токенов. Бенчмарков пока нет, но модель в 4,2 раза экономнее по токенам на SWE Bench Pro и обучена на данных Cursor, что делает её сильным инструментом для разработки приложений.
➡️ Читайте на сайте: https://aff.top/blog/spacexai-vypustila-grok-4-5
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
ChatGPT ads внедрил функцию автосоздания креативов
OpenAI добавила в ChatGPT Ads автогенерацию креативов: вставляешь ссылку на сайт, ИИ анализирует лендинг и создаёт релевантный креатив. По ощущениям, такие материалы должны легко проходить модерацию, но пока неясно, насколько они поддаются правкам. Источник интересен ещё и тем, что вайт можно сгенерировать тут же через ChatGPT.
➡️ Читайте на сайте: https://aff.top/blog/chatgpt-ads-vnedril-funkciiu-avtosozdaniia-kreativov
🧠 Ещё больше инсайтов → в канале AFF.top
OpenAI добавила в ChatGPT Ads автогенерацию креативов: вставляешь ссылку на сайт, ИИ анализирует лендинг и создаёт релевантный креатив. По ощущениям, такие материалы должны легко проходить модерацию, но пока неясно, насколько они поддаются правкам. Источник интересен ещё и тем, что вайт можно сгенерировать тут же через ChatGPT.
➡️ Читайте на сайте: https://aff.top/blog/chatgpt-ads-vnedril-funkciiu-avtosozdaniia-kreativov
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Google search console теперь можно добавлять соцсети
Google добавил в Search Console поддержку аккаунтов соцсетей: теперь можно отслеживать ключевые запросы, источники и географию переходов, показы и клики по ссылкам. Функция подключается там же, где и сайты, доступны четыре соцсети на выбор. Rollout постепенный — доступ получают не все сразу.
➡️ Читайте на сайте: https://aff.top/blog/v-google-search-console-teper-mozhno-dobavliat-socseti
🧠 Ещё больше инсайтов → в канале AFF.top
Google добавил в Search Console поддержку аккаунтов соцсетей: теперь можно отслеживать ключевые запросы, источники и географию переходов, показы и клики по ссылкам. Функция подключается там же, где и сайты, доступны четыре соцсети на выбор. Rollout постепенный — доступ получают не все сразу.
➡️ Читайте на сайте: https://aff.top/blog/v-google-search-console-teper-mozhno-dobavliat-socseti
🧠 Ещё больше инсайтов → в канале AFF.top