Как-то это не выглядит как ответ, я намекал на то, что вы таким решением «искусствено» изменили конверсию, чтобы она вам подходила. В статье не написано, почему так было сделано, и получается, что люди, которые не понимают «зачем» тупо начнут так делать и получать не верные результаты.
Я это говорю не просто так, т.к у нас интернет магазин, который входит в ТОП-100 в штатах по выручке. И наши задачи работают в обоих направлениях, просто мы не делаем такого разграничения как «срежем ка мы возвраты, т.к тогда цифра красивей». Тест должен идти достаточно времени, чтобы убрать эти выбросы.
Также, каждый день идут промо-акции, рассылки, которые приводят на сайт разные группы людей, на разные группы товаров, что усложняет однозначно и быстро дать ответ, что стало лучше или хуже.
Еще выглядит странным, что вы говорите о 10-20 A/B тестов, но не говорите о Multivariate A/B тестах. Т.к если идет паралельно не один тест а несколько, нужно учитывать все вариации A/B тестов, чтобы видеть, какая связка в совокупности дает наилучший результат.
«Однако, в рамках следующего этапа пост-тест анализа были исключены заказы call-центра, а также аннулированные заказы.»
Почему были исключены анулированные заказы? И к анулированным заказам, были ли отнесены возвраты? Т.к если были, то это очень страно.
Магазин выполняет свою задачу, когда продает товар. Если товар возвращается, то в большинстве случаев, это проблема товара, и бизнес процессов и людей, которые решили продавать не качественный товар.
Например, вы сделали акцию, на товар на складе, чтобы его распродать, товара много. Весь распродали, конверсия увеличилась, но товар оказался не качественный и его весь вернули. Это не значит, что это нужно не учитывать. Т.к возможно для этого были сделаны разные улучшения, чтобы продать (или продавать и дальше этот товар).
В общем основной вопрос — почему исключили анулированные и были ли это тоже возвраты?
А так за статью спасибо. Хоть и PR статья, коих огромное кол-во. Но изложено доступно.
как-то часто видишь на хабре статьи, что закрылся один ЦОД, серваки вынесли из другого ЦОДа.
А при чем здесь безопасность? и как backup'ы к этому относяться?
у нас в связке Amazon/DigitalOcean, которые прекрасно дополняют друг друга, также набор жирных серверов в локальном DC для ресурсоемких задач для бизнеса.
Просто вы упускаете тот факт, что демпинг цен возвращается и бьет больно, и это было не раз. Те серверные, которые начинают свой путь с «дешевых и классных» серваков, в итоге заканчивают жесткими тормозами и не способностью предоставлять качественный сервис.
вместо MongoDB, можно использовать ElasticSearch. Данные хранятся в MySQL, и специальные расширенные данные для постройки фасетов, поиска, получения записей храняться в ElasticSearch.
Т.к ES, в таком случае не primary storage, то в нем, данные просто дублируются и используются только когда это необходимо: Поиск, Фасеты, Статистика.
Сейчас как раз таким и занимаюсь. Нехватка памяти довольно распространенная проблема особенно при индексации больших обьемов данных. Решение использовать для этого ES не выходит дешево для стартапов, т.к памяти действительно надо много.
Самая неприятная проблема это обновление (или добавление) mapping'а полей. После создания нового индекса с обновленным mapping'ом, нужно выкачать все данные из ES и запихнуть их в новый индекс. С этим хорошо справляется поиск с типом scan (eg. /_search?search_type=scan&scroll=10m). Но надо понимать, что если данных очень много и документы большие, это занимает достаточно много времени + кушает досоаточно RAM'а. Также весь этот процесс усугубляет то, что база работает как NoSQL и в нее все время идут данные.
Купил я книгу, разбираюсь, могу сказать, что книга устарела немного, если следовать 1 в 1 тому, как там написано, встречаются не совсем понятные ошибки, которые не так просто понять и исправить, и почти все касаются ember-data. Я бы посоветовал исправить начальные главы книги, чтобы так сказать, не разочаровывать читателей ). В целом книга неплоха.
Вот вопрос, который меня мучал изначально, в гайде не смог найти толковый ответ. Все примеры, которые есть по ember'у, очень прямолинейны и далеки от более реальных приложений, как должно выглядеть следующая структура:
/dashboard
этот route содержит в себе несколько компонентов страницы, есть левое меню, которое приходит с сервера, есть данные статистики, есть dashboard статистика, и есть один график. Все это приходит от сервера в одном запросе, разделенными приблизительно так:
Можно было бы еще дать ссылку на описание Bredcrumbs от Google — support.google.com/webmasters/answer/185417 и можно еще сказать, что breadcrumbs, могут быть и не одни на странице. Если товар находится не в одной категории, а в нескольких, например.
какой-то АД при приеме на работу… интересно, люди, которые сейчас работают, готовы взять за свой счет отпуск, чтобы целый день с вами поработать, а потом понять, что это не для них? Или этот 1 день всетаки оплачивается?
после такого комментария, думаю Idotz захочет подать на вас в суд, и выиграет, с легкостью… А подделка документов, любых и для любых целей карается законом, учитывая, что вы сразу признали, что данные не верные, а паспорт вы подделали.
В общем может быть так, что ваш Success Story может обернуться крайне плохо.
Я это говорю не просто так, т.к у нас интернет магазин, который входит в ТОП-100 в штатах по выручке. И наши задачи работают в обоих направлениях, просто мы не делаем такого разграничения как «срежем ка мы возвраты, т.к тогда цифра красивей». Тест должен идти достаточно времени, чтобы убрать эти выбросы.
Также, каждый день идут промо-акции, рассылки, которые приводят на сайт разные группы людей, на разные группы товаров, что усложняет однозначно и быстро дать ответ, что стало лучше или хуже.
Еще выглядит странным, что вы говорите о 10-20 A/B тестов, но не говорите о Multivariate A/B тестах. Т.к если идет паралельно не один тест а несколько, нужно учитывать все вариации A/B тестов, чтобы видеть, какая связка в совокупности дает наилучший результат.
«Однако, в рамках следующего этапа пост-тест анализа были исключены заказы call-центра, а также аннулированные заказы.»
Почему были исключены анулированные заказы? И к анулированным заказам, были ли отнесены возвраты? Т.к если были, то это очень страно.
Магазин выполняет свою задачу, когда продает товар. Если товар возвращается, то в большинстве случаев, это проблема товара, и бизнес процессов и людей, которые решили продавать не качественный товар.
Например, вы сделали акцию, на товар на складе, чтобы его распродать, товара много. Весь распродали, конверсия увеличилась, но товар оказался не качественный и его весь вернули. Это не значит, что это нужно не учитывать. Т.к возможно для этого были сделаны разные улучшения, чтобы продать (или продавать и дальше этот товар).
В общем основной вопрос — почему исключили анулированные и были ли это тоже возвраты?
А так за статью спасибо. Хоть и PR статья, коих огромное кол-во. Но изложено доступно.
А при чем здесь безопасность? и как backup'ы к этому относяться?
у нас в связке Amazon/DigitalOcean, которые прекрасно дополняют друг друга, также набор жирных серверов в локальном DC для ресурсоемких задач для бизнеса.
Просто вы упускаете тот факт, что демпинг цен возвращается и бьет больно, и это было не раз. Те серверные, которые начинают свой путь с «дешевых и классных» серваков, в итоге заканчивают жесткими тормозами и не способностью предоставлять качественный сервис.
вместо MongoDB, можно использовать ElasticSearch. Данные хранятся в MySQL, и специальные расширенные данные для постройки фасетов, поиска, получения записей храняться в ElasticSearch.
Т.к ES, в таком случае не primary storage, то в нем, данные просто дублируются и используются только когда это необходимо: Поиск, Фасеты, Статистика.
В таком случае, такой подход очень даже ничего.
— Да, считаю корректным, если результат исследования выкладывается в свободный доступ.
github.com/django/django/pull/2720
master/slave -> leader/follower -> primary/replica -> master/slave
хороший пиар вышел :)
Самая неприятная проблема это обновление (или добавление) mapping'а полей. После создания нового индекса с обновленным mapping'ом, нужно выкачать все данные из ES и запихнуть их в новый индекс. С этим хорошо справляется поиск с типом scan (eg. /_search?search_type=scan&scroll=10m). Но надо понимать, что если данных очень много и документы большие, это занимает достаточно много времени + кушает досоаточно RAM'а. Также весь этот процесс усугубляет то, что база работает как NoSQL и в нее все время идут данные.
В остальном одни плюсы.
md5(message + code), вы можете быть подвержены Length Extension Attack:
blog.whitehatsec.com/hash-length-extension-attacks/
en.wikipedia.org/wiki/Length_extension_attack
Пару лет назад flickr был подвержен именно такой атаке — netifera.com/research/flickr_api_signature_forgery.pdf
sha1 и другие простые функции тоже подвержены этой атаке. Чтобы их обойти, нужно использовать подпись сообщений по HMAC.
P.S тут речь идет не о хэшировании пароля
/dashboard
этот route содержит в себе несколько компонентов страницы, есть левое меню, которое приходит с сервера, есть данные статистики, есть dashboard статистика, и есть один график. Все это приходит от сервера в одном запросе, разделенными приблизительно так:
{
dashboard: {
data: [{… data1… }, {… data2… }, {… data3… }]
menu: [{… item1… }, {… item2… }, {… item3… }],
indicators: [{… indicator1… }, {… indicator2… }, {… indicator3… }],
statistics: [{… statistics1… }, {… statistics2… }, {… statistics3… }],
}
}
data, menu, indicators, statistics (collection'ы) — разные блоки, темплейты. data1, data2, data3 etc. — это все моделию
и вопрос такой, как в идеологии ember'а, такое реализовать?
Спасибо!
упс…
В общем может быть так, что ваш Success Story может обернуться крайне плохо.