ЧМ-2026: $35 млрд ставок, но стадионный gambling-инвентарь обнулён
11 июня стартует крупнейший ЧМ в истории: 48 команд и 104 матча. Прогноз по ставкам — $35 млрд, при этом FIFA убрала gambling-рекламу со всех стадионов.
Для iGaming это миграция не только в Influence, но и в другой контур атрибуции. У инфлюенсерского трафика чаще ломаются click_id, рефы и post-click цепочки: редиректы, bio-links, webview, промокоды вместо нормального event_id.
Что стоит собрать до запуска:
—
— first-party storage для click_id на лендинге
— server-side отправку registration/deposit
— промокод как отдельный match key, а не замену атрибуции
— раздельные события для influencer_id / placement / creative
Если закупка уйдёт в Influence, а трекинг останется last-click + UTM, часть депозитов будет выглядеть как direct/organic. Это не проблема медиабаинга — это проблема схемы событий.
11 июня стартует крупнейший ЧМ в истории: 48 команд и 104 матча. Прогноз по ставкам — $35 млрд, при этом FIFA убрала gambling-рекламу со всех стадионов.
Для iGaming это миграция не только в Influence, но и в другой контур атрибуции. У инфлюенсерского трафика чаще ломаются click_id, рефы и post-click цепочки: редиректы, bio-links, webview, промокоды вместо нормального event_id.
Что стоит собрать до запуска:
—
event_id единый для Pixel/CAPI или SDK/Events API— first-party storage для click_id на лендинге
— server-side отправку registration/deposit
— промокод как отдельный match key, а не замену атрибуции
— раздельные события для influencer_id / placement / creative
Если закупка уйдёт в Influence, а трекинг останется last-click + UTM, часть депозитов будет выглядеть как direct/organic. Это не проблема медиабаинга — это проблема схемы событий.
Server-side проксирование Pixel событий: чек-лист без потери дедупликации
Если проксируете браузерный Pixel через sGTM, первая ошибка — менять payload «как удобнее». Для browser и server части должен совпадать event_name и event_id, иначе deduplication начнёт считать дубли как отдельные конверсии.
Проверьте базу:
— event_id генерируется один раз и уходит в Pixel и CAPI
— fbp и fbc не теряются при проксировании
— user_data передаётся в одном формате: email_hash, phone_hash, external_id
— IP и User-Agent берутся из запроса, а не подставляются шаблонно
Дальше смотрите на routing. Если Custom Client режет query string или cookie headers, серверный запрос к Meta становится «беднее» клиентского. В итоге EMQ падает не из-за CAPI как такового, а из-за того, что вы потеряли контекст до отправки события.
Отдельно проверьте порядок обработки: сначала принять browser event, потом нормализовать данные, потом отправить server copy. Если на этом этапе есть ретраи, ставьте idempotency по event_id, иначе получите повторную отправку одного Purchase.
Практика простая: проксирование работает только когда сервер повторяет смысл client-side события, а не «улучшает» его. Сначала синхронизируйте идентификаторы и поля, потом уже оптимизируйте шаблоны и логику маршрутизации.
Если проксируете браузерный Pixel через sGTM, первая ошибка — менять payload «как удобнее». Для browser и server части должен совпадать event_name и event_id, иначе deduplication начнёт считать дубли как отдельные конверсии.
Проверьте базу:
— event_id генерируется один раз и уходит в Pixel и CAPI
— fbp и fbc не теряются при проксировании
— user_data передаётся в одном формате: email_hash, phone_hash, external_id
— IP и User-Agent берутся из запроса, а не подставляются шаблонно
Дальше смотрите на routing. Если Custom Client режет query string или cookie headers, серверный запрос к Meta становится «беднее» клиентского. В итоге EMQ падает не из-за CAPI как такового, а из-за того, что вы потеряли контекст до отправки события.
Отдельно проверьте порядок обработки: сначала принять browser event, потом нормализовать данные, потом отправить server copy. Если на этом этапе есть ретраи, ставьте idempotency по event_id, иначе получите повторную отправку одного Purchase.
Практика простая: проксирование работает только когда сервер повторяет смысл client-side события, а не «улучшает» его. Сначала синхронизируйте идентификаторы и поля, потом уже оптимизируйте шаблоны и логику маршрутизации.
Server-side проксирование Pixel событий: чек-лист без потери дедупликации
Когда Pixel уходит через sGTM, чаще всего ломаются не «события», а их связка: event_id, fbp/fbc и порядок отправки. Поэтому сначала проверьте, что client-side и server-side шлют один и тот же event_id для одного действия, иначе deduplication превращается в лотерею.
Что должно быть в прокси-цепочке:
— Pageview/Purchase идут в один и тот же endpoint
— В payload сохраняются event_name, event_time, event_id
— Для CAPI передаются user_data: email_hash, phone_hash, ip, user_agent, fbp, fbc
— Хеширование только SHA-256, с нормализацией lower-case, trim, E.164 для телефона
Дальше смотрите на порядок запросов. Если server-event приходит сильно раньше Pixel, часть систем может выбрать не тот источник для дедупликации. Рабочий паттерн: генерировать event_id на клиенте, а в sGTM только прокидывать его дальше без переименования и без «умного» преобразования.
Отдельный чек: не теряйте query-параметры click_id на редиректах и не режьте cookies на уровне прокси. Если fbc/fbp пустые, EMQ и match rate падают даже при идеальном роутинге.
Итог простой: сначала стабилизируйте event_id и user_data, потом уже оптимизируйте маршрутизацию. Если дедупликация не сходится, прокси не лечит атрибуцию — он только ускоряет поломку.
Когда Pixel уходит через sGTM, чаще всего ломаются не «события», а их связка: event_id, fbp/fbc и порядок отправки. Поэтому сначала проверьте, что client-side и server-side шлют один и тот же event_id для одного действия, иначе deduplication превращается в лотерею.
Что должно быть в прокси-цепочке:
— Pageview/Purchase идут в один и тот же endpoint
— В payload сохраняются event_name, event_time, event_id
— Для CAPI передаются user_data: email_hash, phone_hash, ip, user_agent, fbp, fbc
— Хеширование только SHA-256, с нормализацией lower-case, trim, E.164 для телефона
Дальше смотрите на порядок запросов. Если server-event приходит сильно раньше Pixel, часть систем может выбрать не тот источник для дедупликации. Рабочий паттерн: генерировать event_id на клиенте, а в sGTM только прокидывать его дальше без переименования и без «умного» преобразования.
Отдельный чек: не теряйте query-параметры click_id на редиректах и не режьте cookies на уровне прокси. Если fbc/fbp пустые, EMQ и match rate падают даже при идеальном роутинге.
Итог простой: сначала стабилизируйте event_id и user_data, потом уже оптимизируйте маршрутизацию. Если дедупликация не сходится, прокси не лечит атрибуцию — он только ускоряет поломку.
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
Adblock detection: как не терять события, когда браузер режет теги и пиксели
Adblock чаще ломает не «аналитику вообще», а конкретные точки: загрузку GTM, запросы к /collect, пиксельные gif, сторонние скрипты. Поэтому считать нужно не по факту отказа скрипта, а по тому, дошёл ли серверный hit и есть ли запасной маршрут.
Рабочая схема:
— client-side отправляет event_id и минимальный контекст
— sGTM принимает его и пишет в first-party endpoint
— если браузер блокирует пиксель, сервер всё равно видит POST
— для критичных событий держите fallback через form submit / fetch
Что проверять:
— не грузите всё через один внешний домен
— не завязывайте Purchase только на JS callback
— добавьте таймаут на client-side и retry на server-side
— сравнивайте browser count vs server count по event_name и event_id
Анти-кейс: если событие живёт только в `gtag('event')`, Adblock не просто режет доставку — вы ещё и теряете дедупликацию. Тогда Pixel и CAPI расходятся, а EMQ/Match Quality на сервере выглядит хуже, чем есть.
Вывод простой: считайте не «блок есть или нет», а покрытие маршрутов. Чем раньше у события появляется server-side дубль и нормальный event_id, тем меньше потерь от блокировок и тем чище атрибуция.
Adblock чаще ломает не «аналитику вообще», а конкретные точки: загрузку GTM, запросы к /collect, пиксельные gif, сторонние скрипты. Поэтому считать нужно не по факту отказа скрипта, а по тому, дошёл ли серверный hit и есть ли запасной маршрут.
Рабочая схема:
— client-side отправляет event_id и минимальный контекст
— sGTM принимает его и пишет в first-party endpoint
— если браузер блокирует пиксель, сервер всё равно видит POST
— для критичных событий держите fallback через form submit / fetch
Что проверять:
— не грузите всё через один внешний домен
— не завязывайте Purchase только на JS callback
— добавьте таймаут на client-side и retry на server-side
— сравнивайте browser count vs server count по event_name и event_id
Анти-кейс: если событие живёт только в `gtag('event')`, Adblock не просто режет доставку — вы ещё и теряете дедупликацию. Тогда Pixel и CAPI расходятся, а EMQ/Match Quality на сервере выглядит хуже, чем есть.
Вывод простой: считайте не «блок есть или нет», а покрытие маршрутов. Чем раньше у события появляется server-side дубль и нормальный event_id, тем меньше потерь от блокировок и тем чище атрибуция.
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
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
Server-side трекинг для PWA: где ломается атрибуция и как это чинить
В PWA часто нет нормального reload-паттерна: пользователь открывает приложение, переходит между экранами без полной перезагрузки страницы, а client-side теги видят только часть истории. Поэтому sGTM здесь нужен не «для красоты», а чтобы собрать события в один поток и не потерять Purchase, Lead или add_to_cart.
Ключевая специфика:
— отправляйте событие не только из view, но и из app-router переходов;
— передавайте стабильный
— храните first-party идентификатор в cookie или localStorage и поднимайте его на сервере;
— для авторизованных пользователей используйте email/phone hash, но только после нормализации.
Отдельная боль — offline/online стык. В PWA событие может родиться без сети и уйти позже. Если вы шлёте его напрямую в vendor API, атрибуция разваливается. Лучше буферизовать payload на клиенте, а серверу отдавать уже собранный пакет с временем исходного действия, IP, User-Agent и click_id, если он есть.
Ещё один частый анти-кейс: тег срабатывает только на первом открытии, а затем PWA живёт внутри одного shell. Проверка простая — сравните число route-change events и число server hits. Если разрыв растёт, проблема не в CAPI, а в том, что вы слушаете не тот источник событий.
Вывод простой: для PWA проектируйте трекинг как event stream, а не как набор pageview-ов. Тогда sGTM перестаёт быть «пожарной трубой» и начинает реально держать атрибуцию.
В PWA часто нет нормального reload-паттерна: пользователь открывает приложение, переходит между экранами без полной перезагрузки страницы, а client-side теги видят только часть истории. Поэтому sGTM здесь нужен не «для красоты», а чтобы собрать события в один поток и не потерять Purchase, Lead или add_to_cart.
Ключевая специфика:
— отправляйте событие не только из view, но и из app-router переходов;
— передавайте стабильный
event_id для дедупликации Pixel + CAPI;— храните first-party идентификатор в cookie или localStorage и поднимайте его на сервере;
— для авторизованных пользователей используйте email/phone hash, но только после нормализации.
Отдельная боль — offline/online стык. В PWA событие может родиться без сети и уйти позже. Если вы шлёте его напрямую в vendor API, атрибуция разваливается. Лучше буферизовать payload на клиенте, а серверу отдавать уже собранный пакет с временем исходного действия, IP, User-Agent и click_id, если он есть.
Ещё один частый анти-кейс: тег срабатывает только на первом открытии, а затем PWA живёт внутри одного shell. Проверка простая — сравните число route-change events и число server hits. Если разрыв растёт, проблема не в CAPI, а в том, что вы слушаете не тот источник событий.
Вывод простой: для PWA проектируйте трекинг как event stream, а не как набор pageview-ов. Тогда sGTM перестаёт быть «пожарной трубой» и начинает реально держать атрибуцию.