Гайд: как заработать первые деньги на Pornhub

Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.

Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.

Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…

➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub

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

Почему атрибуция на основе последнего клика окончательно стала рудиментом

В 2026 году продолжать оценивать эффективность каналов по последнему клику (last-click) — это всё равно что пытаться управлять современным маркетплейсом с помощью бумажных счетов. В эпоху, когда пользователь совершает до десяти касаний с брендом, прежде чем оформить покупку, старые модели слепнут.

Проблема не только в приватности данных, которая ограничила возможности классических трекеров. Проблема в самой логике RevOps (единой системы управления выручкой), где маркетинг, продажи и клиентский сервис работают как один организм. Когда мы отдаем всю ценность конверсии только последнему источнику, мы фактически «убиваем» верхние этапы воронки, ориентированные на формирование спроса и построение авторитета в тематике (Topical Authority).

В BigQuery мы решаем эту задачу через переход к моделированию маркетингового микса (MMM) и анализу инкрементальности (дополнительной ценности). Суть в том, чтобы использовать SQL-запросы не просто для выгрузки отчетов, а для сопоставления сырых данных из CRM, логов рекламных платформ и оффлайн-событий.

На практике это выглядит так:
— Мы перестаем верить «красивым» отчетам из рекламных кабинетов.
— Мы строим собственные таблицы соответствия, где объединяем данные о расходах с данными о фактической выручке, очищенной от возвратов.
— Мы проводим тесты на «выключение» каналов, чтобы понять, какой объем продаж был бы без конкретного источника трафика.

Цифра из практики: после пересчета атрибуции на основе вклада каждого этапа пути клиента в одном из наших проектов по E-com, стоимость привлечения покупателя (CAC) в контентных каналах оказалась на 35% ниже, чем показывала система аналитики до этого. Стало очевидно, что инвестиции в экспертный контент, который «прогревает» аудиторию, приносят кратно больше LTV (пожизненной ценности клиента), чем закупка трафика на прямую продажу.

Сегодня аналитик в маркетинге — это не тот, кто умеет строить дашборды. Это тот, кто умеет доказать руководству, что отказ от краткосрочной метрики в пользу долгосрочного удержания (retention) — единственный способ выжить при снижении среднего чека рынка. Перестаньте искать «святой грааль» в атрибуции. Начинайте собирать собственный массив данных, который будет отражать реальную экономику вашего бизнеса, а не рекламные сказки платформ. Использование облачного хранилища здесь — не роскошь, а необходимость для построения достоверной картины мира.

— @BigQuery4MarketingPro

Как Nike собрал единый профиль клиента из 40+ источников в BigQuery и перестал терять атрибуцию

Контекст

К 2024 году у Nike было больше 40 разрозненных маркетинговых платформ: приложения Nike, SNKRS, Run Club, Nike.com для 35 стран, retail-данные, программа лояльности, медиа-сети, сторонние ритейлеры. Каждый канал жил в собственной DMP (data management platform) или SaaS. Маркетологи получали отчёт, в котором атрибуция последнего клика регулярно приписывала конверсию платной выдаче Google, хотя покупатель впервые увидел бренд в подкасте или через уведомление SNKRS за 11 недель до заказа. В условиях cookie-less атрибуции такая картина стоила бюджета.

Задача

Свести поведение клиента во всех точках в один профиль, построить самообучающуюся атрибуцию и отдавать сегменты в медиа-активацию в реальном времени. При этом не нарушить GDPR и не зависеть от сторонних идентификаторов.

Решение

Nike развернул собственный слой данных на BigQuery (Google Cloud) и связал его через серверный коннектор с медийными платформами. Схема строилась вокруг сущности Member — единого идентификатора, который склеивался по логину в приложении, email в чеке, email loyalty-карты и хешу мобильного идентификатора.

Ключевые шаги:

— Событийный стрим из приложений, сайта и POS (point of sale — кассовые терминалы) лился в BigQuery через Dataflow с задержкой до 90 секунд
— Офлайн-продажи матчились с цифровым профилем по ключу клиента, что в e-com и ритейле обычно боль
— Для атрибуции использовали data-driven модель на базе BigQuery ML с Shapley Value — алгоритм справедливого распределения вклада между касаниями
— Сегменты экспортировались обратно в DV360, Meta, TikTok через server-side коннекторы, без передачи сырых персональных данных

Результат

За первый год работы: доля корректно атрибутированного медиа-вклада выросла с ~45% до ~78%. Бюджет на нижне-воронковые кампании (ориентация на тех, кто уже близок к покупке) перераспределили: +22% в brand-форматы (верхняя часть воронки, узнаваемость) и лояльность, -15% в performance-выдачу. LTV (пожизненная ценность клиента) участников Nike Membership вырос на 14% год к году. Главное — маркетинг перестал спорить с финансами о вкладе каждого канала: модель показывала вклад в инкрементальную выручку, а не в последний клик.

