Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

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

SPF и DKIM ломают доставку чаще, чем контент письма

Если рассылка уходит в спам или режется на приёме, сначала проверяйте DNS, а не шаблон письма. Базовый набор такой:
— SPF: одна TXT-запись на домен отправителя, без дублирующих политик
— DKIM: отдельный селектор, ключ не короче 1024 бит
— DMARC: хотя бы p=none для наблюдения за ошибками

Главная ошибка — несколько SPF-записей на один домен. Должна быть одна, собранная через include и ip4/ip6. Вторая проблема — забытый выравненный домен: письмо подписано одним доменом, а From указывает на другой. Для фильтров это уже повод ухудшить репутацию.

DKIM проверяется просто: отправили тест, открыли заголовки, нашли DKIM-Signature, потом сверили, что подпись проходит по тому же селектору, который лежит в DNS. Если ключи меняли — старый селектор не удаляйте сразу, пока все сервисы не переедут. Иначе получите плавающий брак на части трафика.

Отдельно смотрите на обратные записи и HELO/EHLO: если сервер представляется одним именем, а PTR ведёт в другое, часть почтовиков снижает доверие. Стабильность — это отсутствие магии, только предсказуемая конфигурация.

Проблема не в сервере, проблема в его настройке. Разворачиваем, проверяем, мониторим.

Логи сервера показывают, где сливается бюджет, если смотреть не на CTR, а на ошибки доставки

Проблема обычно не в «плохом трафике», а в том, что часть запросов не доходит до трекера или падает на уровне инфраструктуры. В логах это видно быстро: 4xx, 5xx, таймауты, редиректы по кругу, пустые ответы от upstream. Если в отчёте конверсии есть, а в access/error-логах растут отказы, деньги уходят в пустоту.

Смотрите не только на код ответа, но и на связку:
• всплеск 499/504 — клиент не дождался ответа, теряете сессии
• 301/302 в цепочке из 3+ переходов — лишняя задержка и обрыв атрибуции
• 200 с пустым телом или битым JS — трекинг не сработал, лид не засчитан
• рост 5xx на одном роуте — проблема в backend, а не в креативах

Дальше нужны кореляции по времени. Сверяйте логи веб-сервера, прокси, приложений и трекера в одном таймлайне. Если ошибки идут пачкой после роста RPS, значит сервер не выдерживает нагрузку и начинает резать заявки. Если ошибки локальны по одному IP, подсеть или ASN можно сразу уводить в отдельную проверку.

Минимальный порядок работы: включить раздельные логи по виртуальным хостам, хранить request_id, поднять alert на аномальный рост 4xx/5xx и раз в день смотреть топ URL по ошибкам. Стабильность — это отсутствие магии, только предсказуемая конфигурация. Разворачиваем, проверяем, мониторим.

Nginx для лендинга: 5 настроек, которые убирают лишнюю нагрузку

Если лендинг ловит всплески трафика, Nginx должен отдавать статику и резать лишнюю работу, а не «помогать» PHP пережимом CPU. Базовый набор: worker_processes auto; worker_connections 4096; use epoll; multi_accept on; — это снижает шанс упереться в лимит соединений раньше, чем в железо.

Включите keepalive_timeout 15; keepalive_requests 1000; и отдавайте css, js, картинки с долгим cache-control. Для статики: sendfile on; tcp_nopush on; tcp_nodelay on; — это убирает лишние копирования и сокращает задержку на мелких ответах. Сжатие держите умеренным: gzip on; gzip_types text/plain text/css application/javascript application/json; иначе CPU начнёт работать на упаковку мусора.

Если лендинг генерируется приложением, кэшируйте HTML на уровне Nginx через proxy_cache или fastcgi_cache. Даже короткий TTL снимает пиковую нагрузку на upstream и делает поведение предсказуемым. Для защиты от «медленных» клиентов ставьте client_body_timeout 10s; client_header_timeout 10s; send_timeout 15s; — это отсекает соединения, которые только занимают сокеты.

Проверьте лимиты ОС: somaxconn, file-max, ulimit -n, а также backlog в listen. Без этого Nginx можно настроить правильно, но упрётся в ядро. Стабильность — это отсутствие магии, только предсказуемая конфигурация. Разворачиваем, проверяем, мониторим.

На Anthropic, OpenAI, Google и SpaceXAI подали в суд из-за ИИ

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

➡️ Читайте на сайте: https://aff.top/blog/na-anthropic-openai-google-i-spacexai-podali-v-sud-iz-za-ii

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

Google ads начал показывать расходы конкурентов

Google Ads запустил Peer Spending — инструмент, который сравнивает расходы аккаунта с рекламодателями из той же ниши без раскрытия чужих данных. Он показывает, тратите вы больше, меньше или примерно на уровне конкурентов на уровне кампаний и групп объявлений. Для арбитража это скорее ориентир по бенчмаркам, чем инструмент прямого усиления залива.

➡️ Читайте на сайте: https://aff.top/blog/google-ads-nachal-pokazyvat-raskhody-konkurentov

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

Минфин РФ планирует выпустить собственный стейблкоин

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

➡️ Читайте на сайте: https://aff.top/blog/minfin-rf-planiruet-vypustit-sobstvennyi-steiblkoin

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

Мониторинг сервера без алертов в Telegram — это уже не мониторинг

Проверять надо не «жив ли хост», а цепочку целиком: ICMP, TCP-порт, HTTP-ответ, DNS, TLS-сертификат. Если падает только один слой, алерт должен показать, где именно сломалось. Иначе получаете ложные срабатывания и лишний шум в чате.

Минимальная схема:
— health-check с интервалом 30–60 секунд;
— таймаут короче интервала, иначе очередь алертов забьётся;
— 2–3 подряд неуспешные проверки перед уведомлением;
— отдельные уведомления на деградацию и полный даун.

Telegram-бот — удобный канал, но не хранилище инцидентов. В сообщении нужны: имя сервера, тип проверки, код ошибки, время и ссылка на дашборд. Без этого оператор начинает гадать, а не чинить. Для критичных сервисов добавляйте escalation: сначала чат дежурных, потом личный алерт, потом повтор через заданный интервал.

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