Но цена за акцию сейчас ниже нем только денежная часть из предложения ксерокса. Это чистый выигрыш прямо сейчас. Не хочу тут спорить нужны ли фондам деньги. Мой пойнт был в том, что отказ ксерокса вызван сильной переоценкой на рынках из-за Эпидемии, это тактическое решение.
Там большая часть деньгами предлагалась. Я думаю сейчас многие акционеры HP жалеют что не согласились. Сейчас на кэше сидели бы. А Xerox слился так как их предложение сейчас слишком выгодно. Это не конец.
Если что, я вне политики, но в порядке бреда:
Как я понял этим приложением пользовались многие жители Украины из-за блокировки там вконтактика. Может в качестве стратегии защиты выйти на российские самые ватные сми? Типа чувак боролся с «ужасной Украинской цензурой» и тут его свои же схватили. Публичность должна помочь по идее, хотя что я понимаю в российском правосудии…
У меня была точно такая же история. Тоже кредитка и полный офлайн без предупреждения. Слава богу там крутилась внутренняя аналитика на BigQuery, а продакшн был на AWS. Было бы правильно, если бы Гугл четко писал об этом риске заранее и давал возможность как-то очевидно верифицироваться, что мы компания, а не студент.
Очень хорошая статья. В А/Б тестировании много подводных камней, даже в онлайне — делить по чётности IP адреса это такое… чревато.
Я бы попробовал сделать массовое А/А тестирование на ретроданных двумя методами (Вашим и консалтерским). Тесты дело капризное. А так — кучу раз генерируем сплит на две группы, выбирем случайный интервал, считаем тест. В результате можно оценить долю ложно положительных. Делали Вы что-то подобное? Из опыта — есть шанс такой метод объяснить руководству.
При желании можно и ложно отрицательные (чувствительность теста) примерно оценить. Если исключать известные предикторы из модели, например, кампании, которые шли в части магазинов и смотреть сработал ли твой тест. Но это тоже «такое» — магия%)
Весь мой скромный опыт работы с такими госкомпаниями говорит о том, что режима только два — не работать а писать отписки, но без нарушений; или работать, но тогда придётся обходить бюрократизм и это нарушения конечно. Все эти бухгалтерские дела — ни о чем вообще. Если бы Кудрин нашел эти деньги на чьём то счету — было бы совсем другое дело.
Насколько я помню свою жизнь в Сибири, лопата пригождается не только чтобы закрыть дверь, но и чтобы её откопать от снега, когда наконец понадобилось зайти.
Это всё очень вперчатляет! Велосипед пару раз изобретён и классические грабли собраны, но так продвинуться вперёд самостоятельно — это реально круто.
Я не согласен с советами про ERP, если предприятие этого ещё не сдалало — не в Ваших силах это изменить. Это как совет «станьте ежами».
Я подобные задачки решал несколько раз, поэтому хочу дать пару советов:
1. Утащите все данные в Google BigQuery. С одной стороны, это сервис внутри гугловой инфры, Google Sheets умеют из него писать и читать. Не придётся миргировать всю систему за раз. С другой стороны, это настоящая база данных с масштабом, SQL, клиентами под разные языки программирования и т.п. Работать будет за секунды, даже не за десятки.
2. Утащите всю логику в SQL на BigQuery. Иначе через пол года сами утоните в своих функциях. Вы, конечно, не послушаете. Но как уже утоните, тогда будете знать куда мигрировать.
3. Я правильно понял, что цены поставщиков меняются часто, а набор товаров — редко? Уже советовали вверху — нужно разделить задачи поиска актуальной цены и задачу матчинга товаров. Введите свой стандарт написания и свою номинклатуру товаров. Все товары поставщиков сматчить один раз к этой номинклатуре. Далее использовать эту таблицу индексов для поиска цены (DB & SQL — никуда без этого).
4. Учитесь кодить на питоне. Под эти задачи очень подходит. Он сможет работать с базой данных и слать туда SQL. Плюс при желании настроить нейросетку — вот они библиотеки, все рядом.
5. До нейросетки стоит попробовать n-gramm. Или уже делали? Ещё хороший контрольный признак — это разброс цен. Если алгоритм сматчил товар за 100 руб и за 10000 руб — что-то явно не так.
Понятно, что разные методы оптимизации могут иногда приводить к разным результатам. Но из полученных двух вариантов, какой давал меньшую loss function?
Вы серьёзно?
Если магазин использует такие методы продвижения (тырить трафик взломав конкурента), то есть серьёзные подозрения, что на этом дело не закончится.
Конечно, какая разница Яндексу, что он показывает на топовых позициях — сайт нормального интернет магазина или сайт мошенников. Контент-то одинаковый, юзер не заметит, значит трафик не упадёт.
Всё правильно написано, плюсую. Я тоже люблю подход «как можно меньше писать самому.» Одно не нравится — зачем было выбрасывать Google Sheets? Система, где весь фронт-енд сделан на Телеграме и гуглдоках, — это круть. Я так считаю.
И раз пошла такая пьянка, попробую отговорить от использования ROC AUC. По сути качество классификатора определяется количеством ошибок первого и второго типа. При разных «стоимостях» этих ошибок разные классификаторы будут оптимальны. ROC AUC — это такой странно взвешенный интеграл поверх всех возможных соотношений этих стоимостей. Его хорошо использовать, чтобы показать силу какого-то алгоритма вцелом. Без привязки к конкретной задаче. В Вашем случае задача очень конкретная. Вы же не готовы рассылать всем юзерам вообще, так как будет низкий отклик и юзеры расстроятся от спама. Но и таргетировать на 99% отклик — это потерять большую часть потенциальных пользователей этого приложения. Значит можно выбрать некий целевой % отклика и оптимизировать ровно к нему. Теоретически классификатор который тренировали на этот уровень будет на нём бить классификатор который тренили на ROC AUC.
Но цена за акцию сейчас ниже нем только денежная часть из предложения ксерокса. Это чистый выигрыш прямо сейчас. Не хочу тут спорить нужны ли фондам деньги. Мой пойнт был в том, что отказ ксерокса вызван сильной переоценкой на рынках из-за Эпидемии, это тактическое решение.
Там большая часть деньгами предлагалась. Я думаю сейчас многие акционеры HP жалеют что не согласились. Сейчас на кэше сидели бы. А Xerox слился так как их предложение сейчас слишком выгодно. Это не конец.
Как я понял этим приложением пользовались многие жители Украины из-за блокировки там вконтактика. Может в качестве стратегии защиты выйти на российские самые ватные сми? Типа чувак боролся с «ужасной Украинской цензурой» и тут его свои же схватили. Публичность должна помочь по идее, хотя что я понимаю в российском правосудии…
Я бы попробовал сделать массовое А/А тестирование на ретроданных двумя методами (Вашим и консалтерским). Тесты дело капризное. А так — кучу раз генерируем сплит на две группы, выбирем случайный интервал, считаем тест. В результате можно оценить долю ложно положительных. Делали Вы что-то подобное? Из опыта — есть шанс такой метод объяснить руководству.
При желании можно и ложно отрицательные (чувствительность теста) примерно оценить. Если исключать известные предикторы из модели, например, кампании, которые шли в части магазинов и смотреть сработал ли твой тест. Но это тоже «такое» — магия%)
Про SQL и не начинайте:) Для каждого инструмента свои задачи. В моём понимании его задача — это по большей части именно SQL.
Я знаю Talend ETL (со своими ограничениями), ну и просто на питоне парсить.
Я не согласен с советами про ERP, если предприятие этого ещё не сдалало — не в Ваших силах это изменить. Это как совет «станьте ежами».
Я подобные задачки решал несколько раз, поэтому хочу дать пару советов:
1. Утащите все данные в Google BigQuery. С одной стороны, это сервис внутри гугловой инфры, Google Sheets умеют из него писать и читать. Не придётся миргировать всю систему за раз. С другой стороны, это настоящая база данных с масштабом, SQL, клиентами под разные языки программирования и т.п. Работать будет за секунды, даже не за десятки.
2. Утащите всю логику в SQL на BigQuery. Иначе через пол года сами утоните в своих функциях. Вы, конечно, не послушаете. Но как уже утоните, тогда будете знать куда мигрировать.
3. Я правильно понял, что цены поставщиков меняются часто, а набор товаров — редко? Уже советовали вверху — нужно разделить задачи поиска актуальной цены и задачу матчинга товаров. Введите свой стандарт написания и свою номинклатуру товаров. Все товары поставщиков сматчить один раз к этой номинклатуре. Далее использовать эту таблицу индексов для поиска цены (DB & SQL — никуда без этого).
4. Учитесь кодить на питоне. Под эти задачи очень подходит. Он сможет работать с базой данных и слать туда SQL. Плюс при желании настроить нейросетку — вот они библиотеки, все рядом.
5. До нейросетки стоит попробовать n-gramm. Или уже делали? Ещё хороший контрольный признак — это разброс цен. Если алгоритм сматчил товар за 100 руб и за 10000 руб — что-то явно не так.
Если магазин использует такие методы продвижения (тырить трафик взломав конкурента), то есть серьёзные подозрения, что на этом дело не закончится.