Урок для маркетологов

Когда атрибуция последнего клика — единственная метрика, вы обречены дотировать тот канал, который случайно оказывается последним. Data-driven подход с собственной витриной в BigQuery требует инвестиций, но окупается за счёт пересборки бюджета. В эпоху privacy-first (приоритет приватности) и роста server-side (серверная обработка данных на стороне компании) ожидать точной картины от платформ-источников — значит принимать решения с перекосом.

— @BigQuery4MarketingPro

Как навести порядок в GTM для маркетинга за 15 минут

Если в контейнере Google Tag Manager уже десятки тегов, триггеров и переменных, без структуры любая правка превращается в риск. Простая организация помогает быстрее находить ошибки, передавать проект команде и не ломать аналитику в момент запуска кампаний.

— Создайте папки по логике бизнеса
Разделите контейнер не «как попало», а по функциям: аналитика, пиксели, формы, e-commerce, эксперименты, служебные теги.
Так маркетолог сразу видит, где лежит то, что влияет на отчёты, а где — вспомогательные настройки.

— Сгруппируйте теги по сценарию использования
Внутри папок держите отдельные блоки под ключевые сценарии: сбор событий, передача конверсий, ретаргетинг, серверные вызовы.
Это особенно полезно, когда у проекта несколько каналов трафика и разные команды подключают свои события.

— Приведите названия к одному стандарту
Используйте понятные шаблоны: тип тега, объект, действие, канал, например: GA4_Event_Form_Submit.
Единый стиль экономит время на аудитах и снижает шанс перепутать похожие сущности.

— Включите подсветку кода в пользовательских HTML и JavaScript-элементах
Когда скрипты длинные, цветовая подсветка помогает быстрее замечать скобки, ошибки синтаксиса и лишние символы.
Это мелочь, но она сильно уменьшает число поломок при ручных правках.

— Проверяйте сложные вставки перед публикацией
Не редактируйте многострочные скрипты «на глаз» прямо в проде: сначала открывайте их в удобном формате и сверяйте логику.
Для маркетинга это критично: одна ошибка в коде = потерянные конверсии и искажённая атрибуция.

— Назначьте правила поддержки структуры
Зафиксируйте, кто создаёт папки, как называются объекты и куда попадают новые теги после запуска.
Без этого контейнер снова быстро превратится в свалку, особенно если над ним работают несколько подрядчиков.

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

— @BigQuery4MarketingPro

Сбер запустит свой криптокошелёк

Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.

Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.

Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍

➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek

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

Индия потребовала от Telegram удалять пиратский контент

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

Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.

Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent

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

Google ads меняет стратегию по конверсиям

Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.

Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…

➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam

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

Как не допустить, чтобы SGTM ставил cookie FPID: чек-лист для privacy-first аналитики в BigQuery

При настройке server-side через Google Tag Manager (SGTM) часто появляется cookie **FPID** — она нужна для предпочтительного использования идентификатора в Google Analytics 4 (GA4). По сути, это cookie, которая приходит в **HTTP-ответе от сервера** и помечена как **HttpOnly** (к ней не получить доступ из браузерного JavaScript).

Если цель — белая, управляемая аналитика без сюрпризов в согласиях и учёте, возьмите под контроль FPID и связанный поток данных в BigQuery.

— Определите, где именно выставляется FPID
Проверьте, какой компонент формирует HTTP-ответ (ваш сервер/контейнер). Смысл: понять “источник истины”, чтобы потом управлять настройкой, а не симптомами.

— Включите FPID по умолчанию только там, где это оправдано
Симо Алава рекомендует включать toggle на стороне server-side по умолчанию, но вы включаете его не “из любопытства”, а после проверки: влияет ли это на идентификацию и воспроизводимость данных для вашей модели атрибуции.

— Согласуйте FPID с режимом consent (согласия) и политиками хранения
HttpOnly снижает доступность для клиентского скрипта, но не отменяет необходимость корректной логики согласия: если пользователь не дал разрешение, идентификаторы не должны появляться в ответах/логах.

— Зафиксируйте, что FPID не раскрывается в событиях “как попало”
Проверьте, попадает ли FPID в параметры событий, заголовки или в payload, который улетает в BigQuery. Цель: предотвратить нежелательное распространение идентификатора по системам, где вы его не планировали хранить.

