- Регистрация
- 16.03.2016
- Сообщения
- 1 437
- Благодарностей
- 1 029
- Баллы
- 113
Мое время – мои деньги!
Как я автоматизировал работу своих интернет-магазинов
Реальная история про то, как появление в ZP всего лишь одного кубика восемь лет назад изменило мою жизнь ))
Как я автоматизировал работу своих интернет-магазинов
Реальная история про то, как появление в ZP всего лишь одного кубика восемь лет назад изменило мою жизнь ))
Признаюсь, у меня профдеформация: «чукча – писатель» (не фигура речи, практически дословно, профессия – почти "писатель"). Поэтому будет много текста )) Для кого-то – очень много текста… Думал что-то поскрывать под спойлеры, но не стал. У меня не было цели и задачи кого-то чему-то научить (тем более, завсегдатаев Зеннолаба, они сами кого хочешь и намного профессиональнее научат, да и других статей в конкурсе достаточно), здесь вообще больше про подход новичка, а не техническую реализацию. Ну и здесь мне было важно показать, как мной решалась проблема именно в тот момент и с учетом минимальных знаний, которые были тогда в моей голове: как я утыкался в стену, искал решения, придумывал обходные и не всегда очевидные пути, проходил дальше и шаг за шагом двигался к тому, ради чего все это начинал )) В решении, по сути, элементарной для меня нынешнего задачи )) Понятно, что сейчас это все сделалось бы намного быстрее, проще, логичнее. Тогда мне было важно просто сделать!
Ну и это мой первый опыт участия в конкурсах (да, я "дебютантка", для нас даже номинацию ввели
), несмотря на 8 лет регистрации, так что, скажем так, это просто "проба пера" )) Начать решил с "мемуаров". Да и просто захотелось, нескрою, немного вернуть себя во времена, когда небо было голубее, трава - зеленее, ночи – бессоннее, а ИИ – намного глупее. В конце концов, конкурс про "кейсы автоматизации" – а это тоже кейс, просто руками новичка.Весь этот опус, скорее, для тех, кто только присматривается к ZennoPoster и задается вопросом: «Зачем он мне нужен?» Чтобы заработать деньги – это понятно, в конкурсах сотни историй о том, как это сделать «легко и просто, причем, без регистрации и смс». У меня – не про это. У меня про то, как ZennoPoster стал сперва палочкой-выручалочкой, а затем и основным инструментом автоматизации работы нескольких интернет-магазинов, а также взаимодействия с курьерками, маркетплейсами, различными сервисами, средством для аналитики и прогнозирования, и вообще… Почти каждое утро начинается с вопроса «Что бы мне еще такое автоматизировать?» ))
2013 год. Я уезжаю на полгода на последний в своей жизни выездной проект. Жена беременна, скоро появится ребенок, я понимаю, что работа, которая приносит прилично денег, мне больше не подходит: я не хочу, чтобы у моего ребенка «папа всегда был в командировках». Да, я и так, по сути, фрилансер со стажем, но уезжать куда-то уже не готов.
Возвращаясь с проекта, я решил открыть свой интернет-магазин. Навыков «поковыряться в коде» для «собрать магазин на движке» более чем достаточно. Буквально за месяц разбираюсь со всем с нуля, собираю магазин на Opencart (выбор движка оказался простым: поставил на хостинг Magento, Prestashop, Opencart, по скорости работы из коробки и удобству/логичности для себя выбор пал на последний), находим со знакомым несколько поставщиком, заливаем товары (сидим по ночам дома, все делаем ручками), запускаемся…
Нам повезло с двумя вещами. Во-первых, суммарно на двоих у нас хватило навыков, чтобы весь процесс мы могли обрабатывать сами, без необходимости кому-то за что-то платить (водителям, администраторам, кодерам, менеджерам). Т.е., мы, по сути, не могли уйти в минус из-за тех же зарплат сотрудникам, ели заказов нет. Просто не получали доход сами, инвестировали время. Второй и, думаю, самый важный момент: у нас обоих были дополнительные источники дохода, которые позволили нам спокойно экспериментировать и дожидаться, когда оно «во что-то вырастет» ))) Да, это не был бизнес-проект из серии «быстро срубить бабла», скорее, было на попробовать/поучиться и, глядишь, на перспективу будет приносить определенный доход. Впервые, кажется, по 5к рублей мы поделили спустя полгода после запуска )) Не столько нужны были деньги, сколько для сигнала, мол, оно принесло хоть какие-то деньги. Остальное все «реинвестировали»: офис, упаковка, тесты с рекламой, докупка всяких модулей/решений для сайта и т.д. В общем, не гнались за деньгами. Сумму покрупнее попилили где-то через год, и только где-то через полтора года проект позволил, скажем так, ежемесячно получать деньги, которые были сопоставимы с не заоблачной, но весьма неплохо зарплатой. При отсутствии начальников, бессмысленной траты времени на отчеты и совещания и прочего. Да, работа, но, во-первых, работа все-таки на себя, ну и понимание, что твое рабочее место – оно, в целом, тоже имеет определенную капитализацию и, в случае чего, может быть продано )) Забегу немного вперед: пока не продано, но до сих пор работает и приносит деньги )) Да, схемы/процессы постоянно немного трансформируются, появились и маркетплейсы, и магазин уже не один, а десяток, но в целом – оно живет и приносит деньги (но да, это не единственное, что приносит деньги). Без продажи кейсов в инстаграме из серии «научу быстро зарабатывать без вложений», но работает…
Мы росли естественным путем, не гонясь за деньгами: расширяли ассортимент, постоянно допиливали сайт, тестировали разные схемы получения трафика и воронки непосредственно на сайте. В целом, все было нормально. Заказов было не так много, времени хватало на все, поскольку вся работа почти делалась руками.
Но наступило лето, а потом и осень 2014 года. Доллар попер вверх, перспективы по многим направлениям в жизни стали весьма туманными. Я параллельно успеваю вписаться в ипотеку (на еще адекватных на тот момент ставках и ценах), но кредит оформляли на маму (я же фрилансер, мне банку сложно объяснить источники дохода), а ей из-за возраста дают только на 9 лет (что сказывается на сумме ежемесячного платежа, которая на тот момент мне казалась немного высоковата).
Постоянный рост курса доллара привел к тому, что поставщики меняли цены несколько раз в день. Ассортимент на тот момент у нас был уже, кажется, в районе десятка тысяч товаров (для успокоения – мы забирали товар у поставщика непосредственно после заказа, т.е., себе ничего не закупали, изначально пошли по этому пути). Все свободное время мы правили цены )))
Это был первый этап, когда пришло осознание – нужна автоматизация. Еще не было понимания, какая именно и каким способом, но что-то надо было делать. Плюс мы зависели от остатков на складах поставщиков, это тоже требовало решения. Благо, попутного. Поставили на опенкарт модуль импорта/экспорта. Кажется, на фрилансе друг нашел человека, который написал ему «обработчик прайсов/остатков» для Excel (да, он работает до сих пор и до сих пор через него мы правим цены на сайтах после очередного повышения). Где-то прайсы присылали, где-то они лежали на сайтах, где-то файлов не было, но на сайте поставщика можно было посмотреть наличие. Пришлось разбираться с парсингами. Так у меня появился Content Downloader (сейчас, кажется, уже пяток пожизненных лицензий), который на тот момент решил 80% наших проблем. В итоге вместо 6 часов, условно, ручных правок у нас стало в день уходить 30-60 минут на обработку всех поставщиков (спарсить, обработать, импортировать).
Так прошел весь 2015-й год. Мне на тот момент казалось, что у меня все автоматизировано )))
Первую лицензию ZennoPoster я купил в начале 2016 года благодаря Складчику (мне кажется, это была чуть ли не единственная оптовая продажа Зенки на Складчике). Я люблю инвестировать в инструменты, поэтому сразу прикупил Pro )))
Постепенно изучал функционал, что-то пытался придумывать, а потом в процессе изучения выяснил, что буквально недавно (в январе 2016 года) в версии 5.9.8.0 появилось следующее:
Узнал я об этом не сразу, курс @stmult был записан до этого, но затем он выложил отдельное видео о появившихся новых экшенах (а появилось тогда много нового и интересного, насколько помню). Картина в моей голове в одно мгновение сложилась в единое целое.
Это была не просто «любовь с первого взгляда», это оказался в прямом смысле поворотный момент в моей жизни )))
К этому моменту в моем бэкграунде было следующее:
- Понимание структуры БД у Опенкарта
- Умение парсить данные и приводить их к удобному мне виду
- Общее понимание логики работы ZennoPoster (еще раз, отдельное спасибо @stmult за базу)
Возможность работать напрямую позволяла не только автоматизировать процесс полностью, но и контролировать его на каждом этапе (спасибо «логике if» (с) /кто понял «пасхалку», тому отдельный респект/). Проверил несколько простых запросов напрямую в магазин через кубик – все работало.
И закипела работа. Задач было несколько, надо было их разбить на блоки и каждый сделать отдельно.
Для начала нужно было иметь остатки от всех поставщиков в едином формате (для удобства). Кто-то ежедневно присылал файл на почту, кто-то выкладывал на сайт, кто-то ничего никуда не выкладывал, но данные можно было брать с сайта, кто-то выкладывал в облако. Под каждый случай я писал шаблон, который добывал остатки и делал из них одинаковый файл. Причем, действительно, каждый раз приходилось обрабатывать «непростую» логику поставщика )) Где-то файлик забивался руками менеджеров и приходилось исправлять многочисленные косяки (от лишних пробелов до замен русских букв на латинские или наоборот). Где-то надо было добавлять разархивирование скачанного файла. Где-то экселевский файл просто лежал, но на нем стоял пароль, который надо было научиться снимать. Где-то остатки присылались и на почту и надо было забирать оттуда (через кубик работы с почтой не получилось, я так и не нашел способа получать приложенный файл), поэтому пришлось работать через вебморду (и методом проб и ошибок остановился на почте от Яндекса, в ней оказалось проще забирать вложения прямо со страницы со списком писем). Даже простое скачивание остатков из облака было не всегда простым, поскольку поставщик выкладывал туда кучу файлов и нужно было уметь найти единственно верный.
Напомню, я только начал работать с ZennoPoster, поэтому каждое решение – это было отдельный квест. ChatGTP тогда еще не было, поэтому поиск ответов не всегда был тривиален. Но здесь огромное спасибо нашему сообществу: решения находились на форуме (в старых статьях из конкурсов, в ответах на чужие вопросы, в ответах на мои вопросы). Именно решение важных для меня практических для меня задач дало для меня серьезный толчок в плане понимания, как можно использовать ZennoPoster.
В общем, спустя какое-то время у меня была наложена система, по нужному под каждого поставщика расписанию собирающая остатки, приводящая все это к единому формату и складывающая «в одну папочку».
Можно было приступать к тому, ради чего это вообще затевалось )) Тем более, что к этому моменту я запустил еще два интернет магазина, поэтому даже полуручная работа стала снова отнимать больше времени, чем хотелось…
Структура БД Opencart проста/линейна до невозможности. Даже спустя много лет для стабильной работы не потребовались никакие JOIN’ы. Что важно было на тот момент – в карточках товара уже были поля, которые никак не задействовались.
В качестве поля для артикула я решил использовать MPN (очевиднее казалось SKU, но его я уже использовал для своих внутренних артикулов для сайта, чтобы было проще искать, когда звонят и называют артикул – они были исключительно числовые).
Запрос очевиден:
SQL:
UPDATE `oc_product` SET `quantity`={-Variable.product_quantity-} WHERE `mpn` = "{-Variable.product_sku-}";Т.е, мы взяли файл с остатками, разобрали таблицу, из каждой строки взяли артикул и количество, сформировали строку, добавили в список, потом все это залили в базу.
Товаров на сайте было достаточно много, файл с остатками, на которых тестировал, тоже был большой (а грузились именно все товары из остатков, даже если их не было на сайте). Первый запуск решения, которое должно было решить все мои проблемы, меня разочаровал =(
Мне казалось, что все отработает за доли секунды, а оно заливало остатки, кажется, несколько минут. Да, это все равно была полная автоматизация, но было ощущение, что должно работать «не так»…
Полез копать. Увидел, что в шаблоне был включен браузер, хотя он не использовался нигде в работе. Естественно, перевод шаблона в «безбраузерный» ускорил работу, но не настолько, насколько я этого ждал… Добавил тайминги с выводом в лог, чтобы можно было понять, в каком именно месте происходит задержка. Выяснилось, что тормозил именно процесс заливки в базу.
Мне кажется, я перелопатил весь интернет, чтобы понять причину (OpenAI на тот момент, мне думается, даже не существовали, так что, задавать свои дурацкие вопросы было особо некому)… Решение нашлось неожиданно и оказалось до банального очевидным (ну, очевидным для меня нынешнего, не тогдашнего, мне кажется, я тогда просто моим любимым, без шуток, «методом тыка» его нашел). ИНДЕКСЫ!!!
Поле MPN, по которому я заливал остатки, не было «проиндексировано». Добавил индексы (заодно и в другие столбцы добавил индекс, потому как по ним тоже потом пригодились выборки).
И шаблон, который до этого отрабатывал весь процесс за 2-3 минуты отработал буквально за пять секунд. Мне сперва показалось, что произошла ошибка, поскольку лог просто «просвистел». Запустил еще раз – то же самое. Проверил остатки на сайте – все было правильно.
Оно работало. Причем, это была первая реализация всего процесса, сделанная собственными руками. И она работала так, как я себе это представлял: быстро и, главное, полностью автоматически!
Я решил еще немного ускорить процесс, добавил заливку в базу частями (до этого, условно, у меня одним запросом уходило 3000 строк, я сделал заливку блоками – по 500 строк, что позволило выиграть еще секунду-другую, но больше делалось для того, чтобы меньше напрягать базу в процессе обновления).
В общем, я казался себе настоящим кулхацкером, богом автоматизации и вообще красавчегом…
Утром следующего же дня пришлось несколько переосмыслить свое место во вселенной автоматизаторов: упал заказ на товар, которого не было у поставщика, но он был на сайте. При этом в логе не было никаких ошибок, все отработало штатно.
Было понимание, что я что-то упустил, но не было понимания – где именно… Пришлось учиться «сегментировать» процесс, постоянно сужая область для поиска проблемы. В шаблон добавлялись логи, добавлялись записи в файлы списков запросов в БД, ответов от БД, если что-то шло не так. Спустя какое-то время я понял, что данного товара в файле поставщика вообще не было (он просто не выкладывал в остатки отсутствующие товары).
Т.е., все остатки накатились верно, но не затронулись товары, которых нет в наличии. И если они были до этого, они так и оставались в наличии с прежними остатками.
Лично для меня всегда было не так важно, насколько «правильно/грамотно» оно реализовано, а было важно, чтобы работало.
В моей юности в середине 90-х была такая игрушка «The Incredible Machine» (386-й комп с Windows 3.11 пришел на смену стоявшего до этого EC-1841, да, должен признаться, мне повезло, ведь у меня 90-е прошли в постоянных экспериментах с настройками autoexec.bat и config.sys (олдфаги поймут
), а не в том, что показывают в нашумевшем недавно сериале), в которой тебе давались разные предметы и задания из серии «такой-то шарик должен оказаться в таком-то месте». Подразумевалось, что для выполнения задачи нужно использовать почти все предметы, но я почти всегда шел другим путем – я просто решал задачу по-своему. «Шарик в лузе» - задание выполнено, чем – вас не волнует, даже если я делал это двумя предметами вместо двадцати )) Где надо было прокатиться – я просто перепрыгивал, экономя время/предметы. Эта привычка со мной до сих пор ))Самым очевидным решением проблемы с отсутствующими остатками было получить из базы список всех товаров, тем товарам, которые есть в остатках, проставить нужное количество, а оставшиеся обнулить. Было решаемо, но на тот момент я бы зарылся в этих сравнениях и сопоставлениях. Я пошел иным путем, исходя из имеющихся на тот момент инструментов (точнее – знаний).
Я просто сперва обнулял остатки всем товарам, а затем уже поверх накатывал остатки из файла поставщика.
Всего один запрос решал всю проблему:
SQL:
UPDATE `oc_product` SET `quantity`=0 WHERE 1;Мне не пришлось даже ждать следующего дня, чтобы понять ошибку, звонок в магазин раздался буквально через пять минут. Клиентка сетовала, что она долго выбирала товары, их было очень много в наличии, и пока она оформляла заказ товар «закончился». Я проверил файл остатков поставщика, там было еще много. Интереснее было другое – я этого поставщика вообще не трогал, разбирался с другим. И тут я в очередной раз «все понял»… В общем, думай медленно – решай быстро, а я поторопился не там.
Запрос на обнуление остатков обнулял ВСЕ товары в магазине, а накатывались после этого остатки только по конкретному поставщику. Т.е. схема по своей идее была правильная, но она не работала. Пошел думать (раньше бы пошел покурить, но к тому моменту уже бросил).
Первым очевидным вариантом был сбор всех остатков со всех поставщиков, сведение в единый файл остатков уже после этого обновление на сайте. Было вполне реализуемо, но не имело логики: все поставщики выдавали остатки в разное время (кто-то хоть каждый час, кто-то раз в сутки, кто-то – раз в несколько дней). Т.е., по какому-то поставщику всегда будет уже неактуальная информация.
Начал думать, как реализовать обновления по каждому конкретному поставщику, не затрагивая остальных. Снова заглянул в базу данных, решение оказалось на поверхности.
Как уже писал выше, в Opencart у товара есть много разных полей, которые, как правило, не используются. MPN я использовал для артикула, были еще location, ean, jan, isbn (в принципе, учитывая, что работаем мы напрямую с базой, и самому движку и сайту даже нет необходимости с этими данными работать, любую нужную «колонку» мы можем просто создать). Для поставщика я использовал поле LOCATION (уже на опыте сразу проставил ему индекс). В итоге товарам одного поставщика я присвоил буквенное обозначение поставщика.
В итоге запрос обнуления у меня стал выглядеть так:
SQL:
UPDATE `oc_product` SET `quantity`=0 WHERE `location` = "{-Variable.location_value-}";
SQL:
UPDATE `oc_product` SET `quantity`={-Variable.product_quantity-} WHERE `mpn` = "{-Variable.product_sku-}" AND `location` = "{-Variable.location_value-}";При этом, пока тестировал, поймал себя на мысли, что использование дополнительного поля LOCATION позволяло мне «отцеплять» товары от обновления. Например, у поставщика товар закончился, но он из каких-нибудь возвратов есть у нас в офисе. Я просто менял обозначение поставщика у данного товара в поле LOCATION на что-нибудь другое (например, «в офисе»), ставил нужное мне количество, и остатки по данному товару больше не трогались. Или у поставщика пересорт по товару, в остатках есть, а по факту – его нет (причем, до инвентаризации он будет числиться в остатках), тоже оцепил, вписав в LOCATION «пересорт» и обнулив остатки. Нужно вернуть, вписал обратно буквенное обозначение поставщика – все снова обновляется.
Несмотря на то, что большинство проблем и ошибок в логике и реализации выяснялись уже в процессе работы (что, в общем, нормально), какие-то вещи удалось предусмотреть наперед. Так, в частности, я на этапе продумывания и реализации логики обезопасил себя от случаев, когда, допустим, в файле с остатками что-то не так, в процессе заливки их произошла ошибка, а остатки уже обнулились. В итоге у меня перед заливкой остатков создается блок «бэкапа» - я выгружаю из базы все товары (артикул + количество), формирую из него запросы такие же, и в случае, если на этапе новых остатков вылетает ошибка, гружу обратно те остатки, которые были до этого. Несколько раз меня эта предусмотрительность выручала ))
Плюс я добавил себе отстукивание в телегу об обновлении, причем, я проверяю количество товаров «в наличии» до обновления и после обновления и они пишутся в уведомлении. Это позволяет успеть заметить, когда что-то с остатками не так. Иногда поставщик меняет формат выгрузки и у меня были случаи, допустим, когда цена попадает в поле количество. А этот поставщик в остатки выгружает даже товары, которых нет в наличии (с 0 в остатках). Но цена есть у всех товаров, соответственно, все товары «стали» в наличии. Уведомление вида «Магазин Рога и Копыта обновили. Товаров в наличии было: 1328, стало: 3898» как бы намекает, что где-то что-то не так (слишком большие изменения) и надо проверить. Бывали и случаи, когда всем товарам ставился 0 (поставщик косячил в остатках или где-то менялся формат выгрузки), уведомление тоже позволяет это заметить, поскольку будет «Магазин Рога и Копыта обновили. Товаров в наличии было: 1328, стало: 0».
В общем, такие «триггеры» для ручной проверки )) Помогают чувствовать, что процесс идет ))
Единственное, что я до сих пор так и не реализовал (по факту – просто так и не было необходимости, особенность товара, которым торгую я) – это обновление остатков у опций (допустим, если товар имеет разные размеры и это не отдельные карточки, а именно «опция» у одного товара).
Суть в том, что именно с опциями у Opencart все немного не так линейно, как с самими товарами. По сути, все варианты всех товаров находятся в отдельно таблице, и связаны с товарами через ID. И у опций в движке нет как такового артикула, что несколько усложняет прямое взаимодействие ))
Вариантов решения несколько, кому надо, просто выберите свой:
- Каждый вариант/размер – это отдельная карточка товара, которую просто обновляем по своему артикулу (в общем, мой путь).
- Есть модули, которые делают опциями конкретный товар. Т.е., по сути, то же самое, что и в первом варианте, обновляем сами товары по артикулам, но они все выводятся в одной карточке.
- Есть модули, которые добавляют опциям поле артикула, тогда просто меняем вид запроса и льем остатки непосредственно в опции, где надо (но тут внимательно, важно, чтобы и другие инструменты импорта/экспорта поддерживали эти решения и не затирали данные при массовом обновлении, например, описаний товаров – скорее всего, старые записи с опциями просто удалятся, создадутся новые с новыми id без дополнительных данных). Просто изучайте инструменты, с которыми работаете, особенно, насколько они правильно работают друг с другом.
- Разобраться с JOIN и лить остатки по связке товар+вариант, но тогда нужна будет промежуточная «база», где будет привязка конкретного артикула у поставщика к первоначальному артикулу карточки на сайте и id опции )) Квест прикольный (что-то подобное реализовывал для WB, у которого обновление остатков идет не по нашему артикулу, а по артикулу WB, т.е., напрямую из файла остатков лить не получается, нужна «прокладка»), кому захочется, покопается.
- Найти свое решение! Которое будет работать у тебя, даже если остальным кажется не самым правильным. Ломай стереотипы ))
Шутки – шутками, но шаблоны, которые были написаны почти восемь лет назад, работают до сих пор. Да, какие-то изменения были внесены, но чисто косметические (например, добавилось внесение даты изменения остатков в поле UPC или по одному поставщику, у которого два склада, информация по каждому отдельно вносится в поля JAN и EAN). Основа – не менялась. И вряд ли будет, потому как меня она полностью устраивает (почему бы не устраивать, если работает как часы уже много лет?). Причем, даже не столько по тому, как это сделано, а именно по логике работы.
Да, данный способ реализации неидеален, я сам это прекрасно знаю. Специалисты по мускулу найдут более элегантные и, уверен. правильные формы запросов (грузить 500 разных запросов одним блоком выглядит действительно не совсем «логичным»). Спецы по Opencart приведут в пример пяток модулей для автоматической обработки прайсов, которые решают те же задачи прямо с сервера.
Знаете, что я скажу и первым, и вторым? Мне все равно, что вы думаете ))) Это мое решение, на тот момент оно прямо спасло не только меня и мое время, но и, в общем, бизнес, пусть и на стадии роста, потому как в ручном режиме я бы долго не протянул и забросил бы )) Но мы же тут про ZennoPoster, поэтому я просто описал лично свой «путь автоматизатора» с использованием того инструмента, который был в моих руках. Более того, это было время, когда ZennoPoster вообще казался шайтан-машиной, а опыта было - с гулькин нос, ведь даже банальная обработка таблицы казалась верхом автоматизации. И я просто решал свою проблему, не задумываясь над тем, как это решение выглядит. В общем, с самого начала у меня была какая-то тактика. И я ее придерживался.
Можно ли было все сделать иначе и правильнее? Несомненно! У меня в голове, на бумажках, в файлах, наверное, сотни идей того, как что-то сделать сразу идеально )) И, правильно, оно все так и осталось в голове и на бумажках, даже что-то в начатых шаблонах. Мало из этого доведено до конца, пусть даже «корявого и неправильного»… Как говорится, к черту все, берись и делай! Конечно, если нужно ехать, а не шашечки.
Здесь скорее история про то, что ZennoPoster – это отличный инструмент, который может быстро решить собственную проблему в работе. Для меня в конкретном примере стало взаимодействие с БД, у кого-то будет обработка большого количества таблиц с данными (у меня для себя, без шуток, сотня шаблонов под просто работу с таблицами написана) или взаимодействия с API (я ZennoPoster'ом отслеживал косяки курьерок, чтобы вовремя пинать по выплатам, доставкам и т.п.), автоматизации работы с маркетплейсами (у меня и остатки обновляются, и цены отслеживаются и пересчитываются, и заказы отслеживаются, и массивы анализируются). Каждому свое ))
Уверен, большинство до сих пор рассматривает ZennoPoster как инструмент прямого зарабатывания. Но все же знают, что зарабатывает идея или схема, а ZennoPoster просто может позволить ее проверить/автоматизировать/реализовать. Т.е., все это будет работать и без ZennoPoster, но лучше с ним ))
Мне кажется, многие новички, кто слышал про ZennoPoster, даже видел его, не до конца понимают, зачем его покупать. Я, признаюсь, был таким же (точнее, я его брал под конкретное решение/шаблон, который даже не использовал, кажется). Кто-то идет в конкурсные статьи и видит «истории успеха», покупает ZennoPoster и думает, что сейчас все сделает и срубит кучу бабла ))) В общем, вероятность такого успеха каждый может оценить сам.
Я попытался описать другой вариант «зачем может пригодиться ZennoPoster». У меня была конкретная «боль», мне надо было ее «закрыть». Я взял имеющийся инструмент, выстроил для себя логику (без этого, сами понимаете, ничего не будет), разбил на этапы и пошел писать решение под каждый этап, параллельно изучая, как это делать (что делать – я уже знал, это очень важно, потому как если ты не знаешь не только как делать, но и что делать – вряд ли удастся добиться результата).
Что-то запускается по расписанию, что-то запускается автоматом в конце работы других шаблонов, многое – запускается руками из отдельной админки, которую собрал для себя на простом XCRUD и через которую "свел" абсолютно всю работу с маркетплейсами.
Да, понятно, что все хотят деньги )) Просто для меня мое время – это тоже деньги. С другой стороны, опыт, методы и даже инструменты, которые я получил/проверил/написал за последние годы позволили мне автоматизировать очень многие процессы не только для себя, но и для кого-то еще. Имея, по сути, пассивный доход со стоящего в углу комнаты сервера, обслуживающего, в том числе, и чужие магазины, маркетплейсы и так далее…
Так что, скринов и пруфов не будет, придется верить на слово ))
Для тех, кому лень читать (прекрасно всех понимаю, сам бы не осилил, писать - проще
), приложил сам шаблон, который выполняет данную задачу. Шаблон специально полностью на кубиках, нет даже никаких сниппетов, чтобы, как говорится, сохранить аутентичность. Ну и показать тем, кто до этого никогда не брал в руки ZennoPoster, что в нем нет ничего сложного, это весьма "user friendly" инструмент, с которым будет совершенно несложно разобраться. Особенно, если есть задача, которую надо решить. И хочется решить самому.Тем кто ищет "крутые технические решения", сэкономлю кучу времени - их здесь нет )) Но, благо, статей много, как правило, большинство из них прямо действительно многому могут научить!
Плюс немного разъяснил логику работы и показал, как что работает, в видео. Сразу извиняюсь, решился записывать видео в последний момент, и оказалось, что микрофон на домашней гарнитуре немного фонит. Новый покупать уже не было времени, поэтому, как смог, подчистил шумы, но неидеально ))
Так что, вернемся к тому, с чего начинал: "Прошу понять и простить..."
Последнее редактирование модератором:
