Пролистал по заголовкам несколько последних страниц с постами корп блога, может плохо смотрел, может случайно упустил нужные статьи. Подскажите, пожалуйста, где можно почитать про практическую сторону дела? В смысле, не говоря об очевидных вещах (как отправить емейл и где хранить лида), интересует ряд аспектов: встроить свой собственный канал коммуникаций (кастомные гуи, логика, интеграции, юзерские роли); строить кастомную логику поверх емейла (всякие там триггеры, трекинг, и прочие клёвые штуки); инсертить и удалять как-то из базы записи (иногда миллионами в день), желательно чтобы можно было и push и pull; иметь структуру данных сильно сложнее, чем "лид-опортьюнити-ордер-клиент" (а иногда ещё и многие-ко-многим) и крайне желательно, чтобы на миллионах исторических экшенов в базу можно было накидать новых полей и не умереть. И прочие подобные крутые штуки, с помощью которых можно крутить-вертеть коробку под свои нужды и процессы.
Таким образом, проблема вовсе не в высоких зарплатах программистов. Проблема в наличии огромного количества халтурщиков, которых некуда деть. Так ведь?
Как правило, на страницах авторизации 3DS видно в чью пользу совершается платёж. Клиент, приходя по кнопке "оплатить" интернет-магазина или сервиса не ожидает увидеть там ФИО физического лица, как правило.
Не очень ясен смысл затеи. У тинькова, например, есть готовый платёжный виджет для размещения на сайте. Почему не использовать его?
Странный UX. Клиент, покупая что-либо в вебе, ожидает на странице 3DS и в списке своих транзакций увидеть что-то понятное и релевантное продавцу.
А в Вашем случае клиент увидит card2card Иванову Ивану?
Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
Берём контору, использующую MDM для BYOD (ну там, в корпоративный exchange ходить с айфончика, который парень на день рождения подарил).
Ставим в ближайшей кафешке сканер HS-платформы
Таргетируем на сотрудников, досягаемых через HS-платформу, фишинг с раздачей собственного SCEP профиля
????
PROFIT
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.
Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".
Где конкретно — не скажу. Но рекомендую, если интересно, полистать комьюнити больших и очень больших вендоров — и не такие масштабы бывают.
Пролистал по заголовкам несколько последних страниц с постами корп блога, может плохо смотрел, может случайно упустил нужные статьи. Подскажите, пожалуйста, где можно почитать про практическую сторону дела? В смысле, не говоря об очевидных вещах (как отправить емейл и где хранить лида), интересует ряд аспектов: встроить свой собственный канал коммуникаций (кастомные гуи, логика, интеграции, юзерские роли); строить кастомную логику поверх емейла (всякие там триггеры, трекинг, и прочие клёвые штуки); инсертить и удалять как-то из базы записи (иногда миллионами в день), желательно чтобы можно было и push и pull; иметь структуру данных сильно сложнее, чем "лид-опортьюнити-ордер-клиент" (а иногда ещё и многие-ко-многим) и крайне желательно, чтобы на миллионах исторических экшенов в базу можно было накидать новых полей и не умереть. И прочие подобные крутые штуки, с помощью которых можно крутить-вертеть коробку под свои нужды и процессы.
Спасибо!
Таким образом, проблема вовсе не в высоких зарплатах программистов. Проблема в наличии огромного количества халтурщиков, которых некуда деть. Так ведь?
Непонятна сфера применения шлюза. Для интернет-коммерции точно не годится. А зачем тогда?
Как правило, на страницах авторизации 3DS видно в чью пользу совершается платёж. Клиент, приходя по кнопке "оплатить" интернет-магазина или сервиса не ожидает увидеть там ФИО физического лица, как правило.
Не очень ясен смысл затеи. У тинькова, например, есть готовый платёжный виджет для размещения на сайте. Почему не использовать его?
Странный UX. Клиент, покупая что-либо в вебе, ожидает на странице 3DS и в списке своих транзакций увидеть что-то понятное и релевантное продавцу.
А в Вашем случае клиент увидит card2card Иванову Ивану?
Выходит, смысл исключительно в том, чтобы привести клиента на страницу перевода денег с предзаполненным получателем?
Честно говоря, вот это кино, на мой взгляд, самое лучшее обозрение того, что мы называем "рунет" глазами гуманитария, которому социальное ближе и интересней технологического. И это достойно. В конце концов про софт и DRM здесь все и так знают. А о влиянии на общество задумываются не все.
Вот тут Вы не совсем правы. Хотя это зависит от точки зрения.
С точки зрения типичного участника, скажем, Хабра, интерес представляют именно люди, чьи руки и головы стояли и стоят за технологиями, которые обеспечивают проистекание общественных процессов. То есть таки инженеров, делавших и делающих рунет технический.
А кино — оно про сами процессы, текущие в "народных массах". С этой точки зрения ключевые уже не инженеры, а движетели потоков. Пусть бы и поначалу движетелями бывали инженеры.
Все же рунет — как и любое другое общественное явление — это, в первую очередь, движение. Поток, внутри которого существуют другие потоки, во главе которых оказываются люди. Причем покуда задача людей во главе потока — определять повестку членов потока, инженеры в таких ролях — случайная случайность. В основном же во главе гуманитарии по складу ума. А софт вообще вторичен.
Так что все вполне сходится. Со временем вместо ролей "восторженных инноваторов-романтиков" на передний план выходят роли "Потупчик", "Навальный" и "Носик".
А можете заодно подсказать толковых ресурсов по админству и внедрению AEM? Документация адоби, как обычно, местами потрясающе неочевидна.
Ручная модерация кампаний в диджитал маркетинге — это хорошо, но очень сильно дорого, когда кампании не свои, а партнёрские, и выручка от канала пропорциональна объему партнёрской базы и их кампаний. ИИ не панацея — примеров промахов существующих вендоров хватает.
Уповать на то, что если контора практикует BYOD, то конторский профиль запрещает установку сторонних — возможно. Но ровно до момента, пока сотрудникам массово очень сильно не захочется себе ещё профилей. То есть, пока предложения партнёров HS-платформы недостаточно щедры или всеобъемлющи.
С другой стороны, в свое время все тоже самое было с email каналом. И на сей раз приспособимся.
Так DKIM цел. От остальных esp приходят отчёты с успехами обработки политик. То есть это именно локальные проблемы и/или некорректные реализации esp.
В aggregated отчётах DMARC по моим доменам видны случаи, особенно от yahoo/outlook.com и пары локальных европейских esp, когда письмо не прошло DMARC из-за fail'а DKIM и реже SPF, а IP-адрес в отчёте о таких письмах — один из хостов того самого esp. Сделать с этим вряд ли что-то можно, а включать reject с такими отчётами (единицы % от общей массы трафика) — страшно.
Кажется, форварлинг форварлингу рознь.
На практике postmaster MailRu настоятельно советует, например, включать для домена DMARC в p=reject вместо p=none, но в то же время множество случаев, когда большие ESP пересылают письма между своими внутренними хостами без поддержки ARC и все — DKIM сломан, DMARC не проходит, при p=reject письмо отвергается.
Как быть с таким?
Нашел для себя не менее (в чем-то и более) декларативную штуку — docopt: https://github.com/docopt/docopt
Я дико извиняюсь, последний раз с апачем имел дело в 2010, но во-первых, CharsetSourceEnc требует включенного mod_charset, а во-вторых, внутри используется iconv на каждый запрос — не слишком ли это дорого для шаред хостингов?
Справедливо, но нет. Или нужна открытая документация, а ещё лучше — способ описать "важное" письмо самим письмом: метадата в верстке или ещё что-то. В противном случае сервис не может никак заранее предвидеть будет ли его уведомление в текущем дизайне действительно распознано как "важное", или свалится вслед за остальным маркетингом. Или заводить десятки ящиков сотрудникам и тренироваться на них, что тоже даёт такие себе гарантии.
Забороть спам — намерение, безусловно, благое. Но мы все ведь знаем, куда такие намерения могут привести.
Вот просто например.
Есть сферический сервис в вакууме — service.tld. Этот сервис шлёт с info@service-mail.tld письма с маркетингом ("черная пятница", етц) и письма "ваша подписка продлена".
Юзер получает за год 3-5 писем с маркетингом, "отписывается" от рассылки, и в итоге уведомления о продлении подписки или, что хуже, невозможности продления (карта кончилась) не увидит. Как быть?
Так тоже самое происходит с доменами, например. И, если мне память не изменяет, были в прошлом истории с регистрацией освободившихся доменов и чтением писем, на них приходящих "по старой памяти".