Можно обозвать поля стандартно и через jinja подставлять нужные. Если default , то ''. Второй уровень много места не займет. Но конечно кастыль) Но если заказчик настаивает, и не так выкрутишься
Добрый день. Спасибо за 2 статьи! Пытаюсь воспроизвести примеры, но в итоге упираюсь в настройки безопасности:
Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'strict-dynamic' На просторах интернета рекомендуют менять политику безопасности, но чем это чревато и как вы решили этот вопрос?
Как боретесь в тестах с ситуациями, когда при росте конверсии на одном уровне падает конверсия на другом? Напр. Рекламой пригнали не релевантный сегмент, он смотрит товар, идет к заказу и ... оказывается он живет где - нибудь на селе где самовывоза нет и доставки. В итоге уходит с сайта. Такая фича кому засчитывается в плюс, а кому в минус?
Я решал бизнес проблему тем, что было на руках. Вижу цель, не вижу препятствий) Работает быстро, ставится на поток. Сверху монтируется shiny (пример визуала) и совсем симпатично. Код для заказчика под капотом. Таблицы и дашборды на выходе. С osm только дороги релевантно брать для моей задачи. Как альтернатива беготни по графу на R и хранения, можно попробовать PostGis, но сам я до него не добрался. Инструментов масса.
Когда вы открываете свой бизнес, вы на старте сами каждый винтик на кухне проверите, в каждое заведение съездите, трафик сами посчитаете) Систему аналитики выстраивать тут неоправданно дорого. Где-то уже на 5-10 заведений уже нужна описательная аналитика, т.к. за всем не уследишь. Для таких гео проектов думаю сеть из 50-100 пиццерий уже м.б. оправдана, т.к. цена ошибки высокая, а процессы все уже делегированы от собственника. В ретейле, например, ошибка выбора локации менее болезненная: меньше требований к ремонту помещений, нет расходов с кухней, меньше персонала. Опять же, есть стратегия выбора локаций: открыть точку, не пошла - переезжаем на следующую. Есть даже федералы, кто сочетает такой подход с геопространственным анализом) Т.е. да, актуально: средний бизнес +
я указывал, что это всего-лишь одна фича. Она помогает комплексно оценивать, но сама оценка локации на 100% в неё не упирается. В том же "Пиво против кофе" косвенно социальная среда рассматривается через бизнес окружение: наливайки и микрозаймы говорят о менее обеспеченных районах, кофейни и рестораны - более обеспеченные. На моей практике эта фича конвертированная на доход в городе коррелировала с товарооборотом, но точность модели только на эту фичу была слабая. По сути фича захватывает 2 параметра: плотность населения и среднюю конкуренцию. Ретейл точно их оценивает.
Да, тут предпосылка, что клиенты привязаны к месту проживания, а не к месту работы. Это не везде сработает. Офисные сценарии не рассматриваем. По частному сектору, не могу однозначно сказать, на сколько потребительские практики отличаются от тех, кто живет в многоквартирных домах. Но если будут основания, что частный сектор не интересен, можно легко его исключить из анализа.
Не рассматривал, что это закрытый город) Однозначно, в закрытых городах сложнее бизнес вести) Спасибо за комментарий)
Я и сам не люблю этот инструмент, но он очень популярен в нашей стране, от этого пока никуда не деться. А вот Excel не плохая прога, если её апгрейдить (например Data Mining) и освоить некоторые формулы. После неё хорошо изучать полноценные языки. Лично я сейчас R осваиваю и SQL.
А если не секрет, как этот алгоритм называется, который я описал?
Спасибо, внес несколько правок.
По поводу формул: здесь скорее алгоритм работы с данными, который описан в 2-х предложениях: «При этом, рассчитывая в ABC+ массив для каждого продукта включая сумму его оборота и сумму оборота для всех других продуктов продававшихся в одни и те же с ним периоды. Из этого массива и рассчитывается, к какой группе принадлежит продукт».
Я реализовывал это на Excel, но зная алгоритм можно реализовать и на других программных пакетах (получше).
Если правильно перенести идею на программный продукт, то пользователю нужно будет просто задать период начала и период конца для анализа.
Вопрос про плохие продажи — в точку. Здесь, пожалуй, спасет только либо увеличение временной градации (вместо дней смотрим недели, вместо месяцев-кварталы), либо, работа с большим числом продаж (чтобы не было колебаний в продажах от 1 до 3-х единиц товара в месяц).
Ну и обращу внимание на название статьи, ABC очень не надежный метод, и я его модификацией устраняю всего один недостаток, чтобы минимизировать ряд ошибок со стороны его использующих на ежедневной основе. Но на более качественном уровне анализа данных лучше использовать другие методы. Тут вам и кластеризации, и факторный анализ, и регрессионные модели разных мастей.
Можно обозвать поля стандартно и через jinja подставлять нужные. Если default , то ''. Второй уровень много места не займет. Но конечно кастыль) Но если заказчик настаивает, и не так выкрутишься
Добрый день. Спасибо за 2 статьи! Пытаюсь воспроизвести примеры, но в итоге упираюсь в настройки безопасности:
Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' 'strict-dynamic' На просторах интернета рекомендуют менять политику безопасности, но чем это чревато и как вы решили этот вопрос?
Автор не дурак, а вполне спокойно делится опытом. Автору однозначно лайк.
Спасибо за статью.
Несколько вопросов:
Смотрите ли на этап выкупа заказа?
Как боретесь в тестах с ситуациями, когда при росте конверсии на одном уровне падает конверсия на другом? Напр. Рекламой пригнали не релевантный сегмент, он смотрит товар, идет к заказу и ... оказывается он живет где - нибудь на селе где самовывоза нет и доставки. В итоге уходит с сайта. Такая фича кому засчитывается в плюс, а кому в минус?
Я решал бизнес проблему тем, что было на руках. Вижу цель, не вижу препятствий) Работает быстро, ставится на поток. Сверху монтируется shiny (пример визуала) и совсем симпатично. Код для заказчика под капотом. Таблицы и дашборды на выходе. С osm только дороги релевантно брать для моей задачи. Как альтернатива беготни по графу на R и хранения, можно попробовать PostGis, но сам я до него не добрался. Инструментов масса.
Когда вы открываете свой бизнес, вы на старте сами каждый винтик на кухне проверите, в каждое заведение съездите, трафик сами посчитаете) Систему аналитики выстраивать тут неоправданно дорого. Где-то уже на 5-10 заведений уже нужна описательная аналитика, т.к. за всем не уследишь. Для таких гео проектов думаю сеть из 50-100 пиццерий уже м.б. оправдана, т.к. цена ошибки высокая, а процессы все уже делегированы от собственника. В ретейле, например, ошибка выбора локации менее болезненная: меньше требований к ремонту помещений, нет расходов с кухней, меньше персонала. Опять же, есть стратегия выбора локаций: открыть точку, не пошла - переезжаем на следующую. Есть даже федералы, кто сочетает такой подход с геопространственным анализом) Т.е. да, актуально: средний бизнес +
Согласен с аргументами.
По пунктам
я указывал, что это всего-лишь одна фича. Она помогает комплексно оценивать, но сама оценка локации на 100% в неё не упирается. В том же "Пиво против кофе" косвенно социальная среда рассматривается через бизнес окружение: наливайки и микрозаймы говорят о менее обеспеченных районах, кофейни и рестораны - более обеспеченные. На моей практике эта фича конвертированная на доход в городе коррелировала с товарооборотом, но точность модели только на эту фичу была слабая. По сути фича захватывает 2 параметра: плотность населения и среднюю конкуренцию. Ретейл точно их оценивает.
Да, тут предпосылка, что клиенты привязаны к месту проживания, а не к месту работы. Это не везде сработает. Офисные сценарии не рассматриваем. По частному сектору, не могу однозначно сказать, на сколько потребительские практики отличаются от тех, кто живет в многоквартирных домах. Но если будут основания, что частный сектор не интересен, можно легко его исключить из анализа.
Не рассматривал, что это закрытый город) Однозначно, в закрытых городах сложнее бизнес вести) Спасибо за комментарий)
А если не секрет, как этот алгоритм называется, который я описал?
По поводу формул: здесь скорее алгоритм работы с данными, который описан в 2-х предложениях: «При этом, рассчитывая в ABC+ массив для каждого продукта включая сумму его оборота и сумму оборота для всех других продуктов продававшихся в одни и те же с ним периоды. Из этого массива и рассчитывается, к какой группе принадлежит продукт».
Я реализовывал это на Excel, но зная алгоритм можно реализовать и на других программных пакетах (получше).
Если правильно перенести идею на программный продукт, то пользователю нужно будет просто задать период начала и период конца для анализа.
Вопрос про плохие продажи — в точку. Здесь, пожалуй, спасет только либо увеличение временной градации (вместо дней смотрим недели, вместо месяцев-кварталы), либо, работа с большим числом продаж (чтобы не было колебаний в продажах от 1 до 3-х единиц товара в месяц).
Ну и обращу внимание на название статьи, ABC очень не надежный метод, и я его модификацией устраняю всего один недостаток, чтобы минимизировать ряд ошибок со стороны его использующих на ежедневной основе. Но на более качественном уровне анализа данных лучше использовать другие методы. Тут вам и кластеризации, и факторный анализ, и регрессионные модели разных мастей.