This media is not supported in your browser
VIEW IN TELEGRAM
Chat GPT-5.6 будут выдавать лишь избранным
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
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
Удаление 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
Нутра-оффер: где заканчивается маркетинг и начинается health claim
В нутра вертикали граница проходит не по креативу, а по обещанию. Если текст говорит о вкусе, форме, удобстве, составе и бытовом опыте — это маркетинг. Если он обещает лечение, профилактику, снижение симптомов или влияние на диагноз, вы уже в зоне health claim.
Проверка простая:
— есть ли слово «лечит», «устраняет», «снижает риск», «восстанавливает»;
— есть ли привязка к болезни, органу, функции организма или возрастной группе;
— обещает ли креатив результат, который нельзя подтвердить составом и маркировкой.
Самая частая ошибка — маскировать claim под «отзыв», «историю до/после» или «рекомендацию эксперта». Для модерации это не смягчение, а тот же смысл в другой упаковке. Отдельно смотрите на лендинг: дисклеймер внизу не спасает, если заголовок и первый экран уже обещают медицинский эффект.
Для команды полезно держать правило: один оффер — одна допустимая формула обещания. Формулировки про комфорт, поддержку и общий wellness обычно безопаснее, чем любые фразы про терапию и быстрый эффект. Но и тут важны юрисдикция, категория продукта и то, что написано на упаковке.
Если хотите меньше отклонений, проверяйте креатив по одному вопросу: можно ли убрать название болезни и смысл останется тем же. Если нет — это уже не маркетинг, а health claim.
В нутра вертикали граница проходит не по креативу, а по обещанию. Если текст говорит о вкусе, форме, удобстве, составе и бытовом опыте — это маркетинг. Если он обещает лечение, профилактику, снижение симптомов или влияние на диагноз, вы уже в зоне health claim.
Проверка простая:
— есть ли слово «лечит», «устраняет», «снижает риск», «восстанавливает»;
— есть ли привязка к болезни, органу, функции организма или возрастной группе;
— обещает ли креатив результат, который нельзя подтвердить составом и маркировкой.
Самая частая ошибка — маскировать claim под «отзыв», «историю до/после» или «рекомендацию эксперта». Для модерации это не смягчение, а тот же смысл в другой упаковке. Отдельно смотрите на лендинг: дисклеймер внизу не спасает, если заголовок и первый экран уже обещают медицинский эффект.
Для команды полезно держать правило: один оффер — одна допустимая формула обещания. Формулировки про комфорт, поддержку и общий wellness обычно безопаснее, чем любые фразы про терапию и быстрый эффект. Но и тут важны юрисдикция, категория продукта и то, что написано на упаковке.
Если хотите меньше отклонений, проверяйте креатив по одному вопросу: можно ли убрать название болезни и смысл останется тем же. Если нет — это уже не маркетинг, а health claim.
Квартальный iGaming-обзор по GEO: какие проверки делать до запуска в новое гео
Перед выходом в новую юрисдикцию не смотрят только на «разрешено / запрещено». Для iGaming важнее слой надстройки: лицензирование, реклама, KYC, AML, хранение данных и правила выплат. Именно на этом уровне чаще всего возникают остановки трафика и заморозки платежей.
Сначала фиксируйте регуляторный статус GEO:
— есть ли отдельная лицензия на оператора, аффилиата или маркетингового посредника;
— допускается ли реклама азартных игр, и если да, то в каких каналах;
— есть ли локальные требования к дисклеймерам, возрастным ограничениям и responsible gaming.
Дальше проверяйте комплаенс-цепочку онбординга:
— KYC: какие документы принимаются и на каком этапе запрашиваются;
— AML: какие триггеры вызывают ручную проверку;
— payouts: разрешены ли карты, e-wallets, bank transfer, крипто, и какие провайдеры считаются допустимыми.
Отдельно смотрите на данные:
— где можно хранить персональные данные;
— нужен ли DPA и локальный представитель;
— какие сроки хранения установлены для документов и логов.
Для арбитражной команды полезно вести матрицу по GEO: лицензия, реклама, KYC, AML, платежи, data retention, санкционные ограничения. Это сокращает ошибки на старте и помогает техлиду сразу увидеть, где нужен отдельный процесс, а где — стандартный шаблон.
Если в матрице нет ответа хотя бы по одному блоку, запуск в GEO лучше считать не готовым.
Перед выходом в новую юрисдикцию не смотрят только на «разрешено / запрещено». Для iGaming важнее слой надстройки: лицензирование, реклама, KYC, AML, хранение данных и правила выплат. Именно на этом уровне чаще всего возникают остановки трафика и заморозки платежей.
Сначала фиксируйте регуляторный статус GEO:
— есть ли отдельная лицензия на оператора, аффилиата или маркетингового посредника;
— допускается ли реклама азартных игр, и если да, то в каких каналах;
— есть ли локальные требования к дисклеймерам, возрастным ограничениям и responsible gaming.
Дальше проверяйте комплаенс-цепочку онбординга:
— KYC: какие документы принимаются и на каком этапе запрашиваются;
— AML: какие триггеры вызывают ручную проверку;
— payouts: разрешены ли карты, e-wallets, bank transfer, крипто, и какие провайдеры считаются допустимыми.
Отдельно смотрите на данные:
— где можно хранить персональные данные;
— нужен ли DPA и локальный представитель;
— какие сроки хранения установлены для документов и логов.
Для арбитражной команды полезно вести матрицу по GEO: лицензия, реклама, KYC, AML, платежи, data retention, санкционные ограничения. Это сокращает ошибки на старте и помогает техлиду сразу увидеть, где нужен отдельный процесс, а где — стандартный шаблон.
Если в матрице нет ответа хотя бы по одному блоку, запуск в GEO лучше считать не готовым.
SPF, DKIM и DMARC для CPA-email: базовая гигиена, без которой домен быстро деградирует
В email-маркетинге для CPA важны не «красивые письма», а доверие к домену. Если у домена нет SPF, DKIM и DMARC, почтовые системы видят отправителя как менее предсказуемого. Это влияет на доставляемость, а не только на спам-папку.
Минимальный набор для любого домена в рассылках:
— SPF: явно перечисляет, какие серверы имеют право отправлять письма от имени домена
— DKIM: подписывает письмо криптографически, подтверждая, что оно не было изменено
— DMARC: задаёт политику, что делать, если SPF/DKIM не проходят, и даёт отчётность по домену
Для CPA-команды особенно важно разделять домены:
— отдельный домен для прогрева и массовых отправок
— отдельные поддомены под разные потоки
— не смешивать транзакционные и промо-рассылки в одном контуре без необходимости
Ошибка, которую видят чаще всего: SPF есть, DKIM настроен частично, DMARC отсутствует. В такой конфигурации письма могут доходить, но репутация домена остаётся слабой, а разбор инцидентов — почти вслепую.
Практический чек:
— проверяйте, что SPF не превышает лимиты по DNS-запросам
— используйте DKIM-ключи достаточной длины и не забывайте ротацию
— начинайте DMARC с режима мониторинга, а не с жёсткой блокировки
— анализируйте отчёты по доменам и поддоменам отдельно
Если у email-канала нет аутентификации, это не «техническая мелочь», а постоянный риск для доставляемости и репутации.
В email-маркетинге для CPA важны не «красивые письма», а доверие к домену. Если у домена нет SPF, DKIM и DMARC, почтовые системы видят отправителя как менее предсказуемого. Это влияет на доставляемость, а не только на спам-папку.
Минимальный набор для любого домена в рассылках:
— SPF: явно перечисляет, какие серверы имеют право отправлять письма от имени домена
— DKIM: подписывает письмо криптографически, подтверждая, что оно не было изменено
— DMARC: задаёт политику, что делать, если SPF/DKIM не проходят, и даёт отчётность по домену
Для CPA-команды особенно важно разделять домены:
— отдельный домен для прогрева и массовых отправок
— отдельные поддомены под разные потоки
— не смешивать транзакционные и промо-рассылки в одном контуре без необходимости
Ошибка, которую видят чаще всего: SPF есть, DKIM настроен частично, DMARC отсутствует. В такой конфигурации письма могут доходить, но репутация домена остаётся слабой, а разбор инцидентов — почти вслепую.
Практический чек:
— проверяйте, что SPF не превышает лимиты по DNS-запросам
— используйте DKIM-ключи достаточной длины и не забывайте ротацию
— начинайте DMARC с режима мониторинга, а не с жёсткой блокировки
— анализируйте отчёты по доменам и поддоменам отдельно
Если у email-канала нет аутентификации, это не «техническая мелочь», а постоянный риск для доставляемости и репутации.
Чек-лист compliance для b2b-сейл партнёрки: что должно быть до первого лида
В b2b-сейл партнёрке compliance — это не «бумажка для галочки», а набор условий, без которых потом трудно разбирать споры по лидам, оплатам и источникам данных.
Минимум, который стоит зафиксировать до запуска:
— юрисдикции сторон и применимое право в договоре;
— описание допустимых источников трафика и запрет на серые методы;
— правила обработки персональных данных: кто controller/processor, где хранится база, кто отвечает на запросы субъекта;
— подтверждение согласия на передачу лида и срок хранения доказательств;
— процедура KYC для партнёров и бенефициаров;
— санкционный и PEP-screening, если есть выплаты через финансовых посредников;
— антифрод-правила: дубли, мусорные лиды, подмена компании, fake contacts;
— SLA по верификации лида и основания для reject/reversal;
— логирование источника: UTM, click-id, time-stamp, IP, user-agent, CRM-статус;
— право на аудит и порядок хранения переписки по спорным лидам.
Отдельно проверьте, чтобы в договорах совпадали маркетинговые обещания и фактический оффер. Если sales-команда обещает одно, а affiliate-материалы ведут на другое, спор почти всегда уходит в плоскость доказательств.
Практика простая: если элемент нельзя показать в виде документа, лога или правила в CRM, значит его как будто нет. Для b2b-партнёрки это самый частый источник претензий, а не сам трафик.
В b2b-сейл партнёрке compliance — это не «бумажка для галочки», а набор условий, без которых потом трудно разбирать споры по лидам, оплатам и источникам данных.
Минимум, который стоит зафиксировать до запуска:
— юрисдикции сторон и применимое право в договоре;
— описание допустимых источников трафика и запрет на серые методы;
— правила обработки персональных данных: кто controller/processor, где хранится база, кто отвечает на запросы субъекта;
— подтверждение согласия на передачу лида и срок хранения доказательств;
— процедура KYC для партнёров и бенефициаров;
— санкционный и PEP-screening, если есть выплаты через финансовых посредников;
— антифрод-правила: дубли, мусорные лиды, подмена компании, fake contacts;
— SLA по верификации лида и основания для reject/reversal;
— логирование источника: UTM, click-id, time-stamp, IP, user-agent, CRM-статус;
— право на аудит и порядок хранения переписки по спорным лидам.
Отдельно проверьте, чтобы в договорах совпадали маркетинговые обещания и фактический оффер. Если sales-команда обещает одно, а affiliate-материалы ведут на другое, спор почти всегда уходит в плоскость доказательств.
Практика простая: если элемент нельзя показать в виде документа, лога или правила в CRM, значит его как будто нет. Для b2b-партнёрки это самый частый источник претензий, а не сам трафик.
Политика Meta по health claims: где чаще всего режут трафик
Meta особенно внимательно смотрит на креативы и лендинги, где есть обещания по здоровью, снижению веса, лечению, восстановлению или «быстрому результату». Речь не только о прямых медицинских утверждениях, но и о формулировках вроде «убирает боль», «нормализует давление», «лечит бессонницу».
Главная ошибка — пытаться маскировать claim под «личный опыт», «мнение эксперта» или «натуральный состав». Если сообщение по смыслу обещает эффект для здоровья, оно всё равно попадает в зону риска. Для Meta важен не жанр текста, а то, какое ожидание создаёт реклама.
Проверяйте три слоя:
— креатив: есть ли до/после, шок-обещания, намёк на диагноз или лечение;
— лендинг: совпадает ли текст с объявлением и нет ли там более жёстких формулировок;
— сбор данных: если на странице есть квизы про симптомы, возраст, лекарства или диагноз, это уже чувствительная зона.
Отдельно опасны абсолютные обещания: «без побочек», «гарантированный эффект», «работает для всех». Даже если продукт допустим к продвижению, такие формулировки часто становятся причиной отклонения или последующей блокировки связки.
Если вертикаль завязана на здоровье, лучше строить коммуникацию вокруг общих свойств, состава, ухода или образа жизни, а не вокруг лечения и обещаний результата. Чем ближе текст к медицинскому утверждению, тем выше требования к доказательности и модерации.
Для арбитражной команды полезнее не искать «серую» формулировку, а заранее выстроить словарь разрешённых и запрещённых claims для каждой связки. Это дешевле, чем пересобирать кампанию после отклонения.
Meta особенно внимательно смотрит на креативы и лендинги, где есть обещания по здоровью, снижению веса, лечению, восстановлению или «быстрому результату». Речь не только о прямых медицинских утверждениях, но и о формулировках вроде «убирает боль», «нормализует давление», «лечит бессонницу».
Главная ошибка — пытаться маскировать claim под «личный опыт», «мнение эксперта» или «натуральный состав». Если сообщение по смыслу обещает эффект для здоровья, оно всё равно попадает в зону риска. Для Meta важен не жанр текста, а то, какое ожидание создаёт реклама.
Проверяйте три слоя:
— креатив: есть ли до/после, шок-обещания, намёк на диагноз или лечение;
— лендинг: совпадает ли текст с объявлением и нет ли там более жёстких формулировок;
— сбор данных: если на странице есть квизы про симптомы, возраст, лекарства или диагноз, это уже чувствительная зона.
Отдельно опасны абсолютные обещания: «без побочек», «гарантированный эффект», «работает для всех». Даже если продукт допустим к продвижению, такие формулировки часто становятся причиной отклонения или последующей блокировки связки.
Если вертикаль завязана на здоровье, лучше строить коммуникацию вокруг общих свойств, состава, ухода или образа жизни, а не вокруг лечения и обещаний результата. Чем ближе текст к медицинскому утверждению, тем выше требования к доказательности и модерации.
Для арбитражной команды полезнее не искать «серую» формулировку, а заранее выстроить словарь разрешённых и запрещённых claims для каждой связки. Это дешевле, чем пересобирать кампанию после отклонения.
Privacy policy для лендинга: какие пункты должны быть на странице до запуска
Если на лендинге есть форма заявки, пиксель, аналитика, чат или передача лида в CRM, privacy policy нужна не «для галочки», а как базовый документ по обработке данных. Для арбитражных команд это особенно важно: трафик идет через несколько подрядчиков, а ответственность за сбор и передачу данных обычно размазана по цепочке.
Проверьте, чтобы в политике были:
— кто является оператором/контролером данных и его контакты;
— какие данные собираются: имя, телефон, email, IP, cookie, device ID, UTM;
— зачем они собираются: обработка заявки, аналитика, ретаргетинг, связь с пользователем;
— на каком основании идет обработка: согласие, договор, законный интерес — в зависимости от юрисдикции;
— кому данные передаются: CRM, колл-центр, рекламные платформы, подрядчики;
— есть ли трансграничная передача и в какие страны;
— сроки хранения и критерии удаления;
— как пользователь может отозвать согласие, запросить доступ, исправление или удаление;
— используются ли cookies, пиксели, SDK и как ими управлять;
— как обновляется политика и где опубликована актуальная версия.
Отдельно проверьте, чтобы текст соответствовал фактической схеме: если данные улетают в 3 системы, а в политике написана одна CRM, это слабое место при проверке.
Для EU ориентируйтесь на GDPR и ePrivacy, для РФ — на 152-ФЗ и локальные требования к согласию и обработке персональных данных. Политика должна совпадать с формой: если чекбокс согласия есть, рядом должна быть ссылка на документ.
Хорошая практика — держать privacy policy короткой, но точной: без общих фраз, с реальными получателями данных и понятным механизмом согласия.
Если на лендинге есть форма заявки, пиксель, аналитика, чат или передача лида в CRM, privacy policy нужна не «для галочки», а как базовый документ по обработке данных. Для арбитражных команд это особенно важно: трафик идет через несколько подрядчиков, а ответственность за сбор и передачу данных обычно размазана по цепочке.
Проверьте, чтобы в политике были:
— кто является оператором/контролером данных и его контакты;
— какие данные собираются: имя, телефон, email, IP, cookie, device ID, UTM;
— зачем они собираются: обработка заявки, аналитика, ретаргетинг, связь с пользователем;
— на каком основании идет обработка: согласие, договор, законный интерес — в зависимости от юрисдикции;
— кому данные передаются: CRM, колл-центр, рекламные платформы, подрядчики;
— есть ли трансграничная передача и в какие страны;
— сроки хранения и критерии удаления;
— как пользователь может отозвать согласие, запросить доступ, исправление или удаление;
— используются ли cookies, пиксели, SDK и как ими управлять;
— как обновляется политика и где опубликована актуальная версия.
Отдельно проверьте, чтобы текст соответствовал фактической схеме: если данные улетают в 3 системы, а в политике написана одна CRM, это слабое место при проверке.
Для EU ориентируйтесь на GDPR и ePrivacy, для РФ — на 152-ФЗ и локальные требования к согласию и обработке персональных данных. Политика должна совпадать с формой: если чекбокс согласия есть, рядом должна быть ссылка на документ.
Хорошая практика — держать privacy policy короткой, но точной: без общих фраз, с реальными получателями данных и понятным механизмом согласия.
Сайт ломается не в коде, а на стыке шаблона, контента и загрузки — проверьте это первым делом
Если у проекта «всё вроде работает», но заявки падают, ищите не один баг, а цепочку мелочей. На RU-CMS это обычно: битый шаблон, лишние обёртки в верстке, тяжелые картинки, дубли H1 и формы, которые не отправляются из-за JS-ошибки.
Базовый чек-лист перед запуском:
— открыть сайт с отключенным JS и проверить, что не разваливается критичный контент;
— пройтись по главной, каталогу, карточке, форме и 404 как обычный пользователь;
— посмотреть, не тянет ли шаблон внешние скрипты, шрифты и счетчики без необходимости;
— проверить, не живут ли в верстке старые блоки после редизайна;
— убедиться, что SEO-метки, микроразметка и каноникал не конфликтуют между собой.
Для Bitrix и MODX типовая ошибка одна и та же: правят только внешний вид, а бизнес-логика остается в старом состоянии. Потом шаблон обновили, а в компонентах остались старые допущения — и ошибки всплывают уже на бою. Поэтому любой правке нужен короткий прогон по сценариям: вход, поиск, корзина, форма, личный кабинет, мобильная версия.
Если делать это регулярно, сайт перестает «внезапно» ломаться на ровном месте. Перед любым релизом сначала проверяйте путь пользователя, потом уже пиксели, а не наоборот.
Если у проекта «всё вроде работает», но заявки падают, ищите не один баг, а цепочку мелочей. На RU-CMS это обычно: битый шаблон, лишние обёртки в верстке, тяжелые картинки, дубли H1 и формы, которые не отправляются из-за JS-ошибки.
Базовый чек-лист перед запуском:
— открыть сайт с отключенным JS и проверить, что не разваливается критичный контент;
— пройтись по главной, каталогу, карточке, форме и 404 как обычный пользователь;
— посмотреть, не тянет ли шаблон внешние скрипты, шрифты и счетчики без необходимости;
— проверить, не живут ли в верстке старые блоки после редизайна;
— убедиться, что SEO-метки, микроразметка и каноникал не конфликтуют между собой.
Для Bitrix и MODX типовая ошибка одна и та же: правят только внешний вид, а бизнес-логика остается в старом состоянии. Потом шаблон обновили, а в компонентах остались старые допущения — и ошибки всплывают уже на бою. Поэтому любой правке нужен короткий прогон по сценариям: вход, поиск, корзина, форма, личный кабинет, мобильная версия.
Если делать это регулярно, сайт перестает «внезапно» ломаться на ровном месте. Перед любым релизом сначала проверяйте путь пользователя, потом уже пиксели, а не наоборот.
Forwarded from Потрачено! Клуб спящих бизнесменов!
Коллеги, тут типа серьёзный пост про кое что новое....
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
AI-бот с «врачебным анализом» и психологом в контуре: гео не указано
Автор сделал Telegram-бота freefeeltrackerbot и пишет, что Opus 3.8 «может делать серьезный врачебный анализ». Также указано, что бот подключен к психологу, который «параллельно все контролирует», и что автору он помог «за 7 дней».
Для арбитражных команд это зона health/mental health claims и обработки чувствительных данных. Если трафик идет в EU, с 25 мая 2018 действует GDPR: данные о здоровье — special category data по Art. 9. Для РФ применим 152-ФЗ от 27.07.2006, включая режим специальных категорий персональных данных по ст. 10.
Перед тестом такого ленда завтра стоит проверить минимум четыре вещи: гео, текст согласия на обработку health data, формулировки медицинских обещаний в креативах и политику хранения диалогов. Отдельно — раскрытие роли психолога: кто получает данные, на каком основании и как пользователь может удалить историю.
Автор сделал Telegram-бота freefeeltrackerbot и пишет, что Opus 3.8 «может делать серьезный врачебный анализ». Также указано, что бот подключен к психологу, который «параллельно все контролирует», и что автору он помог «за 7 дней».
Для арбитражных команд это зона health/mental health claims и обработки чувствительных данных. Если трафик идет в EU, с 25 мая 2018 действует GDPR: данные о здоровье — special category data по Art. 9. Для РФ применим 152-ФЗ от 27.07.2006, включая режим специальных категорий персональных данных по ст. 10.
Перед тестом такого ленда завтра стоит проверить минимум четыре вещи: гео, текст согласия на обработку health data, формулировки медицинских обещаний в креативах и политику хранения диалогов. Отдельно — раскрытие роли психолога: кто получает данные, на каком основании и как пользователь может удалить историю.