Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

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

BigQuery как хранилище server-side событий: не склад, а слой контроля качества

Если sGTM шлёт события в BigQuery «на всякий случай», через месяц вы получаете не аналитику, а дорогой мусорный ящик. Рабочая схема другая: сырые события кладём отдельно от нормализованных, а в витрину — только то, что прошло проверку на schema, dedup и обязательные поля.

Что важно хранить:
— raw payload целиком: чтобы пересобрать логику маппинга без повторной отправки
— event_id, client_id, user_id, fbp/fbc: для склейки и поиска дублей
— timestamp received / timestamp event: чтобы видеть лаги между браузером, сервером и DWH
— routing metadata: какой client, tag template, source domain, trigger

Дальше строится простой контроль:
— `COUNT(*)` vs `COUNT(DISTINCT event_id)` — ловит дубляж
— `NULL` по email_hash/phone_hash — показывает, где ломается enrichment
— доля событий без `user_agent` или `ip` — сигнал, что server context теряется
— сравнение inbound и outbound объёма по каждому event_name — помогает найти обрыв в маршрутизации

Главная ошибка — использовать BigQuery как единственный источник истины для CAPI. Истина там только после нормализации: один и тот же `Purchase` может прийти три раза с разным quality, а в хранилище это будут три строки. Поэтому raw и curated должны жить отдельно.

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

Facebook CAPI без потерь событий: схема, которая не ломается на дедупликации

Если Pixel и CAPI отправляют один и тот же event, потери чаще всего не в Meta, а в вашей схеме: разные event_id, несинхронный тайминг, пустые user_data и кривая нормализация. Сначала фиксируйте идентичность события, потом уже улучшайте матчинг.

Что должно уходить в CAPI:
— event_name, event_time, event_id
— fbp, fbc, client_ip_address, client_user_agent
— email_hash, phone_hash, external_id, если они реально есть и нормализованы
— action_source и page_url для контекста

Дедупликация держится на одном правиле: Pixel и server должны делить одинаковый event_id. Генерируйте его на стороне клиента до отправки и прокидывайте в оба канала. Если event_id создаётся отдельно в браузере и на сервере, дедуп почти всегда начинает «плыть».

Отдельно проверьте нормализацию PII: email в lowercase, phone в E.164, хеширование только после очистки пробелов и символов. На сервере не теряйте client_user_agent и IP — без них EMQ проседает даже при хорошем наборе user_data.

Если хотите стабильную CAPI-схему, сначала сделайте одинаковый event_id, потом доберите матчинг через fbp/fbc и нормализованные user_data.

Server-side трекинг для PWA: где ломается сессия и как не потерять атрибуцию

PWA часто ведёт себя не как обычный сайт: кеш, service worker, быстрые навигации без полного reload и отдельная логика офлайна. Из-за этого client-side события могут приходить рваными: PageView дублируется, Purchase теряется после закрытия вкладки, а `fbp/fbc` не всегда живут так, как ожидает CAPI.

Для sGTM здесь важны 3 вещи:
— передавать стабильный `event_id` для дедупликации Pixel + CAPI;
— сохранять first-party идентификаторы в cookie с корректным `SameSite` и `Secure`;
— не полагаться на `window.onload`: в PWA нужный триггер часто `route change` или кастомное событие приложения.

Если service worker отдаёт страницу из кеша, серверу нужен контекст: `client_id`, `event_time`, `page_location`, `referrer`, `user_agent`, `ip`. Без этого ухудшается матчинг и растёт доля событий без привязки к сессии.

Отдельно проверь офлайн-очередь. События, собранные в PWA без сети, должны уходить на сервер с исходным временем события, а не временем отправки. Иначе атрибуция съедет в сторону последнего касания.

Минимальный чек-лист:
— один источник генерации `event_id`;
— логика сохранения идентификаторов вне volatile storage;
— маршрутизация server-side на уровне маршрута, а не только page load;
— тест на back/forward navigation и кеш service worker.

В PWA выигрывает не тот, кто «отправил больше событий», а тот, кто сохранил их порядок и контекст.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

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

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

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

