Доброго времени суток хабросообщество!
Последние несколько лет я занимаюсь в основном разработкой и поддержкой интернет-магазинов. За это время мной было решено много интересных и не очень задач.
Однажды, я побывал в офисе одного из своих бывших заказчиков, и увидел как мучаются менеджеры, которые занимаются добавлением новых товарных позиций. Глядя на все это, у меня появилась идея попробовать максимально облегчить эту задачу. И вот что из этого получилось. Сразу оговорюсь, что в этой статье, я просто опишу идеи и их результат применения на практике. Никаких исходников я выкладывать не буду, т.к. это главное требование заказчика. Все ниже изложенное было реализовано на php и postgresql.
1. Сначала нужно добавить товар в базу. Обычно это происходит так. От поставщика приходит excel-файл со всеми доступными товарными позициями и менеджер начинает их скурпулезно заносить в базу.
Я решил начать с этого этапа. Зачем руками забивать, то что уже оцифровано? За пару часов был написан скрипт, которому скармливают этот самый файл от поставщика, а на выходе получаем новый товар в базе. Еще за пару часов я научил этот скрипт понимать шаблоны, т.е. из какого столбца какую информацию брать. И после этого, для обработки файла, помимо excel-таблички еще и указывался файл с шаблоном. Здесь самым сложным было научить скрипт понимать в какую категорию какой товар кидать. Для решения этой задачи, в файл с шаблоном еще добавляем табличку с соответствием, категории поставщика к категории из нашей базы. И теперь почти любой excel-файл с товарами быстро добавляется в базу. В будущем думаю добавить промежуточную страницу, чтобы перед добавлением в базу, спрашивать у пользователя, что добавлять, а что нет, т.е. спарсили прайс и выводим форму в которой можно поставить галочку (или наоборот убрать), что заносить в базу, а что нет. Также можно в эту форму добавить возможность редактировать название товара и категорию. Вообще в этом нет ничего нового или умного, но готовых решений я не видел. Большинство парсеров с таким функционалом заточены под определенный формат входных данных и не поддаются легкой конфигурации. На этом этапе все. Поехали дальше!
2. На следующем этапе необходимо найти фотографии для вновь прибывших товаров. Как бы это не было печально, но большинство магазинов, у которых нет своих складов (а может и просто большинство) добывают картинки из интернета. Когда я это увидел решение не заставило себя долго ждать. Был написан небольшой скриптик, который по очереди берет новый товар из базы, выделяет его модель и пуляет запрос к сервисам поиска картинок. Далее парсим html-страничку с результатом поиска, находим там картинки, которые нашли поисковики и выводим все это. Пользователю просто остается выбрать подходящую картинку и нажать кнопочку сохранить. В сухом остатке такое решение экономит около 3-5 минут менеджера для каждого товара. Я понимаю, что брать чужие фотографии это очень не хорошо и все такое. Но во-первых это бы происходило бы и без моей помощи, во-вторых все те сайты, которые не хотят, чтобы их материалы уходили на сторону, просто добавляют защиту в виде ватермарки.
3. После того, как у нас появился товар и для этого товара была найдена картинка, нам остается только сделать для этого товара описание. Я лично считаю, что текстовое описание должен писать человек, и никаких быстрых и тем более полезных решений здесь быть не может. Но помимо текстового описания есть еще технические характеристики и эти технические характеристики одни на все, т.е., если 10 магазинов торгуют одним и тем же товаром, то и технические характеристики этого товара у всех должны быть одинаковыми, ну или хотя бы не противоречить друг другу.
Чаще всего эти технические характеристики, представляют собой набор параметров и их значений. Что я увидел в офисе интернет-магазина по этому вопросу? Ежедневно два менеджера сидят и очень внимательно копируют эти характеристики с сайтов производителей и со всяких каталогов, типа яндекс маркета. Ситуация осложняется тем, что эти наборы все хранят по-разному и тупым копи-пастом здесь не обойтись. К примеру, размеры духового шкафа можно хранить в виде такого параметра и его значения: размеры: 120х80х100, а можно расписывать, каждый размер в свой параметр или одинаковые по смыслу параметры, могут называться по-разному. Поэтому даже очень внимательный и натренированный менеджер не в состоянии скопировать все параметры, больше чем к 30-40 товарам за день. Причем такие замечательные кнопки, как копировать набор всех значений параметров от одного товара к другому или применить это значение параметра ко всем товарам в этой категории, кардинально эту проблему не решают.
Здесь действительно пришлось «изобретать велосипед». Самое первое, что пришло в голову, это написать парсер, который будет автоматически тянуть наборы параметров и их значений с сайта источника и предлагать менеджеру выбрать соответствие параметра с сайта источника к параметру из нашей базы, но я решил на этом не останавливаться. Почему бы, после того, как менеджер выбрал соответствие, не запоминать его и в следующий раз, когда наткнемся на такой же параметр автоматически предложить это соответствие? Так как большинство товаров однотипные, и, к примеру, могут быть 10 товаров отличающихся друг от друга только 3-4 параметрами, то после проставления соответствий у двух-трех товаров, для остальных останется только зрительно проверить эти соответствия и сразу нажать кнопку сохранить. В итоге получился вполне милый парсер технических характеристик. При помощи этой штуки один менеджер теперь обрабатывает по 100-120 товаров за день, что примерно в 3-4 раза больше изначальных показателей.
Парсинг параметров
При разработке этого парсера я сразу разделил логику парсера и логику интерфейса, и теперь для добавления нового сайта источника достаточно описать где и что лежит у нового источника. Так же были добавлены всякие приятные “плюшки”, типо преобразования сантиметров в миллиметры (на сайте для которого я все это делал все размеры принято хранить в миллиметрах) и др.
После всех вышеизложенных ухищрений общее время на добавления одного товара сократилось с 15-20 минут до 3-5 минут. Я же на реализацию и внедрение потратил около 4 дней. С учетом того, что речь идет о добавлениии 2000-3000 товаров, выгода налицо!
Последние несколько лет я занимаюсь в основном разработкой и поддержкой интернет-магазинов. За это время мной было решено много интересных и не очень задач.
Однажды, я побывал в офисе одного из своих бывших заказчиков, и увидел как мучаются менеджеры, которые занимаются добавлением новых товарных позиций. Глядя на все это, у меня появилась идея попробовать максимально облегчить эту задачу. И вот что из этого получилось. Сразу оговорюсь, что в этой статье, я просто опишу идеи и их результат применения на практике. Никаких исходников я выкладывать не буду, т.к. это главное требование заказчика. Все ниже изложенное было реализовано на php и postgresql.
1. Сначала нужно добавить товар в базу. Обычно это происходит так. От поставщика приходит excel-файл со всеми доступными товарными позициями и менеджер начинает их скурпулезно заносить в базу.
Я решил начать с этого этапа. Зачем руками забивать, то что уже оцифровано? За пару часов был написан скрипт, которому скармливают этот самый файл от поставщика, а на выходе получаем новый товар в базе. Еще за пару часов я научил этот скрипт понимать шаблоны, т.е. из какого столбца какую информацию брать. И после этого, для обработки файла, помимо excel-таблички еще и указывался файл с шаблоном. Здесь самым сложным было научить скрипт понимать в какую категорию какой товар кидать. Для решения этой задачи, в файл с шаблоном еще добавляем табличку с соответствием, категории поставщика к категории из нашей базы. И теперь почти любой excel-файл с товарами быстро добавляется в базу. В будущем думаю добавить промежуточную страницу, чтобы перед добавлением в базу, спрашивать у пользователя, что добавлять, а что нет, т.е. спарсили прайс и выводим форму в которой можно поставить галочку (или наоборот убрать), что заносить в базу, а что нет. Также можно в эту форму добавить возможность редактировать название товара и категорию. Вообще в этом нет ничего нового или умного, но готовых решений я не видел. Большинство парсеров с таким функционалом заточены под определенный формат входных данных и не поддаются легкой конфигурации. На этом этапе все. Поехали дальше!
2. На следующем этапе необходимо найти фотографии для вновь прибывших товаров. Как бы это не было печально, но большинство магазинов, у которых нет своих складов (а может и просто большинство) добывают картинки из интернета. Когда я это увидел решение не заставило себя долго ждать. Был написан небольшой скриптик, который по очереди берет новый товар из базы, выделяет его модель и пуляет запрос к сервисам поиска картинок. Далее парсим html-страничку с результатом поиска, находим там картинки, которые нашли поисковики и выводим все это. Пользователю просто остается выбрать подходящую картинку и нажать кнопочку сохранить. В сухом остатке такое решение экономит около 3-5 минут менеджера для каждого товара. Я понимаю, что брать чужие фотографии это очень не хорошо и все такое. Но во-первых это бы происходило бы и без моей помощи, во-вторых все те сайты, которые не хотят, чтобы их материалы уходили на сторону, просто добавляют защиту в виде ватермарки.
3. После того, как у нас появился товар и для этого товара была найдена картинка, нам остается только сделать для этого товара описание. Я лично считаю, что текстовое описание должен писать человек, и никаких быстрых и тем более полезных решений здесь быть не может. Но помимо текстового описания есть еще технические характеристики и эти технические характеристики одни на все, т.е., если 10 магазинов торгуют одним и тем же товаром, то и технические характеристики этого товара у всех должны быть одинаковыми, ну или хотя бы не противоречить друг другу.
Чаще всего эти технические характеристики, представляют собой набор параметров и их значений. Что я увидел в офисе интернет-магазина по этому вопросу? Ежедневно два менеджера сидят и очень внимательно копируют эти характеристики с сайтов производителей и со всяких каталогов, типа яндекс маркета. Ситуация осложняется тем, что эти наборы все хранят по-разному и тупым копи-пастом здесь не обойтись. К примеру, размеры духового шкафа можно хранить в виде такого параметра и его значения: размеры: 120х80х100, а можно расписывать, каждый размер в свой параметр или одинаковые по смыслу параметры, могут называться по-разному. Поэтому даже очень внимательный и натренированный менеджер не в состоянии скопировать все параметры, больше чем к 30-40 товарам за день. Причем такие замечательные кнопки, как копировать набор всех значений параметров от одного товара к другому или применить это значение параметра ко всем товарам в этой категории, кардинально эту проблему не решают.
Здесь действительно пришлось «изобретать велосипед». Самое первое, что пришло в голову, это написать парсер, который будет автоматически тянуть наборы параметров и их значений с сайта источника и предлагать менеджеру выбрать соответствие параметра с сайта источника к параметру из нашей базы, но я решил на этом не останавливаться. Почему бы, после того, как менеджер выбрал соответствие, не запоминать его и в следующий раз, когда наткнемся на такой же параметр автоматически предложить это соответствие? Так как большинство товаров однотипные, и, к примеру, могут быть 10 товаров отличающихся друг от друга только 3-4 параметрами, то после проставления соответствий у двух-трех товаров, для остальных останется только зрительно проверить эти соответствия и сразу нажать кнопку сохранить. В итоге получился вполне милый парсер технических характеристик. При помощи этой штуки один менеджер теперь обрабатывает по 100-120 товаров за день, что примерно в 3-4 раза больше изначальных показателей.
Парсинг параметров
При разработке этого парсера я сразу разделил логику парсера и логику интерфейса, и теперь для добавления нового сайта источника достаточно описать где и что лежит у нового источника. Так же были добавлены всякие приятные “плюшки”, типо преобразования сантиметров в миллиметры (на сайте для которого я все это делал все размеры принято хранить в миллиметрах) и др.
После всех вышеизложенных ухищрений общее время на добавления одного товара сократилось с 15-20 минут до 3-5 минут. Я же на реализацию и внедрение потратил около 4 дней. С учетом того, что речь идет о добавлениии 2000-3000 товаров, выгода налицо!