— Настройте в BigQuery контролируемую схему и валидации
Добавьте в DWH правила контроля: “есть ли FPID/какой идентификатор в связке с user_pseudo_id”, и что делать при расхождениях (например, не смешивать потоки разных режимов идентификации в отчётах).

— Проведите инвентаризацию идентификаторов в пайплайне
Сведите в таблицу: какие поля вы используете для связки (cookie/id, pseudo-id, client_id) и где создаётся/обновляется. В 2026 это критично: privacy-first атрибуция вытесняет last-click, и чистота ключей важнее количества.

— Проверьте инкрементальность поведения после изменений
Сделайте небольшой A/B в логике конфигурации (или разнесение по тестовым сегментам) и сравните метрики качества данных в BigQuery: доля событий с нужным ключом, стабильность join’ов, разрыв последовательностей.

когда это пригодится
когда вы переводите tracking на server-side/SGTM и хотите сохранить управляемость идентификаторов, не ломая согласия и связность аналитики в BigQuery.

— @BigQuery4MarketingPro

В 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

Компания Meta выпустила Muse Image

Meta выпустила Muse Image — нейросеть, которая генерирует изображения как агент: сама ищет референсы, пишет код и рассуждает перед созданием картинки.

Одна из фишек — можно скинуть ссылку на публичный профиль человека в соцсети, и модель возьмёт его внешность за референс.

Есть один вопрос, который интересует всех арбитражников: как это повлияет …

➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-image

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

Retention-матрица за 10 минут: SQL-запрос для BigQuery

Строить удержание по когортам (cohort retention) — базовая задача, если вы работаете с LTV и retention в E-com или B2B SaaS. В BigQuery это делается одним запросом без выгрузок. Вот готовый шаблон.

**1. Подготовьте данные.**
Убедитесь, что у вас есть таблица событий с полями:
- `user_id`
- `event_date` (DATE)
- `event_name` (например, `'purchase'` или `'session'`)

Если данных нет — используйте GA4-экспорт в BigQuery (таблица `events_*`).

**2. Определите дату первой активности для каждого пользователя.**
Это будет когорта (первый день, когда пользователь совершил целевое действие).
```sql
WITH cohort AS (
SELECT
user_id,
MIN(event_date) AS first_date
FROM `project.dataset.events`
WHERE event_name = 'purchase'
GROUP BY user_id
)
```

**3. Присоедините все последующие активности и рассчитайте день когорты.**
```sql
SELECT
cohort.first_date,
DATE_DIFF(events.event_date, cohort.first_date, DAY) AS day_number,
COUNT(DISTINCT events.user_id) AS users
FROM `project.dataset.events` AS events
JOIN cohort ON events.user_id = cohort.user_id
WHERE events.event_name = 'purchase'
GROUP BY first_date, day_number
```
На выходе получите строки вида: `2026-01-15, 0, 1000` — это 1000 пользователей, совершивших первую покупку в день когорты; `2026-01-15, 1, 200` — те же пользователи, купившие на следующий день, и т.д.

**4. Превратите в retention-матрицу.**
Чтобы видеть проценты, добавьте знаменатель — общее число пользователей в когорте (на day_number=0).
```sql
WITH base AS (
...предыдущий запрос...
),
cohort_size AS (
SELECT first_date, users AS size
FROM base
WHERE day_number = 0
)
SELECT
base.first_date,
base.day_number,
ROUND(SAFE_DIVIDE(base.users, cohort_size.size) * 100, 2) AS retention_pct
FROM base
JOIN cohort_size USING(first_date)
ORDER BY first_date, day_number
```

**5. Визуализируйте.**
Готовый результат можно сразу вывести в Data Studio (Looker Studio) или через `EXPORT` загрузить в электронную таблицу. В BigQuery также можно использовать `ARRAY_AGG` для транспонирования строк в столбцы — если нужно получить классическую таблицу «дни по горизонтали».

**Почему это работает:**
- Минимум движений — только один проход по таблице.
- Считается удержание для любого события: покупка, визит, заполнение формы.
- Легко адаптировать под LTV (подставить сумму вместо COUNT).

Попробуйте на своих данных

— @BigQuery4MarketingPro

Китай планирует ограничить доступ к DeepSeek и GLM

Китай готовится ограничить публичный доступ к своим флагманским нейросетям — DeepSeek и GLM. Запрет по образцу США становится новой нормальностью.

Правительство рассматривает трёхуровневую систему: от стандартной регистрации для простых моделей до полного закрытия самых передовых — только для внутреннего использования.

Но есть один подвох, котор…

➡️ Читайте на сайте: https://aff.top/blog/kitai-planiruet-ogranichit-dostup-k-deepseek-i-glm

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