TikTok Events API ломается не на отправке, а на валидации полей: вот где искать ошибку

Когда серверный event уходит, но не матчится — проблема обычно в схеме. Для TikTok Events API критичны три слоя: идентификаторы пользователя, данные события и технические поля запроса.

Проверь базовый набор:
— event, timestamp, event_id
— context.page.url, context.user_agent, context.ip
— user data: email/phone в хеше, ttclid, ttp если они доступны
— currency и value для ecommerce-событий

Типовая ошибка — отправлять пустые строки вместо null или не нормализовать PII перед SHA-256. Email нужно привести к lowercase и trim, телефон — к E.164-логике, иначе валидатор пропустит запрос, но матчинг просядет.

Ещё один частый сбой — дубль event_id. Если Pixel и Events API живут параллельно, идентификатор должен быть одинаковым на обеих сторонах, иначе дедупликация не сработает.

Для отладки удобно проверять запрос в таком порядке:
1. обязательные поля
2. формат timestamp
3. хеширование user data
4. наличие value/currency
5. консистентность event_id между client и server

Если event проходит по HTTP, это ещё не значит, что он пригоден для атрибуции. Сначала валидируй схему, потом уже смотри EMQ и deduplication.

Кросс-девайс атрибуция ломается там, где client-side видит только один экран

Когда пользователь начал путь на телефоне, а купил с ноутбука, Pixel и GA4 часто собирают два отдельных фрагмента. Server-side ID нужен не для «магии», а чтобы связать события в один контур: login_id, hashed email, customer_id, CRM user_id — если они реально стабильны между сессиями.

Базовый паттерн такой:
— на сайте генерируете first-party identifier и кладёте в cookie;
— при логине маппите его на внутренний user_id;
— в sGTM прокидываете этот ID в CAPI / Enhanced Conversions / аналитику;
— при всех дальнейших событиях используете один и тот же ключ.

Важно не путать ID для атрибуции и PII. Email и phone хешируются, а сам server-side ID должен быть бессмысленным токеном без прямой расшифровки. Иначе вы строите не трекинг, а лишний риск. Ещё один частый провал — разные ID в разных поддоменах, из-за чего кросс-девайс склейка разваливается на уровне источника.

Проверка простая: один и тот же пользователь должен получать одинаковый server-side ID после авторизации, а события Purchase / Lead должны уходить с тем же идентификатором и в вебе, и в сервере. Если ID меняется при каждом визите, у вас нет атрибуции, есть набор несвязанных хитов.

Практика одна: сначала стабилизируйте identity layer, потом уже оптимизируйте EMQ и deduplication.

BigQuery как хранилище server-side событий: когда это лучше логов и CSV

Если sGTM уже шлёт события на несколько endpoint’ов, BigQuery удобно использовать как слой сырого факта. Не как отчётный BI-слой, а как место, где лежит полный event stream: входящие payload’ы, debug-флаги, ошибки валидации, повторные отправки.

Главное правило: в таблицу надо писать не только “успешные” события. Иначе вы теряете возможность искать, почему рассыпались дедупликация, match_keys или routing. Полезно хранить:
— event_name, event_id, timestamp
— user_data в хэшированном виде
— fbp/fbc, ip, user_agent
— source, client_id, request_id, status_code
— raw_payload в отдельном поле или отдельной таблице

Структурируйте хранение сразу. Для аналитики по времени — партиционирование по дате события. Для быстрых разборов — кластеризация по event_name, event_id, request_id. Если кладёте всё в одну широкую таблицу, следите, чтобы raw JSON не ломал стоимость запросов.

Практика, которая спасает дебаг:
— одна таблица для “чистых” событий
— одна таблица для ошибок и невалидных запросов
— одно поле для correlation id между sGTM, CAPI и downstream-системами

Такой слой позволяет быстро сравнить: что пришло на вход, что ушло в Meta/Google/TikTok, и где именно событие потерялось. Для server-side атрибуции это часто важнее, чем сама витрина в Looker.

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